Tag Archives: EA

A Comparison of the Top Four Enterprise Architecture Methodologies

Microsoft has published a comparison of the four most well-known frameworks / methodologies / processes that aim to help you with Enterprise Architecture. These are

There is a whole bunch of other interesting articles on this page, so you might want to browse around there a bit.

Business Analyst and Enterprise Architect

In a recent edition of their ZapFlash newsletter the guys from ZapThink (I could not reach their site when writing this, therefore no link is put in here) bring up a pretty interesting topic. They discuss the relationship between the role of a {en:business analyst} (BA) and that of an enterprise architect (EA). They put them much closer to one another than I would have done prior to reading this, which triggered some thinking on my side that I would like to share with you.

The core point, I think, is that both roles were “invented” in the attempt to link the strategic layer of the organization with the operational one. (Hm, can you think of this as an incarnation of the famous knowing-doing-gap?) This view leaves out completely the notion of business and IT, which would delude things for now. Both sides have realized (or were probably forced to) that in many cases there are significant gaps between what is needed and what exists in reality. So they have both moved from their home territory into “enemy’s land” in order to grab their share of the pie. This has narrowed the gap but not closed it.

What is needed is a role that coordinates and brings together the BA and the EA. It is in my view not realistic (and probably also not desirable) to merge EA and BA into one physical person. But the main problem, from an overall organizational point of view, is that they serve two different masters. They therefore have goals that conflict on a practical level, although the intentions point (hopefully) into the same direction. The result of this combination is that a lot of discussion, negotiations etc. takes place. And at the end of the day a compromise is reached, that nobody is really happy with.

Instead it might be worth thinking about a new organizational layer sitting between business and IT. BAs and EAs would be reporting into the same person and work on the same set of goals. The challenging thing would obviously be to identify those goals. But hey, this is true for all parts of the organization. On a very high level I could think of revenue (coming from the BA side, mirroring how well the needs of business are served) and profit (coming from the EA side, representing how efficient things are). This is certainly just {en: brainstorming}, but it illustrates the point.

An even better approach would probably be to take the line of thinking from the above paragraph and implement it into the existing orgchart. Hm, looks a bit like a matrix organization (anybody out there who really likes them?). Still, saving an organizational layer is certainly worth a reasonable thinking effort.

That’s it for now. I am looking forward to comments on this.