[the enterprise engineering series] enterprise architecture at work || beyond enterprise...
TRANSCRIPT
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