What exactly is an Enterprise Architect versus a Solution Architect?

https://www.linkedin.com/pulse/what-exactly-enterprise-architect-versus-solution-johan-carstens

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 organization's IT environment and engage wherever and whomever necessary to help guide project team's to deliver toward it. There are formal definitions out there.

I get the impression there are people out there that think an Enterprise Architect is a Solution Architect but work in enterprise organizations. 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 recognize that there are organizations 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 have 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 in governance activities.

For example, an Enterprise Architect may have Business Architects which document Business Strategies, Program and Project Portfolios, Business Processes and Roles as well as a number of other artifacts to help analyze them such as mapping artifacts.

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 be involved at the earliest point a new business initiative is created and do very high-level 'solutioning' via whiteboard and reference to future state architecture elements. Then, when the business initiative gains momentum and is backed by Enterprise Architecture future state concepts, 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 to provide 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 artifacts 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 complementary 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.

 If you need a strong and experienced Enterprise Architect "consultant" to lead or steer challenging IT projects including technology road-maps feel free to contact me.

Johan Carstens - Enterprise Architect

Milton Keynes - UK 

Johan.carstens@cio-services.co.uk, 07850063850 

 Hi All, 
Thank you for the great feedback and forwarding on this post, It would be very interesting to understand the key benefits you feel and Enterprise Architecture brings to your organisation and the role Enterprise Architecture play in the business as a whole. 

SA vs SA, BA vs BA, EA vs SA

 

Business Analyst vs Business Architect

http://enterprisearchitects.com/bridging-business-analysis-and-business-architecture-australia/

 

http://www.infoq.com/news/2012/04/analysts-architects

 

http://blogs.msdn.com/b/nickmalik/archive/2012/04/06/the-difference-between-business-architect-and-business-analyst.aspx

Software Architect vs Solutions Architect

http://www.cutter.com/content-and-analysis/resource-centers/enterprise-architecture/sample-our-research/ea120725.html

 

http://www.quora.com/What-is-the-difference-between-a-Software-Architect-and-a-Solutions-Architect

http://stackoverflow.com/questions/524941/whats-the-difference-between-solutions-architect-and-applications-architect

https://www.linkedin.com/groups/What-is-solution-architect-What-1523.S.210487640

EA vs SA

http://blogs.msdn.com/b/gabriel_morgan/archive/2007/09/02/enterprise-architect-vs-solution-architect.aspx

The Role of Solution Architect

 

http://www.cutter.com/content-and-analysis/resource-centers/enterprise-architecture/sample-our-research/ea120725.html

The role of an architect is often loosely or ill defined so I'm not surprised when people ask me what I think an architect's role should be, and how one type of architect relates to another. In reality, this is to be expected given the range of needs, projects, processes, and organizational structures at different companies. Just today, two different clients asked about the role of a solutions architect, particularly in relation to an enterprise architect.

The table below summarizes the main differences that I typically see.

Table 1 -- Comparison of Solution and Enterprise Architects

Topic
Solution Architecture
Enterprise Architecture

Scope
Single solution or set of related solutions
All current and future solutions and COTS

Primary Goals
Ensure that the solution fits within the enterprise context
Define the enterprise context including business, information, application, and technology

Responsibility
Translates nonfunctional and functional requirements into design, within enterprise context
Translates strategies into target architectures and roadmaps

Tradeoffs
Enterprise strategy and goals vs. solution tactical and delivery requirements
Prioritization and rationalization of conflicting business, information, and technology requirements

Primary Artifacts
Solutions architectures and designs
Enterprise reference architectures, patterns and standards

Primary Stakeholders
Solutions owners, EA, development team, technology
Executive leadership, business leaders, CIO, solutions

Characteristics
Credibility with solutions teams and owners
Broad knowledge and experience, vision

Skills
Conceptualization, patterns, modeling, design, communications
Contextualization, conceptualization, abstraction, modeling, communications

Reporting Structure
Assigned to and functions as part of solution team; may report to solution owner or line of business, development, or EA
Reports to EA team, typically part of CIO organization

Regardless of their role and title, architects apply architecture skills, principles, and best practices. Both architects want to establish a few fundamental concepts:

• What things need to be the same to achieve goals, efficiency, and effectiveness?
• What things need to be different to achieve competitive, geographical, and other requirements?
• How do the similarities and differences fit together in context?

The most obvious difference is the scope to which these are applied. An enterprise architect has an enterprise-wide scope, while a solution architect has a narrower scope. The difference in scope leads to perhaps the most important distinction between these two roles, which is the primary goal of the architect. An enterprise architect wants to answer these questions at the enterprise level and define the enterprise context of what things need to be the same (such as common customer information), what should be differentiated (such as partner relationships and policies), and how they fit together. In coming up with the enterprise context, the EA must consider business, information, application, technology, and security concerns.

Given that context, the primary goal of the solution architect is to ensure that the solution fits within the enterprise context. This means that the solution aligns with business goals and processes, uses and provides enterprise information consistently, integrates effectively with other applications, supports a common application environment and user interaction model, uses the common technology platform, and achieves enterprise level security, QoS and scale. However, the solution team in general is focused on the specific solution and may not have a very good understanding of the enterprise context. Therefore, the solution architect acts as a bridge between the Enterprise Architecture and the solution to make sure that the solution fits within that enterprise context.

In achieving these goals, each architect has different responsibilities, makes different tradeoffs, has different stakeholders, and creates different artifacts. And while the skill sets are similar, there are a few important priorities. Perhaps the most important quality that the solution architect can have is credibility with their stakeholders. If the architect is trying to influence business process design, then they better have some knowledge and experience with BPM. If they're trying to influence software design, then some foundation in software engineering will be important. While credibility is obviously important for an EA, we also require the EA to have an understanding of a broad range of topics and widely varied experience. In addition, it is critical for the EA to be able to envision the future state of the enterprise and translate that vision into a target architecture.

A less important distinction is the actual reporting structure. I have seen solution architects report to the development team, a line of business, a solution owner, or even be part of the EA group. (Actually, I often recommend that EA provide a solution architecture team whose members are assigned to solution projects.) Rather, what is more important is that the solution architect acts as the bridge between the solution and the enterprise context and architecture so that both sets of goals are achieved.

I welcome your comments about this Advisor and encourage you to send your insights tomrosen@cutter.com.

-- Mike Rosen