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.]
Thanks for this clear diagram! Two of the questions that I have to answer at least once a week is "What are the services that the architecture team provides to projects" & "Why does your team sometimes veto the technology decisions within individual projects?"
To answer these questions, I structured our service offerings into two groups: Strategy and Execution. These are perfectly mapped to Planning & Delivery that you use. You post validated the approach & shows why both types of services are needed!
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.
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.
If only architecture was a straight line, except for rare cases the plan, deliver, operate will be a circle based on continues improvement. Your description clearly indicates why most Enterprise Architects are so useless, they have no clue on the current SDLC since they are hardly involved and their knowledge is outdated. They try to discuss new projects with the business but most come from an IT background and only talk technology.
If you want to plan asuccesfullproject include a solution architect, if you need to apoint an Enterprise Architect, since it still is in vogue to do so, hire someone with a business background. Enterprise Architecture is about the Enterprise not about IT.
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?
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.
Yep. we disagree. Dirk nailed this one. EA is a business role, not a technical one. An EA that delivers no code is quite capable of providing a huge value.
I was quite proud of the fact that, in my first four months as an EA, I was able to deliver over 1M in direct value to the IT budget.
Without writing a line of code. Because writing code is a technical activity.
An EA would not write the container, nor would they write the code that fits in it. The EA would decide that a Proof-of-concept or pattern project would take place, and a senior SA would write the container. Then, the EA would help publicize the existence of the container and help find a pilot project, where another SA would write the code that fits in the container.
I know effective Enterprise Architects who started life as a accountants, project managers, and general liberal arts majors, without ever writing code.
It's a business role, JJ.
In an ideal world a company would build a software system which has properties consistent with the company business goals and the strategy. The role of the architectural activities then is to create a foundation on which those business goals can be easily achieved. For example if the company is building an accounting system with an intent to sell it later in different counties (business goal), then it suggests that it should be easy to adapt the system to different languages or certain accounting algorithms that vary depends on the country.
The role of an architect then is to understand those business goals, transform them into design goals (maintainability in the example above) make the right trade-offs and design the architecture which implements those goals.
This then suggests that the architect needs to have good knowledge/skills of both – the company business and culture as well as technical skills.
Can those skills be combined in a single role or do we need to separate the role into EA and solution architects? If so, under which circumstances they can and should be separated and under which circumstances they can't really be separated?
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.
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.
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.
A couple of really good questions.
First off, the inputs to EA are the same as the inputs to senior business planners: market trends, core strategies, company position, company culture, but most importantly, measures of success. The EA cares, passionately, about "how success is measured."
Of course, so do business leaders. The business leaders make themselves busy by crafting strategy and then operating on the basis of that strategy.
Ideally, the EA has two primary roles. 1) The EA informs the CIO and company leadership about opportunities in technology that may affect strategy and would directly impact measurable performance. That output is a series of reports and presentations. 2) The EA takes the strategy of the business and IT executives and creates a framework that will be used to judge each of the IT funding requests that come from the business.
As the business decides their strategy, they may decide to spend money on their IT systems. But the EA has to insure that the limited resources of IT are spent wisely. The EA cares about "moving the needle" on that dashboard, and any investment that a business wants to make will be judged and prioritized alongside it's downstream effect.
The input to this part of the EA job is the "book of work" requested by business. The output is a set of priorities and judgements made about that book of work. The EA has already examined the portfolio of applications running in production, and has formed his or her own opinion on what must be done next, whether it is replacing a legacy system that is not going to meet future needs, or filling in a gap in the portfolio to improve business capabilities. But the EA cannot (usually) fund large projects. One of the business leaders has to propose it, and the EA will help support and defend it in the prioritization process.
Depending on the company, that prioritized book of work may go to a single CIO or, more likely, a council of business leaders led by the CIO, where the final decisions are made about "what to build."
Interesting note: in some companies, Enterprise Architecture also has a team dedicated to "advanced" or "emerging technology." I believe this is a reflection of the first role I described. In that situation, there may be a dedicated budget to build software, and those _developers_ and solution architects, working on those projects, will report up to the EA team. But they are not enterprise architects. They are developers. It is a coding project. An EA may decide "what" they should build, but the very smart solution architects in that team will decide how to build it.
Lastly: you are correct in your statement: EA primarily serves the corporate stakeholders: shareholders, executives, and departments. In Microsoft, the company will spend 1.2 Billion dollars on their own technical infrastructure. Not one penny of that goes to developing software products. Enterprise Architects have very little effect on Microsoft's software products. We effect how that IT money is spent.
The only point of cross-over is in Software + Services, or in things like XBOX Live, where IT functions and capabilities can impact the products themselves. In this area, EA does become involved to help insure that systems within IT are capable of handling the impact of large volumes, security threats, and consistent experience placed by those software products... but we do NOT decide what service to deploy to the public.
I hope that helps.
Thank you Nick for the thorough response. Now the difference is mostly clear to me.
One thing that I’m still not quite clear is the fact that if the role name has the word “architect” in it implies that he/she creates some kind of architecture. Usually in software (and perhaps in other disciplines) we can describe different architectural structures/views (such as design time view, run-time, deployment, etc.) in terms of components, relationship between them and interfaces.
Based on your examples above it looks like the EA is concerned about entire set of applications running at the enterprise. So using the definition of architecture above, his/her architecture consist of different enterprise applications and relationship between them and this is what he designs. And he/she is not probably concerned about how each component (individual application in this case) is designed internally; this is mostly job of a solution architect.
Does it make sense to think about EA’s architecture this way? Or does EA produce no architecture whatsoever and instead produces things like “set of priorities and judgments made about that book of work”? In that case the word architect is kind of misleading.
Remember that I said that EA produces a series of presentations and reports used to guide the management on the proper use of technology? Those reports are in the form of architectural models along with the "shiny button" text needed to make them clear to executives.
The term "shiny button" refers to the fact that the models have to be stripped of any detail that is not pertinent to a decision, and the decision needs to be framed in terms of a "shiny button" that any executive can understand whether or not they should pick it up.
So EA's do architecture. But they do it at the level that you discuss: interactions between applications.
Thank you for your time Nick, the role of EA makes more sense to me now.