Business Architecture – Is it IT’s intrusion into Business?

OMG’s SOA Consortium working group recently published a paper on their perspective of Business Architecture.  The paper is clearly by the IT Practitioners.  The way they define Business Architecture is as follows –

We define business architecture as the formal representation and active management of business design. Expanding this definition, business architecture is a formalized collection of practices, information and tools for business professionals to assess and implement business design and business change.

The paper advocates the active management of business design, with the same focus as that of IT.  Though it sounds good on paper, is it really practical? -  Especially when the fact is Enterprise Architecture is driven by IT. Will the social and power structure present in Today’s organization allow this?

 No doubt that we need a clear understanding and formal representation of business design, however, the comprehensiveness should be limited to suit the need, which is typically an input to IT (and not management of business).  Also, the involvement of business in driving the IT solution is critical, however, the involvement should be periodic, although frequent, and every attempt should be made to keep the overhead on business  as minimum as possible.  Attempting active management of business may be considered as unnecessary intrusion of IT into business and often, it is counter-productive. Instead, a process for periodic review of business models and refresh should be institutionalized.  The EA-IT team should, however, do the active management of IT portfolio and ensure alignment of IT investments with business goals through active governance structure.

Having said this, the paper does provide some useful information and examples of artifacts. It will be good if OMG standardizes the business architecture models and encourage tool vendors to support it. The Enterprise Business Motivation Model (EBMM) will be a great start.

Cut your losses !

I have been working with customers to help them modernize their IT systems for few years now. I have seen that customers are more receptive, if we prescribe to build over the existing systems rather than rebuilding from scratch. Though it is comforting to see optimal reuse of existing, practically, sometimes it makes better sense to rewrite than reuse, especially if the current systems are architected in a fashion that will hinder achieving the desired target state for the business. Most often, it is a psychological block that makes it difficult to move away from something that we have cared for a long time. It is like an affinity of share pundit to his or her loosing stock. They buy every time stocks go below and average out its price, but they end up losing everything at the end. It sometimes makes sense to cut your losses and invest somewhere else that is likely to give you most returns.

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.