The non-overlapping responsibility set: Solution Architect and Enterprise Architect

Recently, Mike Walker posted a blog entry on the difference between Enterprise Architect and Solution Architect (sometimes called Application Architect).  I think this is an interesting space, because I believe that some folks have a mistaken perception that these two roles do the same things at different levels.  Nothing could be further from the truth, as Mike's breadth-depth diagram helps to illustrate. 

The work of an Enterprise Architect is different from a Solution Architect, as different from each other as they are from Project Manager or Software Tester.  Certainly, a single person can play different roles over time.  A developer can become a project manager (or Scrummaster), but that doesn't mean that the job is the same.  

Being an Enterprise Architect myself, who grew up out of Solution Architecture, I don't view the differentiation so much as a difference between breadth and depth, or the overlapping of roles, but rather as a partitioning of responsibilities.

I think much of the misunderstanding about the role of the EA comes from a lack of visibility of the planning cycle for Information technology.  Many developers have no idea that a planning cycle even goes on.  (In some companies, the planning process is informal, or worse, hidden, so it is no surprise).

As Gabriel Morgan pointed out last fall, the activities of the Enterprise Architect fall mostly in the planning space, while the activities of the Solution Architect fall mostly in the Development space.  I indicate this with the "Span of Responsibility" triangles.  At any point in time, the thicker the triangle, the more responsibility that role has.

To Be Clear: Planning does NOT include requirements gathering.  That is part of "Deliver." 

Planning is about the organization deciding what projects to do, why to do them, what they should accomplish for the company, and how much should the company spend for them.  Planning decides to "build the right app."

Delivery is the entire SDLC, including waterfall, agile, spiral, or some blended process.  Pick your poison.  The point is that the dividing line is the point where the organization decides to fund the project.  Only then are the requirements, use cases, scenarios, etc, collected.  All of our notions of object oriented development, and all the process debates, affect ONLY the "Deliver" slice.  Delivery decides to "build the app right."

I believe that once a stakeholder understands this distinction, it becomes more clear to them what the Enterprise architect is responsible for.  The EA is not there to design an app, or figure out what the interfaces are.  They are there to make sure that all of the apps in the portfolio continue to be "about" building systems for the enterprise.  They insure that project managers keep integration interfaces in scope, because the app that will use that interface will be built next year... long after the current project is delivered.

Enterprise architects take the long view.  No one else is paid to.

[note: I updated the model on 10-Jun-08 to correct a mistake in the span of responsibility.]

Technorati Tags: Enterprise Architecture,Solution Architecture,Information technology

Comments

• Anonymous
  June 01, 2008
  The comment has been removed

• Anonymous
  June 02, 2008
  It's nice to see your EA role plays into the post release period.  I belive you are outnumberred by people (not neccessarily your peers) who see the EA's responsibilities end at the project funding gate.

• Anonymous
  June 04, 2008
  Hi Rebekah: I'm glad that our viewpoints align.  That helps to assure my understanding as well. Hi Craig: I shudder at the thought of the EA going "offline" during delivery.  This may happen in wildly underfunded Enterprise Architecture programs that attempt to take a 'breadth first' approach, and therefore stretch their resources too thin.   IMHO, they won't produce value.  Only by having the resources focus on the projects that deliver enterprise value can you develop roadmaps that produce lasting value over multiple years, and therefore improve the project portfolio and reduce the cost of ownership for all of IT.  Those measurements REQUIRE work during the delivery cycle.

• Anonymous
  June 04, 2008
  The comment has been removed

• Anonymous
  June 04, 2008
  Hi Dirk, Perhaps your snap judgement is a bit hasty.   The key to explaining technical information is to focus on a viewpoint that conveys the specific elements you wish to highlight.  Removing unnecessary detail is key to being able to clearly explain a concept and get a decision from business that is needed to drive a simple and useful solution. The illustration that I provided is simply that: a view on the concept of an ITLC, simplified specifically to show the overlay in the span of control.  Placing cycles onto the model would add nothing.  I'm aware of iterative and agile methods.  I chose not to illustrate them. That you are not able to understand this does not demonstrate a limitation on my part.   I am a solution architect, and have been one for over a decade.  I happen to be employed in the Enterprise Architecture team and have been plying my architecture skills to a different set of responsibilities. Clearly your preference for solution architecture shows that either you are one, or you have had a good experience with one.  That is great, and I take it as a compliment to my field. That said, EA is quite different, and if EA does not provide value to you, perhaps you have not yet had the opportunity to have a positive experience with Enterprise Architecture.  Consider: if you have met only one carpenter, and he was unable to drive a straight nail, that doesn't mean that no carpenters have skills.  It means only that you haven't met one yet. Were we to work together, you'd quickly discover that I am not only quite able to discuss technical solutions, but I'm quite able to discuss business as well.  As the co-founder of a dot-com, and the practice manager for a consulting company, I assure you that my business credentials are sound. As for SDLC, would it help if I explained that I'm a certified Scrummaster, an expert in MSF and RUP, and the co-author on a book about agile requirements gathering?  

• Anonymous
  June 05, 2008
  Nick: I am not sure we would ever agree on a thing. We seem to have a perfectly divergent view of things. I am a bit disappointed by the claims you are making, I believe that you are oversimplifying way too much to be in the position to make any conclusions. Instead of using overloaded terms (ES, SA..) it might be easier to look at the architecture-related activities that are needed to successfully deliver a solution. You would then be able to sort out the ones that can be common to a series of solutions and the ones that are specific to a solution. You might also realize that your question is technology dependent. You could ask questions like: "is an Architect responsible for the construction of a service (SOA, Identity Management, Monitoring, Management, Virtualization...) an EA or an SA?" You might also quickly find out that anything that is "container" based has a nice EA / SA division, but in that case the EA is a solution architect that is building a container infrastructure and the SA is a solution architect that is building a solution hosted in this container. So I am not sure that the division of roles that you (and so many other people) are referring to really applies. Not to mention that an EA that provides guidelines and recommendations without ever building a solution has a value close to nil. For me, the best EA strategy is to factor in some EA budget in every solution such that best practices and guidelines can emerge from real world experience rather than magazines, blogs... In order to bring some coherence to the whole you may organize once/twice a year an architect conference that looks at trends and identify potential EA activities in the solution pipeline (someone has to build the container). I truly think that creating 2 roles increase both your costs and the disconnect between EA / SA and ultimately leads to poor results and people constantly trying to navigate around EA standards.

• Anonymous
  June 05, 2008
  The comment has been removed

• Anonymous
  June 06, 2008
  The comment has been removed

• Anonymous
  June 06, 2008
  Hi Max 100% of your example is the role of the solution architect.  The only part of your example that has much of anything to do with EA is in the first statement: "In an ideal world..." I don't live in an ideal world.  My guess: you don't either.   The EA helps the company decide what system to build, why to build it, and why not to build something else that is "really important."   The Solution architect is a very important role.  She helps to translate the system quality attributes required by the company strategy into systemic designs.  The senior developers exercise their skills in patterns to flesh out the design (and test cases) and commit it to tools, while the junior developers fill out the code, build scripts, deployment scripts, and all the rest. EA has a role to play, and it deals with technology, but it is not normally a technical role.  It is the job of the EA to see that technology is needed, or not needed, and guide accordingly.   Make sense?

• Anonymous
  June 06, 2008
  It occurs to me, Max, that I didn't answer your question.   In smaller IT orgs, the role of the EA is played by the IT director or the CIO.  It is rarely played by the solution architect. It is possible, I suppose, for a solution architect, who delivers systems, to also play the role of EA, from a governance standpoint.  I haven't seen it, but anything is possible. EA is a business role.  EA deals with future-looking technology trends, funding cycles, and strategic alignment.  

• Anonymous
  June 07, 2008
  Nick, Thank you for clarification, the difference between the two roles makes more sense now however I'm still not quite sure about the work products the EA produces. In my example above (which you believe is 100% solution architect) he/she gets a set of business goals as in input and designs system/software architecture that has properties consistent with the business goals. Following with simplified model, what information/data the EA needs as an input and what does he/she produces as an output of his/her activities? Another question I have is does the role of EA exist in a company that produces and makes a product, say some shrink-wrapped product? It appears to me from the discussion above that it mostly makes sense for the company where IT serves company main business which is usually not software related. Of course in your situation Microsoft’s main business is software. Probably it depends on the size of the company, but in any case the customers of EA are other departments of the company and not directly the external customer. Thanks.

• Anonymous
  June 07, 2008
  The comment has been removed

• Anonymous
  June 09, 2008
  The comment has been removed

• Anonymous
  June 09, 2008
  The comment has been removed

• Anonymous
  June 09, 2008
  Thank you for your time Nick, the role of EA makes more sense to me now.

• Anonymous
  June 10, 2008
  In my opinion, a business function can often be best understood by describing the processes that compose

• Anonymous
  June 17, 2008
  A fantastic exchange of views! I believe an EA should, above all things, understand the Enterprise value chain and how technology supports it. EA's should always look to see where there are new opportunities to improve the value chain and understand/define how an Enterprise will realise its ROI on any programme or project. At this point the ROI may be a business transformation (reduction in FTE, consolidation, acquistion etc) which is often as difficult as IT delivery!

• Anonymous
  June 19, 2008
  I heard abt a new role of Solution Adviser. Any idea if this is closer to EA than SA?

• Anonymous
  June 19, 2008
  Sorry, Setty.  I have not heard that title applied to architects before.  Usually, the title of Advisor is given to people responsible for sales.   --- N

• Anonymous
  June 26, 2008
  Nick, Nice clarification of the key roles we keep hearing being bandied about. It's easy to see how EA can be viewed incorrectly as simply a glorified SA with a big picture view.

• Anonymous
  July 27, 2008
  Thank you Nick for this detailed explanation. I now understand the difference after reading your blog and all the explanation in your comments.