![](bg2.png)
Enterprise Architecture is the organizing logic
for business processes and IT infrastructure
reflecting the integration and standardization
requirements of the firm’s operating model. EA is
conceptual blueprint that defines the structure and
operation of an organization. (Spewak,1993)
An architecture framework is a toolkit which can
be used for developing a broad range of different
architectures.
Architectural domains are a structuring criterion
for a collection of architecture products.
Architecture frameworks defines usually 3-4
domains/ areas, that structures the outcomes of
architecture planning. Typical results are: Business
architecture, Information systems architecture, often
subdivided into Data architecture, Application
architecture, and Technical architecture.
During the research several architecture
frameworks were analysed, in order to find which
approach should be selected for service modelling.
The Enterprise Architecture Reference
Traditional Model offers clear distinction between
the architecture domains (Business, Information/
Data, Application/Integration and Technical/
Infrastructure).
The Zachman Framework is an Enterprise
Architecture framework for enterprise architecture,
which provides a formal and highly structured way
of viewing and defining an enterprise.
Capgemini’s Integrated Architecture Framework
has evolved based on the real-world experience, and
continues to provide strong focus on the need to
understand the business needs and drivers, and for
all aspects of the architecture and all architectural
decisions to be traceable back to these business
priorities (Mulholland and Macaulay, 2006).
The GAME architecture approach is strongly
based on the general categories of business,
application, data and infrastructure, but completes
with security and governance architecture.
The Department of Defense Architecture
Framework (DoDAF) provides a foundational
framework for developing and representing
architecture descriptions, it establishes data element
definitions, rules, and relationships and a baseline
set of products for consistent development of
systems, integrated, or federated architectures.
TOGAF (2009) is a high level and holistic
framework for assisting in the acceptance,
production, use, and maintenance of enterprise
information architectures. Practical and proven, it is
based on an iterative process model supported by
best practices and a re-usable set of existing
architectural assets.
The approach of McKinsey for architecture
structures (Buckow-Rey, 2010) tends to integrate the
Business and IT views of an organisation. This
approach focuses on the problem of architecture
complexity that became common in big
organisations with diversified activities.
Analysing the methodological part of the
projects 8 architecture modelling approaches were
analysed. The analysis focused on the following
issues:
• Modelling structure, layers, categories and
relationships
• Service definitions
• Measurement requirements
Based on these main aspects the TOGAF and
DoDaF architectures were the most suitable for
further investigation, although neither approaches
can be used as they are.
During modelling, the project has strongly built
on the previously presented architecture modelling
approaches, and the project follows the generally
accepted main architecture groups, as: business
architecture, service architecture, IT architecture
(including data, application and technology
architecture). As the part of the business architecture
the research emphasise the importance of processes,
as part of the business architecture. Services for
customers and even internal services are created
through processes.
3 MEASUREMENT MODEL
Enterprise Architecture approaches covers both
business and IT areas. These frameworks define
building components, relationships, that often
determined by a specific goal. In order the
emphasize the importance of business and IT
performance measurement, not only output
indicators, but hidden factors should be also
explored. Business indicators inherited in business
performance (Kellen, 2003), but fails to incorporate
IT performance.
The service can be seen as the aggregate of key
business functions. In order to be able to manage
and improve the value creation ability of the service
we have to control the process which provides the
service therefore measure the process.
The more sophisticated control we want over a
process, the more depth we should measure.
What can we gain from the measurement:
• know the current state of the services, therefore
know the service availability,
CLOSER 2011 - International Conference on Cloud Computing and Services Science
320