EA and
Strategy
One of more than 200 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 01/01/2017 12:43
And one of several papers on the home page
about the terms and concepts used in architecture frameworks.
·
Enterprise & Solution Architecture EA and the Digital
Enterprise EA
and Strategy
·
Building Blocks, Interfaces and Services Architecture and
Design Architecture and System TOGAF-ArchiMate alignment
Contents
Mainstream
EA and business strategy
Mainstream
EA and technology strategy
Today’s business systems evolved by incremental formalisation of social systems.
For ever and a day:
· businesses roles and processes have depended on
· information systems (IS), which have used some kind of
· information technology (IT), from clay tablets, to pen and paper, to digital computers.
In the 1970s, methods for analysing and designing digital information systems (IS) made little or no reference to computing IT.
EA emerged in the 1980s from the idea a business should integrate its roles, processes and data into one coordinated business system, based on an integrated IS architecture.
Also, during the 1980s, distributed computing massively increased the complexity of IT nodes, networks and security threats.
So the IT architecture itself required more substantial design and planning.
Recently, some server-side IT architecture has been retreating from the view of business managers into the “cloud”.
However, cloud-provided services still need management, and client-side IT architecture is expanding with mobile devices and the “Internet of Things”.
All this IT architecture is useless to a business that does not know what information it wants and what to do with it.
Today, mainstream enterprise architecture takes a holistic, systemic view of business roles and processes that create and use business data.
Business processes are integrated through the exchange of information in messages and sharing of memories.
Enterprise architects
govern the portfolio of business
systems, striving to optimise it by standardisation and integration.
Some now use “EA” to mean business strategy, business planning, or business management consulting.
That is not what mainstream EA means, and it leads to confusion or roles and responsibilities.
The primary concern of enterprise architects is business system planning.
Business system planning is different from, and subordinate to, business planning.
The highest level business strategies and plans are defined by board members (or politicians in the case of government agencies).
They may address for example:
· expansions and contractions, mergers, acquisitions and divestments.
· markets: moving into or out of specific areas, changing products, changing customer base
· politics: compliance with legislation and regulations
· competitors: advertising, product/service pricing
· economics: changes in exchange rates, stock prices and wages.
All these things can have impacts on business systems.
Changing business systems is one part of what is needed to implement the highest level plans.
But rightly or wrongly, many CEOs view changes to business systems as "back office".
EAs must research and
heed business goals, strategies and management structures.
They may influence
them, and contribute to them.
They advise business managers on the digitisation of business processes and exploitation of data captured.
They act as management consultants in this realm; but not in any every area that business managers may seek advice.
They are not usually
expected by board members to take a lead in business strategy/planning or
organisation design.
On EA as strategy
“EA as Strategy” is a popular book by Ross, Weill and Robertson.
The book’s title is occasionally misinterpreted as meaning “Business Strategy is EA”.
The authors present the cross-organizational integration
and standardisation of operational roles and processes as strategic business
aims.
This table shows what
they call the “operating model” for the business processes of an enterprise.
|
High integration |
Coordination |
Unification |
|
Low integration |
Diversification |
Replication |
|
|
Low
standardisation |
High
standardisation |
Enterprise architecture emerged to take a holistic, systemic view of business systems.
The vision was and is to integrate business systems - their roles, processes and data – into one business system.
So, a business strategy to unify business processes is a strong wind behind the sails of EA.
By contrast, a business strategy to diversify tends to undermine the highest-level EA – though it creates work for solution architects, and there might still be a need for an enterprise-wide IT architecture (an enterprise-wide network, identity management system, shared data centres, etc.
On “business
architects”
Like so many terms, this is ambiguous; there is a huge difference between:
· a business systems analyst (modelling changes to functions/capabilities, roles and processes) under the title “business architect”
· a business strategist or business planner, super-ordinate to EA.
In an EA context, business architects model processes that create and use data.
Their process models may include the names of activities that are:
· disorderly, ad hoc, improvised, informal, intuitive, creative or empathetic
· manual - such as digging holes in roads
· electro-mechanical - embedded in heating, ventilation and motorised systems - such as car production lines.
All of these activities may be essential to business success.
But the realisation of these activities is outside of what EAs are responsible for.
EA was created to minimise the cost and risk, and maximise the benefit, of business systems that depend on digitised business data.
These business system depend on information systems which depend on IT.
CEOs and CFOs may complain about the cost of IT, but there is an argument for saying they underestimate its value.
Businesses depended on clerical data processing long before computers were invented.
Today, computers do far more data processing work than humans can do, faster and more accurately.
EA emerged as the “information age” dawned, with little reference to technology.
First employees, and then customers, were connected to the enterprise IT network.
Now some IT architects describe their role as “enterprise architect”.
However, most IT architects (driven by non-functional requirements) pay little attention what business data is captured or how it is used.
People who don't understand the business roles, processes or data are not well called enterprise architects.
On the other hand; enterprise architects do need some understanding of the capabilities of (the services provided by) technologies.
Businesses depend on the use of platform technologies to capture, move, store, process, and transmit digital data.
And when new technologies come along, they look to where
business roles and processes can take advantage of them.
E.g. They might well research what the Internet of Things and Big Data tools
can do for their business.
Or give solution architects the go ahead to develop silo solutions that test their usefulness
Enterprise architects advise managers on digitisation of roles and processes, business applications and exploitation of data captured.
They may advise on standardising or updating the platform technologies used by business applications.
They may advise on moving business and platform applications from in-house into “the cloud”.
They are not responsible for managing IT operations or IT services management.
They are rarely responsible for IT strategy as a whole.