EA and SA roles in Avancier Methods

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.

 

EA and SA overlap, they must run into each other; but it is helpful nevertheless to distinguish them.

This paper 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!”

What differentiates EA from SA?

In an assignment for the BCS in 2008, 1,100 job adverts with "architect" in the job title were analysed.

There were many titles: 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”.

There were roughly 4 solution architects for every 1 enterprise architect.

 

EA and SA are contrastable on several scales; both should span the four architecture domains, but their scope tends to differ in other ways.

Enterprise Architecture tends to

Solution Architecture may (without an overarching EA)

Look to integrate systems across the enterprise

Deliver a solution for a local function or unit

Standardise process and data definitions

Use parochial process and data definitions

Be relatively strategic (typically, 2 to 10 years)

Be relatively tactical (typically, 6 months to 2 years)

Produces relatively abstract models and plans

Produce relatively concrete models and plans

SA without EA

Today, the key roles in a major global service provider include Solution Manager, Solution Architect, Business Analyst and Technical Architect

They have no role called enterprise architect, because they consider that to be a role in their customers’ organizations.

 

A solution to be designed and deployed needs a solution architect - with or without any overarching EA.

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 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.

EA and  Business Architecture

Solution architecture usually starts with some BA activity.

First, there is some kind of business case - outlining the benefits, costs and risks of a proposed change.

Then, the target business architecture definition is likely to describe

·         an external view of the business system: its inputs and outputs (products or services).

·         an internal view of the business system: its processes, roles/components and the information they create and use.

 

What some consultants choose to call “Business Architecture” ranges more widely across, for example:

·         market research, product or service design, strategy setting, advice on mergers and acquisitions

·         the sociological aspects of an organisation, human nature and motivations.

 

Some distance what they call Business Architecture from information systems and the IT they need.

OK, but EA has always been about the effective integration of human and computer activity systems.

So, Business Architecture and EA are probably best thought of as overlapping sets.

EA contrasted with SA

This table below represents reasonable consensus.

 

Enterprise Architect

Solution 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.

·         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 partnership 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.

 

A solution architect is leader and enough of a generalist to be able to coordinate all domain specialists.

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.

Orthogonal EA and SA road maps

Scoping architecture work (breadth, depth, time, cost, resources etc.) is a challenge

Much discussion of EA 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.

In practice, enterprise-level road maps can and often do cut across solution-delivery-oriented road maps.

The challenge is to progress the former while many if not most solution architects are working to shape and steer specific systems and projects.