Wednesday, June 3, 2009

Review of the BA Role in TOGAF v9

I just reviewed TOGAF v9. Here are my thoughts. This framework does a fairly good job introducing the role of the business architect. The structure of the document suggests a waterfall approach to the business architecture phase as well as the others. I know that it speaks about iterative development, but can easily be interpreted otherwise and it is essential to be iterative and adaptive - your architecture WILL change and it must be adaptable (now and in the future).

I do agree completely that Business Architecture is a prerequisite for other architecture work (again I would say leading slightly here because it is essential to have the other domains involved as early as possible). The role of the BA is essential as a bridge to structure the needs of the business for buy-in, illumination and analysis and for consumption by technology.

A good point, often overlooked, is the BAs role in value demonstration. My experience is that a good BA can make a business case and demonstrate the need for change better than almost anyone.

Organizations, and programs, don't always have their mission, vision, goals, etc. well defined and aligned. This often falls to the BA and is the reason that I advocate the BA having a sound understanding of business strategy and enterprise planning.

I take a small exception to the statement that business strategy defines what and the BA defines how. To me the BA defines the what more clearly. But I nit pick.

TOGAF mentions the common experience of having to do legwork to scope the program effort and get buy-in and determine feasibility. I find this to be an absolutely essential aspect of the job. Also, managing value delivery is vital and this is done by keeping a close eye on the prize and making smart trade-offs where and when necessary - this should occur continuously throughout a program life cycle. I know that some will think that this is the job of the Program/Project Manager, but the BA is the one who demonstrates the way forward and therefore should have a razor view of the way forward. It is the role of the BA to help decide whether changes to the program are justifiable.

Reality often dictates that a BA has to work from the middle out, working top down on the vision (and buy in) and working bottom up on what do we have and how does it need to change. These two approaches (working simultaneously) help ground the program in reality.

TOGAF speaks of repositories. Anyone maintaining anything that is versioned should have a repository. This does beg interesting questions concerning configurations. If we try to build our models and descriptions in tools that can be extended toward development (MDA) then configurations become important artifacts in the delivery of business change.

Service orientation is another must for the BA. NOT fine grained services that expose technical interfaces, but the bundling of activities (and processes) into interfaces and components into business services. This is less granular and should immediately speak to the business - if it does not then you're probably doing it wrong. Service orientation can also be applied to platforms and business units in a componentization of the organization.

TOGAF feels document heavy, so I would advise a little caution. I have seen organizations adopt RUP as very document centric and it is easy to lose focus on the task at hand which is improving the fitness of the organization. So my advice is to not interpret this framework literally. Use the documents as suggestions and seek out tools that allow you to build value as you document - tools that are building your product AS you document. IBM's Rational Tools do this well as well as their Business Modeler and System Architect. There are quite a few of these on the market.

I would not take the inputs and outputs as essential. Very often these are simply not available. I would not create new kinds of documents unless absolutely necessary.

One more point on iterations. Change management is very collaborative and iterative. I recommend a Program Office that has business representation, a BA (and perhaps the other EA roles), Program Manager, and the project lead(s). This is the minimum. Other possible roles are Communication Management, Change Management, etc.

All in all the TOGAF v9 is a good introduction to the role of a Business Architect.

Join the community for business architects at Inside Business Architecture.

No comments:

Post a Comment

There was an error in this gadget
There was an error in this gadget