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