Enterprise and Solution Architecture challenges

https://bit.ly/2OlDn6j

Copyright Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated 04/12/2018 11:24

 

The paper is the second of two that positions mainstream enterprise architecture in relation to solution architecture.

It is written to reflect the history of architecture roles and the reality of modern architect job descriptions.

It is suggested as pre-course reading for Enterprise and Solution Architecture (ESA) certification courses in this Training Calendar.

 

·         RK “All in one article...” [now two articles]

·         VE “Thanks for sharing.”

·         SW “This is good reading. Thank you for sharing.”

·         TRB “Good read.”

·         SG “Very much insightful. Thanks a ton.”

Contents

Preface. 1

Governance of solution architects by enterprise architects. 2

Populating your Strategy and Architecture team.. 3

Guerilla EA.. 4

Architecture methodology. 5

Agility in its various guises. 7

References. 10

 

Preface

It is presumed here that you are familiar with context discussed in this previous paper:

·         Enterprise and solution architecture

·         Architect roles in SFIA

·         Architect roles in the TOGAF standard

·         Architect roles in advertised role definitions

·         Decades of solution architecture

·         Decades of point solution proliferation

·         Decades of EA as business system planning

 

There is a reasonable understanding out there of why Solution Architects are needed. 

There are difficulties resourcing higher/wider Enterprise Architecture (EA).

Defining the monetary business case for any strategic or cross-organisational activity is difficult.

People mistake TOGAF (a management framework for an architecture-led project) for an education in EA.

Much teaching of TOGAF and its like is naive.

Some have built EA models that are not used or usable in practice.

The tools we have are still not great, and in trying to please every customer some tool vendors make their EA model incoherent.

The variety of business contexts makes it impossible to prescribe, generically, where EA fits.

Also, some big up EA too far.

 

EA has always been challenging, both technically and politically..

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.”

 

The balance between centralisation and decentralization?

What if nobody sees a need for current “silo systems” to interact?

Suppose the only business-wide view required is financial summary information collected from disparate business units?

A highly diversified business presents a challenge to the notion that the enterprise is a holistic system.

 

Still, a Strategy and Architecture team has a role to play in governance of solution architects working on discrete business systems.

Suppose your enterprises wishes to standardise, integrate and optimize systems to the benefit to the enterprise as a whole, and mitigate change risks.

Then it needs standards, principles, reference models, best practices and road maps for business system change.

And it ought to govern solution architects with reference to that collateral.

 

The pace of change?

What if managers insist they need a point solution tomorrow?

Enterprise architects can give waiver for an innovative and/or agile project to proceed outside of normal governance.

 

OK, but can we have an “agile architecture”?

Read this other paper on agile architecture for discussion of

·         Agile architecture: what does it mean?

·         On the Scalable Architecture Framework (SAFe)

·         On agile development versus agile systems

·         Conclusions in an enterprise architecture context

 

Read on for discussion of:

·         Governance of solution architects by enterprise architects  2

·         Populating your Strategy and Architecture team   3

·         Guerilla EA   4

·         Architecture methodology  5

Governance of solution architects by enterprise architects

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.

 

All is trade offs

The aims of EA include the de-duplication and integration of many systems - the rationalisation and optimisation of business system estates.

 

Point solutions (innovations or not) are contrary to a holistic enterprise architecture.

But enterprise architects may sanction point solutions.

Architects should assess trade offs and make a decision, rather than allow point solutions to proliferate unconstrained.

 

Similarly, duplication of data storage by different applications is contrary to holistic enterprise architecture.

But architecture governance may allow some duplicate data to continue, or even to be created.

 

EAs may choose, or help to choose, generic and enterprise-wide platform technologies.

But the imposition by some EAs of middleware technologies on SAs might well have cost more than it saved.

Populating your Strategy and Architecture team

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.

Guerilla EA

What if there is no “enterprise architect” in the organisation?

There is often some kind “Strategy and Architecture” team that supplies solution architects to projects.

A CIO, CTO or architecture team manager can

·         ask solution architects to work with an EA mindset.

·         socialise architects into a group that cooperates by aligning and integrating solutions

·         give architects some time and opportunity to do strategic EA level analysis and planning

·         encourage them to do what they can, when and where they can, to move the enterprise towards an EA vision.

 

Here, this is called “Guerilla EA”.

E.g. The organisation in the table below has no enterprise architect, and only four solution architects.

But they collaborate with an EA mind set when the opportunity arises.

 

A university

total 

c75 people in business system change

total 

c165 people in IT services management

 total

Campus data centres

2

Solution architects (TDAs with EA mind set)

4

Groupware / mailing list

3

Schools

26

Supplier relationship managers (licences)

2

Senior management

5

Buildings (25m)

300

Data integration specialists

5

Data centre / hardware / operations

6

Staff

9000

Application development team

13

File store / directory / identity management

7

Students

31000

User engagement and requirements specialists

24

Service desk

9

 

PMO (programme/project managers, back office)

27

Client Devices, Desktop apps, OS and printers

10

Clerical administration

10

IS/IT projects per year

150

OS / databases / networks

30

Business applications

600

 

 

Hardware – desk tops, projectors etc.

85

 

There being no EA function, the principal solution architect sent two others, not called “architect”, to attend our architect training.

An education in enterprise and solution architecture can be relevant and useful to people with no EA function.

Architecture methodology

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.

And then direct each method user to decide which ideas best suit their particular transformation challenge.

Design thinking

Design thinking is not a particular approach, but a label for a collection of ideas such as.

·         Capture the inspiration, the vision.

·         Take a human-centric view of business roles and processes.

·         Manage stakeholders and value propositions.

·         Treat all design as re-design, as a baseline to target transformation.

·         Make ideas tangible to facilitate communication.

·         Use visual languages, sketch diagrams and technical drawings to show abstract requirements may be met by concrete systems.

·         Design process steps can occur in parallel and be repeated (aren't linear)

·         Double loop learning.

 

These ideas have long and widely been used in conventional system design methods.

Most feature in most enterprise and solution architecture methods. E.g.

 

A design thinking process (Wikipedia)

TOGAF’s ADM process

Avancier Methods phases

1 Define

phase A

Initiate

2,3,4 Research, Ideate, Prototype

phases B, C, D

Architect

5 Choose

phase E

Plan

6 Implement

phases F and G

Govern development

7 Learn

phases G and H.

Govern change

 

Architecture methods encourage parallel and iterative paths both through the phases of its process and within each phase.

E.g. TOGAF says the timing and order of steps should be adapted to the situation.

True, it encourages some big-up-front design, but how much you do is up to you.

True, it does not encourage prototyping in phases B to D, but that is a perfectly reasonable thing to do.

The enterprise as a system

Some use the terms system, component, process and service interchangeably.

Some use them with different (and sometimes contradictory) meanings.

 

In some standards from The Open Group

In Fowler’s writings for programmers

A structural building block that offers multiple services (a service portfolio) 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.

 

It is commonly said that “enterprise architecture views the enterprise as a system, or system of systems”.

But there are profound misunderstandings of what this means.

To call every problem, situation or business “a system” is unhelpful.

It is important to distinguish:

·         a social network in which people communicate

·         a social system in which people realise role and rules.

 

An enterprise is one social network that realises many social and technological systems.

Architects may find some systems overlap, duplicate or even conflict with each other.

Enterprise architects apply some change control to large-scale, generational, system change.

For more on these underpinning concepts, read papers 5 and 6 on this system theory page.

Management of system design

EA frameworks like TOGAF are not primarily design methods,

They are abstract management frameworks for design thinking.

TOGAF is intended to help people manage the time, cost and risk of work to change business systems.

It does not teach architects how to do architecture.

Solution architects need more concrete training in architectural design principles and patterns.

System testing

Architecture methods don’t include testing itself, but must define systems in a way that is testable.

Whether you use diagrams or  not, testable requirements are specified in the domain-specific language of the system to be tested.

Templates for specifying required system behaviors include user stories, use case descriptions, and service contracts (signatures and semantics).

All are variations on the theme of specifying system behaviours (services and processes) declaratively by their entry and exit conditions.

·         Entry conditions may be defined as triggers, inputs and preconditions.

·         Exit conditions may be defined as outputs, post conditions and the values of those to system users.

 

(Read The science and philosophy of systems for the underpinning theory of system specification.)

System integration

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.

System lifecycles and technical debt

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?

System road maps

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 are always trade offs and compromises to be made; so EA is political.

Who has authority to make decisions depends on the enterprise’s management and governance structures and processes.

References

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.

There is a common theme in the referenced sources – a focus on business roles and processes that create and use business data.

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.