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
Single solution or set of related solutions
All current and future solutions and COTS
Ensure that the solution fits within the enterprise context
Define the enterprise context including business, information, application, and technology
Translates nonfunctional and functional requirements into design, within enterprise context
Translates strategies into target architectures and roadmaps
Enterprise strategy and goals vs. solution tactical and delivery requirements
Prioritization and rationalization of conflicting business, information, and technology requirements
Solutions architectures and designs
Enterprise reference architectures, patterns and standards
Solutions owners, EA, development team, technology
Executive leadership, business leaders, CIO, solutions
Credibility with solutions teams and owners
Broad knowledge and experience, vision
Conceptualization, patterns, modeling, design, communications
Contextualization, conceptualization, abstraction, modeling, communications
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 firstname.lastname@example.org.
-- Mike Rosen