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.