Other
enterprise architecture challenges
https://bit.ly/2OlDn6j
Copyright Graham
Berrisford. One of several hundred papers at http://avancier.website. Last updated 22/06/2020 13:11
The article is the second of two that positions mainstream enterprise architecture in relation to solution architecture.
To read the first, click here enterprise and solution architecture: things to know.
Read on for some challenges people face.
Contents
Populating
your Strategy and Architecture team
Governance
of solution architects by enterprise architects
A
few notes on architecture methodology
The number of roles called “architect” varies widely between organisations.
Some enterprises have never set up an EA practice; some have done so and struggled to make an impact.
However, many do have a team called “strategy and architecture” or the like.
Every enterprise
has to work out for itself how its roles cover the cells of the table below.
|
Domain Level |
Business |
Data/Information |
Applications |
Infrastructure technology |
|
Enterprise
architecture
|
Business
roles & processes, standardisation,
integration and
road maps |
Business
data standardisation,
integration and
road maps |
Business
application portfolio standardisation,
integration and
road maps |
Platform
technology portfolio standardisation,
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 |
First, there must be a manager (CIO or other) who appreciates and wants to sponsor enterprise and/or solution architect roles.
That manager may create a Strategy and Architecture team – covering some or all of the table above.
How the activities in the table are mapped to roles and people depends on the manager, and the size and nature of the enterprise.
And by the way,
it is normal to engage security
specialists in each architecture domain.
Division of roles by
scope
A large and diverse enterprise may be divided into “segments”, each with its own Strategy and Architecture team.
The segments likely correspond to distinct business functions/capabilities.
E.g. a bank might have retail banking, wealth management and investment segments.
Division of roles by
level
A Strategy and Architecture team may divide its roles according the three rows of the table above.
So there is a hierarchy of enterprise, solution and software/technical specialist architects
Some insert a “segment” level between the enterprise and solution levels.
Where an enterprise is happy with silo solutions that duplicate and don’t integrate – the focus may be on solution architecture in the second row of the table.
Division of roles by
domain
A Strategy and Architecture team may divide its roles according the columns of the table above.
“The enterprise architect" is rare, since it is difficult for one person to manage portfolios in all four domains.
A Strategy and Architecture team might employ an enterprise architect in charge of each architecture domain (the columns of the table).
By contrast, a
solution architect is often expected span all domains, and join up the
perspectives of specialists working in each domain on a project.
This makes
broadly educated solution architects the lynch pin of an architecture function.
A solution architect’s vision usually has a relatively short time frame and narrow scope.
In the 1980s, the need to take more strategic and cross-organisational view of business processes and business data became clear.
The cost and quality issues caused by “silo systems” led many to call for higher-level “enterprise architecture”.
Enterprise architects take the broadest possible view, look to standardise, integrate and coordinate business systems across an enterprise.
They respond to the outputs of business planning, align system changes with them, and may influence them.
EA is challenging politically as well as technically.
The idea is to take a cross-organisational and strategic
perspective of business systems and changes to them.
Enterprise architects need not only appropriate knowledge, skills and resources, but also cross-organisational authority.
They act as a central design authority and risk management function.
They guide and govern lower level solution and technical architects working on specific programmes and projects.
EA aims include the rationalisation and optimisation of business systems, de-duplication and integration of systems.
But enterprise architects can and do give waivers from enterprise-level standards and principles.
They may
sanction point solutions and/or duplication of data storage, contrary to a
holistic enterprise architecture, enterprise.
Architecture is high level design and planning of systems that must be designed, tested, integrated and replaced.
How to build a coherent architecture method that makes enterprise transformation quicker, cheaper, better or less risky?
One has to draw many ideas from many sources..
It is commonly said that “enterprise architecture views the enterprise as a system, or system of systems”.
But to call every problem, situation or business “a system” is unhelpful.
It is important to distinguish:
· a social entity or network in which people communicate
· an activity system in which people play role and follow rules.
An enterprise is a social entity that employs many distinct socio-technical activity systems.
Those systems may overlap, duplicate or even conflict with each other.
Enterprise architects strive to standardise and integrate systems, but complete integration is impossible.
The more systems are commoditised or
industrialised - the more enterprise architect oversight is needed.
Customised and bespoke systems may benefit initially from an agile development approach.
EA frameworks like TOGAF are abstract management frameworks for design thinking.
TOGAF can help you organise work to change business systems; it does not teach you how to do the work.
Achitects need more concrete training in architectural design principles and patterns.
How far to populate an EA repository with documentation?
Enterprise architects are interested in portfolio-level documentation
Solution architects are interested in system/solution-specific documentation
A few ideas:
· At any level of system decomposition, a context diagram showing inputs and outputs, or an interface definition.
· At a high level: business processes/value streams/scenarios.
· At a high level: business function/capability hierarchies and application catalogues.
· At a middle level: use cases/epics, sagas, kernel entities, components, microservices.
· At low level: user stories, atomic transactions, data entities and objects/classes.
Any of these may usefully be documented to assist the design process.
How much documentation need be retained? I don’t know. It depends.
And I haven’t mentioned the deployment to infrastructure.
Unfortunately, the many standards architects refer to (like TOGAF, ArchiMate, BizBOK and UML) are terminology torture on their own - let alone in combination.
Because authors use ordinary words (like service, process, function, capability, actor, interface and process) with a variety of meanings.
|
Meaning in standards from The Open Group |
Word |
Meaning in Fowler’s writings for programmers |
|
A structural
building block that offers multiple services to its clients |
Component |
A unit of
software that is independently replaceable and upgradeable. |
|
A behavior composed
of process steps in a sequence that leads to a result. |
Process |
An instance of
a component executed on a computer. |
|
A discretely
requestable behaviour that encapsulates one or more processes. |
Service |
An out-of-process
component, typically reached by a web service request or RPC. |
Architecture methods should include not only system definition, but also patterns for system integration.
Systems can be integrated by users, messaging or database consolidation, online or off line, and in ACID or BASE styles.
Architecture methods have to address the life cycle of a system, and when to replace old systems.
Many applications are badly made, they have poorly structured databases and/or give poor user experiences.
Many are over-engineered: too many layers, vacuous abstractions, facades on facades, needlessly rich domain models and needless use of middleware.
Even well-engineered application – after they have been amended in various ways – can become badly engineered.
But if an application works, and doesn’t cost much, it may not be a concern to enterprise architects.
Technical debt isn’t a measure a poor software design, and refactoring all poor design would be impossible.
Technical debt is a measure of the technical insurance premium worth paying to increase system longevity.
First you have to assess the size and likelihood of the risk.
· How important is the application? Does it work well enough now?
· How long will the application be needed? Will it work for the foreseeable future?
· How likely will it have to be changed much, or re-platformed, in future? What will be the cost of doing that?
· What is the cost of refactoring now to make the application easier, quicker and cheaper to change in the future?
· Would it be better simply to replace the application by another?
Architects produce road maps that set out how one or more baseline systems are replaced by one or more target systems..
A solution architect drew the following simple road map for replacing an old accounting system by a new one.
|
System element |
Baseline
state |
Transition state 1 |
Transition state 2 |
Target state |
|
Reporting |
Old system |
New system |
New system |
New system |
|
Purchase
to Pay (PtP) |
Old system |
Old system |
New system |
New system |
|
Order
to Cash (OtC) |
Old system |
Old system |
Old system |
New system |
|
Temporary
data flows |
Old-to-new PtP & OtC |
Old-to-new OtC |
EA involves coordinating several road maps, strategic and tactical, that cut across each other.
The road map for replacement of the accounting system may have to be shaped in the light of other road maps for
· replacing the CRM application used to capture orders
· making all core business data accessible via interfaces conforming to the OData standard
· reorganising the business from product-focused to customer-focused (or vice-versa).
There is a reasonable understanding
out there of why Solution Architects are needed.
EA has always been
challenging, both technically and politically..
· Defining the monetary business case for any strategic or
cross-organisational activity is difficult.
· The variety of business contexts makes it impossible to
prescribe, generically, where EA fits.
· Some “overegg” what EA can achieve.
EA is political: there are always trade
offs and compromises to be made; and
Who has authority to make decisions? It depends on the
enterprise’s management and governance structures and processes.
Decades ago, US OBM Memoranda 97-16 guidance on enterprise
architecture said this:
“the
balance between centralization and decentralization and the pace of change
within the agency, should be clearly understood.”
Regarding the pace of change, where are some articles
on agile architecture:
2. On agile
software development
3. On agile
businesses and systems
4. On systems
thinking ideas used in agile
5. What is agile
architecture?
6. EA in the world
of agile architecture
Read 50 years of digitisation and EA for a more extensive EA history, and ends with a link to a long list of references from 1970 onwards..
Read EA and TOGAF: how do they differ? for discussion of EA with reference to TOGAF.
All free-to-read materials at http://avancier.website
are paid for out of income from Avancier’s training
courses and methods licences.
If you find the web site helpful, please spread the word and
link to avancier.website in whichever social media you
use.