(Update: To illustrate the “knot-weed ” that can grow out of fertile misunderstandings of architectural roles in a real-life organization, perhaps this might be one sobering example. One might think, for a single person, even “Neo” has no that much powers.)
One question is often asked, at least into my direction. What is the actual difference between Enterprise Architect and Solution Architect?
First of all, there are much more roles for Architects in any modern business. But let’s answer that later. To help the understanding of the audience I often use the following analogy:
The Enterprise Architect is like a town planner. Solution Architect is designing the buildings in that town.
Thus Solution Architecture starts inside the boundaries defined by enterprise architecture.
With my TOGAF hat on, I would say: Top level Architecture continuum of an organization is defined by Enteprise Architecture. Principles and Artefacts and Reusable Blocks.
So Enterprise Architects are “Town Planners”. Let me try and “push” onto you a bit more detail on that side of the analogy, with the following resource.
Enterprise Architects aka Town Planners role is divided bellow, in the word of Urbanism and Building Architecture, into Urban Design and Planning. The latter we might call “Strategy” in the Enterprise Architecture continuum. (click on the image to see the source)
[2009 July 1, original post]
Here is a real-life example: a few days ago I talked to an Architect from real and large UK IT company. His role: an (Azure) Solution Architect.
Hi certainly knew how to migrate the legacy data to the Azure. Technically. But he was completely unaware of compliance issues surrounding the legacy data. Enterprise Architect job would be to plan for that. If EA would be appointed, EA would make blueprints for solutions architects to follow. As a such, he does not administer any system or does not do any development. Or manage any developers.
Still not thinking of hiring an EA? Migrating legacy data to the Cloud, after 25 May 2018, without planning and doing it in a compliant way, is probably the most expensive mistake that one business can make.
For those wanting more here is one more detailed and longer post ( Published Sunday, September 02, 2007 9:18 AM by Gabriel Morgan )
What exactly is an Enterprise Architect versus a Solution Architect? I’d like to chat about the difference because I’m not confident everyone understands this well.
It’s actually quite simple. I propose that a Solution Architect is a project team role that is responsible for the system quality of the solution being delivered to the business. I also propose that an Enterprise Architect is a planning role that is responsible for identifying the future state of an organisation’s IT environment and engage wherever and whomever necessary to help guide project team’s to deliver it. There are formal definitions out there but I thought I’d simplify it for the purposes of this blog post.
I get the impression there are people out there that think an Enterprise Architect is a Solution Architect but work in enterprise organisations. I also have the impression that there are people out there that think an Enterprise Architect is someone who only works with Powerpoint, collects information from Solution Architects and spends the majority of their time with the business leads and governance boards merely reporting on the information they’ve pulled together. Although I recognise that there are organisations in situations that implement Enterprise Architect and Solution Architect like this, I believe they are inefficient and are likely in a transition state to the more efficient role definitions I proposed earlier.
Taking my proposed definitions, I’d like to identify architect subtypes to help support the difference between them to help describe what I’m talking about.
A Solution Architect may have a number of different types of architects working for him/her to help accomplish their task for delivering a high-quality solution. For example, s/he might have an Infrastructure Architect to manage the architecture of the solution’s hardware configuration so that the solution meets the Quality of Service business and IT requirements while at the same time represents the optimum way to deploy the solution into the target production environments.
There also might be a need for ‘specialist’ architects depending on the complexities of the business requirements or the target production environment. Such ‘specialist’ architects usually are called Domain Architects and examples include; Security Architect, Technology Architect (ie architects that specialize in a specific product or technology), Vertical Architects (ie architects that specialize in systems that are specialized in particular industry verticals such as Financial Services Industry, Telecommunications, Public Sector, etc).
An Enterprise Architect may have also had a number of different types of architects in order to piece together a coherent, actionable future state architecture which can easily map to business strategy, be consumed by project teams and be a major contribution to governance activities.
For example, an Enterprise Architect may have Business Architects which document Business Strategies, Business Capabilities, Business Processes and Roles as well as a number of other artefacts to help analyse them such as mapping artefacts.
An Enterprise Architect may also have Information Architects who document the information models such as Data Subject Areas, Data Facets, Business Objects, Business Entities and Data Entities with the intention of supporting the Business Processes while at the same time designing for data integrity and data quality for the enterprise.
An Enterprise Architect may also have Infrastructure Architects (aka Technology Architects) that focus on the hardware and operating system-level infrastructure.
Lastly, an Enterprise Architect may also have Solution Architects (aka Enterprise Solution Architects and Enterprise Application Architects) who focus on pulling all of the other Enterprise Architecture information together to shape the future state application system architecture.
Here is one place where I think there is confusion by many. You see, I described a Solution Architect at the project-level and an Enterprise Solution Architect across the enterprise and both share the words ‘Solution Architect’ in their role. They have VERY different purposes but are very complimentary. Could it be that simple of a reason why confusion exists? It just might be.
An Enterprise Solution Architect and project Solution Architect roles are very complimentary and because this relationship is of particular interest to me I’d like to take a moment and propose how they are to work together.
I propose that the Enterprise Solution Architect is involved at the earliest point a new business initiative is created and do very high-level ‘solutions’ via whiteboard and reference to future state architecture elements. Then, when the business initiative gains momentum is backed by Enterprise Architecture future state analysis the core project team is formed and the project Solution Architect takes over to be responsible for the solution. The Enterprise Solution Architect becomes a member of the project Solution Architects team and is responsible for the system integration architecture where the solution requires integration between enterprise systems as well as be responsible for providing future state system architecture guidance to help the project Solution Architect make decisions on which systems to commit to using in the solution. The Enterprise Solution Architect then is involved in governance boards to inform decision-makers with future-state architecture artefacts to help justify major technology, system, or business value decisions. That’s it.
As a quick summary, project Solution Architects and Enterprise Architects are different in that they have very different purposes. They are highly complimentary in that Solution Architects focus on delivery of solutions and Enterprise Architects focus on supporting them by documenting future state, participating on their teams and being involved in governance activities.