The meaning EA in an agile world

This is a supplement to a series of mostly short papers.

4. On systems thinking ideas used in agile

6. EA in the world of agile architecture

This older paper addresses questions about the nature of EA in an agile world, which were raised in a Linkedin discussion in October 2015.

Contents

EA and Agile mindsets. 1

Why do some agilists dislike EA?. 2

Is EA IT-oriented?. 3

Is EA responsible for socio-cultural matters?. 3

Is EA responsible for software development practices?. 4

Is EA responsible for IT services management practices?. 4

Is EA responsible for everything in a business?. 5

Concluding remarks. 5

EA and Agile mindsets

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.

In the 2010s, people talk about “NewGen EA” and “Agile Architecture”; do these have any clear meaning?

EA remains about strategic and cross-organisational efforts 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.

By contrast, agile development is deliberately focused on:

· identifying the minimum viable change that adds value to a system/capability,

· delivering that change in the next short sprint/release,

· working practices that capitalise on the skills and knowhow of a small team (of knowledge workers).

Read agile papers 1 and 2 for more on the agile mind set.

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.

Why do some agilists dislike EA?

Proponents of agile approaches sometimes attack a travesty of EA.

The quotes below are from such a source.

"[We need to] treat the enterprise as a complex system like a living organism...”

EA has always regarded the enterprise as a complex system of systems – as in General System Theory.

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.

EA is data-driven; starts with 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.

“[which] 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.”

The meaning of “Agile Architecture” is obscure and debatable.

Read What is agile architecture?

Is EA IT-oriented?

EA traditionally distinguishes:

· Business (the human activity system)

· Information systems (business apps and business data)

· Infrastructure technologies (client and server devices, platform technologies and networks).

EA is about the formalisation, standardisation and integration of business processes that create and use information.

It is primarily about the Business and its information systems, and secondarily about the IT they need.

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.

In “EA as Strategy” MIT authors proposed that if your strategy is to standardise and integrate business processes,

First, get everybody using the 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.

Is EA responsible for socio-cultural matters?

EA does start with people; it identifies stakeholders of many kinds and strives to address their concerns.

But it doesn’t architect, motivate or manage people

Some business roles and steps in business processes are purely intellectual, social, or manual.

But EA focuses on those steps those regular business roles and processes that create and use business data.

What if changes to those processes affects roles played by people?

Then EA works in partnership with business managers, HR and “business change” function

Is EA responsible for software development practices?

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.

Yes, DevOps has its place.

But many or most business apps are packages maintained by external vendors.

And many bespoke business applications are not under continual growth/change and release.

Once change requests die down, the management of the production environment may be left to IT operations specialists?

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.

Is EA responsible for IT services management practices?

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.

Is EA responsible for everything in a business?

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 activities).
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!

Concluding remarks

EA is accountable for digitisable processes rather than for people (else, what are managers and HR for?).
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

· enterprise-wide 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.

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 10/05/2019 18:13

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