A Day in the Life of an Enterprise Architect

I am writing an MSDN article called "A Day in the Life of an Enterprise Architect" that hopefully addresses the many challenges an EA faces every day. The article is in the final stages of publication so it should be available on Enterprise Architecture Center soon.

Below is a small snippet from the article:

A good way to compare enterprise architects with other types of architects is to look at them in terms of Breath vs. Depth. This shows us how deep in expertise (i.e., “Depth” in Windows Infrastructure Architecture) versus the span of responsibilities in which the architect covers (i.e., “Breath” in a Line of Business (LOB)).

As shown below in figure 1.0, enterprise architects cover the breath of IT and to a degree the business concerns as well. When compared to the other roles you can see that the expertise of an EA is very different than the other roles.

Let’s take a look at how these roles are different from each other based on “Breath vs. Depth”:

  • Enterprise Architect – Enterprise Architects span across LOB and IT domains such as: Security, Infrastructure, Information or Development
  • Domain Architect – Architects that focus on a specific domain and have deep expertise that area are domain architects
  • Developer – Developers focus on one solution at a time and have a deep expertise in development


Figure 1.0

Above shows an enterprise architect in contrast with other architects. There are many different architecture operating models. The roles shown above are a sample of a structure that demonstrates how each of these roles aligns.


Figure 1.1

Above in figure 1.1 are two examples of two diverse architecture organizational models. The line in the middle separates out the two models. With each one of these it can impact the role in which an EA operates. With each comes contrary organizational and operating challenge.

Therefore, there isn’t just one criterion for making IT decisions. Decisions are made from multiple perspectives. Often times these decisions are not made based on the merits of the technology in question. Most times it boils down to organizational aspects such as cost, personnel supportability issues and IT standardization.


Keep an eye out for the MSDN article.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s