This page is published under the terms of the licence summarized in the footnote.
All free-to-read materials on the http://avancier.website 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.
This paper addresses a wide range of questions about the nature of EA and agility, raised in a Linkedin discussion in October 2015.
In the 1980s, EA emerged out of “Business Systems Planning” for formalisation of business processes.
In the 1990s, “EA Planning” was concerned with the use and quality of business data created and used by business processes.
In the 2000s,“EA as Strategy” was focused on improving core business processes by formalisation, standardisation and integration.
(Over these decades, business systems have increasingly been distributed over wide area networks, bringing associated security concerns.)
In the 2010s, people talk about “NewGen EA” and “Agile Architecture”; do these have any clear meaning?
EA remains about striving to:
· improve business processes by formalisation, standardisation and integration.
· exploit business data captured by business processes
· do these things with a mind set that is as long-term and enterprise-wide as possible.
While EA can involve dramatic innovations or transformational changes in business processes, it does not have to.
By contrast, Agile development favours negotiation over planning.
The agile mind set is deliberately focused on:
· identifying the minimum change that adds value to a system/capability,
· delivering that change in the next very short sprint/release,
· working practices that capitalise on the skills and knowhow of a small team (of knowledge workers).
Both mind sets are about optimising the effort to change business systems/capabilities, but they are different viewpoints.
Both have their aims and place in the scheme of things; and sometimes they are in opposition, which is fine
It is healthy to have separate viewpoints and to live with cognitive dissonance.
This suggests some misreading(s) of EA, which is in fact business and IS-oriented.
EA is about the formalisation, standardisation and integration of business processes using information systems (IS rather than IT).
That definition seems the best and most consistent with 35 years of EA history.
The raison detre of EA, its impact on the business, depends on the deployment of information systems.
You cannot standardise and integrate core business processes without information systems.
· Formalisation nowadays implies the use of digital information systems
· Standardisation is achieved by the use of business applications.
· Integration is achieved by the exchange and sharing of business data.
EA traditionally distinguishes:
· Business (the human activity system)
· IS (business apps and business data)
· IT (client and server devices, platform technologies and networks).
If EITA is more widespread than EBA, then there are at least two reasons why.
First, the IT platform is the most readily generalised across a business.
Second, you can't integrate business processes without integrated information systems.
In “EA as Strategy” MIT authors proposed that if your top-down strategy is to standardise and integrate business processes,
· first, get everybody using the same platform, same identity management system on the same network
· then, get them using the same business data and business applications.
So their four stages of EA maturity are: 1 Business silos, 2 EITA, 3 EISA, and 4 EBA.
Proponents of agile approaches sometimes attack a travesty of EA; the quotes below are from such a source.
"Treat the enterprise as a complex system like a living organism...”
EA has always regarded the enterprise as a complex system of systems - exactly as in General System Theory.
GST emerged in the 1950s from treating a living organism (holistically) as a system.
It views an animal as a collection of organs cooperating in processes to maintain system state and transform sensations into motor actions.
EA views a business as a collection actors/components cooperating in processes to maintain system state and transform inputs into outputs (deliver services).
It addresses the need of the business to monitor and direct business operations efficiently, effectively and securely.
"focusing more on solving business problems than on extensive documentation and taking a data-driven approach...”
Documentation is not the goal of EA, it is done only so far as it helps to address business needs.
EA is driven by requirements for business services and processes that depend on creating and using business data.
Obviously, you can’t integrate business roles and processes if data in messages exchanged does not conform to agreed data definitions
“to business transformation...
An enterprise cannot be in perpetual transformation, and EA isn’t always about transformation.
EA is sometimes about tidying up the mess created by the last attempted transformation, merger or acquisition.
“all herald an upheaval in the practice of EA itself.”
Nothing so far sounds much different from what EA has meant over 30 years.
“Today’s forward-looking executives seek digital transformations of their organizations – technology-enabled business transformation...”
Forward-looking executives should be thinking about many things, some of them well outside the remit of EA.
When they do think about formalisation of core business processes, they should turn to their EA team for help.
“that requires a more agile approach to architecture than traditional EA has offered in the past.”
In practice, it is not always possible to be agile in changing businesses processes and business data.
What is possible depends on a wide range of political, social and technical factors.
But certainly, EA can make small incremental steps towards formalisation, standardisation and integration business processes and data.
“The field of Enterprise Architecture must itself transform into a new, Agile Architecture in order to drive digital transformation effectively in today’s increasingly wired world.”
The meaning of “Agile Architecture” is obscure and debatable.
This grand-sounding term has no agreed meaning.
Does it mean Guerilla EA? Agile architecture documentation? Architecting for a system to be agile?
EA can be about making small steps towards the vision of digitised, standardised, integrated business processes and data.
“Guerrilla EA” does what it can, when and where it can, to these ends.
It may socialise solution architects into a group that cooperates by aligning solutions in the directions of standardisation and integration.
If Agile Architecture means that, then OK.
Agile architecture documentation
Of course you can work iteratively and incrementally, develop your architectural documentation alongside your system.
Years ago, Scott Ambler called this Agile Model-Driven Development, but his guidance is for software development teams.
And isn’t this agile documentation rather than agile architecture?
Surely, an enterprise architect must describe a system's structure and behaviour at a level of abstraction that is as stable as possible?
If that highest-level architecture is continually changing, doesn’t that undermine the notion of architecture?
Architecting for a system to be agile
The notion of an agile system is not a simple or single idea, since a system can be flexible in at least four ways.
A system that is
yet might also be
its architecture is likely to be
do many different things
rigid and hard to change or extend.
large or complex
be readily changed to a new version
limited and not versatile
slight or simple
be extended with extra features
not malleable (the Open-Closed principle in OO design).
fixed (must be right first time)
change its own roles and rules
reliant on human ability, barely a system at all
slight and simple
Building flexibility into a non-human system can be difficult and costly, and make the system more complex.
So, agile enterprise architecture is challenging for all these reasons.
For more on this theme, go to the “Complexity, Agility and Adaptive Architecture” page at http://avancier.website.
General system theory, enterprise architecture and software architecture are all about the design and description of activity systems.
An activity system is a system of repeatable processes that can be described in terms of structural and behavioural elements.
The table below illustrates concepts and principles common to systems of many kinds, including business and software.
General system elements
General business architecture entities
General software entities
Actors/components play roles in
Objects, Classes, Components
Method bodies, Procedures
maintain system state and/or
Business data entities
interact via inputs and outputs
with each other and with
Business Services, Products
Service Level Agreements
external entities and events
Client and server objects
For more on system theory, go to the “Philosophy and Theory of Systems” page at http://avancier.website.
EA does start with people; it identifies stakeholders of many kinds and strives to address their concerns.
But obviously, architects don’t “architect” people, only roles played by people in architected processes.
EA is a political exercise; the political, social and technological context is complex, and never entirely knowable.
Architects may have to study process steps that are intellectual, social, or manual.
But EA focuses on repeatable business behaviour that can be monitored and directed.
In defining a business service contract, or drawing a business process flow chart, it formalises business behaviour into the form of a discrete event-driven process.
EA is concerned to describe roles people play in such processes, most especially, the steps at which they create and use business data.
EA does define very complex adaptive systems.
However, the phrase “complex adaptive system” has a special meaning in sociology.
Read “The relevance of system theory to EA” for an explanation of the difference.
Today’s EA teams are pulled this way and that.
Some have suggested the EA team should be engaged with agile development practices.
Such as "SCRUM" for software development and "DevOps" for IT services management.
But EA cannot be all things to everybody.
Yes, agile software development is a good idea.
Yes, we want the EA team to progress iteratively, and respond to change, and understand agile development practices.
But still, EA is about the advancement and optimisation of the whole business application portfolio, not about how to do software development.
The EA team may have something to say about the company web site.
But enterprise architects are not best employed as SCRUM coaches.
The EA team takes a strategic view of business processes that create and use business data, using business applications.
They may sanction the existence of an application and ensure conformance to overarching road maps.
They may steer software development towards the need for standardisation and integration.
But it isn’t their duty to define the roles in software development teams, or in an IT operations organisation.
Yes, DevOps has its place, but in most enterprises, only a minority of apps will be under a Dev/Ops regime in sight of the EA team.
Many or most business apps are packages maintained by external vendors.
For the rest, agile practices are for active development and maintenance teams, and DevOps is for teams doing continual growth/change and release.
Most business applications are not under continual growth/change and release.
The IT organisation is often divided between
· Strategy and architecture
· Dev/change projects
· IT Services Management (ITSM).
In practice (despite DevOps) the last two are very different worlds.
You can apply EA to the organisation and processes of ITSM.
E.g. The Open Group's IT4IT is an EA reference model for an IT services management organisation.
But if EA retreats into ITSM then it has lost the plot; the primary focus of the EA team has to be on core business processes.
The more that IT operations are outsourced (into the cloud perhaps), the more the EA team is free focus on core business operations.
Outsourcing data centre resources with no effect on business processes, data and apps is primarily a matter for ITSM.
However, where it does have an effect on customer, supplier or employee behaviour, then it becomes an EA thing as well.
And the EA team should address the effectiveness and integration of cloud-based apps.
Taking a holistic view does not mean EA is responsible for all enterprise resources or processes.
Consider a business
that provides road digging and repair services.
The EA team is probably not responsible for designing and planning changes to:
· recruitment, motivation or sacking of road gang members
· the organisation of a road gang
· ways that gang members dig holes in roads or repair them
· specifications of spades, pneumatic drills, tarmac or vehicles
· the HQ management structure
· office buildings and facilities management contracts
· data centre design, heating, ventilation and air conditioning.
Holistic in system theory means addressing the overall behaviour of a system rather than its component parts.
Holistic in EA means seeing the enterprise as one coherent system in which core business processes are integrated.
The EA team is engaged where enterprise resources play roles in digitisable business processes.
EA may consider purely intellectual, social or manual activities.
But it focuses on
process steps where data is created or used (to monitor and direct business
It ensures a workflow delivers job instructions to a road gang leader's mobile device, and helps him record the time the job was completed.
It does not tell gang members how to dig holes in roads.
It is not responsible for many things, probably most things, in a business. And heaven help us if it was!
EA is accountable
for digitisable processes rather than for people (else, what are managers and
EA may well address support processes, but should strive to keep its focus on the core processes.
Suppose there is a variously-skilled EA team led by an EA manager.
The EA team manager is responsible for governance of the business systems portfolio, meaning:
· digitisable business processes,
· business data they create and use,
· business roles in processes that create and use data
· functional and non-functional qualities of the above
optimisation of the above.
And for principles, standards, patterns and high-level designs that
· enable cross-organisational systemisation of a business,
· encourage integration and reuse
· align the four primary architecture domains
EA itself is an informal social system; it is a meta system to the formal business systems it shapes and steers.
It is highly political; every EA class puts communications skills at the top of their list of required skills and knowledge.
By contrast, the operational business systems that EA describes (and governs through development, deployment and change) are formal.
The artefacts used in TOGAF-style EA to define the architecture of a business are exactly in accord with general system theory.
They define a collection of actors playing roles in business processes to maintain system state (create and use business data entities) and transform inputs into outputs (deliver business services).
What others call EA
Some use the term EA for business management consulting.
Some use the term EA for EITA, for governance of a technology platform that is increasingly generalised, commoditised and shareable (i.e. not business specific).
Some EA teams are really a collection of Solution Architects working to shape and steer discrete software projects and IT services.
Is your EA team really a collection of Solution Architects?
Or an in-house team tasked with the governance of the Solution Architects who work for your suppliers?
Then your team needs certification in a Solution Architecture framework (like Avancier Methods).
Even if EA budgets are slashed, Solution Architects will always be needed, and AM is targeted at them.
And if you want to govern Solution Architects, you need to understand their roles and processes.
This is the third paper under “EA framework FAQS” on the “New Gen EA: roles and realities” page at http://avancier.website.
And the first paper on the “Complexity, Agility and Adaptive Architecture” page at http://avancier.website.
For more on system theory, go to the “Philosophy and Theory of Systems” page at http://avancier.website.
Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 08/11/2015 21:14
Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.website” 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 work, not derivative works based upon it.
For more information about the licence, see http://creativecommons.org