It would sometimes disappoint the reader to look at “why” before “what”, but that is the natural way.  When you compare questions like – “Why use a cell phone?” compared to “What is a cell phone?”, you clearly can spot how the “why” question was asked first, and then attempts to define its outcome started to explode (the “what” part).  Also, the “why” part might have been provoked with other forms such as “I need to communicate on the go, how can I do that?” which is basically an answer to “Why use a cell phone?”!

So, please excuse me for not addressing other important aspects of Enterprise Architecture in this post, like “What is EA, anyways?” which I will do in the near future.  As a first post on my journey on discovering and deciphering Enterprise Architecture, or EA for short, I needed to start with a more provocative mindset.  “Why?” is always a great start!

In my reading through EA literature, I can see two distinct personas for those who pursue an EA effort.  One that looks at it as a core IT function or program to reorganize the house; I would like to call them “EA Technologists”.  The other persona looks at it as a tool to better understand and govern business interactions and deliver value; which I will call “EA Businessmen”.  There is no harm in either, but it then becomes a question of how much value I can gain from an extensive effort in developing an EA.  For example, an EA technologist will always admire the “architecture” side of EA, and will devote most of his or her time in perfecting its outcomes such as frameworks , models, repositories, standards, etc.  He will always value those architecture blueprints that help him address integration issues, business processes, and sourcing strategies, for instance.  On the other hand, an EA businessman will mostly appreciate that tangible benefits of getting closer to business and having a defined way in channeling their needs and reflecting on business satisfaction of IT.  You clearly see him or her worried, and concerned mostly with the “enterprise” side of EA. 

You could see clearly how the second persona (EA businessmen) will have a much greater value in putting together an EA, since IT merely exists to enable and advance (or even lead) business to achieve its desired outcomes.  But, you should perceive both as fine approaches to EA, with different concerns and value propositions.  It’s simply the difference between being “technology practical” and “business practical”.  Both are practical, but have different views on EA, so vote for your favorite side.

Why would an EA technologist pursue an EA effort?

Coming from the technology side, and mostly being concerned with the architectural outcomes, an EA technologist would think of developing an Enterprise Architecture to address one or more of the following (this is not a comprehensive list by any means):

• Understanding the current environment in order to organize the house.
• Developing standards in order to have clarity on selection of systems/technologies.
• Drawing a roadmap of technological improvements to reach a satisfactory level of design.
• Clarifying and/or developing integration standards to easily hook up internal and external IT systems.
• Governing the relationship with external vendors and having a blueprint of standards which they can follow.

You can see how EA technologists, in some cases, try to address specific technology problems.  I believe this is where EA gets intermingled with other technology disciplines such as business process management, integration strategies, sourcing strategies and vendor management, etc.

Why would an EA businessman pursue an EA effort?

Coming from the business angle, EA businessmen are usually concerned with value outcomes from IT to the enterprise, which should connect to those of the enterprise as a whole!.  One or more of the following will be on the agenda of an EA Businessman:

• Making business-conscious decisions in IT, and facilitating/guiding those of the business as well.
• Connecting business strategy to IT strategy, or facilitating the execution of strategy within IT.
• Clarifying IT value to the organization in order to avoid marginalizing its efforts.
• Clarifying business needs in order to govern changes and achieve satisfaction.
• Establishing a rhythm of collaboration between the business and IT.

EA businessmen are always business value-driven which helps them avoid unnecessary architecture jargon (no offense to EA technologists who should, in my opinion, make sure to justify every single model or artifact they produce in their enterprise architecture).  The down side of their efforts is that it is tougher to pursue and usually needs a twist in the mindset.  It is also much harder to make their efforts as concrete as those of the technologists.

Which side I support?

You might guessed my side from the above, but I wish it’s as simple as voting for one side over the other. In my opinion, you should start being an EA businessman who collaborates with or even lead business to deliver value out of IT.  At the same time, you need to dive like an EA technologist on as-needed basis in areas where you need to have concrete deliverables and tools.  This way, you can balance your act by wearing two hats (or working with a team of mixed hats) and avoid time-consuming EA activities unless they are “really” justified.

Your comments are most welcomed!