Chapter 12

Beyond Enterprise Architecture

In the previous chapters we have discussed enterprise architecture modelling and

analysis, its roots and foundations, and have seen enterprise architecture being

applied in a number of industrial cases. The practice and possible added value

have clearly been put forward.

This chapter will help you to put architecture, enterprise architecture, and the

architect him- or herself into perspective. Where does it all come from and where

does it lead?

12.1 The World Before Enterprise Architecture

This book is on enterprise architecture. Although the term has become quite com-

mon, enterprise architecture has only relatively recently reached a level where it is

well understood and practically applicable. As we discussed in Chap. 2, Zachman

(1987) can be seen as one of the first authors to define the concept in its full richness.

But it took until the end of the twentieth century for enterprise architecture to be

widely accepted. Why did this take so long?

Enterprise architecture is very much a holistic approach to the design of

organisations. All different domains in enterprise design meet: organisation, infor-

mation, systems, products, processes, and applications. Understanding the individ-

ual domains is complicated in itself, let alone their interdependencies. We have to

look at this from both a business and a technical perspective.

The 1980s and 1990s of the last century have seen a focus on changing the way

businesses operate. Business process redesign and business process re-engineering

were used to rationalise processes and products. In the past, the industrial revolution

automated many production activities in companies. Work shifted from ‘blue-collar

work’ to ‘white-collar work’. Improving the performance of white-collar work

cannot be achieved by simply automating it, but by working smarter, enabled by

information technology. As Hammer (1990) stated in the title of his provocative

article on business process reengineering: ‘Don’t automate, obliterate’, i.e., radically

M. Lankhorst et al., Enterprise Architecture at Work, The EnterpriseEngineering Series, DOI 10.1007/978-3-642-29651-2_12,# Springer-Verlag Berlin Heidelberg 2013

303

rethink illogical business activities, which are there because nobody dares to chal-

lenge them. Introduce new information technology hand in hand with new business

process ideas. The capabilities of information technology enable this smarter way of

working (Davenport and Short 1990).

Another reason for changing business processes was customer focus. Companies

need to compete and excel to keep and expand their customer base. The customer

demands fast services, cost-efficiency, high, standardised quality, and flexibility.

Ultimately, cost, flexibility, improvement, and standardisation of quality need a

process focus. Looking at the business activities serving the end customer, they

appeared to be partitioned on the basis of, amongst others, historical evolution and

political power structures, existing departmental boundaries, and physical location

and geographical borders.

Given the complexity and risks involved in changing an organisational way of

working, a business process engineering approach is needed. Dealing with design

complexity demands abstraction using architectural methods and tools. By the end

of the last century, different methods and tools had been developed to assist

organisations in optimising processes and introducing customer focus. Business

process redesign has moved from an ill-understood skill, with a substantial failure

rate, to a repeatable exercise (see, e.g., Franken et al. 2000), in which business

process modelling and business process architecture play an important role.

From a technical perspective, modelling and architecture have a longer history.

In hardware design, the notion of architecture has been in use since the 1960s,

pioneered by the likes of Amdahl, Blaauw, and Brooks in their design of the IBM

S/360 mainframe (IBM Corp. 1964). In their research note Amdahl et al. (1964)

give probably the first definition of architecture in the IT world:

The term architecture is used here to describe the attributes of a system as seen by the

programmer, i.e., the conceptual structure and functional behavior, as distinct from the

organization of the data flow and controls, the logical design, and the physical

implementation.’

Information modelling has also been a common practice for a long time.

Entity–relationship diagrams were developed in the 1970s. Nowadays, the class

diagrams of UML form a crucial element in object-oriented analysis and design.

Beyond information modelling, the picture is less clear. The UML standard, as was

discussed in Chap. 2, provides many ingredients for this, but in practice we come

across many proprietary and informal techniques.

Nevertheless, the role of architecture has been much more important on the

technical side than from an organisational or business perspective. One reason for

this is that the importance of architecture in this field is much more obvious than in

business processes: the performance and suitability of applications and systems is

immediately visible, and can lead to bad publicity and unsatisfied users; it is always

convenient to blame ‘the computer’. In the press we regularly see evidence of this

phenomenon. Therefore, robustness, scalability, reliability, and feasibility have

become key concepts in system analysis and design.

304 12 Beyond Enterprise Architecture

For business processes, bad performance is much more accepted. When does the

fact that it takes 12–18 weeks to settle a building permit, or that some insurers have

a backlog of almost half a year in their pension administrations, get into a newspa-

per? Oddly enough, this type of performance was accepted for ages, and hence the

need for business process architecture was barely felt. But times have changed.

12.2 The Advent of Enterprise Architecture

Architecture is progressively seen not just as a tactical instrument for designing an

organisation’s systems and processes, but as a strategic tool for enterprise gover-

nance. Yet, the architecture practice within most organisations is still focused on

design and has not yet progressed to the level of coordination, let alone to the level

of enterprise governance. Furthermore, the term ‘architecture’ and the role of the

‘architect’ are heavily overloaded and have faced serious inflation.

To really profit from the strategic potential of enterprise architecture, an

organisation needs to optimise the skills, methods, and tools of its architects, and

give them the right position in the organisation. In this book, we have mainly

concentrated on the first issue. However, without a proper organisational embed-

ding of architectural practice, the enterprise will reap none of its potential benefits.

Many organisations struggle with this problem. On the one hand, a close rela-

tionship with business units and systems’ development is crucial for a detailed

understanding of the organisation. On the other hand, a certain distance and external

authority is important to keep an overview of different projects, processes, and

changes: the essence of architecture. In many companies, this has resulted in

organisational units such as ‘corporate architecture’ or ‘enterprise architecture’

that are either overwhelmed by the continuous interaction with business units, or,

worse, considered an ‘ivory tower’ and play a marginal role.

The acceptance of the role of the enterprise architect depends directly on its

perceived added value. As Fowler (2003) states, this added value does not come

from ‘drawing pictures’, but is based on shortened development times, reduced

budget overspending, and increased flexibility in the organisation as a whole.

Fowler shows that is it possible to play such a role, if skilled architects, supported

by effective tools, apply the right techniques. We are very close to that stage, but

have not reached it yet.

The organisations that participate in the ArchiMate project are to a certain extent

forerunners in this new era, and already face the difficulties of this struggle. In the

end, there is no real choice: the complexity and speed of change of society requires

enterprise architecture in order to keep up with that pace. Enterprise architects will

have to play a leading role, unless organisations are willing to spend too much

money or not to live up to their customers’ expectations.

A key element in the recognition of the role of enterprise architecture is that we

should be able to quantify the impact of architecture, both financially as well as in

terms of the organisational performance. Unfortunately, it is difficult to quantify

12.2 The Advent of Enterprise Architecture 305

precisely the benefits of a method of working that is so wide ranging as enterprise

architecture. Until recently, hard evidence for the value of enterprise architecture

has been hard to come by, beyond a certain ‘gut feeling’ and qualitative arguments.

But has anyone ever asked a CEO to quantify his or her added value for an

organisation? And evidence is mounting, as more and more case studies become

available that show real added value (see e.g. (Garrett 2004) for an early example),

and analysts such as Gartner and Forrester increasingly focus on enterprise archi-

tecture as an indispensable management practice. Furthermore, enterprise

architectures themselves are increasingly used as an instrument to assess the

benefits of IT projects (see, e.g., Romani 2003).

12.3 The Extended Enterprise

So enterprise architecture is here to stay. When architecture and architects have

become well established and have shown serious added value, their role will

become that of both enterprise visionary and enterprise supervisor. The architect

will be a linking pin between CIO, CTO, and CEO and the organisation, translator

of strategic choices to tactical decisions and changes, protector of the conceptual

integrity of the enterprise’s processes and systems, and guardian of the relationship

between the enterprise and its environment: he or she will be both guard and

guardian angel. However, new challenges for enterprise architects are just beyond

the horizon.

Customers have become increasingly demanding and product innovation rates

are high. Globalisation of markets and the availability of new electronic media lead

to new players entering existing markets, disintermediation, and an ever higher

competitive pressure to work more effectively, reduce costs, and become more

flexible. The advent of e-business and e-government has definitely changed the way

organisations and cross-organisational processes function.

E-business introduced new business models and new ways of thinking.

According to Venkatraman (1995), IT-enabled business transformation can take

place at different levels, ranging from local optimisations to radical business

change or even business network redefinition, in e-business-like transformations

(Fig. 12.1).

E-business has changed our view of organisations, moving from an enterprise

perspective to a network perspective (see, e.g., Dai and Kauffman 2002). At the

ICIS 2000 conference, a debate was organised around the question whether the

trend towards e-business calls for changes in the fundamental concepts of informa-

tion systems (Alter et al. 2001). The debate did not lead to a clear conclusion,

although the audience in general stated that no new fundamental concepts were

needed to describe systems. Possible, new ways of building systems were needed,

and, therefore, a new role of enterprise architecture.

The scope of an enterprise architect is increasingly the extended enterprise, or

business network, in which the enterprise operates (Kalakote and Robinson 2001,

306 12 Beyond Enterprise Architecture

Hoque 2000). Business network architecture has become a new playing field,

determining the borders of business models and business network design.

Modelling techniques for this type of architecture may change, but more in the

sense that different views will be used rather than entirely new concepts. The

ArchiMate modelling language was originally inspired by business network

concepts, such as those described in Steen et al. (2002).

In several respects, networked business architecture and design differ from

‘traditional’ enterprise architecture (if there is such a thing). As stated in Janssen

et al. (2003), the networked business architect should:

– Start the development of business services supporting cross-company coopera-

tion from a business network perspective, not from the perspective of a single

organisation. This implies that in principle many different actors involved can

fulfil different roles at the same time, and that many relationships co-exist within

the network.

– Emphasise the roles of organisations in the business network with respect to

each other, instead of the actual actors themselves.

– Link cooperation between companies to internal business processes and existing

(legacy) systems.

– Assess the consequences and prerequisites of technology for business processesand cross-company cooperation.

– Effectively allow knowledge on standards and available components to be

gathered and reused, preferably supporting component-based development and

reuse, designing for flexibility.

A specific issue in the design of such collaborative networks is that of transpar-ency (Janssen et al. 2008). An organisation needs to make its architectures trans-

parent to its partners (up to a certain level) to be able to cooperate, and compliance

with various regulations (e.g. SOX and Basel II in finance, HACCP and ISO 22000

in the food industry, data retention policies from the US government or the EU) also

Localized exploitation

Internal Integration

Business network redesign

Business process redesign

Business scope redefinition

Potential benefits

De

gre

e o

f b

us

ine

ss

tra

ns

form

ati

on

Fig. 12.1 Transformation levels according to Venkatraman (1995)

12.3 The Extended Enterprise 307

requires organisations to be increasingly transparent. This makes the need for a

standard architecture language as described in this book even more apparent.

However, disclosing business strategies or private customer data might be dis-

tinctly unwise or even illegal. Architectures of business networks need to accom-

modate these conflicting requirements. Especially in public-private or cross-border

cooperation between government agencies and commercial organisations, with their

often conflicting goals and requirements, we expect this to become a crucial element

in architectural design.

Moreover, organisations must deal with rapidly changing environments, adapt

their way of working, and increase their capabilities to anticipate and respond to

such developments: they must become agile enterprises. Agile enterprises embrace

change as a positive force and harness it for the organisation’s competitive advan-

tage. This requires a combination of adaptive methods and flexible solutions

(Lankhorst 2012).

Models play a prominent role in achieving agility. By using declarative, rule-

based, and executable models instead of software codes, systems can be adapted

much more quickly, in many cases by business experts instead of software

developers. Moreover, architecture models help you to create a coherent, holistic

approach, relating high-level business goals and requirements, via the design of the

business operations, to the actual implementation and execution. This direct con-

nection between strategy and execution greatly improves the speed of action of the

enterprise.

However, this ever increasing pace of change, the growing complexity of

networked enterprises, and the limited span of control of each actor in this network

imply that an architect can no longer pretend to provide complete designs for

situations in the distant future. Rather, architects will increasingly be pointing the

way, creating the conditions, and setting the boundaries for self-organisation and

evolution of the enterprise. In this complicated, networked and rapidly changing

world, the role of the enterprise architect as a ‘great communicator’ needs to grow,

and even enter the realm of the ‘great negotiator’, as architectural decisions move

beyond the reach of a single organisational unit or managerial entity. This will have

serious consequences for the skills and tools needed for the ‘agile business network

architect’. He or she will have to guard the interests of the different organisations

involved, balancing cooperation in the network, organisational impact, regulatory

compliance, speed of change, and individual benefits. The enterprise architect’s

role between guard and guardian angel will provide a decisive competitive edge to

organisations in this dynamic world.

308 12 Beyond Enterprise Architecture