Information Technology Reference
In-Depth Information
elements and does not cover other important aspects, such as conformance
testing and quality assurance, enterprise planning and federation.
The other group of frameworks focuses more on the processes and method-
ologies used to build the enterprise architecture. The most prominent example
here is The Open Group Architectural Framework (TOGAF) [98]. It divides
an enterprise information architecture by using four categories (the business,
application, data and technical architectures). However in TOGAF, the em-
phasis is placed on the ADM (architecture development method), which is the
process and methodology that creates the architecture. This methodology-
based view of an enterprise architecture is one of the major strengths of
TOGAF, which can be seen as complementary to more organizational-based
approaches such as the Zachman framework.
TOGAF first made use of a formalized architecture description language
in its latest version, TOGAF9, which also adds a certain level of formalism
for the relationships between various concepts, including links between IT and
business concerns.
There are also more specialized frameworks that concentrate on partic-
ular domains, such as defence or government. The Department of Defense
Architecture Framework (DoDAF) [66] and the Ministry of Defence Architec-
ture Framework (MoDAF) [85] are examples developed by the US and UK
governments, respectively. The Federal Enterprise Architecture Framework
(FEAF) [70] is an attempt by the US federal government to integrate all the
architectural activities in its multiple agencies under a single common frame-
work.
Unlike Zachman or TOGAF, this group of frameworks has a strong em-
phasis on high-level management because of the particular requirements and
concerns of the organizations being served. This results in reduced coverage
of the more technical aspects. In addition, the frameworks reflect the organi-
zational thinking of the domain in which they were developed, making them
dicult to reuse in a broader industrial context.
A common problem with all these frameworks comes from their complex-
ity. Although initially relatively compact, they have evolved over the years
to accommodate too many aspects and functions, making them hard to man-
age or to use in an effective way. In general, specifying an enterprise system
requires the balancing of many aspects that could be considered, and also
of the interests of a variety of different stakeholders. It is important that
any framework should allow each stakeholder to express their requirements
and solutions in a way that is familiar to them, by using their normal tools
and techniques. This means that the framework must allow the integration
of the specifications expressed in different ways. At the same time, it pro-
vides mechanisms for maintaining and ensuring the consistency of potentially
conflicting requirements or different views of the system. Thus, a key require-
ment for an effective framework is that its components should be cohesive,
with clearly expressed correspondences between the elements seen by the dif-
ferent stakeholders. In this respect, many of the proposed frameworks identify
