Architect roles as seen in BCS professional certificates for enterprise and solution architecture

In an assignment for the British Computer Society, 1,100 job adverts with "architect" in the job title were analysed. The many titles included: technical architect, software architect, J2EE architect, data architect, process architect, etc. Adverts for enterprise architects featured terms like “strategy”, “engagement with senior executives”, “standards” and “governance”. And there were roughly 4 solution architects for every 1 enterprise architect.

Enterprise and solution architect roles do overlap, but in practice they are distinguished, and sometimes report to different managers. This article draws some distinctions that can be found in research of both the literature and the job market.

“I just wanted to take a minute and let you know how much I appreciate your contribution to this discussion. As you've so clearly stated, EA and SA are two different and distinct roles. … many are trying to answer a question long ago defined - what is an EA. I commend you on [answering] the question in a manner that clearly and firmly states the role of an EA. Brava!”

Contents

Architect roles. 1

Enterprise architect 2

Solution architect 3

Software architect 3

Business Architecture in an EA context 3

Solution architecture outside an EA context 4

Further contrasts between EA and SA.. 5

Enterprise Architect 5

Solution architect 5

Further reading. 6

Architect roles

Architect: [A role] that involves analysis of a context and requirements, analysing and choosing between options, defining an architecture, using principles and patterns, ensuring agreement of what is described, planning the move from the baseline state to the target state, and governing that change.

Higher level roles abstract from detail and operate more widely, with a broader scope. Higher level roles govern lower roles to some extent.

Architect domain Architect level	Business architect	Data architect	Applications architect	Technology architect
Enterprise architect
Solution architect
Software architect & other technical specialist

The architecture work space

The graphic above is a simple way to view architect roles. Different organisations divide the work differently, and define other specialist architect roles. Any one architect may work at more than level and in more than one domain.

Whereas enterprise-level architects often specialize in one architecture domain, solution architects are expected to know enough about all of the domains to have a coherent discussion with domain specialists.

(Note that design for non-functional requirements, especially security architecture, can be relevant at every level and in every domain!)

Enterprise and solution architect roles are contrastable on several scales; both may act in any of the four architecture domains, but their focus tends to differ in other ways.

Enterprise Architects tend to look to integrate systems across the enterprise, standardise processes, data definitions and technologies, be relatively strategic (typically, 2 to 10 years). and produce relatively abstract models and road maps.

Solution Architects may look to deliver a solution for a local function or unit, use parochial process and data definitions, and technologies, be relatively tactical (typically, 6 months to 2 years) and produce relatively concrete models and migration paths (also called road maps).

Enterprise architect

[An architect] who takes a cross-organisational and strategic view of business systems, looking to.

• optimise business systems by digitisation, standardisation and integration
• exploit business data captured by business processes
• identify potential innovations in business processes
• maintain enterprise-wide business, data, application and technology component portfolios
• maintain cross-organisational and/or strategic road maps
• shape, steer and govern the work of solution architects.

Solution architect

[An architect] who focuses on individual solutions and systems.

• addresses problems and requirements, related to specific processes and applications.
• aims to ensure the quality of solution delivery, in compliance with overarching goals, principles and standards where possible.
• describes solutions and govern their delivery, usually at a project level
• understands all domain/views well enough to work with all analysts and designers
• details a system architecture sufficiently for detailed design and building to proceed
• focuses on critical success factors, especially non-functional qualities.
• shapes, steers and governs the work of detail designers and implementers.

Software architect

[An architect] who addresses the modularisation and integration of software components, usually at a relatively fine-grained level.

Aside: Several principles and patterns of software architecture (such as encapsulation behind interface definitions, hierarchical composition, coupling v decoupling of components, orchestration v choreography of components) are so general that they are useful at higher levels of application and business architecture.

Business Architecture in an EA context

Enterprise-level architects describe the aims, activities and actors of an enterprise, along with the resources they need at an abstract level. A comprehensive enterprise architecture should cover:

• A.   Business Drivers which prompt the declaration of
• B.   Business Goals which are met by providing
• C.   Business Services/Products which are delivered by completing
• D.   Business Processes which are performed by actors playing
• E.    Business Roles which create and use
• F.    Business Data using
• G.   Business Applications that run on
• H.   IT platforms.

Any architect seeking to change elements at one level needs to understand the level above.

Business directors are responsible for business planning and defining A, B and C. Enterprise-level architects are responsible business system planning and defining C, D E, F, G and H, at an abstract level.

Business architects typically focus on C, D, E and sometimes F. Some consultants use the term “business architecture” more widely (across, for example, market research, product design, strategy setting, advice on mergers and acquisitions, and the sociological aspects of an organisation). Some distance business architecture from the IT support they need. However, EA has always been about the effective integration of human and computer activity systems. So, business architecture and EA may be thought of as overlapping sets.

Solution architects usually start with some business architecture activity. First, there is some kind of business case - outlining the benefits, costs and risks of a proposed change. Then, a target business architecture for a particular solution may describe both an external view of the system of interest (its inputs and outputs, products or services) and an internal view (its processes, roles/components and the information they create and use).

Solution architecture outside an EA context

Today, one major global service provider studied has no role called enterprise architect, because they consider that to be a role in their customers’ organizations. Their architect roles include Solution Manager, Solution Architect, Business Analyst and Technical Architect.

With or without any overarching EA, a solution to be designed and deployed needs a solution architect. And to be honest, compliance of a solution with EA standards and road maps can add to the time, cost or resources needed. So even where EA standards and road maps are in place, some SA may occur outside of, or even in conflict with, the EA.

Solutions designed and delivered with little or no regard to EA may include:

• Tactical solutions and silo systems
• Any bought or built solution or system that is given a waiver from EA (for a benefit, time, cost or resource reason).
• And any solution or system that is beyond the scope of EA jurisdiction.

Discussion of EA sometimes obscures the fact that so-called “road maps” can cut across one another. An aim of enterprise level thinking is to define long-term targets for an enterprise's business processes, applications, and platform technologies. To reach these targets, the enterprise needs strategic road maps showing where and when changes will be made. But meanwhile, more tactical solutions and silo systems must be developed and deployed. So, in practice, enterprise-level road maps can cut across solution-delivery-oriented road maps, or migration plans. The challenge is to progress the enterprise architecture while many if not most solution architects are working to shape and steer specific systems and projects.

Further contrasts between EA and SA

A solution architect is a leader and enough of a generalist to be able to coordinate all domain specialists. However to call all solution architecture “EA”, however small-scale, tactical and parochial, would be to put EA history into reverse gear. The risk is that the meaning of EA is diluted to the point it has no meaning.

The comparison below represents reasonable consensus about role differences.

Enterprise Architect

• title often used by enterprises for the manager or member of a central EA function.
• is strategic: addresses cross-organisational concerns and goals
• treats a whole enterprise as a system, the highest, widest, longest-term kind of architecture
• responsible for optimisation (often by integration or standardisation) of the enterprise system estate
• responsible for the quality and completeness of strategic road maps
• maintains enterprise architecture collateral in enough detail to enable impact analysis
• must understand the enterprise system estate
• must engage with senior executives and their strategies.
• is responsible for enterprise integrity and quality
• guides solution architects on cross-organisational standardisation and integration opportunities.
• may commission and govern solution architects working on discrete system developments.
• acts as a governor to ensure solution architects comply with any relevant overarching EA.

Solution architect

• title often used by systems integrators in the bid phase, and sometimes the delivery phase.
• relatively tactical: addresses specific problems and requirements
• focuses on selected business processes and applications.
• shapes and describes a solution, usually at a project level
• responsible for the quality and completeness of a solution outline or high-level design.
• describes architecture at a level sufficient for detailed design and building to proceed
• must understand all facets of design well enough to form a coherent solution architecture
• must partner with and coordinate lead business analysts, software architects and others
• is responsible for delivery quality: focuses on critical success factors, especially non-functional qualities.
• must identify and mitigate all manner of technical risks, with delivery time and cost in mind.
• governs solution delivery at a project level
• may or may not be asked to be heedful of any relevant overarching EA.

A domain specialist architect may contribute to a solution, but that doesn’t make them a solution architect. A domain specialist or solution architect may contribute to EA aims, but that doesn’t make them an enterprise architect.

Further reading

This article is not included in either of the two books written by me and recently published:

1. Systems thinking renewed
2. Applying systems thinking to EA.

The first is written mainly for college teachers and students. The second is written more for professional enterprise and solution architects. For extracts from the second book, read some of the other articles I have posted in Linkedin, notably Article 3 "The Architecture Workspace".