Enterprise Architecture: What Discipline is that?

orge Cordeiro Duarte and Mamede Lima-Marques

Centre for Research on Architecture of Information, University of Brasilia

Campus, Brazilia, Brazil

Abstract. This paper analyzes Enterprise Architecture (EA) as a discipline of

study. Current EA foundations, theories and practices are discussed using an epis-

temological framework. Strengths and weaknesses of current approaches are dis-

cussed. Immaturity of EA as a discipline and practice Is identiﬁed. The main

causes of immaturity are analyzed. A research agenda is proposed to provide ma-

turity in EA foundations, theories and practice.

1 Introduction

noindentCurrent enterprise environmentis characterizedby complexity.There are many

elements to control and change is constant. Enterprise Architecture (EA) is considered

an instrument to help organizations to act effectively in this scenario by providing a

blueprint of organizational elements and their relationships. The big picture provided

by EA helps decision-making and change management.

Enterprise architecture is a promise for organizations efﬁciency, but it is still a con-

fusing concept [28]. Since its beginning, many heterogeneous EA proposals have been

developed. The approaches often overlap theories and practices with other enterprise

disciplines. Proposals are often complex and their beneﬁts cannot be perceivedby users,

creating obstacles for its correct understanding, affecting its acceptance and use. The

lack of a generally agreed terminology in this domain is also a bottleneck for its efﬁ-

cient application. This is the Reason why kappelman [14] considers EA at its beginning

despite the concept be known for at least 25 years.

The aim of this paper is to analyze the state of the art of EA as a discipline, iden-

tifying and evaluating its foundations, theories and practice. It also proposes a theoret-

ical framework and a research agenda to clarify EA foundations, concepts, scope and

practice. Section 2 presents the main deﬁnitions, concepts and approaches found in the

literature. Section 3 proposes a epistemological framework to assess EA as a discipline

of study. Section 4 details the main theoretical approaches. Section 5 analyzes the in-

tersection of EA with other disciplines. Issues of clarity in the boundaries of the EA as

a discipline are discussed in session 6. A research Conclusions and agenda to EA are

presented in Section 7.

Cordeiro Duarte J. and Lima-Marques M. (2010).

CEnterprise Architecture: What Discipline is that?.

In Proceedings of the International Joint Workshop on Technologies for Context-Aware Business Process Management, Advanced Enterprise

Architecture and Repositories and Recent Trends in SOA Based Information Systems, pages 7-15

DOI: 10.5220/0003025400070015

 SciTePress

2 A Framework to Assess EA as a Discipline

In order to assess EA as a discipline we use a framework, proposed by [8], shown in

ﬁgure 1. This framework comprises three levels of inquiry in a discipline: epistemology,

science and practice.

Fig.1. Hierarchy of Inquiry Systems with their Respective Inputs and Outputs [8].

Epistemology, according to [8] is that portion of the philosophy of science that

enquires into the sources of knowledge of a scientiﬁc discipline. The outputs of epis-

temological level are science paradigms. According to Thomas Kuhn [16], a paradigm

represents the way problems are conceptualized. It is made up of commitments shared

by a scientiﬁc community, to accept certain theories, methods and models. A paradigm

reﬂects the values by which the scientists judge how to conﬁgure or to deﬁne a problem

as well as their attitude towards any likely answer(s) or solution(s).

The second part of the model is science. Science is a body of knowledge about a

particular object, obtained with certain criteria in a methodical and systematic body

logically constructed. It is also considered as a set of methods and procedures used to

elucidate issues of reality [29]. Science outputs are theories and models.

The last part of the model, practice, applies theories and models to solve speciﬁc

real word problems.

3 ENTERPRISE ARCHITECTURE PARADIGMS

This section presents an review of main epistemological approaches and makes an as-

sessment of EA foundations.

3.1 Epistemological Apprroaches

According to Hirschheim [11], there are several philosophical approaches that help es-

tablish the paradigms of knowledge of a discipline. The main difference between them

is how knowledge is obtained: By reasoning, by experience and by mutual inﬂuence

between reasoning and experience.

The Rationalist Paradigm. The rationalism is a epistemological approach which ar-

gues that knowledge is formed by reasoning, so it is mental. Based on Descartes, [4],

this epistemological theory see elements of the world functioning as a clock. Once man

interact with the world, he can module the reality in a scientiﬁc method and everything

will work as drawn in the module.

The Empirical Paradigm. A second approach, empirical, claims that knowledge only

happens in experience. The mind can construct models but only the interaction with the

world will give the true knowledge. This is the materialist approach of Locke [18] and

Hume [12].

The Phenomenological Paradigm. A third approach says that knowledge is a phe-

nomenon that occurs in the interaction between mind and experience. The Phenomenol-

ogy approach, created by Husserl [13] and contributions of Heidegger [10], Gadamer

[7] and others analyzes the essence of the phenomenon in a humanist perspective. The

word inﬂuences the world and man also designs the world, and perceptions and designes

are made in collaboration with others.

3.2 Assessing EA Paradigms

We did not ﬁnd a research speciﬁcally about EA epistemology, but is it possible ti

identify some paradigms analyzing EA approaches. EA approaches, detailed in next

sections, have focus in organizational domain modeling, providing mainly technical

aspects os models. Current EA approaches see the world, its elements and relations

and assume that everything will work as a clock. Approaches also consider that we

have many visions of the same subject, depending on the perspective of the user. But

these models and visions are not updated dynamically. Once developed and approved

they are considered as a truth for everyone. No approach considers that in a dynamic

situation changes may occur everyday in the interaction of man with te reality. So we

can consider that current approaches use a rationalist perspective. Once modeled and

approved models predominate over reality.

We conclude, analyzing EA features, that the rationalist perspective is insufﬁcient

as paradigm to the discipline. The humanist approach of phenomenology, in our opin-

ion is more suitable as a foundation for EA and so approaches must consider human

interaction with the architecture. In other words, models must be accessible to everyone

and approaches must give conditions for update information in dynamic and custom

bases.

4 Enterprise Architecture Science

This section presents a review of the literature and makes an assessment of EA theories.

4.1 Enterprise Architecture Deﬁnitions

There are many deﬁnitions for EA. The name of discipline, itself, may vary, being re-

ferred to as Enterprise Architecture (EA) [31] or Enterprise Information Architecture

(EIA) [3]. Examples of EA deﬁnitions found in literature: An abstraction of the main

elements of the organization and their relationships [26]; Deﬁne the various elements

that make up an organization and how they relate and establish the principles and guide-

lines governing their design and evolution over time [20]; A coherent set of principles,

methods and models used in the design and construction of the structure, processes,

systems and infrastructure of an organization [17]; Blueprints which deﬁne a complete

and systematic position of the current and desired organizational environment [24]; A

description of a complex system (the enterprise) at a point in time [2]; The structure

of components, their relationships, and the principles and guidelines governing their

design and evolution over time [5]

4.2 Enterprise Architecture Objectives

Some examples of EA objectives found in the literature: EA intends to model, analyze

and communicate the organization. The beneﬁts of EA are the knowledge infrastruc-

ture for reporting and analysis by all stakeholders and the possibility of designing new

conditions in an organized manner [17]. EA is not only an instrument for strategic plan-

ning of IS/IT planning but also other business functions, such as compliance control,

continuity planning and risk management [30]. The objectives of the EA are risk and

compliance control, project and organizational programs management, portfolios of IT

management and integration between business and IT [24]. According to [21] an EA,

as a whole, is used in a number of different ways to guide, direct, and manage an enter-

prise: Is a basis for decision making and planning; Governs the identiﬁcation, selection

and development of standards; is the mechanism for managing change within the enter-

prise; Enables effective communication about the enterprise.

4.3 Enterprise Architecture Users

According to John Wu

, Enterprise Architecture is for every one. The senior manage-

ment need EA to support decision making on capital investment, The project manager

need EA to reuse common resources. The security engineers need EA to know what to

secure about. Service Oriented Architecture depends on EA to select the proper service.

A important factor for EA utilization is the capability to access the EA artifact in time

for need.

4.4 Enterprise Architecture Approaches

Since middle of the 1980s several proposals for EA appear. The diverse proposals have

different approaches aiming different objectives. Table 1 shows a classiﬁcation of pro-

posals in ﬁve approaches: Strategic EA, enterprise modeling, enterprise modeling meth-

ods and standards, enterprise architecture language and Information Architecture.

http://it.toolbox.com/blogs/lea-blog/enterprise-architecture-disciplines-15651

Table 1. Evolution of Technology and System Applications.

Approach Objective Proposal

Strategic EA Blueprints showing enterprise and

technical infrastructure

[23]

Enterprise Modeling Framework of organizational models [31]

Enterprise modeling methods

and standards

Framework, methods and standards

for organizational models

[20, 5]

Enterprise architecture language Framework and language to model

architectural models

[17]

Enterprise Information Architec-

ture Approach

Infrastructure for modeling the enter-

prise information

[19]

4.5 Assessing EA Theories

EA deﬁnitions are comprehensive and clear, considering the architecture as covering

all organizational domains. Its goals are also clear because they consider architecture as

capable of enabling organizational knowledge and manage change. The problem in the

theories of EA is in the methods proposed to achieve its objetives. Available approaches

vary in detailing architecture levels. There is no consensus on the best strategy. EA

must model only strategies? must models all elements? who makes the models? Current

approaches do not make clear the boundaries of architecture modeling in relation to

other areas of enterprise modeling, such as processes and applications. So is not clear

yet what subjects are exclusive to EA discipline.

5 Enterprise Architecture Practice

This section presents a review of the literature about EA practice, and makes an assess-

ment of tools, organizational structures and strategies.

5.1 Enterprise Architecture Tools

Schekkerman (2009) publishes an extensive annual survey of the various EA tools in

the market. It is important to note that following Zachman proposal, the architecture

can consist of models from various domains which can lead to the conclusion that any

modeling tool can be considered as a tool for EA. This is the focus of Schekkerman

analyzes. The study shows most of the tools meet only part of architecture domains

and no tool is specialized in EA, They provide resources to make many other things

such systems or processes modeling. There also other reviews of EA market analyzing

Strengths and Weakness of theirs resources [6]. Research institutes, such as Gartner

and Forrester, also publish annual reports assessing the tools to EA. Both consider that

only six or seven companies meet the requirements for an EA tool. These requirements

are: resources to model the various domains, speciﬁc resources to model architecture

and identify relations between models, support for the main frameworks, resources for

managing projects, resources for publishing on the Web, collaboration resources and a

repository for storing and retrieving models. The main companies that offer tools with

these requirements are: IBM (System Architect and Rational)

, IDS Scheer (ARIS

tools)

, Metastorm

, Troux Technologies

and Alphabet

5.2 Enterprise Architeture Strategies

Many EA programs do not succeed because they are not well implemented. It is recom-

mended to implement an EA program in ﬁve steps: Initiate the effort; Describe where

we are; Identify where we would like to be ;Plan how to get there; Implement the archi-

tecture [1].

Initiate the Effort. Develop an architecture framework;Create readiness for architec-

ture Build the architecture team; Identify and inﬂuence stakeholders; Encourage open

participation and involvement; Reveal discrepancies between current and desired state.

Describe where we are. Characterize the baseline architecture; Make it clear to every-

one why change is needed.

Identify where we would Like to Be. Develop the target architecture; Communicate

valued features; Energize commitment; Create a plan for transition activities

Plan how to Get there. Develop the transition plan; Execute the target architecture

Communicate the transition plan; Establish sound management structure; Build support

for the architect.

Implement the Architecture. Maintain/enhance the target architecture; Develop new

competencies and skills; Reinforce architectural practices

5.3 Organizational Structures for Enterprise Architeture

To reach its goals EA must have an organizational structure with a group responsible

for it [9]. [22] proposes a structure with an EA board and an EA operational manage-

ment team. This team must have a central staff and also specialists distributed in local

departments that contributes to EA contents. The central staff does not generate content.

The central staff must implement and manage an infrastructure to EA and identify and

publish EA policies and guidelines. As Rosenfeld states, EA is a mix of users, context

and context [22]. EA community is composed by users and content generators that are

also users. Each user needs a speciﬁc vision of architectural elements. Each content

contributor deals with a speciﬁc content level. It is a function of EA staff to know who

does content and who needs information. The enterprise Architect is the main profes-

sional for EA. Given the interdisciplinary nature of EA, the enterprise Architect must

have a general knowledge of various discipline [25]. These discipline, among others,

are business strategy, ﬁnancial management, organizational dynamics, business process

design, and information technology.

http://www-01.ibm.com/software/rational/

http://www.ids-scheer.com/index.html

http://www.metastorm.com/

http://www.troux.com/

http://www.alfabet.com/

5.4 Assessing EA Practice

Current Research on EA practice does not present a positive situation. A survey pub-

lished by Gartner [2] identiﬁes that only 25% of EA initiatives can be considered active

and mature. 50% of them take 2 steps forward and 1 step back and 25% have failed

repeatedly. An investigation of perception and practice of EA found that IT profes-

sionals still do not perceive EA as an organizational effort, but an IT initiative which

indicates that EA is not properly implemented [15]. The same survey shows that the

identiﬁcation of requirements is still a great challenge in information systems develop-

ment which shows the necessity of change in systems development processes. Another

study identiﬁed that only 6% of organizations have an appropriate degree of maturity in

the modularization of its information systems [23]. The literature is plentiful in percep-

tions that EA, though admittedly to be an important tool, it is not a standard practice in

organizations, mainly considering medium and small ones [27].

6 Assessing EA as a Discipline

The enterprise architecture discipline touches the same subjects as business process

management, information systems and other enterprise disciplines, but from a differ-

ent perspective and in a distinctly different context. The EA context is holistic and its

perspective is organizational, while the other disciplines are implementation-speciﬁc.

The enterprise architecture discipline is more than a superset of engineering do-

mains. While the subjects of enterprise domains are meant to be applied to the solution

implementation, the EA subjects are largely used for enterprise analysis, planning, and

architecture governance.

EA is among enterprise disciplines already consolidated. What speciﬁc knowledge

we need to enterprise analysis, planning, and architecture governance? When does en-

gineering end and architecture begins? Who models the speciﬁc vision of architecture?

How to integrate Models? How to ﬁnd a speciﬁc model for a speciﬁc need? How to get

collaboration of other domains to construct a dynamic architecture? How to reach EA

audience? How can be the enterprise architect profession deﬁned? How can he be edu-

cated? how to collaborate with who needs to know the architecture in a timely fashion?

Approaches such as Zachman lists a number models that are related to other or-

ganizational domains and suggests no method to elaborate the models. So it does not

indicate speciﬁc theories for a EA discipline. TOGAF suggests speciﬁc methods but

it has a rationalist view, not considering human aspects. The same happens with the

proposal of Archimate. Without considering the human aspects of architectural models

and collaboration aspects in developing then the approaches are incomplete with less

chance of succeed.

Current EA tools are not speciﬁc to EA. They are IT or BPM approaches with some

resources to EA. EA needs models from IT and from processes and it sounds logical

to evolve them to EA. But these tools do not help to identify the frontiers between

domains, so it is not clear to managers and professional who does what. Tools are also

rationalist oriented without resources for collaboration. Organization changes everyday

and resources to update elements and relation in a collaborative environment is needed.

Education is another big problem to EA. It is hard to ﬁnd speciﬁc formal education

to EA. No even a mere discipline in IS, IT or Processes courses can be found. This is,

perhaps, the most striking sign of immaturity of EA as a discipline. We do not have a

deﬁned body of knowledge in formal education. IT is not easy to ﬁnd in the literature

proposals of a curriculum for the discipline of EA.

Concepts found in literature are clear to deﬁne the speciﬁc object of EA: Organi-

zational elements and their relations. The objectives also sound clear: To provide orga-

nization knowledge and help in planing and change management. The problem here is

with current approaches. They have three kind of problems: they do not help to estab-

lish a frontier with other disciplines, they do not provide a body of speciﬁc methods for

the discipline and they do not consider human collaboration aspects. That is the reason

why many organizations fail in the implementation of the EA and others not even try.

7 Conclusions and Research Agenda

This paper presented a review of current literature on concepts and approaches to EA,

contributing to a better understanding of the state of the art and the challenges of this

ﬁeld of research and practice. It assessed EA as a discipline using a framework with

epistemological, theoretical and practical levels. Looking at EA foundations, theories

and practice it is easy to see that, even though EA is seen with optimism on a medium

and long run, the current reality is not good. Most of the professionals who could be

using the existing proposals consider approaches still confusing and complex and tools

much expensive. It is not clear for systems analysts the boundary between modeling a

system and modeling an application architecture. It is not clear for business analyst the

difference between a process model and an a business architecture model. It is not clear

to both professionals who should make engineering models and architecture ones.

If EA boundaries are not clear to professionals, they are not clear to executives ei-

ther. So, EA initiatives are not properly structured. A poorly structured EA initiative is

a sure failure. EA is certainly a complex initiative considering the existing approaches.

The expectation is that over time it becomes mature to be implemented in a less com-

plex manner. For this to happen it is necessary, above all, better approaches and more

specialized and affordable tools.

A new agenda of EA research as a discipline is needed. Research must clarify EA

boundaries, and provide unique foundations and theories. EA methods and tools must

change of paradigm. The rational paradigm is not sufﬁcient to orient theory and practice

of EA. Research is needed to bring human perspective to EA. Research is needed to

provide speciﬁc tools for EA considering the collaborative paradigm. Research is also

needed to set formal education to enterprise architects.

References

1. Boster, M., Liu, S., and Thomas, R. (2000). Getting the most from your enterprise architec-

ture. IT Professional, 2(4):43–1.

2. Burke, B. (2006). Enterprise architecture: New challenges - new approaches. Report, Gartner

Group, New York.

3. Cook, M. (1996). Building Enterprise Information Architectures: Reengineering Informa-

tion Systems. Prentice Hall, New York.

4. Descartes, R. (1994). Discourse on Method. Everyman.

5. DoD (2007). Dod architecture framework version 1.5. Technical report, Washington DC.

6. Ernst, A. M., Lankes, J., Schweda, C. M., and Wittenburg, A. (2006). Tool support for

enterprise architecture management - strengths and weaknesses. In EDOC ’06: Proceedings

of the 10th IEEE International Enterprise Distributed Object Computing Conference, pages

13–22, Washington, DC, USA. IEEE Computer Society.

7. Gadamer, H.-G. (2005). Truth and Method. Continuum, New York.

8. Gigch, J. P. V. and Pipino, L. L. (1986). In search for a paradigm for the discipline of

information systems. Future Computing Systems, 1(1):71–97.

9. Harmon, P. (2003). Developing an enterprise architecture. Technical report,

www.Bptrends.com.

10. Heidegger, M. (2008). Being and Time. Harper Perennial Modern Classics, San Francisco.

11. Hirschheim, R. (1985). Information systems epistemology: an historical perspective, pages

13–35. North-Holland Publishers, Amsterdam.

12. Hume, D. (1962). On human nature and the understanding. Macmillan, New York.

13. Husserl, E. (2001). Logical Investigations. Routledge, London.

14. Kappelman, L. A. (2007). Enterprise architecture not just another management fad. Align

journal.

15. Kappelman, L. A. and Salmans, B. (2007). Information management practices survey 2007

preliminary report: The state of ea: Progress, not perfection.

16. Kuhn, T. S. (1996). The Structure of Scientiﬁc Revolutions. University Of Chicago Press,

Chicago, 3 edition.

17. Lankhorst, M. (2005). Enterprise architecture at work - Modelling, communication and

analysis. Springer-Verlag, Heilderberg.

18. Locke, J. (1994). An Essay Concerning Human Understanding. Prometheus Books, London.

19. Morville, P. and Rosenfeld, L. (2006). Information Architecture fot the Word Wide Web.

OReilly, Sebastopol.

20. open Group, T. (2009). Togaf - version 9 enterprise edition. Technical report, San Francisco.

21. Rood, M. (1994). Enterprise architecture: deﬁnition, content, and utility. In Third Workshop

on Enabling Technologies: Infrastructure for Collaborative Enterprises, pages 106–111, New

york. IEEE.

22. Rosenfeld, L. (2007). Enterprise information architecture: Because users do not care about

your org chart.

23. Ross, J. W., Weill, P., and Robertson, D. (2006). Enterprise Architecture As Strategy: Cre-

ating a Foundation for Business Execution. Harvard Business School Press, Boston.

24. Schekkerman, J. (2009). Enterprise architecture tool selection guide. Technical report.

25. Strano, C. and Rehmani, Q. (2007). The role of the enterprise architect. Information Systems

and E-Business Management, 5(4):379–396.

26. Vernadat, F. (1996). Enterprise Modeling and Integration: Principles and Applications.

Springer, New york.

27. Vernadat, F. (2007). Interoperable enterprise systems: Principles, concepts, and methods.

Annual Reviews in Control, 31(1):137–145.

28. Vernadat, F. B. (2002). Enterprise modeling and integration (emi): Current status and re-

search perspectives. Annual Reviews in Control, 26(1):15–25.

29. Vita, L. W. (1965). Introducao a ﬁlosoﬁa. Editora Atlas, So Paulo, 2 edition.

30. Winter, R. and Schelp, J. (2008). Enterprise architecture governance: the need for a business-

to-it approach. In Proceedings of the ACM symposium on Applied computing, pages 548–

552, New York, NY, USA. ACM.

31. Zachman, J. (1987). A framework for information systems architecture. IBM Systems

Journal, 26(3).