Coming down from the Ivory Tower of Enterprise Architecture

Read it at - https://www.linkedin.com/pulse/coming-down-from-ivory-tower-enterprise-architecture-amit-unde?trk=prof-post

Translating Business Strategy to Enterprise Architecture

I recently concluded a consulting assignment to define Future (after M&A) enterprise Architecture for a health insurance company, who acquired another company with considerable overlap in business.

While it was ‘relatively’ easier to come up future IT architecture by analyzing future needs and system overlap, it was quite challenging to present to executive board (completely non-technical with attention span of max 5 mins) and explain how exactly it maps to their business strategy. We had generated loads of detailed EA artifacts, however, challenge was to put all this together in just couple of slides and create a strong business case to move forward.

I found TOGAF’s Content Metamodel very useful in creating this linkage. I identified strategy business themes and for each business theme, and developed a view similar to content metamodel to link business strategy to required business services first, and then further to changes required in business process & IT systems.

A quick glance at artifacts is as shown -

Is it End of Zachman ?

It's very sad the way things turned out for John Zachman's associations. Just came across an excellent post by Gartner's Philip Allega on this topic - http://blogs.gartner.com/philip-allega/2010/09/01/john-zachman-is-dead-long-live-john-zachman/

One would have expected further research from such elites, rather than just attempts of commercialization of the framework. Really, not much has been added to the framework, since, it is published in 1980s... Though there is lot of value in the thoughts that are behind the framework, IMHO, the use of framework itself is quite hyped.
In comparison, other established EA frameworks ( and methodologies) like TOGAF and even the new upcoming like EACOE are quite useful. May be they will continue Zachman's legacy.. but without his name !
Looks like he wants it that way.

Test Drive your Architectures for effective evaluations

Are you one of those sitting in ivory towers of Enterprise Architecture Group, tasked with responsibility of evaluating project architectures and ensuring IT Governance? If you have done few reviews before, you would know that it is highly subjective process that depends largely on the evaluators’ technical skills, functional/environmental knowledge, authority structure, and other political forces. The evaluators who are parachuted into the project group for reviews are especially handicapped due to lack of knowledge of functional requirements, and often only concentrate on ‘technology’ implementation reviews. Hence, most of the reviews remain superficial and only partially beneficial.

So how exactly should you evaluate the architectures? 

I would say do what you do when you buy a car. Test Drive! You will only know the car’s performance when you actually drive it and feel it, and not just by reading specifications or by asking questions. Similarly, to evaluate the architecture, apply it to the specific functional scenarios and measure the quality attributes.

Carnegie Mellon Institute (SEI) has developed the architecture evaluation methodologies on the same principle. The most known methods are –

1)   ATAM (Architecture Trade-off Analysis Method) –

This methodology analyzes how well the software architecture satisfies the quality attributes (e.g. scalability, modifiability, performance etc), by applying the architecture to short-listed functional scenarios. It prescribes developing a quality attribute utility tree, and analyzing it for each scenario and alternative architecture approaches. For each scenario, the method prescribes identifying the following –

a)    Sensitivity points – a collection of components that are critical for achieving a quality attribute,

b)    Trade-off points – a sensitivity point that affects multiple quality attributes, typically trades one off for the other,

c)    Risks – something that inhibits the system from achieving its quality goal (this also includes the decisions that are not taken),

d)    Non-risks – something that is done right (and should not be changed)

2)   CBAM (Cost Benefit Analysis Method)

CBAM begins where ATAM leaves off. It prescribes analyzing the cost, benefits and schedule implications as well for architectural approaches before making the final decisions.

3)   ARID ( Active Reviews for Intermediate Design)

This is more of a design review than architecture review, but uses the same principle of applying design to scenarios, and even writing a pseudo code to evaluate different parts of design.

The SEI has documented a very formal step by step process for all these methods. One way that may be counter productive as people tend to focus on activities, rather than the principles behind these methods. There is a great scope to tailor these methods to suit your organization, and conduct such evaluation in agile way.

More on this topic later…

- Amit Unde

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.

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 - http://www.microsoft.com/learning/mcp/architect/solutions/default.mspx

I found a very interesting blog that describes the architecture process in a much lucid way - http://blogs.dirteam.com/blogs/natashamocke/archive/2007/09/02/microsoft-certified-architect-certification-process.aspx

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

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.