That was Suite! Not really

This morning I was asked to go to an all morning presentation by Oracle. The presentation explained Oracle's vision with its products and its newly acquired company's, BEA, products. The core presentation was given by Thomas Kurian Senior Vice President for Oracle's Fusion Middleware. The presentation was insightful and it showed that Oracle has a defined and definite vision. I, however, being a skeptic will accept Oracle's vision when I see results. Other than enjoying Oracle's flagship product which is their relational database product, I have not been impressed with Oracle products. That being said, I do believe that Oracle is going to keep the Weblogic Application Server as well as other quality products. It is going to be interesting how other vendors will compete with Oracle in the Application and Middleware space.

Like Oracle, IBM has been buying strategic companies like Oracle but they NOT are buying monster size companies like BEA or PeopleSoft. IBM products work well however they are very expensive and their support is expensive as well. Oracle is following the Sun and RedHat approach which is to follow the Open Source paradigm. Thomas Kurian stated that Oracle is going to streamline the Weblogic IDE,which is based on Eclipse framework, make it open source. It will be interesting where Oracle Fusion Middleware will be in the next two to five years. During the presentation, Thomas Kurian talked about the Weblogic Suite, SOA Suite, BPM Suite and every other Suite possible. So in closing I say, "That's suite!" Actually I say this Larry Ellison, show me good software and I will say, "Suite software". If the software is not good then I will call the Oracle Fusion Middleware, law-suit software and not suite software.

Zapped

Last week, I was in a ZapThink Service Oriented Architecture (SOA) Bootcamp. It was a descent class since they derive their material from actual SOA implementations in large corporations. They presented high level principals and "gotchas" but I felt it lacked something but I cannot tell what. I thought the ITIL v3 Foundations course was more intense and it actually presented some excellent concepts. I highly recommend taking ITIL v3 Foundations course and the ZapThink bootcamp does a good job of re-enforcing overall same concepts which are:

• How does IT solve a business problem? This is key since vendors and developers tend to buy the tool or solution and then retrofit it to a business problem. I have been involved in couple of projects which spelled D-O-O-M-E-D after they were cancelled.
• Capture Business Processes - This is an other key since requirements are derived by analysts which inturn are passed down to the architects and engineers. Architects and Engineers design solutions to the requirements. If they had an insight into the business processes, the solutions could be better and cheaper.
• Business Agility - Flexible IT systems provide businesses more flexibility to be agile. Services support this paradigm however defined Configuration Management processes are key as well.
• Architecture - Enteprise, Data, Process, and Technical Architectures are key since they provide a defined approach in designing a system or an enterprise. No more Ad-hoc development projects. As a developer and an as an architect, this is key since developers love to know their constraints. We, as developers, have been burnt by poorly written code or no documentation.

Overall good IT architecture with SOA or no SOA, involves alot of common sense, a business understanding and knowing your constraints. Ideas are great but we all have to be realistic.

Technology Injection is bad!

You must of heard of Anti-patterns or practices which cause more problems in any Information Technology. Well here is one that I see in my current employment and I call it Technology Injection is bad. At my current employer, an average software development project has a duration of two to five years. The common problem with this approach is that new technologies are introduced or injected in the middle of the project cycle to address certain requirements. Is this a good approach? No! Since the new technologies are not researched well and they usually cause more headache since it also introduces new infrastructure, new skill sets associated with the technology, and it has a lasting impact on the project and eventually on the system.

Then the question comes up, "How do we address the problem of Technology Injection?"

The answer is that the system has be well architected which promotes loose coupling, well defined functional requirements, and not deviating from non-functional capabilities. Each architecture should be flexible enough for change but change would be done in a phased approach. If the architecture is not flexible then be sure to have those big yellow stickers which say in menacing black print, "LEGACY SYSTEM", since you might need to use them in five to six years. Like any IT approach, research and development (R&D) and thorough technology analysis need to be done to identify which technologies can be safely injected into the system.

IT Architecture = Communications

For the last six months or so, I have been working for the US Government as a Services Oriented Architecture (SOA) Technical Lead. Eventhough that is my functional title, I act more as a Information Technology (IT) architect. It is my first job where I am an IT architect. At my previous job I was a part-time XML data architect where I did alot of data modeling, data analysis and then defend why I modeled certain data structures a certain way. When I was not a XML data architect, I was a JEE developer. Eventhough developers aspire to be an architect because they can get to design the systems and leave the grunt work to other developers, this may not be true when the developer becomes an architect.

Couple of summers ago, I took a class to become a Java Enterprise Architect and it is there I learnt that an architect doesn't have a set role. As a developer or a project manager, your roles are pretty much defined but an architect's role is ambigous. In the class, I was taught that one of primary responsibilities of an architect is to see his system or project succeed. In some projects, he can be coding and developing reference architectures and in other projects, he is basically working with the project manager in refining requirements. After being an IT architect for the last six months, I have to say that the instructor was absolutely correct. An architect's role is ambigious to a project but every project must have an architect. An architect is a rare breed because:

1. he understands what is being built and why it is being built
   
2. he can look at code and have code level discussions about the software code.
3. he understands the business problem and why the system is a value to the customer
4. he can work with business analysts in refining requirements or make them more abstract which might give the development team more flexibility
5. he can sit with the project manager and hash out a realistic Work Breakdown Structure (WBS)
6. he can recommend modifications to the project scope if the project is running behind schedule
7. he doesn't need to be the best programmer in the team
8. he doesn't need to design the system but rather review them
9. he doesn't need to write a test plan but he can evaluate it
10. he doesn't need to be a guy. Women can be architects too.

And the biggest trait an architect should have is that he or she should be able to

COMMUNICATE

with various stakeholders and he or she should be able to discuss the system in technical, non-technical, and business terms. Architects should be willing to exchange ideas with other architects and they should humble enough to accepts mistakes if they made them.

The role of an IT architecture will expand as more businesses go into collaborative modes of information exchange since they need to be aware of standards and they should understand the newer technologies. So for all aspiring programmers in the world, it's time to shelf the pocket protector, clean the stacks of burnt or blank CDs, get a haircut, stop living on Red Bull and be more social. Try to interact with your teams and peers since a great idea is bad idea if you cannot communicate it and a better idea is to have your good idea validated with others.

A breath of fresh air. I think Spring is in the air

For the last month or so, I have been working with the Spring framework in developing Java web applications and let me tell you, "It's been a pleasant and a refreshing experiencing." Rod Johnson and gang have finally presented the Java development community with a framework that few people will complain about. My background is Java is that I have been working with it for about five years.

I remember the days when I was looking at Java classes which had HTML code buried in it. Talk about brittle and hard to read code. For example I have also looked at existing production code which consists one JSP which has eight thousand lines of heterogeneous code. When I say heterogeneous code, I mean that the JSP has HTML with scriptlets and JavaScript with scriptlets. The JSP had multiple views, JDBC calls and security. This JSP is still in production and it is used by our beloved government. When I first looked at that messy JSP, I asked the programmers and management who conceived the hideous JSP, why was the JSP created this way and how come no one refactored it. The answer was, "a few years ago, the code was based on a Sybase application server which had to be restarted whenever new code was added." Since JSP pages don't require the application server to be restarted, they went that route. After being on that project for a few months, I realized that the underlining problem which influenced the generation of the hideous JSP was poor project management which included poor schedules, not able to lower customer expectation, etc. etc. Nevertheless the project is slowing moving in the right direction. They have started using Spring, introduced a build process, and they actually sit down do design their application where they are introducing design pattern and promoting the ideas of code reuse, loose coupling, flexible code base, etc., etc.

If used properly, Spring promotes sound architectural practices which make sense. The concept of Inversion of Control (IoC) is very powerful and very simple. The ability to have properties editable from a XML file and then injecting them into classes rather than tracking them down to specific classes. I have seen where folks have created a Properties interface which had public static final variables with properties attached to them. This Properties interface would then get implemented with all the classes that needed it. I thought it was neat concept however it "irked" some of developers. A text properties file is the ideal way but sometimes it can be hard to find the appropriate property for a specific class without going through the class.

After buried many days, months and years in trying to decipher a COTS API which had very little documentation and it is not easily implementable. It is a truly a breath of fresh air to use an API like Spring which is built on solid principles and has incorporated ideas and work from previous frameworks like Struts. Kudos to Rod Johnson and gang!

"We won't mention their name..."

Three weeks ago, I went to Microsoft Technology Center in Reston Virginia. I was part of the Federal Aviation Authority (FAA) team which listened to Microsoft's overall strategy for the next three years, how Microsoft licenses were distributed across the FAA, and listened to their product experts regarding their new products and got a tour of their facility. It was a long session and some parts were interesting. I was amused when their product experts tried to toute the web 2.0 capabilities like creating wikis and blogs on the new Sharepoint product however I asked them if they did any research why they decided to include web 2.0 capabilities in their products. They had good reasons for the wikis since Wikis have proven to be an excellent source of knowledge via Collaborative means. However they didn't give me a good reason why they included blogging software, I realized that big companies like Microsoft provide the "new" capabilities eventhough they don't know if it will ever be used by their customers. I found that very interesting.

The other thing that I thought was hilarious was that their whole staff was taking stabs at Google. Eventhough Google and Microsoft product and services slightly overlap, I didn't think Microsoft and their employee would truly hate Google. For instance, one presentator talked about email services and used Hotmail as an example. Then he stated their products work well Yahoo and other email providers including "the other email provider who is still beta". Then he interjected, "how long are they going to have beta anyway" If you don't know what I am talking about then check out Google Mail or Gmail which is still beta.

Microsoft also stated they are rewriting their whole stack of products to introduce cloud computing since "the other company is planning to expand into this realm." Amazon.com currently provides this service and I know one person who uses their backup service and he is happy with them.

Anyway it looks like Bill Gates new tarket is "the company" that neither he or Microsoft will mention its name. "Hey Bill, 'Google' is not a buzzword but it is simply a company you are jealous of"

I til, you til, we all til for ITIL

For the last three days, I was taking the Information Technology Infrastructure Library (ITIL) version 3 Foundation for Service Management course. Eventhough the course was three days long with one hour lunch break, two working lunchs, nine breaks which lasted from anywhere ten to fifteen minutes, I enjoyed the course. I think ITIL has figured out how to address the Services Oriented Architecture (SOA) lifecycle. ITIL is not proscriptive but rather descriptive. This means that ITIL doesn't promote a methodology like Rational Unified Process (RUP) or Program Management Body of Knowledge (PMBOK) but rather it provides very high level principles which can be used in your organization's methodology. I was familiar with ITIL version 2 and I thought version 2 did a good job of addressing some of the high level processes but it did not tackle the concept of services well. Version 2 stated that there is a notion of service but it didn't talk about how we should address the concept of services. In my previous projects, we extracted the notion and we built our custom methodologies on top of the "concept of a service" however our methodologies were not aligned with other organizations since they had different methodologies on how they should address services. Version 3 addresses this issue since they go into specifics on what a service is, they did a good defining it and the whole ITIL lifecyle is built on Service Management. They also address concepts of Knowledge Management and how it fits in an enterprise. I have been dealing with SOA for the last 3 years and for SOA to be successful, a knowledge repository is essential.

I highly recommend this course for IT architects like system architects and data architects, project managers, program managers and folks who deal with licensing. In a world of high level concepts, buzz words and theortical exercises, I think ITIL offers the appropriate ingredients in implementing a sound SOA in any enterprise. One of the reasons why ITIL makes sense since they went to several successful enterprises, asked them how they managed their IT component, they then processed the information, analyzed the information and finally presented their work to the world as version 3. I believe ITIL followed their 7-step Improvement Process.

I also give kudos to my instructor David Moskowitz who did a great job in covering this material.