The practice of business architecture
Nine views of
the business architect role and its core concepts
Copyright 2017 Graham Berrisford. One of about 300 articles at
http://avancier.website. Last updated 11/11/2020 12:55
At the time of writing, the Wikipedia page on business architecture is a partial, narrow and shallow, and marked as subjective.
And some videos on business architecture by management consultants are pretentious and/or mind numbing.
The aim here is not to promote any particular approach to business architecture – it is only to report and collate what is said in job advertisements and industry standards.
However, something approaching a consensus emerges from the research.
This article updates some research done in 2008 for the British Computer Society’s professional certificates in enterprise and solution architecture.
It is a companion to this newer slide show on business architecture its terms and concepts, and how they relate to each other.
And this older article on the science of business architecture.
Contents
Preface:
positioning BA within EA
The
BA role as employers and recruiters see it
BA
in the Skills Framework for the Information
Age (SFIA)
BA
in Business System Planning
BA
in BOST (relating BA to IT)
How
do business architects differ from business analysts?
More
on the business architect role
Four millennia have passed since the
dawn of civilization and the first business systems were devised.
A mere four decades have passed since
Enterprise and Business Architecture approaches emerged.
Business architects look, across the
breadth of an organisation, to improve, integrate and innovate business
processes.
Most approaches start with some strategic analysis of core
business processes and the data
they need.
In 2006, the popular book "EA as Strategy" urged
enterprises to define their business operating model in terms of core business processes and information.
Modern business roles and processes rely
on IT to store and transmit business data.
So EA can’t ignore IT; however, it
remains focused on supporting and enabling business roles and processes.
Mainstream EA first addresses business processes and information, and only then what they need by way of applications and computing infrastructure.
Since
the PRISM report of 1986, architecture has been divided into the four domains
in the columns of the table below.
The top row of the
table positions EA as a high-level cross organizational and strategic view of
business systems.
|
Domain Level |
Business |
Data/Information |
Applications |
Infrastructure technology |
|
Enterprise architecture |
Business roles & processes, standardization, integration and road maps |
Business data standardization, integration and road maps |
Business application portfolio standardization, integration and road maps |
Platform technology portfolio standardization, integration and road maps |
|
Solution architecture |
Outline design of a solution’s required processes |
Outline design of a solution’s data architecture |
Outline design of a solution’s application(s) architecture |
Outline design of a solution’s IT production environment |
|
Detailed design |
Detailed design of processes & use cases |
Detailed design of data stores and flows |
Detailed design of software architecture |
Detailed design of IT production environment |
Every enterprise has to work out for itself how
its roles cover the cells of the table.
But clearly, the focus of a business architect is
in the top-left quadrant.
Business architects
support business directors.
· are concerned with the services provided by a business.
· must engage with what directors declare by way of goals/strategies/plans that change the market or services of a business.
· may stimulate or contribute to innovations in services, and strategic business planning of the kind done by directors.
However, the
business architect role is distinct from that of a director.
As
described in the job advertisements, industry standards and frameworks below,
the role is more about business system
planning.
Business architects
· analyse current business operations, then design and plan changes to them, with a business case for doing so.
·
must understand where roles and processes
can be supported and enabled by applications, and opportunities that IT can bring.
· are involved in stakeholder management, risk management and must have good communication skills.
Enterprise and business architects are concerned with the services provided by a business.
And with how those services are delivered by processes that refer to and advance the state of the business.
The services are behaviors that deliver results of value to actors with a stake in the business.
E.g. Take out a loan. Complete a tax return. Direct an airplane take off. Conduct a research project.
The role of a business architect can include the identification of service improvements and innovations.
The
processes are sequences of activities that a business must perform to complete
and provide services.
The role of a business architect can include process improvements and
innovations.
The state of a business is represented in information found in the data structures of messages and memories.
The role of a business architect can include improvements and innovations in data capture and use.
You don’t have to model every business activity that could possibly be documented.
You model what you need to understand, then choose what to communicate to others - simplifying as need be.
What can be modelled?
This slide show on business architecture illustrates how architects model business systems.
This table shows how an architect may approach the description of a business, or of a required business change.
|
A simple approach |
A simple illustration |
|
1)
What are the goals
of the business? |
Attract more
customers to the hotel |
|
2)
What services will
the business offer/provide to achieve those goals? |
Valet parking of a
car |
|
3)
What processes
must be performed to deliver those services? |
Park and retrieve
a customer’s car |
|
4)
What roles are
needed to perform the activities in the processes? (And how many actors in
each role?) |
Valet (3) |
|
5)
What organisation
structure is needed to manage the actors? |
Front desk
management |
|
6)
What are the locations
where the processes are performed? |
Hotel entrance and
car parks |
You can find corresponding concepts in many standards and sources on business architecture.
E.g.
The SFIA standard’s definition of the business architect role refers to goals, functions, services, processes,
information, roles and
organisation.
Which of the concepts above appear in definitions of the business architect role in job adverts, industry standards and frameworks?
Read on to find out. Beware there is terminology torture out there.
Both public and
private sector role definitions below refer to goals,
processes, information,
and organisation.
Note that some employers see the business architect role as related to computing/software/technology.
“As part of a dedicated Business
Architecture team you will be working at a macro level,
to design business models to shape
change initiatives in support of the strategic business goals.
Responsibilities:
· Develop business models to support
strategic goals of the business
· Apply structure design methodology
when capturing requirements from the business
· Identify structural issues within the
business and use innovative design models to maximise efficiencies
· Work closely with IT to align
technical capability to business needs
Key Skills:
· Experience in a business architecture
role within the insurance industry
· Extensive experience developing business strategy
· TOM design exposure
This is an excellent opportunity to join a leading process-focused architecture function within the insurance market.”
The business architect in this advertisement defines business processes and connects them to IT.
To “develop the business strategy” surely means to elaborate and realise the “strategic business goals” by optimising and changing business processes.
To connect those processes to IT, architects must define the information created and used at each stage or step.
This business architect is expected to use analysis techniques: business requirements capture, structured analysis and design methods and models.
The generic job description below is quoted from the Canadian government web site in 2018. https://www.tpsgc-pwgsc.gc.ca/app-acq/sp-ps/entreprise-business-eng.html#d2
“Business
Architect
Experience Levels: Junior: < 5 years of experience; Intermediate: 5- < 10 years of experience; Senior: 10+ years of experience, or 5+ years of experience with a recognized professional certification.
Responsibilities could include but are not limited to:
Develop policies and rules that allow an organization to carry out its mandate and functional responsibilities,
and that govern the organization's actual and planned capabilities in terms of computers, data, information, human resources, communication facilities, software and management responsibilities.
Develop the specifications for where, how and why the various organizational components fit together as they do, and how they support the organization's mandate.
Specialties could include but are not limited to BPWin, Oracle CASE, Rational Rose and RUP.”
The generic job description below is quoted from the CW jobs web site in 2018. https://www.cwjobs.co.uk/careers-advice/profiles/business-architect
“Business architect job description
Typically business architects report to the programme director and work alongside the firm's most senior business process executives and stakeholders.
They may report to the IT department, or to the business.
Business process management (BPM) projects need an effective IT architecture.
Working hand-in-hand with the change manager, the business architect takes the lead in developing that architecture.
The business architect fleshes out the business model and describes the need for business technology across the organization and the role that process plays.
Business architects have deep pockets of business knowledge but also see the big picture.
Necessary talents encompass process discipline skills in methodologies such as Lean and Six Sigma.
They’re a hybrid beast and so need a rare combination of business domain knowledge, process experience, transformation talents and methodology skills.
On top of that, you need a winning
personality to bring disparate parties together.
The best business architects have got their hands dirty designing and building technology platforms and can intellectually strip a system down to the hardware and software nuts and bolts.
Additionally, they know all about large-scale, cross-functional processes and systems: supply chain management, enterprise resource planning (ERP), finance, or customer resource management (CRM) are meat and drink to them.
Many business architects end up in financial services where the business
environment of compliance and regulation is complex and fast-changing.
But other sectors working on a similarly large and complex scale (utilities and transportation outfits, energy trading exchanges, telecoms and retailers) are advertising business architects jobs on CWJobs right now.”
SFIA is an international standard for role
definitions used by employers that includes enterprise and solution architect
roles.
E.g. SFIA’s
definition of the business architect role refers to goals,
functions, services, processes, information, roles and organisation.
SFI treats business architecture as a subset
of enterprise architecture.
It says that enterprise and business
architecture roles involve:
· interpretation of business goals and drivers;
· translation of business strategy and objectives into an "operating model" (see note below)
· assessment of current capabilities [cf. functions] and identification of required changes to them;
· description of inter-relationships between business system elements:
o services (resulting from business activities)
o processes (sequencing business activities)
o data, information (created and used by business activities)
o technologies (supporting and enabling business activities)
o people (playing roles in business activities)
o organizations (managing people employed in business roles)
o the external environment (notably customers, suppliers, partners, competitors and other stakeholders)
· formation of constraints, standards and guiding principles necessary to define, assure and govern the required business change.
Some terminology
torture
A business strategy
usually features business goals/objectives,
declared in response to business drivers.
Sometimes it means plan for activities to achieve those goals, perhaps along with some directives (principles
or policies).
A business operating
model in "EA as Strategy" (2006) is an abstract graphical
representation of core business processes and information.
Others use the term to mean a more detailed description of
business actors and activities, structures and behaviors.
A business model is
sometimes used as a synonym of operating
model.
Others mean a business
model canvas, or similar diagram or conceptual tool, indicating
·
how a business makes
money by way of revenue and profit
·
what “value
proposition(s)” the offers customers by way of services
·
the core business processes and resources
·
entities the
business has relationships with.
Here, service-orientation means encapsulating
a system behind an interface composed of the services
the system is required to provide.
The output of a business service may be a tangible "product" or something more intangible – such as advice, be it oral or documented.
EA and BA are much older than today’s TOGAF and BizBOK and have always been about Process and Data before Technology.
Perhaps the first was that of IBM’s Business System Planning, created by Duane Walker in the 1970s.
I am told that IBM's GE20-0527-2 (1978) Information Systems Planning Guide publication was the first definitive guide to business systems planning.
It was source for John Zachman in the 1980s, and set the pattern for other EA meta models in the 1980s and 90s.
Another source (lost to me) reported that the Business System Planning meta model featured these 7 entities and 8 relationships.
· Problems <are solved by > Processes <are enabled and supported by> Applications
· Business entities <are represented by> Data entities <are maintained in> Data stores
· Organisations <perform > Processes <create and use> Data entities
· Organisations <use> Applications <access> Data stores
Notice the focus on Processes and Data used in the Business, rather than IT.
An EA/BA framework typically catalogs entities of importance to a business under hierarchical structures.
The Business
Transformation Framework (BOST), endorsed by CISCO
and Informatica, is generalized from a reference model for a retail
business called ProAct.
BOST is a simple, traditional, EA
framework.
It adds a “business view” over the top
of the business, application and technology domains/layers of enterprise
architecture.
|
BOST |
Features |
|
|
Business architecture |
Business view |
Enterprise market, products,
relationships and resources |
|
Operations view |
Business functions/capabilities, information subjects and flows |
|
|
IT architecture |
Systems view |
Application components and information exchanges |
|
Technology view |
Technology components and devices |
BOST users build a hierarchical structure to describe each view.
Then map elements in one view to
elements in the other views; e.g. map applications to business functions.
The function hierarchy in BOST
You will surely be familiar with a hierarchical organisation or management structure.
Many EA approaches
use a business function hierarchy to impose a purely logical
structure over an
organization’s business activities.
BOST says this provides “a structured definition of
all essential operations capabilities.”
“Functions are independent of:
· organization [the management structure];
· where work is performed [locations] or
· who [roles] performs it; and
· how the work is performed [process
flow sequences].”
For more on what it means to create and use a function hierarchy, and map hierarchies to each other, read The science of business architecture.
More terminology
torture
Note the terminology torture in these three business architecture reference models:
·
In
ProAct for a retailer - the function
hierarchy, from the top down, features capability
area, service function and basic service function.
·
In
PCF for a commercial business - the function hierarchy is called a process hierarchy.
·
In
BIAN for a bank- the function hierarchy is called a service landscape.
BOST
uses function
and capability interchangeably.
It
uses service
where TOGAF says component or building block.
And
by system it means business application (a very narrow use
of the term system.).
BiZBOK
is a relatively young collection of guidance on business architecture. Its
founders say:
“Business
architecture serves as a bridge between strategy and execution.
•
Framing and communicating impacts of strategic
business objectives
•
Aligning strategies and plans across business units
•
Realizing business model aspirations
•
Enabling strategic business transformation”
Other stated uses of business architecture include:
•
“Framing business requirements
•
Scoping IT investments
•
Defining target state IT architectures
•
Integrating companies during a merger or
acquisition.”
Biz BOK defines business architecture thus.
“Business architecture represents holistic, multidimensional business views of capabilities, end-to-end value delivery, information, and organizational structure as well as the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.”
Some more terminology torture.
At the time of writing, some of BizBOK’s glossary definitions are abstract or vague to the point of not being definitive.
Note that a “capability map”
corresponds in appearance and use to a function
hierarchy in some other
sources.
What BizBOK
calls “function” may be called by others a process.
The term “end-to-end value delivery”
suggests the flow of business processes from suppliers to customers.
The term “information” refers to the meanings created and found - by activities in business processes - in data structures.
This table maps BizBOK’s terms and concepts to those in SFIA (before this
section) and TOGAF (after this section).
|
In BizBOK terms |
In SFIA terms |
In TOGAF terms |
|
holistic,
multi-dimensional business views of |
|
cross-organizational,
multi-dimensional views of |
|
capabilities
(see notes below) |
current and
required capabilities |
business functions (see notes on hierarchies below) |
|
end-to-end
value delivery |
processes |
business
scenarios and processes, |
|
information |
data, information |
business
data/information |
|
organization structure |
people and organizations |
organization decomposition |
|
relationships
among these business views and |
|
mappings of
the above views to each other and to |
|
strategies |
business
strategy, goals and drivers |
business
strategy, drivers, goals and objectives |
|
products |
services |
business services |
|
policies |
constraints,
standards and principles |
business
principles and policies |
|
initiatives |
the required
business change |
business vision,
requests for architecture work |
|
stakeholders. |
the external
environment |
stakeholders
and their concerns. |
BizBOK defines an enterprise “on a page" as a high-level business capability map that is independent of the organization structure and process flows.
It suggests you layer heat maps on that map to show areas of concern or change.
You can map each key capability to the organization units needed to realise that capability (in a capability/organization matrix).
That is exactly how TOGAF describes the use of functional decomposition.
And this description of business capability modelling also reads very like a description of functional decomposition.
It is good in many ways, but misleading on a few points.
Read The science of business architecture for more detailed analysis.
TOGAF started as an IT Architecture framework c1995, without reference to EA and BA history.
TOGAF versions 1 to 7 were about rationalising platform/infrastructure technologies.
TOGAF version 8 was radically revised in 2002 with a focus on transforming business systems to meet business goals/objectives.
It is a management framework for the architecture projects on which both business and IT architects work.
The aim is to ensure (taking a cross-organizational view) that
business processes and roles
help a business meet its goals.
TOGAF assumes architects define a target business architecture and
plan how to get there.
It recommends some business architecture effort before embarking on any change initiative.
It says that on starting an “architecture project”...
"... 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 [goals] 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 version 9.2 described business architecture as capturing architectural models of:
“business operations [processes], factors that motivate the enterprise [drivers],
how the enterprise is organizationally structured, and what functional capabilities the enterprise has.”
This table lists maps this definition to some core business architecture entities, and to other terminologies.
|
TOGAF 9.2’s definition of business architecture |
Some core entities |
In SFIA’s definition |
In BizBOK’s definition |
|
“Business operations |
Processes and Roles |
processes |
end-to-end value delivery |
|
“factors that motivate the enterprise” |
Drivers and Goals |
business strategy, goals and drivers |
strategies |
|
“how the enterprise is organizationally structured” |
Organization units and Actors |
people and organizations |
organization structure |
|
“what functional capabilities the enterprise has” |
Business functions |
current and required capabilities |
capabilities |
TOGAF 8 and 9 mostly presumed architects already know architecture definition techniques and artifacts
However, it outlined the ones listed below.
TOGAF provided a process and products for business architecture, as listed in this table.
|
Business architecture process in TOGAF 8.1 |
Business architecture artifacts in TOGAF 9.1 |
|
1. Document the organization structure, relating locations to organization units. |
Organization Decomposition
diagram Business Interaction matrix/diagram |
|
2. Document business goals and objectives for each organization unit. |
Driver/Goal/Objective catalog |
|
3. Define business functions... successive decomposition... into sub-functions. |
Functional Decomposition diagram |
|
4. Define business services each unit provides to its customers, internal and external. |
Goal/Objective/Service diagram Business Service/Function catalog |
|
5. Define business processes, including measures and deliverables. |
Process Catalog, Flow diagrams |
|
6. Define business roles, including skills requirements. |
Role catalog |
|
7. Define business data [information] model. |
Conceptual Data diagram |
|
8. Relate business functions to organization units in the form of a matrix |
Function/Organization matrix |
Note: Business architecture is not limited to supply chain businesses that process and produce concrete products.
TOGAF defines business functions in terms of the services they are required to provide.
The entry conditions to a service include any trigger or input; the exit conditions include any output or product produced.
It then defines the processes and roles needed to deliver a service.
And defines information created and used in business processes in a business/conceptual data model/diagram.
TOGAF 8 and 9 assumed knowledge of the following techniques for modelling business activities, both in a structure and in sequences.
Structured analysis
This completes a function
hierarchy and maps its nodes to organisation
units and to processes.
Read The science of business architecture for a general description of structured analysis.
The following
specific techniques appear in TOGAF.
Functional decomposition (cf. business
capability mapping)
“Functional decomposition diagram [shows] on a page the capabilities of an organization.
By examining the capabilities of an organization, it is possible to quickly develop models of what the organization does
without being dragged into debate on how the organization does it.
... layer heat-maps on top of this diagram to show scope and decisions.
E.g. the capabilities to be implemented in different phases of a change program.”
Business scenario analysis (cf. value stream
analysis)
This is used to discover and document business requirements.
It involves defining a process
to meet a goal, along with the roles of human and computer actors.
The template for describing a scenario starts
thus:
· “Problem description: purpose [goal] of the scenario.
· Detailed objectives.
· Environment and process models: process description, process steps mapped to environment and to people, information flow.
· Actors and their roles and responsibilities: human actors and roles, computer actors and roles, requirements.”
Note: architects usually document roles rather than individual actors (an exception being named organization units).
Like functional decomposition, scenario definition starts at the highest cross-organization level.
“[Business scenarios] may be used iteratively,
at different levels of detail in the hierarchical decomposition of the Business
Architecture."
... any other [comparable] method may be used.”
Value steam
diagrams might be used to represent the highest level
scenarios or processes.
Business process modelling
This involves.
· Identifying business services provided, or required.
· Defining processes (sequences of stages/steps/activities) to deliver the services
· Mapping activities in processes to logical functions and roles.
· Identifying information created and used by activities.
"Process Flow diagrams... may utilize swim lane techniques to represent ownership
and realization of process steps."
TOGAF 9.1 authors treated business
architecture techniques and artifacts as presumed knowledge.
TOGAF 9.2 was extended to include
business architecture terms and artifacts from BizBOK.
Thus TOGAF acquired two business architecture vocabularies and more optional artifacts than anybody wants to use
|
Some
business architecture definition activities |
TOGAF
artifacts in v9.1 |
BizBOK-style artifacts added in v9.2 |
|
Document
the organization structure |
Organization
Decomposition diagram Business
Interaction matrix diagram |
Organization map |
|
Document
business goals and
objectives |
Driver/goal/objective catalog |
Strategy |
|
Define
business services that meet the goals |
Goal/Objective/Service diagram |
|
|
Present
a top-level view of activities needed to deliver services and goals |
Value
chain diagram |
Business
model canvas or diagram |
|
Sequence
activities in processes that
deliver products/services of value |
Business
scenarios or process flows |
Value
stream map or diagram |
|
Define
the abilities or
functions
needed to complete activities And
organise them in a hierarchical structure |
Functions Functional
decomposition diagram. |
Capabilities Business
capability map |
|
Map
business abilities or functions to the
strategy or services |
Business
Service/Function catalog |
Strategy/Capability
matrix |
|
Map
activities in processes to functions,
roles or capabilities |
Business
scenarios or process flows |
Value
stream map or diagram |
|
Map
business abilities or functions to organization units |
Function/Organization matrix |
Capability/Organization matrix |
EA meta models have been around since the 1980s (see footnotes).
The TOGAF meta model was first built by adding two dimensions to more traditional EA meta models.
· There are logical and physical versions of each "active structure” component in each architecture domain/layer.
· Each logical component is defined by the services (specified as service contracts) it is required to offer.
This table classifies TOGAF’s core meta model entities.
|
|
Required behaviors |
Logical active structures |
Physical active structures |
|
Business |
Business Services Business Processes |
Business Functions Roles |
Organization Units Actors |
|
Information Systems |
Application/IS Services |
Logical Application Components |
Physical Application Components |
|
Technology |
Platform/Technology Services |
Logical Technology Components |
Physical Technology Components |
The TOGAF meta model is elaborate, and therefore somewhat impractical as an EA repository structure.
But it does help to teach people two of TOGAF's general principles:
· Define required behaviors (notably service contracts) before structures
· Define logical structures before physical structures.
TOGAF 9.2 and its meta model were further elaborated by including parallel versions of business architecture concepts.
Business capability maps and function hierarchies not only look the same, they have the same purposes and uses.
The business scenario guidance obscures what had formerly been the central idea of a process (cf. value stream) in which human and computer actors play roles to meet a goal.
TOGAF has always promoted service-oriented definition of business systems, whereas BizBOK-oriented extensions refer to products (the outputs of services).
Oddly, the artifacts chapter mentions only BizBOK-oriented artifacts under phase A, though it is
supposed to draft artifacts in every domain (in architecture definition v0.1).
The following sections answer two outstanding questions.
The answers don’t correspond to each other as well as you would like.
First, here is an attempt to reduce
some terminology torture.
On the recursive nature of system and
process definition.
· Systems can be
related in a wider system.
· Processes can be
joined in a longer process (or value stream).
The wider/longer the system/process,
the more abstract (less detailed) the description of it that one person can be
held responsible for
On the analysis and design of
business systems.
· Analysis is the
investigation and description of a situation or system.
· Business analysis is
the investigation and description of business systems (goals, roles and
processes).
· Design is the
description/specification of a new solution or system.
· Business design is
the description/specification of a new business solution or system.
Given the definitions above, some
sources differentiate business analyst and architect roles along these lines.
· Business analysts do
business analysis and design work at lower levels of abstraction, on discrete
solutions/systems.
·
Business architects do business analysis
and design work at higher levels of abstraction, and across an organization.
Digital
Business Analyst in 2019
“Four of our finest BAs shared
their experience across business areas.
·
Solid analysis is the bedrock
(good business case analysis, requirements, stakeholder engagement, ability to
influence) .
·
The digital bit is a combination
of new skills on top...
·
The ability to understand and
engage with agile and fast delivery.
·
Plus some
knowledge of (fast moving) emerging technologies or “knowing someone who
knows”.
·
The ability to very quickly to
translate needs into what is possible is a very powerful combination.
What is different today – from the
systems analyst of yore – is the pace of change and user experience.
Customers have choice, they want
fast response and a good user experience.
But don’t forget those bedrock
skills.
Also, few organisations are
greenfield sites, so the legacy/technical debt needs to be on the right path as
well.
Which requires a team effort.”
A
Digital Business Architect in 2019
EA frameworks like TOGAF propose architects work at the highest
levels of abstraction, and across an organization.
They must begin by
understanding the strategic context, and recording business drivers, goals and
objectives.
To do this,
architects must understand and use the terms that business directors/planners
use.
One contributor to discussion on the internet says this of the business architect role.
“It requires a deep understanding of budgeting,
resourcing, management, marketing and strategy.
Executives learn this on a journey through the ranks
taking a decade or more and/or via a very comprehensive MBA qualification.
The
business architect role
is to: “transform the business
model into an operating model and
align it with the strategic model.”
· “Strategic
models speak to the positioning of the firm that represent the drivers for
the business models.”
· "Business models are how the business generates revenues."
·
“Operating models are the
infrastructure for enabling the business model.”
Some sources appear to suggest business directors/strategists employ MBA-trained business architects.
See Conclusions and Remarks below for references to MBA sources.
This article exposes the terminology torture found in several business architecture sources, and aligns some of them
It is not the aim to present any source mentioned as the whole truth, or an unqualified success.
However, something approaching a consensus emerges from the sources.
Text analysis suggests business architects address six core concepts, here called goal, service, process, role, information and function.
Business architects define these abstract concepts, relate them, and map them to concrete actors working in organization units.
Generally, enterprise architecture views a business as a system in which actors perform activities to meet aims.
Business architects look to improve business processes by optimization, standardization, integration or innovation.
They analyse current business systems; they design and plan changes to them; with a business case for doing so.
This involves some stakeholder management, risk management and the exercise of communication skills.
The term “architect” implies they do all these things at a more cross-organizational and strategic level than “business analysts”.
What about the more human aspects of organization change?
What might be called socio-cultural changes?
And changes to roles, salaries, benefits packages, office facilities, management reporting structures, etc?
Certainly business architects must be aware of these and consider them.
Sometimes however, there is a parallel “business change" team who works with HR, business managers and others.
See “working hand-in-hand with the change manager” in the recruitment agency’s job description above.
This article is a companion to this
newer slide show on business architecture its terms and concepts, and how they relate to each
other.
And this older article on the science of business architecture.
Below are some more sources you might be interested to research.
This Forces article points out that MBA schools still teach business ideas that are decades old.
Michal Porter’s “Competitive forces”1980 and 1985
Harvard Business School’s Porter wrote on why some industries are more profitable and competitive than others.
His big three ideas are the five forces model, generic strategies and value chain.
The value chain diagram is an abstract conceptual tool, comparable with what people now call a business model canvas diagram.
This 2018 article reviews the five forces model from a modern perspective.
Others have pointed out the need to understand the impacts of globalisation, deregulation and digitisation on the model.
Hammer and Champey’s “Reengineering the
Corporation” 1993
MIT professor Hammer spoke eloquently about starting with a clean sheet of paper, and radically changing processes to reduce costs or deliver better services.
Business process reengineering has reportedly failed more often than succeeded, and is no longer fad du jour.
Currently, more incremental business process improvement is favoured.
Clayton Christensen’s “The Innovator's Dilemma” 1997
Another Harvard Business School professor, Christensen’s notion of disruption remains a popular buzzword.
This Computer Weekly article in 2000 doubted his ideas can save big companies from being disrupted.
Did Henry Ford start by drawing a business model canvas diagram?
Would a dose of business process reengineering enable high street retailers to compete with etaillers?
Or older music businesses to compete with Spotify’s operating model?
Other sources you might look at include
·
Architecture Frameworks such as those used by
IBM, CSC (Catalyst) and Cap Gemini (IAF), which informed TOGAF
·
BABOK for business analysts; watch this recording for an extension into the EA space
· Drucker and Peters – management by goals/objectives
· Checkland and Wilson – soft systems (outlined and discussed in this article)
· Six
Sigma and Lean, which encourage eliminating waste from and
maximising the efficiency of processes.
See also Deming, W.E. (2000). Out of the Crisis. The MIT Press.
It includes Demings 14 points for management, listed here https://www.toolshero.com/management/deming-14-points/
Which include:
· Rather than set targets – continually measure and improve.
· Rather than tender on price alone - tender with quality measures as well
· Rather than rely on inspectors – ask all to look out for problems
· Rather than drive by exhortation - facilitate collaboration.
· Educate
You can find some
business architecture processes
and products in Avancier Methods at http://avancier.website.
Avancier Methods align reasonably well with the terms and concepts in SFIA, BizBOK and TOGAF.
You can find
discussion of other architect
roles on this page https://bit.ly/2QMCCFn.