See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/273793763

Business Architect: A Critical Role in Enterprise Transformation

Article in Journal of Enterprise Transformation · March 2015

DOI: 10.1080/19488289.2014.893933

CITATIONS READS

10 2,794

1 author:

Harry H. M. Hendrickx
HHE Investment Services
4 PUBLICATIONS 20 CITATIONS

SEE PROFILE

All content following this page was uploaded by Harry H. M. Hendrickx on 30 September 2015.

The user has requested enhancement of the downloaded file.

 Business architecture for successful transformations

Business architect: a critical role in enterprise transformation

Short title: Business architecture for successful transformations

Harry H.M. Hendrickx, PhD

Address correspondence to H.H.M. Hendrickx, Kerkstraat 11, 4847 RM Teteringen,

Netherlands, Mobile phone: +31 6 27329735, harry.hendrickx@hp.com

Harry Hendrickx holds a Master of Arts in Economics since 1979. He has worked cross industry as
marketer, business consultant, architect and Chief Technology Officer. Since 1987 in the IT sector.
His major topics are business IT alignment, enterprise transformations, business architecture and
governance. Since 1997 he has published articles in (international) academic and practitioner’s
journals, conference papers and books on the topic of business architecture and governance. In 2007
he acquired his PhD at Tilburg University with the thesis “Governance in the practice of the CIO”.

Acknowledgement: the opinions expressed in this paper are the author’s personal view. However, he
could never have accomplished this without the help of others in shaping these ideas. Special thanks
are given for the participants of the special working group of The Open Group1. We all participated in
defining the profession of the business architect during monthly and quarterly meetings between
October 2009 and September 2011. Special thanks should be given to Kevin Daley, Mieke Mahakena,
Mark von Rosing and Leonard Fehskens who were key contributing participants

"This is an Author's Accepted Manuscript of an article published in Journal of Enterprise

Transformation, Volume 5, Issue 1, 16 March 2015, [copyright Taylor & Francis], available online at:
http://www.tandfonline.com/toc/ujet20/5/1 [DOI:10.1080/19488289.2014.893933]."

1
The Open Group®, ArchiMate® 2.0, TOGAF® are registered trademarks of The Open Group in the
United States and other countries.

1
 Business architecture for successful transformations

Business architect: a critical role in enterprise transformation

The recent wave of innovations forces organizations to transform. Current business

models easily become irrelevant, unresponsive and unready. However, successful
change is difficult. In literature failure rates of change efforts of over 70% have been
shown. This article addresses the issue of connecting strategy and implementation from
an architecture perspective by taking a holistic view on the business through a
controlled language, modelling and implementation. The author contends that business
architecture practice can contribute substantially to increase the success rate of
enterprise transformations through alignment of the need, the approach and internal
context. He also argues that a controlled language is one of his key assets, since it
provides rigor in defining and communicating what the right work / right way is when
transforming the enterprise. Thus it resolves one of the big challenges caused by
technological developments. By setting direction and communicating business needs
with rigor the business architect profession enables executive leaders to better
supervise and monitor transformations.

Keywords: business structure; change management; enterprise architecture; strategic

planning; standards

Introduction

This article provides insights in the evolution of a new critical role in enterprise

transformations. The first part includes the definition of business architecture, discusses

issues with traditional practices and discusses its value for enterprise transformations. The

second part of this article contains a literature review and discusses the evolution of insights

and techniques from academics as well as practitioners. Here is assessed what may contribute

to the enhancement of the business architecture practice. In Part III a new methodology is

proposed for a more rigorous transformation approach. Special attention will be paid to the

importance of a controlled language. Furthermore author argues that a holistic approach is

critical, that it is missing in transformations and that there is a need to describe and

communicate the holistic view.

2
 Business architecture for successful transformations

Figure 1 Article structure

In Part IV eight generic steps in business architecture are described and how it is

applied in real life cases. Finally some conclusive remarks are made about the maturity and

value of the profession of the business architecture.

Part I Need for a new profession

Business architecture definition

A concept is best understood once the perceived context is known. However, for better

readability the author defines business architecture upfront. Thus it will serve as a reference

for different sections of this paper. Business architecture is defined as the “formalized

description of how an organization uses its competences for realizing its strategic intent and

3
 Business architecture for successful transformations

objectives”.2 The practice described in this article has the controlled language at its core and

this definition of business architecture is its centre piece. Although the controlled language

has been developed independently and is based on both academic and practitioner’s results it

is fully compliant with the profession as defined by The Open Group (Hendrickx et al, 2011).

Furthermore the author builds on the work by Kotnour (2011) who developed an emerging

theory of enterprise transformations after an extensive literature study and a detailed case

analysis. He defined a framework unifying critical aspects for enterprise transformations. It

will be shown that through horizontal (cross domain) and vertical alignment (strategy and

operations) the proposed business architecture method is very appropriate to apply when

transforming an enterprise. The method standardizes the assessment and communication of

implications of external business vision and strategy for its structure and operations.

Two aspects in particular are relevant in this context. First the importance of “making

a strategy real – systematic change efforts” and second “the alignment of transformation

approach with internal context and transformation need”. The first aspect is being dealt with

because the business architect assesses the structure for accommodating a strategy, and he

sets the direction how solutions comply with it. The second aspect is being dealt with because

he differentiates in his method between the determination of business needs and the

assessment of implications of a strategy for the internal context. This allows him to explicitly

control both vertical (strategy – structure - operations) and horizontal (cross domain)

traceability of requirements.

2
This definition has been agreed upon by the members of The Open Group – IBM, HP, Capgemini,
SAP, Oracle and Ernst & Young - who are Platinum members (the highest membership level)
and represent some 70% of IT services globally. These suppliers have been in different working
groups since 2006 to capture the standardized practice of the business architecture profession.

4
 Business architecture for successful transformations

Issues traditional practice

Current techniques and practices are not adequate. Systematic change means controlling

development of initiatives and assuring that they contribute to the transformation goals. Many

techniques and methods are available – SWOT analysis, capability analysis, strategy

development, business modelling, architecture approach, critical success factor analysis, root

cause analysis, lean six sigma and more – but none of these provide a full perspective how to

translate the strategic intent systematically into an implementation plan. The large number of

techniques and approaches developed over several decades show that this is not easy.

Apparently a need exists to more explicitly prescribe how to provide the full

perspective. A more comprehensive discipline is needed. So, how does a good approach look

like? The ideal approach includes insights that clarify a vision statement; communicates the

intent of stakeholders, goals and objectives; gives clear direction for prioritizing short term

activities; and last but not least includes a shared reference for communication throughout the

transformation lifecycle. How can those criteria be met? Before investigating the evolution of

potential techniques and approaches the challenges in enterprise transformation need to be

well understood. The next paragraph gives a summary based on an academic article from

Purchase et al (2011) and a report on “State-of-the-art architecture 2012” published by the

Netherlands Architecture Forum (NAF 2012). Purchase et al (2011) argued that three aspects

are critical for sound governance of enterprise transformations: a holistic view, multi-

stakeholder management and the systemic nature of transformations. Several academic

authors show that the interest for a holistic enterprise perspective is supported by the view of

many other practitioners and academics.

Value in enterprise transformation

The value in enterprise transformation of the business architect is supported because that role

5
 Business architecture for successful transformations

addresses the key challenges of enterprise transformation. Purchase et al (2011) have also

reported on the difficulty to capture and communicate the enterprise boundaries. Indeed it is,

when one takes the holistic perspective. This is a critical part for resolving transformation

challenges. When one can communicate the boundary and understands the business logic, it

is also possible to define the different groups of stakeholders and their interdependencies.

This would clarify the route of communication, the preferred structure of decision-making

and the shape of decision-making processes. A second challenge for enterprise

transformations is to have a full understanding of the complex inter-play of enterprise and

individual partner goals and the extent to which conflicting goals need to be acknowledged.

The identification of stakeholder values, along with the creation of a multi-stakeholder value

proposition has been proposed as a key strategy for enterprise leaders before starting a

transformation. The business architect addresses this challenge by identifying key

competences and mapping network dependency thus he provides a basis for assessing the

most effective approach.

The third challenge acknowledged by the case described by Purchase et al (2011) is

the recognition of the systemic nature of transformations. The holistic nature tends to get lost

during the implementation phase due to reductionism and a natural move towards more

dyadic operations of sub-teams as opposed to an integrative process. Often one starts

holistically, increases the number of involved participants and then breaks the program down

into workable parts. Most transformations struggle keeping these parts aligned and

integrating them again. With the proposed controlled language parts will be kept aligned

through creation of a holistic view, definition of the boundary of transformation,

identification of the key stakeholders and mitigation of a dyadic process. It is argued that the

business architecture practice is critical for addressing these three challenges and that it

increases the success rate of transformations.

6
 Business architecture for successful transformations

There is another reason to believe that the business architecture profession contributes

to resolving these challenges– holism; multi-stakeholder; systemic nature. This seems

supported by the Netherlands Architecture Community (NAF 2012). Analysis of the state-of-

the-art practices in >100 member organizations of the Netherlands Architecture Forum has

shown several topics with this respect: align intent and architecture; the importance of a

holistic view for successful business IT alignment; importance of a simple language for the

dialogue between stakeholders (NAF Bayens, 2012; NAF Wagter et al., 2012; NAF, 2012).

Intent is something that resides with governing managers rather than implementation

managers. CIOs expressed the need for a role – either from architects or from another

profession – capable of conducting a meaningful dialogue with direction-setting stakeholders

to understand the business intent and its implications for operations. At least 5 out of 14 CIO

interviewees explicitly confirmed the lack of alignment in current architecture practice

between intent and shape of architecture and implementation. Since these issues are not

entirely new, it makes sense to have a closer look at the origin and evolution of the

methodology, assess what the remaining gap is and how to address it.

Part II Literature review

Loose techniques to methodology

Many academic authors and practitioners have addressed these challenges in one or another

way. The invisible hand, political stability, rise of the firm, business dynamics, administrative

behaviour and managing complexity are the themes of concern since Adam Smith (Adam

Smith, 1775; Coase, 1937; Simon, 1961; Forrester, 1971; Ackoff, 1972; Checkland, 1998;

Gharajedaghi, 1999). All have been looking for ways to understand and control how context

influences operations, structure influences performance and how the combination of different

aspects influences organizational dynamics and operational results. Many of their insights are

7
 Business architecture for successful transformations

slowly adopted by an international community that joined forces in international bodies and

has developed and adopted architecture practice over the past two decades for managing the

complexity and risks of information technology. However, after two decades transformations

continue to be a big challenge (Standish Group, 1994; Eveleens, 2010; SIM, 2011). Most

transformations had taken a biased approach – biased to either the strategic, or the business,

or the process or the IT domain – and subsequently got stuck along the way. Meanwhile some

authors argued that success is more likely when strategy and operations, business activity and

technology are integrated and considered in a holistic way (Venkatraman, 2008; IBM, 2010;

IBM, 2011; Versteeg, 2006; Wolfenden, 2000). These authors reinforce this view which has

also been reported by Purchase et al (2011). What caused that the holistic approach has not

been widely adopted?

Already since the late fifties executive level management had recognized the need for

proper methods to communicate priorities for planning and monitoring purpose. R.D. Daniel

(1961) was first to describe it explicitly. He proposed to use Critical Success Factors. This

approach was subsequently tested and enhanced by others. Boynton and Zmud (1984) had

evaluated the practice of Critical Success Factors assessment and its practical use for

planning and communication of priorities as well as information requirements assessment.

Based on two case studies they concluded on the one hand that it is strength of the CSF

method to “develop insights into a number of information services that could significantly

impact the corporation’s competitive position” (page 7). On the other hand that “managers

not involved in strategic & tactical planning can experience difficulty in dealing with

conceptual nature of CSF’s” (page 7). This suggests the difficulty to communicate strategic

intent and vision to middle managers. This view was confirmed by these authors since they

noted as one of the weaknesses of the CSF method: ….”difficult to use and therefore not

appropriate unless analysts possess the capability to successfully apply the method…”.

8
 Business architecture for successful transformations

Within the context of this article the key point is that managers at executive level need to

communicate their priorities and that these have to be well understood and applied by both

managers and professionals at tactical and operational level in the organization.

Strategic view

Other contributing articles come from Prahalad and Hamel (1990) on respectively core

competences and Porter (1996) on the essence of strategy. Furthermore PRISM (1986) on

principle driven information-need assessment may be seen as a sister of the CSF method,

since it also tries to identify key statements that drive the shaping of organization and

information systems (Davenport, 1989). Especially the abstraction layer of competence is one

which is critical for the business architect. Both Prahalad and Hamel (1990) and Porter

(1996) have analysed how insight, experience, culture and fit may be captured. Prahalad and

Hamel developed the concept of “competence”, and Porter developed the concept of “key

mechanism” each at the same abstraction level. Prahalad and Hamel define core competence

as “the collective learning in the organization, especially how to coordinate diverse

production skills and integrate multiple streams of technologies”. Porter emphasizes the

importance of combination and fit of different skills, attitude, activities and technologies. He

captures the combination of those aspects in “key mechanism”, as the level that expresses the

strength of the organization, its internal dependencies and thus sets direction for shaping

operations. Porter has demonstrated in “What is strategy?” how “key mechanism” relates to

strategic options and how it distributes requirements over other activities. Both contributions

are critical for the business architect because they show how to analyse and capture the

dynamic processes of organizations. Without this abstraction layer traceability between

strategy and structure remained too vague. It enables to move from a reductionist view to a

more holistic view of business.

9
 Business architecture for successful transformations

System view

The quest for managing complexity and chaos resulted in a spectrum of similar

developments. Gharajedaghi (1999) was the first to use business architecture as a way of

thinking and proposed it as a response to complexity and chaos in organizations. He believes

that business architecture is about governing a business for success with a holistic

perspective. His contribution is relevant when defining what aspects should be included in a

holistic view. He approached organizational problems with systems thinking and shows that

different system types exist: mechanical systems, biological systems and social systems. Each

of these has a different structure as well as different behaviour. Organizations are socio-

technical systems which are multi-minded and interactive. He defines organizations as

systems with throughput and organizational processes with four organizational mechanisms

that resolve conflict, assure role identity, decision-making and measurement. Also he argues

that learning is a key ingredient of multi-minded systems where each stakeholder has choice.

He analyses what the basic dimensions of interactive systems are, and what their system

principles are. He gives a description of interactive systems that illustrates concepts that

should be included when managing for success. It is shown how assumptions and

expectations are part of the diagnostic system of an organization, and how feedback and

learning becomes critical to influence decision-making because it develops new shared

insights. See also the work of John D. Sterman (2000) for the systems view of organizations.

This perspective supports the idea to include “assumptions” and “belief” in the holistic view

as well as in the controlled language. It also reinforces the idea that communication is one of

the most critical skills for the business architect since it addresses the feedback and learning

aspects of interactive systems.

10
 Business architecture for successful transformations

IT view

Other authors have a more IT focused perspective. Some focus on the information aspects of

business. Others focus on the process aspects of business. Most apply reductionism to address

complexity, and none deals with the holistic view. The closest to the holistic view is

McDavid (1999) and OMG Business architecture working group (2009). Most authors focus

on eliciting the requirements for IT solutions typically starting with strategic statements and

contextual factors, or more specifically start with existing domains of accountability, and

subsequently derive the process and information architecture (Versteeg, 2006; Wolfenden,

2000; van der Sande, 2000; Business Architecture Guild, 2012). Their common quest is to

clarify the space between strategic statements and solutions in the IT domain. They support

the idea that one of the major contributions of business architecture is its controlled

distribution of information requirements derived from strategic statements.

Van der Sande (2000) and OMG (2009) look for the information architecture as the

intermediate for IT solutions, and McDavid (1999) and Wolfenden (2000) look for a more

holistic organizational view to derive requirements for solutions. Versteeg’s (2006) analysis

seems to lack inclusion of the business logic of the enterprise, the interdependence between

parts of the organization and does not consider explicitly environmental factors that influence

performance. Wolfenden (2000) argues that a holistic approach is needed, which includes

besides the rational decomposition of value statements into requirements also the political

and emotional elements. He proposes to go beyond the process context. However, it is not

shown yet how the gap between strategy and IT could be bridged. McDavid (1999) has

proposed concepts for business architecture practice that better deal with emotional and

cultural aspects. However, these approaches remain isolated, and do not connect the dots of

all aspects yet.

11
 Business architecture for successful transformations

These authors share recognition for having a holistic view which can be

communicated and used for deriving IT requirements. This resonates well with the report on

enterprise transformations from Purchase et al (2011) as well as the contributions of Prahalad

and Hamel, Porter and Gharajedaghi. However, their elaboration differs. Although

Wolfenden claims to provide a holistic view, the technology aspect has not been paid

sufficient attention to. On the other hand Versteeg does not pay much attention to the origin

of strategy statements. Hence, it is difficult to understand and translate the business logic

(how value is created; how revenues are generated; how operational excellence is achieved

and how competition is dealt with) into requirements for operations. A similar comment

applies for the work in the OMG working group for business architecture and the handbook

of the business architecture guild (OMG, 2009; Business architecture Guild, 2012). That

working group has focused on the objects – topics of interest - of an enterprise not on the

business logic which explains the fit of different parts of the enterprise. In brief it is fair to

say that none of the authors with focus on the IT domain succeeded to capture the holistic

view although they agree that it is relevant for deriving requirements.

A closer look at the practice of architects learns that business architecture has been

predominantly perceived as a reference for the context of IT solutions instead of the context

for operations. Subsequently business architecture has so far been focusing mostly on process

descriptions and strategic priorities, and lacked the holistic perspective. Dealing with inter-

dependencies between business domains or technological assets remains difficult. If this

problem is not resolved confusion about requirements remains and problems during design

and implementation continue to arise.

Dichotomised view

Traditionally requirements for operations or IT solutions are derived from strategic

12
 Business architecture for successful transformations

statements. As Henderson and Venkatraman (1993) have shown the idea is to align business

with IT and strategy with operations. They proposed a dichotomised view of the world. Both

the academic and practitioner community has struggled to use this thinking model. And this

was without success, as has been recognized by Venkatraman who recently argued that

business IT alignment is more important than ever before (Venkatraman, 2008). He reflected

that the step between strategy and operations appeared too big or too difficult. Although

techniques and frameworks have been developed to do this in a controlled way, apparently

none was sufficiently convincing and the debate did not stop. Maes for instance had argued

already in 1999 that for effective alignment the space between strategy and operations and

between business and IT has to be developed (Maes, 1999). The middle space refers to the

practice, content models and/or ways of communication. And, in hindsight this is in fact what

the holistic thinkers have strived to do: creating the content for proper communication

between the strategic and operational domains (Versteeg, 2006; Wolfenden, 2000; van‘t

Wout, 2010; Beijer, 2010). In these books and articles authors have reported at least a partial

success with their approach.

Communication view

Although the architecture practice has evolved strongly over the past two decades none of the

approaches has succeeded to bridge that gap either. This was recognized by The Open Group.

Its Board established the Business Architecture special task force at the end of 2009. It

requested to enhance the business architecture practice as part of the TOG Architecture

Framework (TOGAF) and assess whether there would be a need for business architects,

whether a business architecture method could be defined and whether the role could be

certified. Although TOGAF has evolved in a widely accepted standard with well elaborated

concepts and an Architecture Development Method the gap between strategy and operations

13
 Business architecture for successful transformations

was not yet sufficiently closed (van ‘t Wout et al., 2010; Beijer, 2010; Harishankar, 2010;

The Open Group, 2009-2011). The approaches have mainly focused on a decomposition of

business into business functions and the development of information architecture. However,

it still misses how to describe the strategic intent and business needs as a basis for deriving

requirements. Support for this current state of the practice can also be found in NAF (2012).

Apparently the current practice is not satisfactory and a closer look at the problem may help

to understand what is still lacking in the practice.

Even with the new concept of “competence”, it is fair to say that one problem is not

yet resolved sufficiently: bridging strategic and operational level. Boynton and Zmud (1984)

have shown that this cannot be done by analysis only. Apparently it is a skill and needs

discipline. This has recently been confirmed by the special taskforce for business architecture

at The Open Group (Hendrickx et al, 2011). No other currently practiced role in the field of

business IT alignment can fill this gap, neither the business consultant or business analyst,

nor the enterprise architect and technology architects.

The business architect profession is prepared for this role and The Open Group

taskforce has recommended to establish certification. In this article it is argued that the

controlled language is indispensable for this role, since it is required to accomplish the

communication between the different stakeholders. Some would argue that Archimate is such

a controlled language. And indeed the adoption by The Open Group of Archimate as a

standardized language in 2009 for describing architecture supports the idea of a controlled

language. However, also this language is not adequate to resolve the challenges described

above. It still lacks the connection between business vision and strategic intent with

operations. This is confirmed by the “ArchiMate ® 2.0 Specification, The Open Group

Standard” page 24: … “The core concepts of ArchiMate focus on describing the architecture

14
 Business architecture for successful transformations

of systems that support the enterprise. Not covered are the elements which, in different ways,

motivate the design and operation of the enterprise.”

Integration view

None of the methods discussed in the former paragraphs were adequate. The failure rate of

smaller initiatives and enterprise transformations had improved only marginally.

Organizations still struggle to handle the combination of technology and organizational

forces. Technology is a major driver, but it is only one aspect and is not sufficient. Other

relevant aspects are people, process and management, and last but not least the systemic

nature of organizations. It makes sense to investigate how these can be integrated in the

method.

Technology innovations have been an ongoing activity since information technology

exists. Operations have continuously changed in nature and several trend shifts occurred

since its origin: introduction of the mainframe computer, introduction of personal computer;

adoption of the internet; broadband infrastructure; and now information analytics of BIG

DATA, social media, mobilization and the internet of things. Complexity arises because new

technology does not replace old technology, but is added to it. Mainstream approach has

focused on isolating the technology aspects, but lacked a controlled integration. No

methodical way exists to conduct this integration. Moreover dynamics were too high and

organizations kept on lagging behind technological developments. The continuous stream of

adding new technology to existing infrastructures is a big complication for organizations. As

regards to integration the on-going fragmentation of both the supply side and demand side of

IT services results in three big challenges: (1) the requirements journey, (2) the decision-

making journey and (3) the holistic view. A closer look at these challenges gives direction to

the type of solution that is needed.

15
 Business architecture for successful transformations

The “requirements journey” challenge: stakeholders with different thinking models and

interests and at different managerial levels need a similar understanding of the strategic intent and

objectives. Imagine the number of stakeholders getting involved during a transformation. A small

group of stakeholders will grow quickly after visionaries and executives have envisioned a program.

Architects, engineers and implementers need to be clear about strategic intent and objectives

(Versteeg 2006; Wolfenden 2000). The first challenge is then: how to assure that needs and

requirements are both identified and communicated consistently during enterprise transformations?

Table 1 Requirements journey

The “decision-making journey” challenge: decisions for larger initiatives concern

many different aspects: environmental (regulation; culture); business vision related; business

logic related; they also concern the structure of operations; and last but not least they concern

the investment in the learning curve of an organization. And decisions in one area depend on

aspects in other areas. The aspects involved when looking at it from a decision-making

perspective are summarized in figure 3. One of the major concerns is to assure the

consistency of the communication of needs and requirements that address those. Before the

16
 Business architecture for successful transformations

“build decision” decisions are related to the needs and how to address them at what cost.

After the “build decision” interpretation issues occur. Transparency of strategic intent and a

common reference of dependencies and context would facilitate the decision-making process

and assure consistency over time and cross domain.

The third challenge concerns the need for a holistic view. Transformations are

systemic of nature since cause and effect are not always clearly linked and are often separated

over time. The presumption is that an explicit and holistic view of dependencies in the system

and a controlled language contribute to governing those dynamics and reckon with cultural

aspects and experience more explicitly. The first step is to capture the holistic view. The

controlled language show what concepts to include and how these are related with each other.

Figure 2 Decision-making journey

17
 Business architecture for successful transformations

Once captured they show traceability between business needs and structural /

operational requirements through explicit description of both vertical (strategy – structure -

operations) and horizontal (cross domain) dependencies.

In summary it is fair to conclude from the literature review and the three topics

discussed in this paragraph that the following aspects need to be included in the business

architecture methodology: controlled language; a provision to deal with integrative aspects; a

provision to capture and communicate the holistic view. In Part III a method is proposed how

these aspects are addressed.

Part III Proposed methodology

Methodology structure

After having established the remaining gap in the traditional architecture approach, the

methodology can now be completed. The proposed methodology integrates what other

disciplines - strategy, enterprise architecture, business consulting and IT architecture - have

been practicing over the past few decades and on top of that it includes the integrative and

holistic aspects. As discussed earlier the framework of Seligman et al (1989) for describing

information systems methodologies will be applied as a lens for analysing the aspects of the

business architecture method and unifying it as a method. It is called “The five ways”. This

framework has proven its value when developing the architecture capability in large

organizations, hence it is also used here as the frame for analysing the proposed business

architecture methodology and its applicability. First “The Five Ways” framework will be

described, and then applied to the business architecture methodology.

The Five Ways highlight different aspects of a methodology. The Way of Thinking

refers to the basic implicit or explicit assumptions and viewpoints of a methodology. The

Way of Working refers to the operational level of how to create, handle and use the models.

18
 Business architecture for successful transformations

The Way of Modelling describes the network of models, their interrelationships and a

detailed description of the model components and the formal rules to check them. It deals

with the conceptual aspects of the model. The Way of Control refers to the management of

creating, handling and using models, and the Way of Support refers to the techniques with

which the models are represented. Although Seligman et al. (1989) first “had some doubts

about the role of the way of thinking, during their exercise comparing five methodologies for

information system analysis they concluded that it is of central importance as a fundamental

item spreading its influence in a natural manner over the other “ways” (P22).” In the next

few paragraphs the way of thinking, working and modelling will be summarized for the

business architecture methodology as has been discussed in ‘The business architecture

profession’ by The Open Group in Hendrickx et al. (2011). In addition the author extends that

description in this article with the way of control and way of support.

Way of thinking

The business architect adopts a holistic way of thinking. The following notions are relevant to

his approach: holism, organization, competence and formalization. First these will be

discussed before discussing the other ways of the business architect methodology.

Holism is the view that parts can only be understood if one understands it in relation to

other parts of the system. It is opposed to reductionism which takes a simplified often biased

perspective. Holism is the idea that a natural system and their properties should be viewed as

wholes, not as a collection of parts. This often includes the view that systems function as

wholes and that their functioning cannot be fully understood solely in terms of their

component parts. In other words a holistic description of the business should not only

describe the parts of the architecture, but also relate them to the external context, strategy and

19
 Business architecture for successful transformations

operations, organization and technology. It is the challenge of the business architect to show

the cohesion.

Organization is understood as the whole of parts, interconnected and shaped to provide

a service to the environment. In this context Gharajedaghi is followed and organizations are

perceived as socio-technical systems. This implies on one hand that the system contains parts

that have free choice, are influenced by feedback and may have unexpected dynamics

(Gharajedaghi 1999). On the other hand it contains technical artefacts that rely for their

appropriate functioning on human actions or social relations. Experience, feedback and

learning are important aspects of social systems. This set of notions is critical for describing

the essence of an organization. Other relevant elements he has included for dealing with an

organization from a systems perspective are: throughput processes, conflict mechanism,

membership, performance measurement system, decision system and learning & control

system.

Competence is a mechanism applied by the organization to realize strategic intent.

Competences express both the business and organizational need and bind capabilities and resources.

Competence is considered to include aspects of culture and experience. A competence is juxtaposed

from capability(s) or resource(s) that have a more static character, but get a dynamic character when

experience and culture are added. It links strategic intent with business structure through policies.

Competence description is a critical part of the formalized description since it includes the origin of

dynamics in an organization, and also includes the human aspects of choice and experience which

have to be included when taking a holistic perspective of a business. Capabilities address issues or

specific needs and are a combination of resources in a specific relation to each other. And capabilities

can be disentangled into the elementary parts: people, process, technology, management and

information.

Formalization and standardization of concepts is critical for consistency and

communication. The complexity in conveying the intent and priorities across management

20
 Business architecture for successful transformations

levels and disciplines (a.o. functional specialists, business analysts, architects, solution

developers, technical infrastructure experts), between regions and locations often spans

months and sometimes years between the confirmation of a business need, the expected

benefit, the requirement and its application. The relay between creation of insights and their

application pose specific challenges in storing, retrieving and communicating business needs

according to a specific protocol: capturing the meaning; communicating the meaning (NAF

Wagter, 2012); maintaining the meaning. First of all the challenge to capture and

communicate the importance of a specific requirement is resolved through explicit definition

of traceability in the controlled language. Secondly the challenge to assure the right

interpretation of the implication of the holistic view is addressed by formalizing the language

in a way that always the context of a requirement can be traced through the defined holistic

view. This resolves the issue of losing the idea when the enterprise transformation spans

months or even years. Standardized frameworks and tools have been popular with this

respect. Examples of accepted standards are: The Open Group (membership >300 suppliers,

vendors and academia) - Architecture Development Method; Telecom Management Forum

(membership of >80% of Communications Service Providers globally) – Frameworxs; and,

ITIL as widely adopted standard for IT Service Management. The four above notions are

foundational for the business architecture discipline. The relations between them will be discussed in

the next paragraph.

Holistic view of vision, intent, priorities and operations. The proposed goal of

business architecture is to understand how relevant external factors, strategic intent and

investment priorities can be linked with tactical – i.e. structure – and operational level.

Another proposed goal is to identify and communicate the implications of strategy for

operations. A third goal is to assure that aspects are aligned and governed with a holistic view

21
 Business architecture for successful transformations

and that integration of all aspects is more explicitly done. To accomplish these goals the

business architect has to formalize the description of the following aspects of business:

 Holistic view. The business architect considers all elements of equal importance and

each may have a potential impact on other elements. Hence the holistic view includes

all relevant parts and is the business architecture. It includes the external vision, the

strategic intent, the strategic priorities and operations, and it addresses the integrative

aspect of business architecture.

 External vision. Effectiveness of the structure of the change area is interdependent

with the context of that change area. The external vision conveys the visionary’s

insights, thinking models, beliefs and assumptions and includes the factors from the

context that have an impact on operations. The vision is an interpretation of those

factors, the opportunity these provide and the challenges to accomplish the business

vision.

 Strategic intent. The strategic intent conveys the purpose of the system and how it is

expected to perform. Strategic principles and competences are core concepts to

communicate the strategic intent. This concept also addresses the integrative aspect of

business architecture.

 Investment priorities. Is part of the holistic view and sets direction for investment and

action. Objectives set executives in motion and convey the direction for shaping the

operational structure and required solutions.

 Operational structure. Is part of the holistic view and describes the relations between

operational elements: people, process, technology, managerial aspects and

information. The operational structure is interdependent with the external vision and

strategic intent. It describes those parts that are considered essential to realizing the

22
 Business architecture for successful transformations

strategic intent. It explicitly combines elements cross domain and establishes the

connection between strategy and structure.

 Operation. Is part of the holistic view and describes how resources are configured and

what solution requirements are. It is the user perspective of the solution – or the

black-box view.

Figure 3 Holistic view of a business

Controlled language. As argued before, the communication flow during the

transformation through management levels and disciplines requires a controlled and

formalized vocabulary. Using the business architecture vocabulary enables capturing a

holistic view that is consistent, and explicitly clarifies the relation and dependencies between

23
 Business architecture for successful transformations

parts. Figure 4 summarizes the major concepts of this controlled language. It is beyond the

scope of this article to provide all the details and definitions, but the argument for this has

been presented at a conference of The Open Group in Amsterdam in 2010 (Hendrickx 2010)

and is based on a pilot conducted by an international team of different disciplines of members

of The Open Group Business Architecture Working Group.

Way of working.

The pre-requisites for a business architect are (1) to bring sufficient industry knowledge

related to trends and business models, and (2) to understand the basics of business as well as

information technology. Business architects may be generalists, but specific industry

experience is an advantage. As regards the technology they need an understanding of the

essential characteristics and the implications for operations. They have to continuously learn

about the structural implications of a new technology or other market trends, the operational

implications and the challenges for a transformation process. Another important characteristic

of the business architect is that he considers all elements of equal importance. This means

that he assumes that the change of one element may have implications for another one. A

third characteristic of the business architect is that he/she has to follow iterative thinking

or/and an iterative process during architecture development. The business architect has the

method and approach to simulate implications of market trends. Iterations do generate better

understanding and new insights. Once he has done this, he can further elaborate the business

structure and solution requirements in a formalized way. Last but not least business

architects need social and consulting skills to generate a dialogue with executives on the

alignment of strategic intent, the architecture and operations.

The way of thinking and way of working of the business architect as described in this

article is fully aligned with TOGAF 9.1 way of thinking and working. As regards the

24
 Business architecture for successful transformations

different domains of TOGAF 9.1 Architecture Development Method the practice contributes

in particular to Phase A Architecture vision, Phase B Business Architecture and Phase G

Architecture Governance. At Phase A the architecture vision is developed. The business

architecture practice and controlled language gives guidance on which concepts are relevant

for describing a holistic view and which internal and external challenges are expected. Also

scenarios and risk mitigation are developed. At this level the integrative view is retained.

During Phase B the horizontal and vertical traceability between business needs and solution

requirements is elaborated as well as cross domain fit. At this phase each aspect area is dealt

with separately, but also the integrative view of a business is retained. As regards Phase G the

business architect contributes because his insights clarify which stakeholders to involve in

and grant authority in decision-making. The guidance of the current standard TOGAF 9.1 is

too generic for practitioners who seek this guidance, and also some concepts are not included

in the current version. Once TOGAF Phase A and Phase B have been captured in a

formalized description it sets direction for Phase C, D, E, F and H.

Way of modelling

Modelling is always a second best. However, it is better than no modelling. It enables

checking consistency of ideas, and how they are implemented. The business architect creates

formalized models for very different user groups: visionaries, executive management,

architects, engineers and implementers. Since each stakeholder group has personal and

generic preferences communication through modelling is a challenge. Therefore the business

architect applies controlled language and visualizations that reckons with the specific views

and tasks of these stakeholders. Modelling is required for several reasons: to model the

essential elements of a business and their relationship; to create a means for communication

between management levels; to create a means for communication between disciplines; to

25
 Business architecture for successful transformations

create a repository for maintenance and change purposes.

Figure 4 Modelling structure

During modelling the holistic vision is represented and the business needs (competences) are

determined. These formalized descriptions can be decomposed into requirements that are

distributed over business functions / services, capabilities or elementary resources. These

requirements in turn are unified into solutions. Pre-defined syntax to leverage standardized

concepts, controlled semantics to avoid ambiguity and explicit techniques to link the different

levels are required for traceability. For instance external vision and strategic intent are linked

through the mission statement. Strategic intent and strategic objectives are linked with each

other through objectives that express measurable priorities. Architecture level and solution

level are connected through policies that impose the performance characteristics of a business

26
 Business architecture for successful transformations

function and its enabling means. These connection points are central to the controlled

language.

External vision. The external vision contains concepts described in Figure 2. It

conveys the contextual developments applied to the business, its syntax assures that

challenges are explicit and understood by all stakeholders. With a common syntax

stakeholders can have more easily a conversation on the implications of trends or ambition.

The following syntax is proposed for the external vision: Considering the <trend(s); event>

and the following <assumptions; beliefs; insights> the organization identifies an

<opportunity; thread> to build a successful business with the following <business logic>

and <mission; ambition; priorities>. However, to accomplish this aspiration the following

<external challenges> and <internal challenges> have to be addressed.

Business logic. Top managers are concerned getting the vision and strategy embedded

in operations. The business logic is a critical element to assure this. It is in fact the result of

the interpretation of the external vision into a strategy. It should at least include strategic

statements – also referred to as ‘strategic principles’ - on the following aspects: value

creation, revenue generation, operational excellence and competitiveness. Sometimes one or

two other statements are added. Common additional aspects are e.g. globalization (how to

deal with the challenge of globalization) or collaboration (how to deal with the organizational

culture).

As an example the business logic for IKEA may look like this: IKEA creates <value>

by fully modular furniture design, generates <revenue> through direct sales channels,

achieves <operational excellence> through a fully E2E integrated supply chain and

warehousing function and is <competitive> through mass production of design furniture at a

low price. From these statements <strategic principles> the IKEA <competences> can be

derived essential to realize strategic intent and objectives.

27
 Business architecture for successful transformations

Mission. Once the business logic has been understood the organization needs to

establish boundaries of its business. What products and services does the organization

provide, what goals does the executive team formulate and what is the geographical

boundary. These aspects are part of the ambition and will result in the formulation of the

mission statement and strategic objectives. <Mission> is the formulation that conveys both

the need in the market place that the organization wants to provide its products and/or

services for, and at the same time clarifies the boundary of the business. <Strategic

Principles> on the other hand are explicit statements on the business logic that expresses

how executives belief their working model can accomplish the vision.

Competences. The strategic principles imply that specific competences are required to

accomplish the strategic intent. Competences express the business needs, and policies are

derived from these. These policies inform about the quality of the performance of operations.

And from the policy and performance requirements solution requirements can be derived. A

de-composition of the mission statement into a business function hierarchy is very helpful aid

to distribute the requirements over the business. At business function level the integration and

fit of activities can be analysed. An advantage is that requirements of resources can now be

derived without losing oneself in details. Another concept that appeared to be useful in

practice is ‘capability’. It is a helpful concept to define solutions, since solutions often

overlay several business functions. Hence capabilities may be considered as the highest level

of a solution that addresses a business need.

Competence – capability – resource. The relation between competence, capability and

resource need formalization to maintain traceability. A business is composed of resources,

resources combined provide a capability (skills, tools and techniques combined) and once an

organization has a company specific way to operate the capability becomes a competence.

Vertically requirements become traceable between competence and resources. Horizontally

28
 Business architecture for successful transformations

strategic fit becomes traceable through the dependencies/combinations of parts of the

business functions. By applying a formalized description for these concepts traceability of

requirements is assured. As an example in figure 6 the concepts of the controlled language

have been applied to with the IDEF0 modelling. The technique is further explained at the

paragraph on the ‘way of supporting’. This approach is an improvement. Traditionally

solution requirements gathering was more often based on craftsmanship than discipline,

because lacking the right concepts practitioners jumped from strategic objectives directly to

requirements without robust traceability.

Figure 5 Competence-Capability-Resource relations

At ‘resource level’ requirements can be attributed to one aspect of operations: an automated system,

an activity or a particular skill when it concerns people. Requirement analysis is guided by the

29
 Business architecture for successful transformations

hierarchy of business functions. A business function represents an atomic piece of added value and

provides a meaningful boundaries for parts of the business.

We have discussed how the external vision and strategic intent can be represented and

how these can be linked to the operational level. The next step is to understand how business

priorities are represented. The concepts as expressed in figure 3 have been proven effective

for giving direction to planning operations and prioritize requirements (Hendrickx, 1991).

The business canvas model (Osterwalder, 2010) is a more recent and widely embraced

version to prioritize and communicate how the operations should look like for accomplishing

the business vision. The business model canvas is a helpful means and accepted by a global

community for conveying short term priorities, and is quite similar to the list of concepts in

the controlled language. Priorities should be identified in at least these domains of a business

model canvas. Priorities in these areas reflect insights of top management of what can or

needs to be done in a short term and reflect what is in accordance with the strategic intent and

business vision. Once priorities have been assessed the holistic view is complete.

In this paragraph we have explained how the holistic view description looks like and

especially how the controlled relation between these domains can give rigor to enterprise

transformations.

Way of organizing

Business management drives the enterprise transformation. A key organizational task is to

assure that the right content is brought into the transformation process at the right time. The

most important deliverable is the external vision and strategic intent, because these become a

reference throughout the transformation cycle and sometimes guide other initiatives for

several years. Once a common reference of strategic intent has been agreed, it is the business

architect’s responsibility to assure that initiatives comply with that reference. Therefore

30
 Business architecture for successful transformations

leadership and communication skills are key ingredients of both the sponsor and the business

architect. Business architecture is most effective during or immediately after the change or

development of a new strategy. It creates the assets that can be re-used at business planning,

portfolio management or when large initiatives are started.

Way of supporting

Above it was argued that the IT domain is fragmented. And also that information is often not

needed at the time or place of creation. Hence communication needs special attention. How

does one assure that the right information arrives at the right moment at the right place? How

can one be assured that IT architects, engineers, developers and implementers can retrieve

that part of the landscape that they need? One prerequisite is that all have a common

reference. Furthermore it is assumed that a common vocabulary makes documents more

accessible for a diverse user group. A standardized architecture practice as the TOG

Architecture Framework is an example of a common vocabulary. It frames to a common way

of thinking, working and modelling for all stakeholders and is focused on creating cohesion

between strategic intent, architecture shape and implementation.

In addition two techniques in particular are useful when analysing business functions

and vertical / horizontal dependencies: the IDEF0 technique and matrix analysis of

dependencies. The IDEF0 is a relatively simple technique to analyse the controls of a

business function, capability or competence. IDEF0 is not a controlled language itself but a

technique that gives a modelling structure for the different controlled concepts of the business

architect. The other technique is the matrix analysis complemented with the Network

Dependence Diagram 3 (Tillquist et al., 2002). It enables the more detailed analysis of

3
A structured way to model at more detailed level how accomplishment of one task depends on the
tasks or activity of another one.

31
 Business architecture for successful transformations

interdependencies between business functions cross domain. With these simple techniques

both vertical and horizontal traceability can be assured. The controlled language, IDEF0, the

matrix analysis and the Dependency Network Diagram are essential parts of the business

architecture method for analysing and communicating the holistic view and the integrative

aspects of a business.

Above a formalized way is described for business architecture practice. However, the

way of modelling might vary by organization and adapting it to local practice may be needed.

It has already been argued in this article that specific skills do add value to business

architecture practices, but also these tools and techniques are part of the business architecture

methodology.

Part IV The Practice

Eight steps
In this paragraph the practice will be discussed step by step as well as the artefacts

that need to be prepared and connected. The business architect first assures that his role and

the concepts presented in the controlled language are well understood. The thinking behind it

is important, and the statements that the business architect produces should reflect that.

Secondly they do their homework. They ‘Assess needs’ and separate the demand side from

the supply side when aligning strategy and operations and business and IT. Either the

architect has already the experience or assets representing the knowledge of the enterprise, or

he needs to on-board and get up to speed. An effective way is screening annual reports and

investor / shareholder presentations at the annual shareholders meeting. For each controlled

language concept he has to find statements, capture these and formalize its description. As an

example the syntax for an external vision and business logic have been given already in this

article.

32
 Business architecture for successful transformations

Thirdly from the same sources he gathers information on the strategic intent, business

logic and contributing competences. The mission statement can be included as a piece of text.

The mission statement shows what market need is addressed with which services and

products, the business logic shows how the defined mission will be accomplished. Fourth to

link in a systemic way competence to capabilities an intermediate artefact is needed: the

business function hierarchy. This is a decomposition of the mission statement. It shows all

pieces of added value that must be produced to make the business work. It is agnostic, and

will usually not be further detailed than level 3 to demonstrate the structure of a business. The

business function decomposition is a well-established technique in the architecture practice

and can be applied at several levels. At industry level for instance the Telecom Management

Forum (TMF) has developed such a common reference for the communications industry. If

one takes the industry framework and applies the business strategy of a specific company, it

becomes a strong enabler to communicate the implications of a specific strategy to other

stakeholders in the company.

Fifth competences and business logic can be applied to this business function

hierarchy. This phase is the ‘Assess Requirements’ activity. Steps 5, 6 and 7 are included.

These impose the quality of the outcome of each business function. Once the quality has been

defined solution requirements can be derived. All business functions that are impacted by

specific competences can be clustered and show the boundary of capabilities. So far the

analysis has focused on a black box view, not considering how tasks are implemented.

Sixth the quality of resources can be identified based on the steps 2 to 5 and used for

the analysis of each business function’s operation. Now the white box view is adopted and

requirements of specific resource can be identified and informed by the holistic view. What

skills of people, what enabling tools, what specific managerial tasks are required, and what

technology is needed? Seventh at business function level alignment and integration can be

33
 Business architecture for successful transformations

accomplished since it enables to juxtapose the resources in business operations that contribute

to the business strategy. At this level also cross domain strategic fit requirements can be

visualized. This technique has been proven and is very powerful in conversations with

executive management as well as with designers and implementers.

Eighth the business architect should assure that he gets involved when new projects

are started or large programs are being shaped. Once he has a comprehensive holistic view of

the business he becomes the wholesaler of business needs and he has an explicit

understanding of cross domain strategic fit. The business architect can now contribute to the

business planning process, portfolio management process and large transformations by

showing how the business operates and what investment opportunities exist.

Cases

In the former paragraphs the elements of a proposed practice have been discussed, and it was

discovered that business architecture addresses key transformation challenges. Hence it is

proposed to apply the role of the business architect especially when mobilizing for enterprise

transformations. He should have the following tasks: capture the holistic view; initiate a

dialogue to discuss the connection between intent and architecture shape, set direction for the

transformation of operations, monitor that the right content supports decision-making, and

assure decision-making involves the right stakeholders. It is argued that his role is critical

during the idea shaping, viability and feasibility phase. What evidence can be shown that this

practice works?

It has been especially successful in multi-stakeholder situations and in regards to cross

organization topics. In 2003 at a chemical company in the Netherlands the way of working

enabled the management team to explicitly communicate the shared and aligned set of

strategic principles and key competences to a SAP implementation team, without losing sight

34
 Business architecture for successful transformations

caused by varying stakeholder interpretations. If this approach would not have been followed

the strategic intent would be communicated by each individual stakeholder without a

common reference, and would result in a less effective communication of strategic direction.

In 2011 at a high tech firm the controlled language was used to transform a well

elaborated business vision and strategy into a common reference of business needs for IT

stakeholders. The controlled language and way of modelling demonstrates: how to capture

effectively a holistic view, and how IT priorities can be derived from the holistic view. As a

result substantial improvement of the communication of business needs to the IT department

occurred and the common reference sparked the business IT dialogue turning the traditionally

re-active IT response into a more pro-active one.

In another case a global R&D organization of a pharmaceutical company benefited

from the controlled language in 2012 when developing a top down vision and strategy for

high performance computing (HPC). Due to the number of stakeholders, technical

complexity of the topic and its fragmented nature a bottom up approach got stuck and the

techniques and method to resolve this were not available. The proposed business architecture

approach has been applied, and the scattered potential use of HPC and its potential

contribution to the strategic ambition could be clarified and provided a foundation for further

decision-making. The following testimonial supports this: “…. it has given us a great

foundation for what we need to do next….”. Furthermore the formalized description conveys

the integrated and holistic view of more than 10 stakeholders which can now be easily shared

with not yet involved decision-makers.

In 2013 the controlled language has been applied to share and communicate the

business needs of an Integrated Production System enterprise wide transformation in the aero

manufacturing industry, lasting already for more than 5 years. The repository of assets

accumulated over the past six years is not very accessible and need much analysis to

35
 Business architecture for successful transformations

understand. The controlled language and business architecture practice simplify

communication of the vertical and horizontal cross domain dependencies between business

functions. This would accelerate decision-making and assure consistency during subsequent

phases over a long period. Without this controlled language initiatives got lost in details of

too many different areas and dependencies, and varying interpretations of needs, solution

requirements and benefits. Stakeholders of different domains will have difficulty to

understand each other and it will become difficult to make decisions if such a controlled

language is not adopted.

Above the business architect’s contribution to enterprise transformation has been

discussed and some exemplars have been given. Stakeholders were positive and the cases

have demonstrated that the transformation challenges were adequately addressed. Hence it is

fair to say that the practice has a high potential value to accelerate and improve effectiveness

of enterprise transformations.

Conclusive remarks

It seems fair to conclude that the techniques developed for communicating and aligning

strategy with operations have evolved over the last century into a new profession: the

business architecture profession with a consistent and mature methodology. It also seems fair

to conclude that this new profession can play a critical role in enterprise transformations,

since it addresses several enterprise transformation challenges. It is further argued that the

controlled language, especially of the holistic view, is a critical asset to resolve these

challenges. It creates traceability from external vision, to strategic intent and to investment

priorities and proceeds to identify implications for operations. The experience gained with

this approach has demonstrated that the conceptualized role of the business architect is not

only a critical role in enterprise transformation, but is also critical in business technology

36
 Business architecture for successful transformations

governance and business planning processes. It has also been confirmed that this role is not

yet institutionalized and that it differentiates itself from the business consultant and enterprise

architect role. Since the role is not yet recognized sufficiently there is room for improvement

in the practice for business IT alignment in many large and smaller organizations.

REFERENCES

Ackoff R.L. (1972) On Purposeful systems. Tavistock publications.

Business Architecture Guild (2012) Business Architecture Body of Knowledge Handbook.
Beijer, B. and Klerk T. de (2010) IT architecture, Essential Practice for IT Business
Solutions. Lulu.com;
Boynton A.C. and Zmud R.W. (1984) An assessment of Critical Success Factors, Sloan
Management Review (pre-1986); Summer 1984; 25, 4 ABI/INFORM Global pg 17
Capgemini, Large European Bank (2005) A client case of a multi-year approach to develop a
community for architecture practice.
Checkland, P. A.H. (1998) Information, Systems and Information Systems. John Wiley &
Sons
Coase, R. H. (1937) The nature of the Firm, Economica, New Series, Vol. 4, No. 16. pp. 386-
405.
Daniel R.D. (1961) Management information Crisis, Harvard Business Review, September-
October 1961, p 111
Davenport T.H., Hammer M, Metisto T.J. How executives can shape their company’s
information systems, Harvard Business review 67(2): 130-134.
Eveleens J. and Verhoef C. (2010) The Rise and Fall of the Chaos Report Figures, IEEE
Software, IEEE Computer Society 0740-7459/10/ vol. 27 (1)
Forrester J. (1971) Counterintuitive behavior of social systems. Technology Review, 73 (3):
52-68.
Frost & Sullivan (2010), In-depth study, conducted between May and July 2010 for HP. Frost
& Sullivan interviewed 30 top-level CSP executives from Europe, Asia-Pacific, India,
the U.S., Canada, Latin America, and the Middle East.
Gartner Burton B. and Allege P. (2011) Enterprise Architecture must include defining your
enterprise context, Report ID: G00209976, Research Report

37
 Business architecture for successful transformations

Gharajedaghi, J. (1999) Systems Thinking, Managing Chaos and complexity, A Platform for
Designing Business architecture. Butterworth Heinemann
R. Harishankar, K. Holley, R. High, et al (2009) Actionable Business Architecture, IBM
Corporation.
Henderson J., Venkatraman N. (1993), Strategic alignment. IBM Systems Journal, 32 (1)
Hendrickx, H.H.M.
(1991) Business strategy for 6 business units, internal BU reports, Philips Electronics NV,
Netherlands
(2004 and 2005) Business architecture module, 6 lectures in master post-doctoral course,
Architecture in a Digital World.
(2007) Governance in the practice of the CIO, PhD dissertation. University of Tilburg,
Netherlands
(2010) Nobel Prize Case – From controlled language to traceable requirements, presented at
The Open Group Conference, Amsterdam.
Et al (2011), The profession of the Business Architect, IEEE conference paper, Luxembourg
IBM Corporation (2010) CEO study 2010, IBM Institute for business value
IBM Corporation (2011) CIO study 2011, IBM Institute for business value
Kotnour T. (2011) An emerging theory of enterprise transformations, Journal of Enterprise
Transformation, 1:48-69, Taylor & Francis
Maes R. (1999) Reconsidering information management through a generic framework,
Primavera working paper, University of Amsterdam, Netherlands
http://primavera.fee.uva.nl/PDFdocs/99-15.pdf
McDavid D. (1999) A standard for Business Architecture Description, IBM Systems Journal,
VOL 38, NO 1.
NAF - Nederlands Architectuur Forum, State-of-the-art architecture 2012, editors Frank
Baldinger and Daan Rijsenbrij, 10 year NAF, LINE UP and media bv, Groningen,
Netherlands
G. Bayens, Bedrijfsarchitectuur in de praktijk
R. Wagter, D. Witte and L. van der Valk, Waarde van sturen op samenhang via recursiviteit
en projectie
OMG (2009) Defining Requirements for a Business Architecture Standard, Draft 5, 1 October
http://bawg.omg.org/Bus_Arch_Ecosystem_White_Paper_Draft.pdf

38
 Business architecture for successful transformations

Osterwalder A. and Pigneur Y. and Smith A. and 470 practitioners from 45 countries (2010)
Business Model Generation, Wiley published.
Porter M. E. (1996) What is Strategy?, Harvard Business Review, November-December
1996, 62-78 Society for Information Management (SIM) (), “IT Trend Survey”,
annual survey results.
Prahalad C.K., Hamel G. (1990) The Core Competence of the Corporation, Harvard Business
Review, May-June, p1-15.
Purchase V., Parry G., Valerdi R., Nightingale D. and Mills J. (2011), Enterprise
Transformation: why are we interested, what is it, and what are the challenges?,
Journal of Enterprise Transformation, 1:14-33, Taylor & Francis.
Sande W. van der and Sturm B. (2000) Information Architecture, De Infrastructurele
Benadering, Veenman Drukkers, Netherlands
Ross J. W. and Weill P. (2004) IT Governance: How Top Performers Manage IT Decision
Rights for Superior Results, Boston, MA, Harvard Business School Publishing,
Boston Massachusetts, USA
Seligmann P.S., Wijers G.M. and Sol H.G. (1989) Analyzing the structure of I.S.
methodologies, Delft University of Technology, Netherlands
Simon H. A. (1961) Administrative Behavior, New York: The Macmillan Company, second
edition.
Standish Group International, (1994) Chaos, technical report.
Sterman J.D. (2000) Systems Thinking and Modelling for a complex world
The Open Group (2011) The Open Business Working Group consists of thought leaders from
Capgemini, Ernst & Young, HP, IBM, Kingdee and SAP.
The Open Group (2009-2011) Open Group Standard, TOGAF Version 9.1, Document
Number: G116, Published in the US by The Open Group, 2011.
The Open Group, Open Group Standard, ArchiMate ® 2.0 Specification, 2009-2012,
Document C118, Published by The Open Group
Tillquist J., King J.L. and Woo C. (2002), A Representational Scheme for Analyzing
Information Technology and Organizational Dependency, MIS Quarterly, Vol 26 No.
2, p 91-118/June
Venkatraman N. and McGrath D. J. (2008) Business-IT Alignment in a Network-Era:
opportunities & challenges, EIS Conference @ Tilburg, May 22.

39
 Business architecture for successful transformations

Versteeg, G., & Bouwman, H. (2006) Business architecture: A new paradigm to relate
business strategy to ICT. Information Systems Frontiers, 8(2), 91-102. doi:
10.1007/s10796-006-7973-z
Wolfenden, P. J., & Welch, D. E. (2000). Business architecture: A holistic approach to
defining the organization necessary to deliver a strategy. Knowledge and Process
Management, 7(2), 97-106.
Wout J. van‘t, Waage M., Hartman, H., Stahlecker, M. and Hofman, A. (2010) The
Integrated Architecture Framework explained, Why, What, How, Capgemini/Springer
Heidelberg.

40

View publication stats