Upload
armando-cabrera-silva
View
107
Download
2
Embed Size (px)
Citation preview
Roadmap for the implementation of an Enterprise Architecture Framework Oriented to
Institutions of Higher Education in Ecuador
José Carrillo
Departamento de Lenguajes y Sistemas Informáticos e
Ingeniería del Software
Universidad Politécnica de Madrid
Madrid – España
Armando Cabrera, Carlos Román, Marco Abad, Danilo
Jaramillo
UPSI - Investigaciones tecnológicas
Universidad Técnica Particular de Loja
Loja – Ecuador
{aacabrera, caroman, mpabad, djaramillo} @utpl.edu.ec
Abstract -- in the present article, we propose the adoption of a
roadmap for the implementation of a enterprise architecture
strategy in the institutions of higher education of Ecuador with
the purpose of favoring the Information Management Systems
and the best utilization of the IT resources (to improve the
quality of the services, to rationalize the technical
administration and to finance the assets of IT, and to improve
the management of the resources and project portfolios),
promoting the application of an assembly of standards and
guides for establishment, making clear that the roadmap
proposed is a bet for the future and not a striaghtjacket,
therefore the permanent evolution of the technology and the
needs of the business are duly recognized.
Keywords: Higher education, enterprise architecture, framework,
IT governance.
I. INTRODUCTION
The administration and management of the technologies
of information and communication play an important role in
the organizational structure of the institutions of higher
education. Handling the technological infrastructure,
services and resources in line and data, have become some
of the main concerns that the leaders of IT should take into
consideration in order to satisfy each one of the institutional
functions (teaching, investigation and extension1) and with
this to respond to the regulatory changes2, changes of the
external environment, the growing competence,
globalization and the changing expectations of the company.
The comprehension of the interrelations among the
people, the processes of business, applications, data, and
underlying technologies will be fundamental to achieve this
synergy among all parts of the organization. The
development of a Enterprise Architecture (EA) will become
1 Consejo Nacional de Educación Superior (CONESUP), De la
Constitucion, Fines y Objetivos del Sistema Nacional de Educacion
Superior. Base legal Art. 3. Disponible en http://www.conesup.net/capitulo1.php 2 Consejo Nacional de Educación Superior (CONESUP), Ley Orgánica de
Educación Superior. Disponible en http://www.conesup.net/descargas/PROYECTO_LOES.pdf
fundamental in handling these interrelations, and it is for
this that we intend to develop a framework of EA that would
permit itself to include an architectural framework that
could integrate the institutional vision with that of the TI.
From this motivation, it will intially be necessary to
establish a roadmap that will tell how to come and
consolidate the framework of EA like a final product.
Though it can be affirmed that every organization counts on
an informal/empirical EA plan, the adoption of a formal
model is necessary in order to bring us an establishment of
effective IT Governance.
In this context, what purpose does architecture serve if is
not possible for it to to manage itself? The solution is to
adapt the EA (of the institutions of higher education) to the
context of the IT Governance. One cannot achieve effective
IT Governance without the presence of a structured EA
model, and viceversa, the EA can not be concolidated
without an effective and clear strategy from IT (See figure
2). Thus, the architecture once established will serve us in
knowing how the details will be handled throughout all the
structures of the business of the organization (or I segment
architectural), but in making use of the IT Governance, we
will be able to adequately negotiate the EA. In figure 1, this
relation of dependence is illustrated.
Figure 1: Dependency between the EA and IT Governance [2]
Like many other disciplines, the EA much like the IT
Governance are found governed by standards, and full of
formal methodologies. The objective of the establishment
of a framework for the EA in the context of the institutions
of higher education of Ecuador, is to eventually make better
use of the fortresses of methodologies and the benefits lent
by such standards. For this, it will become an analysis of
five frameworks of the EA (Zachman3, FEAF
4, TOGAF
5,
Gartner6, and E2AF), and in the future, it can be
implemented as a framework oriented for the IT
Governance, governed by the standard one ISO 385007
through the "Framework of IT Governance of Calder
Moir8". As for the standards, they should be undertaken
explicitly oriented for this discipline, given chiefly by ISO,
IEEE, IFEAD, The Open Group, CEN, NIST and BPMI,
among others.
II. DEFINING ENTERPRISE ARCHITECTURE,
PURPOSE AND BENEFITS
A. Definition and history
In the beginning it is necessary to make clear the context
of the constituent terms of "Enterprise Architecture,"
therefore upon thinking about business, in innumerable
occasions associates of the discipline of the EA have created
themes related to business management, and as we will see,
this is quite far away from what it really is.
The standard ISO/IEC 42010: 2007 tell us:
“Conceptually an IT architecture is the fundamental
organization of a system, embodied in its components, their
relationships to each other and the environment, and the
principles governing its design and evolution.” [1]
On the other hand, TOGAF [1] proposes a concept of
business undertaking as: "Any collection of organizations
that have a common assembly of goals and/or a simple final
result". The term ―business,‖ in the context of Enterprise
Architecture, can be used to denote both: an entire business
(covering the totality of its Systems of Information) and a
specific control within that business. In both cases, the
architecture crosses multiple systems and functional groups
inside the business.
With the proposed explanation, the concept of EA turns
out to be very simple, a concise definition. Klaus Niemann
[2] states that "The term enterprise architecture refers to a
structured, harmonized and dynamic collection of plans for
the development of an enterprise’s IT landscape.”
3 Zachman Institute for Framework Architecture. . Available in: :
http://www.zifa.com/ 4 Federal Enterprise Architecture Framework. Available in:
http://www.cio.gov/Documents/fedarch1.pdf 5 The Open Group Architectural Framework. Available in official web site:
http://www.opengroup.org/togaf/ 6 Gartner Technology Business. Available in: http://www.gartner.com/
7 ISO 38500 IT Governance Standard. Available in: http://www.38500.org 8 Calder Moir Framework. Available in: http://www.
itgovernance.co.uk/calder_moir.aspx
But this discipline has not been a product of coincidence
nor of rapid development, but has instead involved a slow
but steady process that dates back more than two decades
when John Zachman published an article in 1987 called, "A
framework for the Information Systems Architecture." [3] In
this article, Zachman established the challenge and the
vision of enterprise architectures that would orient the field
for the next 20 years. The challenge consisted of
negotiating the complexity, greater with each year, of the
distributed systems considering that:
"The cost involved and the success of the business
depending increasingly on its information systems require a
disciplined approach to the management of those systems."
[3]
The vision of Zachman was that the value of business
and the agility of the business could be better carried out by
a holistic focus of the architecture of the systems. Such
focus came to be known as, "Framework of Enterprise
Architecture."
The influence of Zachman was such that it overturned
the government of the United States through its Department
of Defense, to create the "Framework of Technical
Architecture for the Management of the Information"
(TAFIM) 9
introduced in 1994. TAFIM and other
methodologies were observed by the Congress of the United
States and as a consequence, they were approved by Law Clinger-
Cohen in 1996, also known as the "Minutes of law for management
of information technology." This established that all the federal
agencies should take measures to improve the efficacy of their
investments in IT [4]. The Counsel10
of CIOs11
, formed by CIOs
of all the most important governmental organizations of the United
States, was created to supervise this effort.
In April of 1998, the counsel of CIOs began to work in its
greater project, the "Framework of Federal Enterprise architecture"
(FEAF). The version 1.1 [5] of this Framework was discarded in
September of 1999.
After several years, the responsibility of the Federal
Enterprise architecture passed from the counsel of CIOs to
the office of Management and Budget (OBM) 12
. In the year
2002, the OBM evolved and changed the methodology of
the FEAF leaving it as Federal Enterprise architecture (FEA,
by its acronyms in English) [5].
In 1998, the four years after the apparition of the
TAFIM, this method was officially withdrawn by the
9 Technical Architecture Framework for Information Management. Available in: http://citeseerx.ist.
psu.edu/viewdoc/summary?doi=10.1.1.25.1473 10
Chief information Officers Council. Available in: oficial: http://www.
cio.gov/ 11 Chief Information Officer 12 Office of Management and Budget. Available in: www.whitehouse.gov/omb/
department of defense. The work carried out by this
methodology was delivered to "The Open Group" that
transformed it into a new standard that is known today as
"The Architectural Framework of The Open Group",
(TOGAF).
During 2005, almost at the same time in which OBM
was becoming the dominant force in the public sector,
another organization (Gartner) adopted measures to become
a dominant force in the private sector. In that year, Gartner
had already become one of the most influential
organizations specialized in consultancy at the level of
CIOs, the specific area of EA -the group of advice and
investigation of IT- was not Gartner, but Meta Group13
, who
was absorbed completely by Gartner.
Due to the undeniable benefits of the EA they have
developed some frameworks as TAFIM, FEAF, TOGAF,
DoDAF14
, MODAF15
, PEAF16
, MAGENTA17
, AGATE18
,
CIMOSA19
, among others which have adopted certain
standard model methods used in defining the critical
elements of architecture and the dependences among them.
The Corporation MITRE shows in its publication EABOK
[5] a significant analysis on the greater historical
developments of the EA (Methodologies) in which it
undertakes the majority of the frameworks mentioned and
more.
B. Dimensions to Consider
An architectural approach covers the key areas of the
organizational life, including the personnel and their
controls of work that conform the organization. There are
various focuses in the structuring of the control of the EA,
these are essentially distinguished in terms of the number of
architectural levels that they cover, the demarcation of those
levels and their granuality.
13 META Group. Available in : http://www.meta-group.com/aboutus.html 14 Department of Defense Architecture Framework. Governmental use.
Developed by DoD - EE UU. Available in: http://cio-nii.defense.gov/sites/dodaf20/ archives.html 15 Ministry of Defense Architectural Framework. Governmental use.
Developed by MoD. Available in: http://www.mod.uk/ DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MO
DAF/ 16
Pragmatic Enterprise Architecture Framework. Available in official web
site: http://www.pragmaticea.com/ 17
Governmental Framework, develop in Singapur. Available in:
http://www.ida.gov.sg/Programmes/20060419144239.aspx?getPagetype=34 18
Atelier de Gestion de l'ArchiTEcture des systèmes d'information et de
communication. Available in: : http://www.ixarm.com/AGATE -framework 19
Computer Integrated Manufacturing Open System Architecture.
Available in official web site: http://cimosa.
cnt.pl/Docs/Primer/primer1.htm
Some representations include more levels or sublevels.
These models are mentioned and utilized by diverse
methodologies and they cover aspects of security,
information, data and integration of the architecture. The
additional components mentioned can be appropriatley
assigned to the basic model shown in the pyramid of Figure
2. Nevertheless, the experience has shown that the models
of the EA complex tend to generate volumes of data that are
difficult to handle, harder still when the architecture is used
for the purposes of analysis and planning. "Although the
complex models can be exact, in practical terms they turn
out to be useless." [2]
Each area of analysis that will be involved in the
construction of the framework for institutions of higher
education, can be respected like a discipline of seperated
strategy (EA segmented), since it is focused on the
personnel and their different levels and areas of training
(personal academic, students, employed and industrious20
).
Often each group has its own tools, methods, rules,
principles and politics, etc., as well as different media to
communicate and to share information on each area. So,
each should have its "own form" of architecture, that is to
say, a particularization in proportion to the global EA that
specifies its forms of "carrying things out."
Figure 2: Base Dimensions of an EA [2]
The important fact to consider about the EA as a
fundamental axis inside the organization is supported in the
capacity of this discipline to act like an element of cohesion
among the layers of figure 2. They should meet the
particularities mentioned in the framework, offering thus a
balance between the vision of the business and the strategy
of IT in the institutions of higher education.
20 Consejo Nacional de Educación Superior (CONESUP), Forman parte del
Sistema Nacional de Educación Superior Ecuatoriano, Base Legal Capitulo 8, 9 y10. Disponible en http://www.conesup.net/
C. Purpose
An EA will help to create transparency, serving as a base
for the delivery of information to the government of the
universities21
. This information will be essential for in
making decisions and the establishment of an adequate
control. Besides this, it will create a solid skeleton to apply
the needed of IT Governance. As far as the adequate
consolidation of a strategy for IT under management given
by the government, the EA will be handled as a fundamental
axis in association with the management of requirements
and portfolios, as well as with the management of operations
and services. See figure 3.
Figure 3: Environment of an EA [2]
D. Architectural life cycle
A generic life cycle is illustrated in figure 4, sampling
the general (basic) steps that often take place in the
development of an EA. Each methodology has different or
equal phases. Among, the most important phases, we can
emphasize, for example, ADM [6] of TOGAF and FEA,
which utilize a cyclic model based on eleven phases. With
the periodic execution of a medium time limit of the cycle
shown in figure 4, a process of integral management can be
established.
The governing that should apply is integral, the
governing of the architecture should be supported by the IT
Governance, both which will be operated on multiple levels.
"The areas that desire to establish or to improve their levels
of government will be able to be referred by the Objectives
of Control of the Information and technologies related as
COBIT22
, that is as a framework for the management of IT
21 Consejo Nacional de Educación Superior (CONESUP), Del gobierno de las instituciones del sistema nacional de educación superior, Base Legal
Capitulo 6. Disponible en http://www.conesup.net/capitulo6.php 22
Control Objetives for Information and Related Technology. Available in
official web site:
with a similar approach on the standards handled by the
PMBOK23
for the management of projects, and ITIL24
for
management of services." [19]
Figure 4: EA generic life cycle [9]
E. Advantages and Benefits
The advantages and benefits will depend strictly upon
the model of controls that might be utilized for the
development of the EA. In general terms, the premise
"Enterprise Architecture supports IT management when it
comes to doing the right things in the right way at a minimal
risk." [2] guarantees the efficiency and efficacy, while the
absence of risks is not more than high security. The most
significant advantages will then offer the development of the
architectural-organizational framework for the institutions of
higher education. These will be:
• The methodology will mature gradually to the extent
that the institutions of higher education are adopting
them as practices of continuous improvement.
• To promote an integral vision of the model of
business based upon the interaction of all the
dimensions involved.
• To help with the creation of a unique repository of
information where the models that reflect the
processes of the business should be included. These
appliances will express the dimensions that define
the business, while also identifying the relation that
exists among them.
• To offer backup to the operations of TI, identifying
impacts in the adjustments of the model of the vision
http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/Tagged
Page/TaggedPageDisplay.cfm&TPLID=55&ContentID=7981 23 Project Management Body of Knowledge. Available in official web site:
www.unipi.gr/akad_tmhm/biom_dioik_ tech/ files/pmbok.pd 24 Information Technology Infrastructure Library. Available in official web site: http://www.itil-officialsite.com/home/home.asp
of the business in order to know the implications of
a change, before starting new projects.
• To provide information to generate possible settings
of solution and in this manner, serving as a tool for
making decisions in the adjustments of the
processes.
Immediate benefits exist that will be able to be observed
in the global areas:
• Efficiency of TI: Involving doing things well
• Efficacy of TI: Involving doing the things that
should be done (and in the correct way). \
• Trust within the EA: Doing things with a most
minimum risk.
F. How to define it
Starting from the initial situational fact (how it is) and
considering objectively the final state in which the higher
education institutions want to arrive (as it should be), we
should consider these two points in the challenge of its
development because the final state will be defined by the
architectural specification of the framework. They should
pay attention and assign resources bring forth a more
organized future (EA objective). Also, the effort should be
protected by a degree of full consciousness with respect to
the current state (assets of existing information, processes of
business, organizational structures and several
infrastructures, etc).
It is vital that the process that specifies the base line be
taken into account with the greater seriousness of the case.
From this we will be able to derive the initial actions to take
and the road thereafter that we should continue on in search
of the EA objective. The feedback of the professionals
illustrates the importance of this: "It cannot be known
where someone is going without clearly knowing where he
is himself." [2]
Identifying the current state will also serve in identifying
gaps, redundancies and assets of hidden data, as well as to
show who does what and where inside the institutions of
higher education. Such a process should include any form
of strategic analysis of gaps heading the documentation of
the roadmap for the architecture.
III. ROADMAP FOR THE IMPLEMENTATION
Considering the EA as an "active business" [6], it is
necessary to establish a plan that would help the institutions
of higher education to finalize the discipline of EA and even
to generate a critical mass through the creation of
educational programs and through the investigation of this
area of growing importance. Arriving at such attainment
will not be an easy task due to the fact that the EA implies
an organizational effort which requires management,
allocation of resources, continuity, coordination and
programs of academic formation. Through joint effort, a
description of operations should be established in which one
could apply the EA, the vision to future that is sought, as
well as the strategies of IT that will support the compliance
of the definite goals. For this, three predominant factors
should be considered.
A. Obtain support from the government of the universities
"Gaining executive commitment to any new initiative
requires the development of a strong business case and a
communications approach to effectively convey that
business case." [6]
Without support from the government of the universities,
it will be difficult to maintain the necessary sponsorship for
financing and implementing the improved processes and
systems. To be able to obtain the sponsorship is necessary
to consider:
• Successes of other organizations (experience and know-
how) in its applications of EA. [6]
• To Use examples to show how the EA offers an integral
program for the management of changes as well as in
achieving improvements in the performance of the
mission and the organizational responsibility as an
approach of IT. [2]
Due to the academic context of the institutions of higher
education, the main goal is to become one of the
participating assets of the EA through a formal, concurrent
and integral commitment. As an institutional example of
pilot plans / complete projects we can take as a reference,
MIT25
, Penn State University26
, JISC program [7],
Monash27
, Minnesota28
and Saint Louis29
.
The EA group in collaboration with the government of
the universities should develop a politic based on the
institutional architectural principles that will govern the
development, implementation and architectural
maintenance.
Once the architectural politics have been disseminated,
the EA group should organize and conduct the program to
25 Massachusetts Institute of Technology. Available in: http://web. mit.edu/itag/eag/ 26 Penn State University Enterprise Architecture Initiative Available in:
oficial: http://ea.ist.psu.edu/ 27 Monash University IT Architecture. Available in:
http://www.its.monash.edu.au/staff/plans/architecture/ 28Minnesota Enterprise_Architecture: http://www.state. mn.us/mn/externalDocs/OET/Minnesota_Enterprise_Architecture_Whitepa
per_061406104429_MEA Whitepaper.pdf 29 Building an Enterprise Architecture Program at Saint Louis University. Available in: net.educause.edu/ir/library/powerpoint/MWR07072.pps
explain the goals, objectives, processes, products, costs and
other activities related to the process. The objective of this
explanation is to attract the main stackeholders from the
lower and mid levels of the organization.
Once, they have developed and analyzed, the first results
of the "products" of the EA should be published within the
organization to show the value of those early results and
thus to achieve the maximum exposition for the benefits in
the effort of the development of the framework.
B. Establish a structure of management and control
The direction, control and monitoring of the activities of
the EA and its progress should be iterative and cyclic. A
strong organizational structure within the institutions of
higher education will be necessary to facilitate and to
accelerate the definitions of the roles and associated
responsibilities of the development of the framework. The
roles should be evaluated in terms of the size of the
organization, the complexity of the business, the architecture
negotiated, along with other factors to determine the
correlation of adequate roles assigned to the personnel.
A structure of management and control should be
conformed by a CIO and a group of technical revision. The
CIO will be responsible for negotiating and analyzing each
aspect related to the EA, as well as communicating and
integrating the university governments with the other levels
(teaching, investigation and extension); for this reason, it
will become a key element of innovation and in achieving a
competitive advantage. The group of technical review will
take charge of examining the projects and their assets to aid
in their alignment with the EA. This group will determine
and document the results at hand with the actions. To
achieve this, the group should revise and be assured that:
• The complete project must be aligned with the EA.
• The project is not aligned with the EA and is
necessary to define an alternative road of action.
• The project is not aligned with the EA and the
renunciation of the development of the project is
approved.
C. Products and activities
1) To develop plan of strategic marketing plan and
plan of communication
Initially a marketing strategy should be established and
an objective strategy whose communication be directed at
maintaining an informed university government down to its
organizational units, as well as to diffuse architectural
information to the management groups. The CIO, in
colaboration with the personnel, should define a marketing
plan and consistent communications in delimitations, level
of detail, mass media, and feedback of the participants,
commercialization calendar activities and in the method of
evaluation of the progress of implementation. The main role
of the CIO will be to interpret the vision of the univerisity
government as well as to recognize innovative ideas.
One of the media suggested that the marketing of the
framework should be the plan of the communications
department: to inform the university governments of the
interested parts within the strategic plan to continue. The
plan of communications can be utilized to express the vision
of the high executive university and the role of the EA in the
compliance of that vision. Also, the plan should report of
the benefits of the architecture as the agent of change to
reach the organizational goals, or like a critical resource for
evaluating options of change, just as the business and the
technology require it. Roles should also be considered as
well as the responsibilities of high executives and their
direct relation with the project. All the previous things will
be able to show the benefits of the EA for the stakeholders
of the institutions of higher education.
2) Develop a Management Plan (MP)
This should include the roadmap for the compliance of
the assembly of goals, as well as the plans of
implementation to arrive at those goals. The figure 5 sample
as they would be able to integrate the layers with regard to
each one of the phases of the project, there being specific
roles for each one of them.
Figure 5: Management of the EA [6]
The MP delineates plans and an assembly of actions to
develop, to utilize and to maintain the EA, including the
management and control of all the architecture. It will
facilitate the monitoring of the costs, the programming of
tasks and will offer data about performance, as well as
procedures of supervision and control that should be
developed, documented and implemented. The PG should
also include appliances [6] such as:
a) Documentation of requirements for the CIO of the
EA, to identify all the needs of financing: expenses, time
limit, calendars, and links to the measures of performance.
b) A plan of the structure (MP) that details the tasks
and subtasks necessary to acquire, develop and maintain the
architecture.
c) The resource estimations and documentation for its
financing, the endowment of personnel, formation, work
space requirements and the needs of the team.
d) The work plan for the start of the plans of the
project.
e) Documentation of requirements to carry out quality
control management of risks, management of configuration
and management of the security.
f) Documentation of requirements for the establishment
and maintenance of a repository of information of EA.
3) Start the Development of the EA
With the products developed in the previous points, in
this environment it is already possible to initiate the project
of EA. There are several peripheral activities associated
with its creation:
• To institute the practices of the Plan of
Management.
• To establish the processes of development of the EA
and the practices of management. [6]
• To qualify the participants of the project of EA. [6]
• To build a base line of the products EA. [5]
• To establish the objective expected with the
products EA.
• To create the plan of sequencing. [2]
• To populate the repository EA. [2]
D. To define the process and the approach
The nature of the institutions of higher education of
Ecuador (publicly financed by the State, privatley financed
jointly by the State and individuals, self-financed30
) and the
factors inherent in the architecture, will dictate the approach
of change of the architecture that is to be developed.
Though an architectural approach is an excellent tool to
handle complex and extensive environments, the depth and
detail of the EA need to be in proportion to the organization.
In the Figure 6 we can observe this relation.
It is essential to determine the use that will be given to
the architecture, because this will determine the
developmental process type. The presence of certain
activities in the definition of the approach is normal, as well
30 Consejo Nacional de Educación Superior (CONESUP), De la
Constitución, Fines y Objetivos del Sistema Nacional de Educación
Superior. Forman parte del Sistema Nacional de Educación Superior Ecuatoriano. Disponible en http://www.conesup.net/capitulo1.php
as in the selection of EA products in the construction and in
the final use. The goals [8] that are pursued with the process
are understand as follows:
• To build an architecture base (of reference)
• To build an objective architecture that shows you
the vision and strategies of the organization.
• To develop a plan of sequencing that describes a
progressive strategy for the transition of the base-
line to the goal.
• To publish an EA approved plan of sequencing that
will be accessible by the personnel of the institution
of higher education.
Figure 6: Depth and Details of the Archictecture [6]
It is essential to determine the use that will be given to
the architecture, because this will determine the
developmental process type. The presence of certain
activities in the definition of the approach is normal, as well
as in the selection of EA products in the construction and in
the final use. The goals [8] that are pursued with the process
are understand as follows:
• To build an architecture base (of reference)
• To build an objective architecture that shows you
the vision and strategies of the organization.
• To develop a plan of sequencing that describes a
progressive strategy for the transition of the base-
line to the goal.
• To publish an EA approved plan of sequencing that
will be accessible by the personnel of the institution
of higher education.
Besides this, some other aspects should be considered
[6] such as:
• To make the rules and the processes of the business
very clear, needs of information, flows, locations.
• Importance of the activities, functions,
organizations, calendars, etc.
• Environment of application of the organization.
• Operational settings, the situations and geographical
zones that are considered (university extensions).
• Projection of financial gain.
• Projection of business and technical areas of risk.
• Projection of the capacity of the specific
technologies, while reaching toward the goals (this
applies only to the architectural goals).
E. Adopt a Framework
On this point, we will have defined at the administrative
level as well as the structure of the project, the following
step will be to adopt a framework (whether predefined or
developed) that will specify in a formal way each element
constituent of the EA. They are various frameworks, but
special attention to five of the most prominent foci of this
discipline has been taken, they should be contrasted in
depth: Zachman, FEA, TOGAF, Gartner and E2AF. It is
because of this that it is necessary to briefly undertake each
methodology and consider a study [18] proposed by Gartner
in which predicts that 95% of the organizations will bear
multiple foci of EA in the year 2015.
Gartner has identifyed in his study four architectural foci
of EA: traditional, federated, exterior middle and negotiated
diversity. The analysis has shown that the majority of
medical assistants of the discipline EA will make use of a
mixture of more than one of these foci based on the needs of
the business. The foci mentioned are defined as:
Traditional: the team of EA takes at base the organizational
structure to facilitate the process of EA, becoming a center
in the normative content that serves to guide the consistent
one and to make decisions about projects with the
consecrated master plan of the architecture. This approach
tends to function well in organizations in which a great part
of is about making centralized decisions that are relatively
stable in terms of the rhythm of change. This, however,
does not function so well in organizations where the
decision-making and authority are distributed and where the
rhythm of change in the business is frequent.
Federated: fact for complex and large organizations, where
it makes often very decentralized decisions, with units of
business characterized by a considerable autonomy in the
EA. An architecture centered in defining the nucleus and
common elements between the departments and units. This
approach adapts well to the organizations distributed
geographically and is less efficient in the highly centralized
organizations of a homogeneous business.
Medium exterior: it is an approximation of the EA by the
one that the architects are centered in the management of the
key dependences among the parts of the organization that
have the major impact in the capacity of change. This
approach centers around the architectural interoperability by
means of the definition of a small, but strong, assembly of
stable standards of interface, to the time that permits a
complete autonomy of it takes of decisions for the
technologies and specific products that are used in the
solutions. This approach is very well adapted for the
organizations and the "ecosystems of business," where the
units of business, associates and suppliers are not under the
direct control of a central team of EA.
Diversity negotiated: they center themselves in the
definition of several options. This approach of the EA
conjugates the need of an assembly of norms with the need
of a diversity of solutions to enlarge the innovation, the
business growth and competitive advantage. The project
team can decide the better product according to than adapt
to the needs of the project, instead of having only one norm
imposed. The advantage of this approach is that it permits
the users and teams (of the EA) to select the correct tool for
their work, which permits the innovation from the diversity.
The disadvantage of this approach is that the users and
teams of the project should accept a greater responsibility
for their decisions.
With a approach combined from the EA, the institutions
of higher education will try to determine the appropriate
equilibrium of control of their architecture by means of the
application of an adequate architectural focus. This signifies
that the team of EA will have to determine a framework of
decision-making that will permit them to evaluate and to
praise what focuses should be used for any solution that
might be given, defining what more could be appropriated
considering the technology, information and aspects of the
business.
1) Zachman
It is defined formally as taxonomy of "architectural
appliances" in terms of an organization (that is to say,
documentation, specifications, model) that are utilized in
private matters inside the movement of the business
according to the addressing which moves the business. John
Zachman describes this work in the following way:
The EA Framework ―applies to Enterprises is simply a
logical structure for classifying and organizing the
descriptive representations of an Enterprise that are
significant to the management of the Enterprise, as well as
to the development of the Enterprise's systems”. [10]
According to Zachman, ―the Framework schema has
been around for thousands of years and I am sure it will be
around for a few more thousands of years. What changes is
our understanding of it and how to use it for Enterprise
engineering and manufacturing.” [11]
The following dimension that Zachman proposes is a
descriptive approach of the appliances, then the essential
questions to respond to which are: what, how, when, where,
who and why of the project. The context of these can be
seen to be affected by who is the owner that formulates the
questions, according to the prevailing need in a specific
moment.
The structural idea that Zachman suggests for the EA is
that they create a composition in private cells in which an
appliance will only be framed. With this objective, the
ambiguity will be avoided due to that which will always be
known: the place that inhabits a specific appliance.
A second suggestion inside the taxonomy of Zachman
indicates that a polite work should be considered whenever
it has been concluded with a private cell. This will
guarantee that they will not become mixtures in the owners
of the work that they produced and with the appliances in
development.
When each one of the arranged cells in a grill (grid) is
full with each one of the appliances that integrates the
System, each one of the participants will have a more
extensive vision of this, since each one of the angles of
disposition, obviously with the approach of EA.
2) TOGAF
It is defined in and of itself as a Framework;
nevertheless, the most important part of TOGAF is its
Development Architecture Method, which is better known
as ADM.
The success of the proposed enterprise architecture by
TOGAF is the division of this architecture in four layers [1]:
• Architecture of Business: includes the parameters
related to the business of this forms manages to
know the objectives and strategy of the same one.
• Architecture of Applications: describes how the
applications are designed and how develops the
interaction among these.
• Architecture of Data: describes as business stores
the data, organizes them and agrees to them.
• Technical Architecture: describes the infrastructure
of the hardware and software that bears the
applications and its interaction.
ADM is a repository for the creation of the architecture,
and this can be organized as a process, which in theory
would summarize the concept of TOGAF in an Architecture
of Processes, instead of as an Architectural Framework or
Methodology, as it is defined by The Open Group.
In comparison with Zachman: "It is necessary to categorize
the appliances" [17], in TOGAF, a technique delivers itself
that permits the creation of the said appliances.
The approach of TOGAF in the environment of the
enterprise architecture is focused directly toward the
continuous architecture, creating ranks that will include
everything from the largest generic architecture, to the
smallest and most specific one, to this type of technique
known as Enterprise Cotinuum. The methodology ADM of
TOGAF permits exactly what is needed to achieve the
movement that goes from the generic thing to the specific
thing.
A differentiation of the levels—in which intends to
itemize the universal thing and to become specific—
described in TOGAF, is the following one:
Foundation Architecture, in which all is included
architectural principles that will be able—at least in
theory—to be used by any IT in the business of your
domain.
The following level of specification, is that of
Architecture of Common Systems, is the architectural
design that is desired in many types of businesses.
The following level of specification is the concern of the
Industrial Architectures, and they are themselves related to
the businesses that have the same control, and in which case
the growth develops to an exponential form (case of branch
offices).
It is called in TOGAF, a specific level of the
Architectures Organizations; and is the architecture that will
be made specificly for a determined business.
3) FEA
Its fundamental objective is to implement a referencial
framework of common Enterprise Architecture for the
multiple agencies and governmental functions of the the
United States. From the point of view of analysis, it
becomes one of the most powerful Frameworks, due to the
fact that it possesses a study of comprehensive taxonomy,
just like Zachman, besides architecture of processes like
TOGAF. So FEA can be considered as a methodology for
the creation of an strategy of Enterprise architecture, or as
the result of the application of processes by a Private
Business. Generally it is described by FEA as an assembly
conformed by five models that you can index to increase its
performance: Business, Services, Components,
Technologies and Data. Those that are considered the
constituent elements of FEA, although a meticulous
processing necessarily will include the following
parameters, they are [6]:
a) A general vision of the Enterprise Architecture.
b) A reference model assembly to describe the different
perspectives of the Enterprise Architecture.
c) Processes to create the Enterprise Architecture.
d) Transactional Processes for the migration of a
Business Pre-Architecture to a paradigm of Business Post-
Architecture
e) Taxonomy to catalogue assets that are included in
the competences of the Enterprise architecture.
f) An approximation of the measurement of
satisfaction of the use of a Enterprise Architecture to
conduct the value of the business.
The Office of Administration of the Program of Federal
Enterprise Architecture (FEAPMO31
) affirms that FEA
provides: "a common language and framework to describe
and analyze IT investments, enhance collaboration and
ultimately transform the Federal government into a citizen-
centered, results-oriented, and market-based organization
as set forth in the President's Management Agenda." [6]
The perspective of FEA and of EA in a business is the
construction of segments, based on the idea introduced by
FEAF. There are two types of segments: the vision-area
nucleus segments, and the business-service segments. The
segments of business-service are fundamental for the
majority of political organizations—probably for all of
them—for this reason, this type of enterprise architecture
has served as a great backup for the governmental
institutions inside the federal offices of the United States.
FEA consists of an assembly of "Reference Models"
interrelated, designed to facilitate the analysis between
agencies and the identification of duplicate values of
investment and of the gaps and opportunities of contribution
among them. Collectively, the index models that compose
the Framework describe the important elements of FEA in a
consistent and common way [6].
4) Gartner
According to the conception of Gartner, the Enterprise
architecture brings with itself three constituents: owners of
the business, specialists of information and implementors of
technology; such an objective is always the unification of
these three elements, and a future adapted to a common
vision of bringing more value to the business.
Beyond any development of appliances and technical
documents, Gartner worries about an efficient
31
The Office of Administration of the Program of Federal Enterprise
Architecture. Available on: http://www.aboutus.org/Feapmo.gov
implementation of a definite model as "common and single
idea," and that it should be understood and shared by all the
participating assets of the business.
According to the models of business, in many
businesses, continuous experiences change in certain
processes. For this reason, Gartner suggests a creation of
Enterprise architecture, in a way in which each member
would know the nature, objective and impact of the said
changes.
Gartner’s proposal is a lot wiser if it is proposed in terms
of strategy, and not so much in terms of engineering. This
vision is focused on the destiny of the business, and the
most important part of this concept is that the idealization of
destiny does not worry so much about where it is going with
the business but more about how it is going.
The Framework of Enterprise architecture proposed by
Gartner is oriented to resolve the creative paradigms in the
collective frameworks. So an architectural model is
presented like a stable and unit assembly in which each
participant should know exactly each vision and approach to
be able to operate coherently according to their levels of
competence. After the definition of a common objective, it
will become possible to implement models that resolve the
efficient form for the future movements of the business.
The main worry of Gartner is how to move what you put on
the file and then to make it march, then some type of
methodology can be found that will not be resolved by
means of shaping it due to the fact that it has been shown
that nobody is capable of shaping absolutely everything
[12].
5) E2AF
The extended enterprise architecture E2AF is a
framework created by the Institute for Enterprise
Architecture Development IFEAD, developed for the
purpose of communicating the architectural aspects to the
stakeholder. It has as its fundamental axis the integration of
the organizational and technological parameters which are
all framed by a plan for integrating holistic unification of the
three fundamental elements: The element of construction,
the element of function and the element of style [21].
Since the organizational perspective is generally of no
importance to the construction of itself, it has has been given
parameters related to enterprise architecture, reducing in a
considerable way the participation of the "style" (element of
the architecture) or simply ignoring the competences that
this supposes. Due to the extended architecture, the style is
considered previously cited, and will be understood in how
it relates to the cultural behavior, values, norms and
principles, as well as in what ways these are incorporated in
the institutional values of the organizations.
At the same time, the enterprise architecture operates the
aspects of Business, Information, Systems, and in a way
integral Technological Infrastructure that covers the
organization and its environment in the plan of zoning and
to an outright level of a city [21].
The E2AF is seeking to help generate the business
architects in an assembly of methods, technical and
practical, giving them the capacity of integrating the
business aspects with the technological, thus having an
elaborate mark of projection with concrete objectives,
administration and management of the complexity
undertaken inside a cycle of continuous change guided by
the Extended Enterprise architecture Extended.
In conclusion, the soon to be adopted E2AE guarantees
that:
• The results can be utilized as a dictionary for
administration and to sail in the prominent aspects
of an institution.
• The roadmaps will be defined to identify the
necessary tasks and the activities within E2AE, it
will be identified by the elements of complexity to
be operated, the people involved in the process as
well as the
• relations and existing dependencies among them
• E2AE will guide efficiently throughout all the
Architectural Activities. [22]
F. Framework selection criteria
Due to the business context and the individual business
of each one of the frameworks to be analyzed, one should
take into consideration the approach that the higher
education (teaching, investigation and extension) proposes;
for this reason, we could recommend to take the most
prominent associate of this context in each one of the four
main methodologies to obtain a personalized methodology,
or to develop well an EA strategy considering the proposal
of the approach of Gartner [18].
As a model of initial reference has been taken by the
Table I, the work done by Roger Sessions [15] and from her
we are able to compare the statistical model proposed by the
PEAF in its proposal of frameworks [16]. Due to the greater
granuality in the criteria, it has been determined to include
the scoring of Sessions in this article.
G. Tool selection criteria
The approach for the selection of the tool should be
oriented by the framework on which they will work, taking
as a reference the two base dimensions presented by the
IFEAD [13]: the basic functionality of each tool, and the
utility that it will offer the different professionals involved.
TABLE I: EA FRAMEWORKS ANALISIS [15]
Criterio Zachman TOGAF FEA Gartner E2AF
Taxonomy 4 2 2 1 2
Proccesses 1 4 2 3 4
Reference-model
Guidance
1 3 4 1 3
Practice
Guidance
1 2 2 4 3
Maturuty Model 1 1 3 2 1
Business Focus 1 2 1 4 2
Governance
Guidance
1 2 3 3 2
Partitioning
Guidance
1 2 4 3 2
Prescriptive
Catalog
1 2 4 2 2
Vendor
Neutrality
1 2 4 2 2
Information
Avaibality
2 4 2 1 2
TOTAL 15 26 31 26 25
Another approach is oriented toward the functionality,
that is, it is described as base requests in how the tool is
capable of carrying out different functions necessary for the
activity of the development of an EA. The analysis is
structured according to the following parametros [13]:
• Methodologies and models.
• Interface models development.
• Automation of the tool.
• Personalization and extension.
• Handling and analysis.
• Repository.
• Architecture of implementation.
• Discharge and technical backup.
• Architectural results.
The second dimension, undertakes the utility of the tool
for the different professional profiles, that is to say, to
capture the apt view from the purpose of the tool, and
describe its usabiltity. The profiles to be considered [13]
are:
• Business Architects.
• Architects of solutions.
• Strategic planning / Direction.
• Business Programs Managers.
• Software architects and engineers.
• External associates.
The figure 7 illustrates some aspects that should be
considered for the election of the tool starting from these
three criteria: purpose, content and format.
EA TOOL
Porpuse Content
Format
RelationshipsENTERPRISE
Visualizations Language
Applications
Information
Business
Technology
Agility
Integration
Products / Services
Processes
Organization
Middle ware
Plataform
Network
DataSoftware
Internal
External
Drawings
Graphics
Images
Models
Patterns
Guidelines
Principles
Rules
Starting Points
Narrative
Figure 7: Dimensions to consider for tool selection [14]
The software of the IFEAD [13] has developed a formal
contracting between thirty-two tools, taking in consideration
eleven criteria. On the Table II of the five products have
been placed that obtained greater scoring. It should be taken
into consideration that this is an analysis for the selection of
the tool that will be utilized, for which, it is recommended
that one revise more the products more in depth: Bizzdesign
Architect and Bizzdesigner, Corporate Modeler Enterprise
Edition, Enterprise Architect, System Architect Family +
Rhapsody, and finally Troux.
H. From development to implementation, how to make the
architecture last
The implementation by itself lacks sense if one does not
establish the necessary starting points to do what the EA has
periodically maintained and submit the work to be reviewed
in case of necessary changes. The Table 3 sample is a
model of strategic approach that could be adopted in order
to establish key points of control. This will support the
review and maintenance of the EA. This model states
cutting the time segments in half, and creating a limit that
seeks to fortify the tactical development and long-term
approach of the strategic direction.
TABLE II: EA TOOL ANALISIS
Criterio/
Vendedor
BizzDesign CaseWise Sparx
Systems
IBM –
TeleLogic
Troux
Metodologies 3 10 10 5 10 Models 8 10 10 8 8 Model Development
Interface 9 7 10 10 10
Automation 9 9 10 10 10 Customization 9 8 10 9 9 Manipulation 10 9 10 10 10 Repository 9 9 10 10 10 Deployment
Architecture 9 7 10 10 10
Licencing 7 7 7 10 10 Architecture Results 10 9 9 10 9 Utility 8 8 6 10 8
TOTAL 8,2 8,4 9,2 9,2 9,4
Once the criterion of the previous sections is taken into
account, it is necessary to carry out a lifting of information
that will serve to generate the products and to populate the
repository EA. The architectural base line and the approach
that the objective considers will be revised and then they
will be able to validate the appliances inherent in the EA.
After this, one should devise models and subsequently these
models should later be refined.
Once the gaps and the plans of migration have been
identified, the EA should be approved, published and
disseminated in the institution of higher education that
might be applying for it. With this step, they will begin to
formally rotate the meshing’s that will integrate the
architectural approach to the processes of the organization.
It should be considered as a guide to the personnel, to
establish the processes and procedures of the application
process of the EA, and finally it should be executed and the
processes should be integrated (processes EA - processes of
the institution of higher education). [6]
TABLE III: STRATEGIC PLANNING OF AN EA [20]
Actual 0-2 years 2-5 years
Base Line Tactical deployment Strategic direction
All products or
technologies
currently in use
(What we have now)
Products or technologies
recommended for use in
the next 2 years (What
we'd like to have now)
Products or technologies
recommended for use in
the next 5 years (What we
want to have in the future)
Mainstream
platforms
Used Elsewhere Emerging platforms
The most important
products or
technologies
currently in use
(What are our
majority use
platforms)
The major products or
technologies used
elsewhere (What other
organisations use)
Products or technologies
to be evaluated (What we
can see coming as
possibilities)
Retirement Targets Containment targets Pilot Platforms
Products or
technologies marked
for retirement (What
we want to get rid of)
Products or technologies
slated for limited
investment (resource,
maintenance, etc.) only
(What we want to get rid
of but can't, so we limit
it's use)
Products or technologies
that we are piloting with a
view to becoming
strategic (What we are
piloting with a view to
becoming strategic)
Finally, to be able to maintain a strong and mature
architecture, these values should be valued periodically.
The EA products will be evaluated on a base level of
reflection with reality and should be considered proposals of
change (as they have been suggested on the TABLE III).
IV. CONCLUSIONS
Facing the challenge of implementing a approach of EA
in the institutions of higher education in Ecuador requires as
a key aspect, to have a clear knowledge of the ―as is‖ and
the ―to be‖ one may want to arrive organizatioanly. The
commitment of the institutions should be integral as far as
the necessary investment of resources for the adoption of the
EA approach upon adequatley assigning resources and
implementing a strong plan, these changes will make the
development process more iterative and simplified. Also, it
should be taken into consideration that the architectural life
cycle should be carried out in a medium time limit by the
constant evolution and growth of the institutions of higher
education to which indistinctly apply, owed to their constant
development. Finally the methodology (framework) that
may be desirable to utilize can be protected by a single
focus, but it is convenient to try to meet the fortresses of
each approach in a hybrid framework specialized for higher
education.
REFERENCES
[1] The Open Group. The Open Group Architecture Framework
―TOGAF‖. The Open Group, 2009. Versión 9. ISBN: 978-90-8753-
230-7
[2] Niemann D. Klaus. From Enterprise to IT Governance ―Elements of Effective IT Management‖. GWV Fachverlage GmbH, 2005. ISBN
3-528-05856-0. [3] Zachman, A. John. "A Framework for Information Systems
Architecture." IBM Systems Journal, Volumen 26, Número 3, 1987.
Disponible en: http://www.zachmaninternational.com/images/stories/ibmsj2603e.pd
f
[4] Clinger-Cohen, Acta de la Ley de 1996 (PL 107-347) Disponible en la librería del Congreso: http://thomas.loc.gov/default.aspx
[5] Corporación MITRE. EABOK. Guide to the (Evolving) Enterprise
Architecture Body of Knowledge. Mclean, Virginia, 2004. [6] Chief Information Officer Council. Federal Enterprise Architecture.
Versión 1.0. 2001. Disponible en el sitio official:
http://www.whitehouse.gov/omb/e-gov/fea/ [7] Joint Information Systems Commitee (JISC). Doing Enterprise
Architecture: Enabling the agile institution. 2009. Disponible en:
http://www.jisc.ac.uk/media/documents/techwatch/jisc_ea_pilot_study.pdf
[8] Ross W. Jeanne, Weill Peter, Robertson C. David. Enterprise
Architecture As Strategy: Creating a Foundation for Business. Harvard Business Press. 2006. ISBN: 978-1591398394
[9] Selig, J. Gad, Waterhouse Pete. IT Governance – An Integrated
Framework and Roadmap: How to Plan, Deploy and Sustain for Competitive Advantage. 2006. Disponible en:
http://www.axisgroup.com/downloads/CA_Clarity_IT_governance_
whitepaper.pdf [10] Zachman, John A. "The Framework for Enterprise Architecture:
Background, Description and Utility." Zachman Institute for
Framework Advancement (ZIFA). Document ID: 810-231-0531 [11] Entrevista con John Zachman. Roger Sessions, Editor en jefe de,
―Perspectives of the International Association of Software
Architects‖. [12] Gartner, Gartner Enterprise Architecture Process: Evolution 2005, R.
Scott Bittler, Gregg Kreizman, ID: G00130849
[13] Institute for Enterprise Architecture Developments – IFEAD. Enterprise Architecture Tools Selection Guide. J. Schekkerman.
Versión 5.0. 2009. Disponible en: http://www.enterprise-
architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v50.pdf
[14] Veltman Elise, Reekum Van. Determinig the Quality of Enterprise
Architecture Products. Tesis de Masterado. Universidad de Utrecht & Sogety Holanda B.V. 2006. Disponible en:
http://www.dya.info/Images/Thesis%20E_van_Reekum_Determinin
g_Quality_Enterprise_Architecture_Services%20v2_tcm13-24174.pdf
[15] Objectwatch Inc. A Comparison of the Top Four Enterprise-
Architecture Methodologies. Sessions Roger. 2007 [16] Pragmatic EA Ltd. PEAF: Framework Comparision. Versión 2.0.
2010. Disponible en www.pragmaticea.com/docs/peaf-overview1-
framework-comparison.pdf [17] Zachman A. John. The Zachman Framework for Enterprise
Architecture: A primer for enterprise engineering and manufacturing. Zifa eBook.
[18] Gartner. Gartner Predicts 95 Per Cent of Organisations Will Support
Multiple approach es to Enterprise Architecture by 2015. Gartner Analysts to Explore the Right approach es to Enterprise Architecture
at the Gartner Enterprise Architecture Summit 2010, 17-18 May in
London. Disponible en: http://www.gartner.com/it/page.jsp?id=1358913
[19] Universidad de Monash. Information Architecture Technology –
MITA. 2006 [20] Universidad de Cardiff. IT Roadmap. Technology brick template.
Disponible en:
http://congliffy.cf.ac.uk/display/LeanEA/Technology+Brick+ Template
[21] IFEAD (Institute For Enterprise Architecture Develop). Disponible
en: http://www.enterprise-architecture.info/ Images/Extended%20Enterprise/Extended%20Enterprise%20Archite
cture.htm
[22] Jaap Schekkerman President & Thought Leader IFEAD Institute EA Developments, The Netherlands, Extended Enterprise Architecture
Framework Essentials Guide Version 1.5, 2006.