Business architect roles

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.


Where is the business architect in the architecture work space?. 1

BA as defined in the Skills Framework for the Information Age (SFIA) 2

BA in a TOGAF context 2

Remarks and further reading. 3


Where is the business architect in the architecture work space?

Other papers on the define the architecture work space below.

Business architects work mostly the  business column, with some attention to the information/data and applications columns.


Architecture Work Space



















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.

BA as defined in the Skills Framework for the Information Age (SFIA)

The SFIA definition treats BA as a subset of EA. This typically involves the

·         interpretation of business goals and drivers;

·         translation of business strategy and objectives into an "operating model";

·         strategic assessment of current capabilities

·         identification of required changes in capabilities; and

·         description of inter-relation-ships between people, organisation, service, process, data, information, technology and the external environment.

·         formation of the constraints, standards and guiding principles necessary to define, assure and govern the required evolution;

BA in a TOGAF context

TOGAF says that on starting a cycle of work:

"... little or no Business Architecture work may have been done to date.

In such cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support.

This may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A."


TOGAF provides a management framework for business process modelling and Business Architecture techniques.

It devotes a whole chapter to business scenario analysis – more than it does for any other technique.


TOGAF has one phase (B) dedicated to Business Architecture.

It assumes knowledge of the following business architecture techniques and products.

“The level and rigor of decomposition needed varies from enterprise to enterprise”


"Business scenario analysis" (cf. value stream analysis)

In essence: this involves designing a business process along with the human and computer roles and resources required for it.

"the ADM has its own method for identifying and articulating the business requirements implied in new business capability to address key business drivers, and the implied architecture requirements...

“This process and may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture."

(See further reading below.)


"Structured analysis" (cf. capability-based planning)

In essence: Define the organisation structure. Define the logical functional structure. Map functions to organizational units. Map functions to processes.

One scopes a business function/capability by the services it offers and the processes steps it performs, and maps it to organisation units and roles.

These are natural outputs not only of a "structured analysis" exercise, but also “capability-based planning”.

(See further reading below.)

"Business process modelling"

In essence: Identify processes needed to supply business services. Decompose process into steps (activities). Map activities to functions. Identify services and resources needed by activities.

"Process Flow diagrams show sequential flow of control between activities and

may utilize swim lane techniques to represent ownership and realization of process steps."
Swim lanes may be used to show organisation units, roles, business functions or applications.

 (See further reading below.)

"Use case analysis" (cf. Information System Services)

In essence: Define the uses that actors playing roles make of an information system, and identify lower level automated services needed to complete a use case.
Use cases connect Business Architecture to Information Systems Architecture.

"the application that supports a process step may be shown as a swim lane."

The connection between process step and application represents one or more use cases.

Defining the use cases or information system services is an application scoping decision.

(See further reading below.)


TOGAF is concerned with the effective integration of human and computer activity systems.

And less with the most human aspects of an organisation: building facilities, management reporting structures, benefits packages, etc

Responsibility for designing the latter may lie with a parallel “business change" team, HR, business managers, etc.

Remarks and further reading

TOGAF is a management framework for architects and high-level analysis and design activities.

It does not explain its artifacts, let alone processes to produce them.

It users are supposed to be architects who already know how to

·         do structured analysis

·         do business process modelling

·         architect solutions

·         analyse application usage and define use cases

·         analyse data and build business/conceptual/logical data models

·         analyse data dissemination and draw a view of that

·         define applications communications - reflecting a data dissemination view

·         analyse a scenario and draw a process system realisation diagram,


Avancier Methods include relevant processes and products

You can find some of them on the Products and Techniques page at htttp://

·         Business diagrams (TOGAF and ArchiMate)

·         Business Functions and Capabilities

·         Capability-based planning (with ArchiMate diagrams or TOGAF artefacts)

·         Structured analysis views (after IE)

·         Process modelling with BPM.



Copyright conditions

Creative Commons Attribution-No Derivative Works Licence 2.0             02/12/2015 00:38

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see