Enterprise architecture: beyond business and IT alignment

Marcel Lee

Pramana

99 avenue de la République

75011 Paris, France

marcel.lee@pramana.fr

2

Table of contents

1 Searching for alignment ..................................................................................... 3 1.1 Original purpose of enterprise architecture .................................................. 3 1.2 Serving the business and aligning IT ........................................................... 3

2 Intertwining aspects ........................................................................................... 5 2.1 Ubiquitous IT: a reality ................................................................................ 5 2.2 Transforming the enterprise beyond business and IT .................................. 5 2.3 Embracing other subjects ............................................................................. 5 2.4 Enterprise as a network of aspects: a holistic approach ............................... 6

3 Bringing it into reality ........................................................................................ 9 3.1 Framing the analysis .................................................................................... 9 3.2 Integrating with current practices .............................................................. 11 3.3 New perspectives, new challenges ............................................................. 11

Abstract IT has always embodied both a huge opportunity and a misunderstood

asset in most enterprises. Today, pressure has never been so hard on IT executives

to reduce cost and complexity while bringing value. Enterprise architecture was

born in an attempt to address this very challenge. But while serving its original

purpose, it usually focuses on business and IT, overlooking other aspects

potentially required for envisioning enterprise transformation. The latter is

becoming more and more compulsory and IT has never been so pervasive in

today’s enterprises. In this context, approaching transformation through a

business/IT duality as in most enterprise architecture methodologies proves to be

insufficient. Pervasive IT infers the consideration of other aspects, all intermingled

one another. One possible way to deal with this reality is to model the enterprise

as a graph of aspects, beyond business and IT. By putting weight on the

relationships between those aspects, one can delineate a Minimal Spanning Tree

that would constitute a pragmatic yet complete frame of analysis. Applied to an

imaginary business case, the aforementioned approach proves to be relevant for

enterprise analysis in a holistic yet pragmatic way. It can also be integrated in

existing frameworks, either as an extension, or as an overarching frame for a

hypothetic enterprise transformation practice. Yet, many additional works need to

be achieved before envisaging such a practice in the future.

3

1 Searching for alignment

1.1 Original purpose of enterprise architecture

IT has always been perceived as both a huge opportunity and an immense bur-

den by organisations. When cleverly used, it can greatly improve performance and

foster innovation. In many ways, it also embodies an intangible and mostly mis-

understood asset whose value is always to be proven, complexity to be tamed and

cost to be put under control.

In the early days, organisations have rushed into IT to take advantage of its po-

tential: process automation, digital desktop, etc. All these advances have been de-

vised and implemented through most of the time an unplanned and rather oppor-

tunistic way. This led to a rather chaotic IT landscape without a solid foundation

to enable reuse and homogenisation. Over time, the cost and complexity of IT sys-

tems have exponentially increased while the additional business value to be de-

rived from those systems has constantly decreased. Organisations have found

themselves facing the following challenge: how can I derive more value from IT

and at the same time reduce cost and complexity? This question has been ad-

dressed by several areas of expertise, among which, enterprise architecture.

1.2 Serving the business and aligning IT

If one cannot find a unique commonly agreed definition for enterprise architec-

ture, practitioners usually do agree on the benefits it can bring to an organisation:

it facilitates the reduction of complexity through better interoperability and pro-

motes cost reduction, through better return on investments and flexibility of busi-

ness capabilities. Practitioners also do usually agree that enterprise architecture

should “enable the process of translating business vision and strategy into effec-

tive enterprise change” [1]. The exact modalities of how to proceed differ from

one methodology to another but most of them are usually applied with the follow-

ing commonality: a business/IT duality, with a strong emphasis on the necessity

for IT to be aligned with the business. Let’s examine in detail the practices mostly

in use in organisations today to confirm this statement.

Enterprise architecture is usually applied in a top-down approach. It operates

with a strong support from the top management in an environment where the vi-

sion statement is clear. In this configuration, all the analysis is conducted so that

the target state of the organisation is in line with the business vision. This is usual-

ly conducted using the “separation of concerns” [2] principle, the concerns in

study differing according to the methodology in effect.

4

For example, in TOGAF (The Open Group Architecture Framework [3]), the

concerns in question are the Business Architecture, Information Systems and the

Technology Architecture. There is a clear business/IT duality in the way architec-

ture is envisaged and IT is supposed to support the target state of the Business Ar-

chitecture, which should itself be directly aligned with the strategic objectives.

In the Zachman framework [4], even though the separation between business

and IT is less formal, the first two audience perspectives (executive and business

management) represent the business aspect whereas the three following audience

perspectives (architect, engineer, and technician) represent the IT aspect. The

alignment notion is clearly represented as a link to be made alongside the audience

perspectives. Like in TOGAF, little or no attention is turned to other concerns than

business and IT.

This business/IT duality is even more striking when adopting a “city planning”

layered approach to enterprise architecture. It organises enterprise into a layered

hierarchy, from the business layer to the technical layer. This methodology, while

aligning IT with the business by essence, gives however few or no room for the

study of other concerns than business and IT.

Now that we have examined the usual practices in effect in enterprise architec-

ture, it becomes apparent that there is usually a strong common emphasis on busi-

ness/IT alignment which permits to prioritize initiatives according to the value

they can bring. Moreover, there is systematically a strong emphasis on reuse and

the building of a foundation architecture. Therefore, enterprise architecture as

practised today is serving well its main original purpose: reducing cost and com-

plexity while deriving more value from IT.

This business/IT duality actually reflects quite well the usual state of mind of

C-level executives regarding IT, namely its contribution to the business vision and

strategy in a context where IT is mostly seen as a utility or as a service provider to

the business. But only very few methodologies approach the enterprise in a con-

text of overall transformation [5], embracing concerns out of the business and IT

scope, like culture, skills or behaviour. Only in the Praxeme framework can we

see a more global approach, as enterprise architecture is defined as the place

“where the effort is made to consider all the aspects together” [6]. But are all these

other concerns of primary importance when dealing with enterprise change? And

if so, how can we cope with them?

5

2 Intertwining aspects

2.1 Ubiquitous IT: a reality

Technology has never been so present in our everyday’s life. With social net-

work, mobility, and new media all in play, our relation with technology has been

reshaped for good. This trend is also increasingly spreading in organisations.

While confined in the early days in a limited number of functions, technology is

now omnipresent: we use applications to develop customer relationship, we use

mobile devices and digital signature to deliver parcels, and we use social networks

to develop new forms of marketing. In a sense, IT has become ubiquitous in most

organisations.

2.2 Transforming the enterprise beyond business and IT

But ubiquitous IT is not all. Organisations have never faced such a shifting and

unstable environment. With the advent of new regulatory policies and the ever

harder pressure of the competition, organisations are constrained to transform con-

stantly.

In this context of ubiquitous IT and compulsory transformation, is enterprise

architecture as practised today relevant for an effective translation of business vi-

sion and strategy into effective enterprise change? As discussed in the first chapter

of the present paper, enterprise architecture usually addresses transformation by

approaching business and IT, the main concern being the alignment of IT with the

business. This approach is suitable in a vision where the business is the most im-

portant driving force of the enterprise and where IT represents an asset whose

main function is to serve the business. But when IT is ubiquitous and when inter-

actions exist between all aspects, this simple approach may be inadequate for

practical purposes. Indeed, how many times have we witnessed a transformation

fail because some critical aspects like culture or behaviour were overlooked? And

yet, in those cases, enterprise architecture was quite practised as defined by the

state of the art methodology.

2.3 Embracing other subjects

Let’s now examine the disciplines involved with transformation in a context

where IT is ubiquitous in the organisation. Most often, the organisation proceeds

6

through an association of disciplines such as strategy, business analysis, innova-

tion, enterprise architecture, change management, and talent management. People

all work together to enable the transition into the desired state of the organisation

and to find the right interaction that delivers added value.

Needless to say, there are other disciplines involved in the transformation pro-

cess and a strong “organic” interaction between them. These disciplines imply

quite a number of aspects beyond business and IT as well as interactions in both

directions. For example, the organisational behaviour influences the way people

interact within business processes which in turn influence the target state of the IT

landscape. Conversely, the latter influences skills and competencies. This illustra-

tion calls for two observations:

a) All aspects are intertwined and to be considered when transforming an

organisation, beyond the separation wall of business and IT

b) Enterprise architecture is not the only discipline at stake when transform-

ing the organisation

Given this, can enterprise architecture take up the challenge of mingling differ-

ent aspects of the organisation beyond business and IT and act as more than a

catalyst for transformation?

2.4 Enterprise as a network of aspects: a holistic approach

In order to answer the latter question, let us formalise architecture in the con-

text of an enterprise. Architecture can be defined as the “structure of components,

their inter-relationships, and the principles and guidelines governing their design

and evolution over time” [7]. An enterprise can be defined as an “organisation en-

gaged in the trade of goods, services, or both to consumers” [8] and viewed as a

complex system of socio-technical aspects including people, culture, information,

technology, business operations, and intellectual property. Enterprise architecture

is usually focused on the business and IT aspects of the organisation. This scope is

surrounded by a context, which includes all other aspects. Enterprise architecture

is normally responsible for the articulation between the scope and the context as

described in the following figure, while making the necessary alignment between

business and IT.

7

context

scope

business IT

finance people skills

motivation

culture

ethicsbehaviourorganisation

policies

management

interaction

alignment

Fig. 2.1. Usual scope and context of enterprise architecture

While simple in its conception, this way of separating concerns may be out of

phase with reality. We indeed observed that in a context of transformation, all as-

pects are to be considered and are linked with one another. This would imply an

overlay of the scope and context as well as links between all aspects as follows. scope = context

finance

business

IT

people skills

motivationpolicies

managementculture

organisation behaviour ethics

Fig 2.2. The enterprise: a network of intertwined aspects

In graph theory, the above representation is an undirected and unweighted

graph. Each aspect in consideration can be represented by a “vertex”, and each

link between two aspects can be represented by an “edge”. Using a holistic ap-

proach, approaching enterprise architecture would theoretically imply studying n

“vertices” and n(n-1)/2 unique “edges”, in two temporal states (baseline and tar-

get).

One matter yet to consider is that depending on the case, interactions between

aspects are in reality not equivalent one another. For example, while in most en-

terprises there is a strong mutual influence between “business” and “behaviour”,

8

there can be very few interactions between “IT” and “ethics”. This can be mod-

elled by putting a weight on each “edge” of the graph inversely proportional to the

importance of the interaction between the two aspects. The business/IT “edge”

would be weighted at 0 by default as it obviously owns a particular position. Con-

versely, there could be no interaction between two aspects, leading us to simply

delete those “edges” from the graph.

Given this, and because all aspects have to be at least analysed separately, we

are compelled to select all “vertices” in the graph and in theory, all “edges”. Stud-

ying the n(n-1)/2 “edges” would however not be efficient from an executive point

of view and one would be enticed to select the most important remaining “edges”.

This problem can be solved in two ways. One is to arbitrarily select the most im-

portant “edges”. Another is to have recourse to a formal method, such as for ex-

ample finding the Minimal Spanning Tree (MST) of the given graph. A spanning

tree is “a subset of edges forming a tree connecting all vertices” and the MST is

“the smallest connected graph in terms of edge weight” [9]. Among the possible

algorithms to find the MST, stand the Prim’s and the Kruskal’s algorithm [9]. We

consider the Kruskal’s algorithm since it will automatically by principle select the

business / IT “edge” whose weight is 0 by default. The following figure illustrates

this algorithm on a graph representing the interconnected aspects of the organisa-

tion in one given temporal state.

0

2

2

4

5

466

7

77

9

1

3

2

4

5

6

Fig 2.3. Illustration of the Kruskal’s algorithm. The numbers in the original graph repre-

sent weights. The numbers in the MST represent the order of insertion.

This example illustrates that it may be conceivable to reduce the number of in-

teractions to study while at the same time address the most important ones using a

formal graph algorithm. Consequently, one could envisage tackling the analysis

part of enterprise architecture in its entirety and not uniquely on business and IT

aspects. This holistic approach may have the benefit of broadening the scope of

enterprise architecture and revive its purpose in today’s environment. It could

thereby have the potential to become one day the practice to consider when deal-

ing with enterprise transformation as a whole.

In the next chapter, we make an attempt to use this approach on an imaginary

business case before giving hints for new perspectives.

9

3 Bringing it into reality

3.1 Framing the analysis

In order to illustrate the approach described above, we now imagine a business

case with an enterprise named Buy-A-Lot, a major player in the electronics retail

sector. In 2012, Bob Casey, the CEO of the company, in response to a harsh com-

peting environment, decides to launch the “Back on Track” program based on

three major strategic orientations: cooperation, interoperability and agility.

In order to plan the transformation, we define the target state of the company

using first a traditional business/IT dual framework, leading to the following high-

level vision statement.

Aspect Description in the target state

Business Highly tactical customer services

Harmonised and end-to-end processes

Clearly defined business services

IT Agile development

Portals and Intranet

Mutualisation of technical resources

Usage of standards

SOA (Service Oriented Architecture)

Table 3.1. High-level vision of the target state of Buy-A-Lot on Business and IT

This first analysis could be satisfying as such and lead to further analysis and

modelling. Bob Casey is however warned about common SOA pitfalls, especially

those dealing with changes in business habits, including the reduction of overlap-

ping in roles and responsibilities. On that account, he wishes to build analysis on

the following aspects as well: behaviour, organisation and skills, making a number

of 10 interactions to study. By adopting the MST approach, he hopes that this

number and consequently the amount of work to provide could be reduced.

The following table is the weighted adjacency matrix of the aforementioned as-

pects in the target state of Buy-A-Lot. Weights are attributed based on the assump-

tion that SOA leads to fundamental changes in behaviour and skills while harmo-

nised and end-to-end processes infer changes in behaviour and organisation.

Business IT Behaviour Organisation Skills

Business - ∞ 12 10 5

IT ∞ - 15 4 8

Behaviour 12 15 - 3 2

Organisation 10 4 3 - 4

10

Skills 5 8 2 4 -

Table 3.2.Weighted adjacency matrix of the aspects in the target state of Buy-A-Lot

Using Kruskal’s algorithm, we can delineate the MST of the graph that leads us

to reduce the number of interactions to study by 60%. The outcome of the discus-

sion on the four remaining interactions is as follows:

Edge Discussion on the alignment

Business-IT - Already covered in the first analysis

IT-Behaviour - SOA calls for responsibility and transparency

- People should collaborate in a service oriented fashion between -

departments (no more request isolated from predefined services)

- Mutualisation of resources and standards mean more strict rules

and potential tensions

- Agile development infers perimeter and timing strictness

Business-

Organisation

- Clearly defined business services and end-to-end processes im-

ply no redundancy in the organisation

IT-Skills - New skills are needed with agile development, SOA and collab-

oration through portals and intranet

Table 3.3.Discussion on the main interactions between aspects of Buy-A-Lot

This quick analysis makes it possible to refine the description of the aspects

and draw a more consistent vision of the target state of the enterprise.

Aspect Description in the target state

Business Highly tactical customer services

Harmonised and end-to-end processes

Clearly defined business services

IT Agile development

Portals and Intranet

Mutualisation of technical resources

Usage of standards

SOA (Service Oriented Architecture)

Behaviour Delimitation of responsibilities and transparency

Service orientation in working habits

Rigor

Potential tensions

Organisation Redundancy free organisation

Skills New skills correlated to new usages and technology

Table 3.4.Refined high-level vision of the target state of Buy-A-Lot

11

This example, while simplistic at first sight, shows however that this approach

can enable a more consistent and rather fast picture of the enterprise. The next step

would consist in defining the baseline state, analysing gaps and defining the tran-

sition.

3.2 Integrating with current practices

While defining the transition, Bob Casey main concern lies in the follow-up

phases, especially regarding the integration with current practices in the company,

for example enterprise architecture, or skills and change management.

One possible way to deal with his concern is to integrate the approach in exist-

ing practices, such as TOGAF. It can indeed be seen as an extension of the analy-

sis in B, C and D phases of the ADM (Architecture Development Method). Start-

ing from phase E, practitioners have the choice between:

a) Restraining themselves to the study of the usual business and IT aspects:

in that case this approach would just be an enhancement of the methodol-

ogy

b) Including all other aspects in the transition and planning analysis. In that

case, this approach could be seen as a practice of enterprise transfor-

mation that would embrace other practices than enterprise architecture.

Facing those two options, Bob Casey acknowledged the relevancy of an enter-

prise transformation practice, but due the novelty of the idea, decided to mitigate

risks and eventually chose the first option.

3.3 New perspectives, new challenges

The approach developed and illustrated previously could be a first step to en-

visage enterprise transformation in a complete, holistic, yet pragmatic manner. It

certainly paves the way for new perspectives more consistent with today’s envi-

ronment, as initiated in certain practices such as Praxeme.

Perhaps one day we will see a more efficient and consistent method for trans-

forming the enterprise. Yet, this also leads to new challenges, such as the model-

ling of all concerns or the integration of all practices within one single framework.

There is undoubtedly much work remaining but the effort may be worthwhile to

make progress in this highly potential field of enterprise management.

12

Cited references

1. Definition of enterprise architecture by Gartner

Gartner, http://www.gartner.com/it-glossary/enterprise-architecture-ea/, accessed 26th July 2012

2. On the role of scientific thought

Edsger W. Dijkstra (1982), selected writings on Computing: A Personal Perspective. New York,

NY, USA: Springer-Verlag New York, Inc. pp. 60–66

3. The Open Group Architecture Framework

TOGAF, http://www.opengroup.org/togaf/, accessed 27th July 2012

4. Zachman Framework

Zachman, http://www.zachman.com/, accessed 27th July 2012

5. Leading Change: Why transformation efforts fail

John P. Kotter (2007), Leading Change. Harvard Business Review, Reprint R0701J

6. Definition of enterprise architecture by Praxeme

Praxeme, http://www.praxeme.org/index.php?n=Thesaurus.EnterpriseArchitecture?userlang=en,

accessed 14th August 2012

7. Definition of architecture in TOGAF

TOGAF, http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html, accessed 27th July

2012

8. Economics: principles in action

Arthur Sullivan, Steven M. Sheffrin (2003). Economics: principles in action. Upper Saddle Riv-

er, New Jersey 07458: Pearson Prentice Hall.

9. The Algorithm Design Manual

Steven S. Skiena (2010). The Algorithm Design Manual. Second Edition. Springer.

Used abbreviations

IT: Information Technology

TOGAF: The Open Group Architecture Framework

MST: Minimal Spanning Tree

CEO: Chief Executive Officer

SOA: Service Oriented Architecture

ADM: Architecture Development Method