TOGAF Certification

I took the TOGAF Level 1 and Level 2 combined exam today.

I am happy to share with you that I have cleared it with a score of 73%

Level 1 – 75%

Level 2 – 70%

I thank Udayan Banerjee for his useful blog with TOGAF 9 sample questions, and Chris Eaton for his blog TOGAF 9 sample questions for Level 1 and Level 2 exams. They were useful.

If you are planning to take the exam in the near future, its worth while noting:

• To answer the questions for Level 1 exam, you get 60 mins. Use them in full. Level 2 starts immediately after you have submited Level 1 exam.
• Pay attention to TOGAF9 Confirmance Requirements. From exam point of view ,dont waste time in reading up stuff that are not required.
• Try and take couple of mock tests – For me, it helped me to identify some areas I was weak and I gave special attention to those topics.
• All are multiple choice, you can use elimination, where you are unable to spot the right answer

Cloud in a box

Cloud in a box.

Came accross this term recently in Steve Jones post. Now thats seriously funny.
The USP of cloud is that there is no box.
If I have to deal with a box to get my “cloud”, whats the point?

I have to admire the marketing guys who came up with this meet me in the middle sort of approach.

The uber cool guys are happy that its “cloud”
Tin huggers are happy coz its in a “box”

Every one wins. (Except ofcourse business)

Optimal Documentation for “Agile” projects

The idea behind “Agile” way of documenting is a significant change from the traditional documentation. In agile way of development and delivery, the emphasis is always on “Just Enough” documentation and “Just in Time” documentation.

The downside being, In the quest for rapid and shorter iterations and sprints, there is a chance that the Agile teams might produce little or no documentation at all!

As in all aspects of life, the key is to strike a balance. This might look like a cliché, on the contrary, if the teams are able to follow the following key steps, this is achievable.

1. Awareness – Awareness is a key ingredient for success. People (Business, Architecture, Design, Development, Testing, Support, Infrastructure) should be aware of each other’s requirements in terms of the information needed to perform their duties to the best of their abilities. This means that everyone accepts what is “too little” and what is “too much”.
2. Education – Since Agile is a new way of doing things, people involved must be educated, and sensitized to the new way of doing things.
3. Collaboration – A lot of review, rework, review cycle can be reduced by encouraging a collaborative environment and equip the team with appropriate tools to facilitate collaboration.

Some of the best practices I  would recommend are as follows.

Document Late: Critical documents like Service Specification, Service Design are done much closer to the actual development of the services. This allows the services to be evolving and can accommodate changes at much later stages.

Targeted Documentation: The documents produced are focused on the consumers of the documents.

Communication & Collaboration: With the combination of Agile and Off shoring, we have to be much more flexible in terms of being communicating and collaboration. Use WebEx sessions, white boards, Instant Messaging, Telephone, and most important of all a WIKI as  collaboration tools.

Automate where possible: I have seen majority of the content for Service Specification generated from WSDLs. WSDLs in themselves are nothing but a specification of the service interface.

Once a WIKI culture is firmly established, it becomes rich in content and an evolving information store. Generating documents like operation manuals from WIKI, can prove to be an effective way to provide information to the Support team.

The other automation ideas

Automatic Release Notes Generation – using the information from WIKI, and SVN to generate the Release notes.

Automated Review – of artifacts like WSDL, XSD, WIKI pages, against various compliance checks.

Service Dependency Documentation Dependencies between services and back ends are discovered and documented from WIKI, SVN and/or Enterprise Repository. No need to maintain a separate dependency matrix.

Requirements as tests: A single source for designers, developers and testers instead of requirements document, design traceability matrix, and test case document.

In Summary, A strong awareness, and clearly defined documentation requirements combined with a culture of collaboration, we can address the documentation concerns of stakeholders while following Agile delivery.

SOA from 10000 ft – Part 2

You can Find the Part 1 of this series Here

Evolution of Software Engineering Paradigms: (Contd…)

The standards such as COM, CORBA enabled the interoperability aspects between systems. However, until the standards such as XML, WSDL, SOAP came about the “true” interoperability was not achieved. We started seeing lots of Web Services bases solutions come about, and for the first time, we saw true interoperability between systems. Once the standards became more mature and active participation from vendors like IBM, Oracle, BEA just to name a few, a new (well, not so new) paradigm took shape in the form of SOA.

SOA – What it is and What it is not?

SOA, is the latest version of software engineering principles that we all have been trying to achieve so far. Cutting through all the flab, and hype around SOA, at heart you will find that SOA is an architectural concept that re-emphasizes the basic design principles like

• Programming to interfaces,not to the implementation.
• Favoring composition
• Loose coupling

The way these are achieved are by creating services not just components and letting the services interact with each other to form a part of business process or a bigger service.

There are certain characteristics that are key to an effective SOA implementation.

1. Standard interfaces. All the services will have a properly defined and self explained interfaces. This is achieved primarily through well designed, documented WSDLs.
2. Each service will perform one activity/function completely.
3. The services will exchange information in standard, well defined manner.
4. There will be a standard based inventory of existing services so that re-use can be encouraged.

On the topic of what is not SOA, there are a lot of points that need to be considered.

• SOA is not a Magic bullet!
• It will not solve all your problems.
• Having a bunch of web services is not SOA.
• Having an ESB is not SOA.

Let me get on with the article, by summarizing what SOA is by saying:

SOA is an architectural concept that puts the focus firmly on basic things like Standard interfaces, loose coupling, proper analysis etc, with an emphasis on standards based exchange of information and ability to easily identify existing services that encourages re-use.

SOA Services - Lego Blocks

The most common analogy for SOA is that of Lego blocks.

• All Lego blocks have a specific interface that is standard.
• Each block is complete in itself.
• You can compose different structures with the same blocks.

In our toy box, we have blocks of different sizes, shapes, and color. We can build a castle with the Lego blocks and then we can quickly dismantle a castle and build a row house! With the same blocks!! You get the picture don’t you?

SOA is all about building the blocks (read services) in such a way, that you can put them to use in many different purposes and situations.  (I am not going to debate on the finer aspects of the analogy, I simply use it to drive home the point of re-use and agility)

Why should I consider SOA

In other words, what does SOA bring on to the table ?

1. Reuse – You can build services that can be used over and over again there by saving your business all important “cash”
2. Agility – You can initiate change, respond to change in much faster manner than before. The time to market can be significantly reduced, once you have a mature set of discoverable, re-usable services.
3. Efficiency – You can streamline your processes and have a much more efficient business.
4. Business & IT alignment – chance to align IT with business, in an much closely, there by leverage each other to achieve the common goals.
5. Rationalize existing infrastructure – by having a standard enterprise level architecture, there is a chance to rationalize infrastructure and thereby reducing the opex.

Before we go on to the next topic, please read the disclaimer: My intention is not to scare you away from SOA, on the contrary it is to make you aware that there are lots of challenges and show you how best we can derive value out the investments made.

What does it take to Implement SOA

A hell of a lot! It’s not an easy road, with simple options and choices. SOA is not for all. It takes a certain level of maturity for a business to go the SOA way.

I am not only talking about the cost aspects, but at an organization level, lots of changes need to happen starting from mind sets, attitudes, way IT and Business interact etc. From cost point of view You are looking at significant investment in terms of technology and effort to achieve a truly rewarding SOA implementation.

Having gotten the bad news out of the way, lets see how we can go about addressing all the challenges and come up with winning strategy for SOA realization.

To begin with, the most important thing is, to have intimate knowledge of your business, various process your business will have, and a sense of how you want to react to change. It does help to conduct a proper analysis of the existing processes, and map them to the existing capabilities. A detailed end to end mapping, starting from a business process, breaking them down to smaller processes, and the components that make up the processes, the platforms that support the components, the infrastructure that supports the platforms etc. Also a detailed analysis of the data involved in all the processes also needs to be done.

I know, it’s a tough one. Particularly for the massive organizations it will take years to complete such a comprehensive study, and by the time we complete study, I am sure what we studied would have become obsolete. For small and medium businesses it might still be achievable, but a time consuming process nevertheless. We also have the risk of not showing any return on investment (ROI) for an extended period of time.

Alternatively, if we went head first into implementing SOA, and building “re-usable” services we will run the risk of creating silos instead of truly Service oriented Architecture. We will still not be able to demonstrate ROI since we have no clue how many of our services will be re-used and there by how much money did we save ? By how much, did we reduce the time to market?

So the answer to the question of “How to implement SOA in the most effective way?” lies somewhere in between the above two approaches. And only after a study of your business, the complexity and the expectations, will we be able to arrive at an effective strategy for SOA realization.

However, Based on previous experiences, There are some key questions that must be asked while trying to identify the strategy to implement SOA.

I shall try to group them into relevant heading. Some questions might repeat, but will have relevance to the heading.

Measure of SOA Success:

• How will the success be measured ?
• Do we have a base line of the following metric
• Cost – to take an idea to realization/product
• Time – to take an idea to realization
• At what intervals the metric be collected to measure progress/success ?

Funding/Business support:

1. How fast would you want to see the benefits?
2. Have we done enough to set the expectations right ?
3. Do we have the time/money to do a complete analysis of business process ?
4. How frequently the processes change ?
5. What are the key milestones and check points for securing funding ?
6. What is the ROI expected, and when would we expect to meet the ROI ?

Organization/Culture:

1. What sort of an organization are we talking about ?
2. What is the existing delivery model/model of engagement between IT and Business ?
3. Is IT and Business working closely ?
4. What is the level of interaction between Business users and IT ?

Eagerness to confirm to Architectural Standards:

1. How long is the business ready to wait to see results under SOA?
2. Under what circumstances, business will support a Non SOA based solution to achieve its objectives ?

(To Be continued)

SOA from 10000 ft – Part 1

There are hundreds and thousands of primers/introduction to the most widely used/abused acronym in the recent times. Why bother to add one more to it ? Well the idea is to give my version of what SOA is, and what it is not and How SOA fits in the grand scheme of things in the business.

I will be tackling this article at multiple levels like What SOA means to Business audience, Techno/Functional audience. I trust your interpretation skills to extract the level of information for further processing.

SOA – Service Oriented Architecture.

Evolution of Software Engineering Paradigms:

Like everything in the world, programming paradigm has been evolving through time. Initially we had low level programming, procedural programming where instructions/code is like a step by step problem solving. Of course, several thousands of lines of code that will do exactly same kind of work, will be re-written over and over again. It introduces complexity and increases the risk of creating lower quality of code.

From here, starts the search for the “holy grail” of re-use.

As the thinking evolved, we moved on to more functional/modular programming, where the problems we are trying to solve will be modeled as functions/modules. The focus was again code level re-use. Also a very interesting software engineering paradigm caught the imagination of the programming community, Object Oriented Programming. This took the problem solving much closer to the actual problem domain. Now we could model based on objects. An object has properties and it performs some function. A powerful way to think!

Several languages offered the capability to solve problems using the OO Principles. The code re-use went on to a new level. Technology was truly adding value to enterprises and helping businesses to grow. The promise of re-use and desire to reduce costs to own and operate IT assets drove the evolution of Software Engineering paradigms to Distributed computing, n-tier architecture etc.,

More the capabilities grew, more the interaction between business and IT grew and business’s dependency on IT. With so many options available and sheer variety of technologies available to solve problems, soon, enterprises started to build a diverse portfolio of IT assets, and islands of systems/applications.

For so many years while the focus has been on code ruse and better tool sets to address business problems, two key factors that would ultimately drive the change towards the SOA paradigm were fast emerging.

• The need to re-use capabilities (not code)
• Lack of interoperability between main technology platforms/vendors.

(End of Part 1)

Here is the part two of the series.

ALSB Build Propagator

A pattern that we used in our Aqualogic Service Bus Development.

Problem :

Once the development activity is completed, the project needs to be deployed in to integration environment, from there it needs to be deployed in testing, reference, performance, and live environments. This means that the following activities need to be done from the nice GUI provided by BEA in the sbconsole.

1. Deploy the application jar
2. Customize the end point urls for the business services

Its is not an issue if we are talking about a few application jars that we have to deploy. For a SOA implementation at enterprise level, there will be hundreds of such application jars that we need to deploy. It is not an effective way to deploy.

Solution:

Design and develop a command line based, Build propagator, that performs the following tasks.

1. Deploy the application jars on to the admin server.
2. Customize the application.
3. Un-deploy the applications.

The propagator performs these tasks by using the API’s provided by BEA.

The SOA Architect

The SOA Architect, becomes the corner-stone in any organization that plans to go the SOA way.
The SOA Architect guides the organization, helps the organization in arriving at the strategic and tactical plans to accomplish the SOA mission.

More on the roles and responsibilities of a SOA Architect.