Thursday, December 6, 2007

Wednesday, November 14, 2007

Microsoft Certified Architect - Is it worth it?

Since I pass my MCA certification (solution architect) last year, I keep getting many questions from peers about MCA. Given the cost and efforts involved in getting certified, many wonder if it is worth getting certified.
I think, it definitely is. Here is why -
1) First, it is pretty hard to get through. That is what makes in more valuable. It is recognized highly in the industry. You may be surprise to know how many CIOs are aware of this certification. I am personally benefited from the MCA title at numerous occasions.
2) It is not only the Technology certification. It stresses equally on many other aspects such as Leadership, Communication, Organizational Dynamics, Strategy, and Processes along with technology (breadth and depth). You will not be able to get through if you are too operational OR too hands-off.
(Contrary to popular belief it is nothing to do with Microsoft technology. I presented case study based on J2EE technologies.)
3) It certifies the experience and not the knowledge alone. In the interview, all the questions are targeted for judging what you have done (rather than what you know). The questions are pretty deep. It is almost impossible to bluff in front of 4 experienced senior architects.
4) It is a great experience of going through the certification process - the mentoring, preparations and appearing in front of the board for interviews. You learn a lot in the process. You don't lose much even if you happen to fail.
5) Finally, though it is tough, if you have experience of architecting systems and if you put right efforts preparing your case studies and presentations, it is something achievable. It is definitely worth trying if you want to make career as an architect.

If you are not aware of Microsoft certification process, refer to -

I found a very interesting blog that describes the architecture process in a much lucid way -

I will be happy to assist if you are preparing for the certification.

Thursday, November 8, 2007

Bogged down with EA frameworks?

If you are one of those overwhelmed with enormity of the popular EA frameworks, take my word – don’t sweat it too much. It is enough to look at 6X6 table of Zachman framework and understand it completely. You don’t have to go for Zachman conferences (unless you want to get thoroughly entertained. He is a great speaker!)

Don’t get me wrong. I like these frameworks as they give you idealistic view of what all you should consider for your EA exercise. Use these frameworks as reference, but never take on ‘all encompassing’ exercise as prescribed by these frameworks. It will only end when you run out of money.
Take a step-by-step approach. I would like to refer to the disciplines mentioned by Scott Ambler in his Enterprise Unified Process
Define what is important for your organization and only concentrate on those disciplines.

Typically, the EA exercise can be divided into 2 parts –
1) Define Enterprise Architecture and IT strategy roadmap
Here you concentrate on following disciplines –
· Enterprise Business Modeling ( Current state & desired state)
· Portfolio Management
· Enterprise Architecture ( Current state & desired state)
· Strategic Reuse
(Assuming that you have decent software development processes already in place. If not, you will have to include process definition discipline as well. )

Use these models to define the gaps / opportunities with your current IT and define the roadmap for implementation by dividing the work into manageable projects and also prioritize the work depending upon your budget and resource availability.

2) Implementation
Once you have identified smaller, manageable projects, apply the development and support disciplines (as defined in EUP) to each of this project and take it further.

I know, it is easier said than done. If you are doing it for the first time, make sure to have experienced resources on your side – especially those who have failed and learned.

Wednesday, November 7, 2007

Testing time for SOA

Recently, I had been invited in a meeting to assess the problems with the high profile ‘SOA’ project. The common business services, which are supposed to be reused across multiple applications, were not performing up to the mark. More than 80% of the problems were related to integration and the performance. The application development teams have already missed deadlines multiple times and some are threatening not to use common services, but instead build their own bridges to the legacy systems.

The common services have been ready for long time; however, the problems are discovered only at the time of integration with applications. This late discovery of issues has put many projects into jeopardy and people are cursing the day when they thought of implementing SOA.
Now, why this happened? Some of the problems could have been tackled at the architectural level, however, I felt, this could have been avoided if only somebody had planned testing at the service level. It is not sufficient just to buy a SOA testing tool. The SOA testing need much more attention and detailed planning.

Here are some of the considerations for your SOA test planning -

1) Context orientation – It is not just enough to send an input to the web service and test whether the outcome is received and compare variables. It is important to know the context in which the service will be called and what the output variables those are more likely to be used. There should be a separate test case for each possible scenario in which the service will be called. Many a times, the output payloads are not fully populated and testers are often told that these variables are not meant to be populated. It would be good idea to verify the assumption against the context.

2) Reduce complexity of testing – The SOA testing is complicated enough. It is not easy to test without a user interface. Typically, it is very challenging to generate test data in the form of input XML. Sometimes, the output XMLs run into MBs and it is impossible to compare them with the ‘expected’ result and find out problems with them. Invest into tools to simplify the invocation of the service and output comparisons. Try to use more user friendly interface such as MS Excel to create test cases and test data, and build a framework around it to take these excels as an input for SOA testing tool.

Remember- If it is not simple to do, it will not happen.

3) Test the service choreography – Most of the times the services are called sequentially from the controllers, however, at the time of testing, those are tested stand-alone with certain assumptions about input and output. It would be good to identify the sequence in which the services would be called and connect their outputs/inputs and simulate the real-life scenarios. Invest into building the tool that can help building up such choreography for testing.