Enterprise Architecture – from Blueprints to Design Services
F. Lillehagen, D. Karlsen, H. G. Solheim, H. D. Jørgensen & H. Smith-Meyer
Troux Technologies AS, Lysaker, Norway
B. Elvesæter & Rolf Kenneth Rolfsen
SINTEF Information and Communication Technology, Oslo, Norway
ABSTRACT: This paper looks at the evolution of Enterprise Architecture modeling and use, since its birth in
the late 1970’s, then looks at the role of architectures in leading companies today, and finally developments to
add more value to past investments are presented and discussed. Until recently enterprise architecture projects
have been focused on business and systems information gathering and presentation, primarily providing
document services to managers. With new advances in active knowledge modeling and in integrated service
architectures many initiatives are started addressing all enterprise knowledge layers. The main purpose of
these initiatives is to integrate active knowledge models, improve view handling, provide model-driven usercomposed services, and support dynamic architecture driven solutions. Finally new approaches to innovative
design, whether the focus is on product, organization, process, system or new enterprises are presented.
Enterprise Architecture is not just about technology, so in the future we must include social and human aspects and integrate the architecture of the human mind and develop new forms of organizational structures.
1 INTRODUCTION
Enterprise Architecture (EA) can be defined as: a
simplified and aggregated representation of many
layers of enterprise knowledge, defining forms, features, roles and functions.
EA solutions should embrace architectures and
views of many enterprise knowledge spaces and dimensions, and must support many perspective
views. For IT people EA is a plan which shows the
main features and characteristics of the system that
will be analysed, justified and agreed before detailed
technical design can commence. Architectures
should be shared and discussed enterprise-wide between all users and stakeholders [7, 14].
Enterprise architecture is both a challenging and
confusing concept. For decades, construction industry has used architecture in the design and construction of all size buildings. Their “architecture” utilizes standard symbols, norms and rules that can be
recognized and understood by all members of their
industry for carrying out the construction work. The
systems engineering community by comparison has
never had the advantage of this type of “time-tested”
structure. Instead, since the beginning, many heterogeneous architecture proposals have been developed.
They are often overlapping approaches and the underlying concepts are not explicitly defined. Simi-
larities and differences between architectures can not
be perceived nor annotated by users. This creates
obstacles for its correct understanding in industry
and finally its acceptance and use.
Architectures of products, organizations, processes and systems, and operational solutions can not
at this point in time be adequately described, analyzed, used and managed by designers and engineers
as a coherent solution-space to meet their challenges.
1.1 Motivation and background
Enterprise architectures are today developed to give
managers a better understanding of the things the enterprise owns, operates, and produces so they can
make better business decisions. Likewise, enterprise
planners need architectures so they can understand
what they have, what they don’t have, and what they
need to have to fill the gaps. For IT managers the
features and functions to be provided by hardware
and software systems are often described in architecture models in such a way that the proposed systems
can be evaluated for how much they contribute to
increased effectiveness of operations. This information and knowledge is used to make better decisions
about how best to spend the IT budgets. Enterprise
architecture, considered as the foundation of enter-
prise systems, has emerged as a ‘tool’ to help stakeholders manage system engineering and IT change.
But EA is not only an IT issue, but influences business, organizations, products, and strategies.
In spite of all the great things that architectures
can provide to business managers, IT people, enterprise planners and stakeholders, there are still severe
shortcomings in the architecture modeling approaches and techniques. Many architecture frameworks have been developed to address different aspects of architecture development, but frameworks
can not support design and team-working [18].
1.2 EA blueprint approaches
Most current EA approaches are information gathering, filling in views that are used as blueprints to
document the legacy [10]. Examples of such frameworks are: Department of Defense Architecture
Framework (DoDAF) [1], Treasury Enterprise Architecture Framework [2], The Open Group Architectural Framework (TOGAF) [3], Generalized Enterprise Architecture and Methodology (GERAM)
[4] and the Zachman Framework [5]. Shortcomings
of these frameworks are that they tend to be documentation-heavy or process-heavy, they do not provide operational support; they do not provide customer knowledge services nor support knowledge
activation, and they are not suitable to smallmedium-enterprises (SMEs) [18].
2 THE EVOLUTION
enable new approaches to model-designed solutions
and model-configured systems [8, 18].
The support of mental, social and new organizational models complementing the technical models
and matching models in the human mind has long
been a challenge. The first attempts at modeling of
human behavior and our minds were made as early
as 1980 to help design good graphic user interfaces.
But we had to wait ten years for more scientific approaches, ref. Senge’s work on mental models [13].
Once mental and social models can be expressed
and represented, prototypes could be available
around 2008, we will be able to develop environments that support integrated design and learning.
2.1 The layered Enterprise Architecture
An important step was taken when the layered Enterprise Architecture was introduced (Lillehagen
2002). The layered architecture, introducing the active knowledge layer, was the basis for the IDEAS
Framework, which has later been adopted by
ATHENA and other projects [7].
Exec
tasks
BOA
EKA
Business
models
BPM
MUPS
EKA Services
The evolution of Enterprise Architecture (EA)
started with the publication of the Zachman Framework in 1978 explaining the complexity of enterprise information management. But the market
break-through came with the technology of Enterprise Modeling. A major market push was provided
by the US Congress in 1996 when it passed the
Klinger-Cohen Act demanding that all public organizations develop and document their enterprise
architecture as a prerequisite to invest in IT.
POPS
SW Repos. serivices
ICT
MDA
SOA
ASA
COTS
Figure 2: The layered Enterprise Architecture with the core
services, perspective views and many knowledge aspects at
each layer. Most abbreviations used should be well-known.
1978
1996
2005
2012
2020
Zachman
Klinger-
Knowledge
Social
Design &
Framework
Cohen Act
Models
Models
Learning
Figure 1: The evolution of Enterprise Architecture from 1978
until today, and the evolution for the next 15 years.
This year we are witnessing the introduction of
true active knowledge modeling and representation
at the heart of architecture models delivered as integrated modeling and execution platforms. This will
The layers are denoted the business operational
layer, the active knowledge layer and the ICT layer.
The active knowledge layer separates the increasingly dynamic business behavior from the software,
and supports user interactive involvement to change
the models and solutions at any time. The main contents of the layers are identified in figure 2.
The Business Operations layer (BOA) has a kernel of business process management and execution
capabilities, including business documents, rules and
protocol handling. This is complemented by a set of
standardized tasks and task patterns for performing
types of business and business models.
The Enterprise Knowledge layer has the POPS
language at its core supported by the EKA services,
then other EKA services are used to extend and
evolve the POPS language meta-models to cover
also the needs of other knowledge spaces.
2.2 Integrating Reference Models
There are some 20 industrial application area reference models being worked on with the purpose to
standardize data exchange and information flow,
Examples are models for supply-change management implementing the SCOR methodology, and for
configuration management and CMMI methodology.
The groups that develop reference models have little
or no contact, so the models will not be compliant
nor coherent. This is potentially a major source of
non-interoperability. These reference models must
be integrated in the EKA by appropriate metamodels and modeling languages as extensions to the
POPS language. This is illustrated by the six white
cylinders illustrating the EKA services in figure 2.
The EKA layer affords responsible users services to use Model-configured User-composed Platform Services (MUPS) to build and manage their
own services and solutions. The MUPS approach to
solutions development and management promises to
provide trust and confidence in use of services.
2.3 Operational Architectures
The AKM approach to modeling has since its inception been looking for ways of developing integrated
modeling and execution platforms supporting the
development of architectures as part of operational
solutions. The ATHENA project has focused on developing the Modeling Platform for Collaborative
Enterprises (MPCE). The MPCE is the first version
of such an integrated platform [16].
2.4 Design Support
With the introduction of integrated modeling and
execution platforms, the POPS language and the
EKA services, we will have a platform capable of
supporting design. To enable true design the MPCE
must support iterations, view handling, concurrent
alternatives and eventually parameter trees, and provide a setting for social models supporting teambuilding and knowledge-sharing.
3 THE ARCHITECTURE OF THE MIND
Recent research in modern sciences, such as phenomenology, evolutionary psychology and cognitive
neuroscience (Gazzaniga, 2002) indicate that knowl-
edge is managed mainly, if not totally, as views in
our mind [15]. This means that good user workplaces and working environments should support
powerful view handling and that we have to understand that complementary views, views containing
different perspectives of the same scene or artifact,
may be partly in our minds and partly in the visual
enterprise models. This also means that it is hard to
judge by looking at external views: what exactly is
knowledge. A view of data or information to one
person can be knowledge to another person. It all
depends on what complementary views you already
have access to in your mind. What we can say is that
in order for anybody to have knowledge at least
three complimentary views must be associated.
3.1 Knowledge Existence
Four zones of knowledge existence, perception and
representation are described and illustrated below.
(a) Horizon of Externalization – expert knowledge,
internal and tacit
(b) Horizon of Participation – participative knowledge, social and external
(c) Horizon of Comfort – sensed knowledge, our
real world precept
(d) Horizon of Reason – general acquired knowledge
d
c
b
Horizon of Extern
a
Horizon of Particip.
Horizon of comfort
Horizon of reason
Figure 3: Depicting the four horizons of knowledge existence
emphasizing the importance of proximity, medium and encoding language in representing knowledge.
Each zone is “delimited by a perceptive horizon
or border, defining knowledge existence, form and
value as dependent on proximity to action and
method of knowledge encoding and diffusion.” The
horizons define the edges of four knowledge spaces
of human minds as illustrated below. “Enterprises
have many knowledge spaces shared among many
humans; the innovative, the operational, the governing, the evolutionary, the strategic, the cultural, and
a multitude of smaller cascaded spaces.”
The four main enterprise knowledge spaces that
we are beginning to understand how to represent are
the innovative, the operational, the governing and
the evolutionary. Each of these spaces has four main
dimensions represented by different aspects depending on the purpose of the model. Different aspects of
the same dimensions and domains may be replicated
in many knowledge spaces.
a
Informal
knowledge
Derived
knowledge
Participative
knowledge
Situated
knowledge
Action
knowledge
Figure 4: Knowledge within the areas bounded by the four horizons of knowledge existence will vary in detail, form, actuality and timeliness. The closer to the scene of action the more
value and richness has the knowledge
The most valuable knowledge is the work generating
and generative knowledge. In figure 4 this is labelled Action knowledge (centre cylinder), The second most valuable is the knowledge acquired by participative actions. These two spaces are referred to
as “Situated knowledge”, and is the core knowledge
we capture and harness when people build teams and
develop shared active models. Situated knowledge is
mostly pragmatic logic, and semantics is primarily
added to provide identification and navigational
properties (nomenclature). Knowledge in the two
outer spaces can also be of great value, but in a business network focusing on core business: core or situated knowledge and related data are vital for success.
Situated knowledge has four intrinsic properties
of great importance for human perception, design
and learning. These are called reflection, recursion,
repetition and replication, and are explained in many
publications and papers [9].
(b) Accessibility—the market penetration and familiarity of the representation language throughout industry and among software professionals.
(c) Usability—the ease with which new users can
adopt and become proficient in the use of the
modeling and representation language
(d) Expressiveness—the ability of the representation language to capture unambiguous meaning,
logic and semantics relevant to a given domain
(e) Life cycle coverage—the scope of the representation language’s utility throughout the development life cycle (e.g., design, architecture, implementation, requirements, testing)
The evaluation criteria can be aggregated into a figure of merit for each domain language being considered and evaluated. If this was done for all modeling
tools and methodologies in the market, then very
few would qualify as appropriate EKM languages.
EKM languages and tools also have to be supported
by platforms closing the gaps between knowledge
modeling and management, and execution of work.
3.3 Models and Views
An active knowledge model can be much richer in
knowledge content than a model of real-world artifacts or products. Most knowledge models comprise
real-world objects and layers of active knowledge,
represented as structures and views. If knowledge
models are created and owned by a person, a designer-team or an innovative enterprise, then they
express the experiences, pragmatic logic and externalized tacit knowledge of leading practitioners.
Other knowledge models may be created and built
by participative persons or novelties that do not express the same multitude of views as they do not
own the core knowledge. The latter models will
naturally not be as rich in content, and the views
may not be as detailed.
Model ownership, practitioner tacit knowledge
externalization and pragmatic logic and experience
capture is key to active knowledge modeling.
3.4 View Orientation
3.2 The Knowledge Modeling Approach
In order to select the best Enterprise Knowledge
Modeling (EKM) approach for active model development, services enabling MUPS, and model execution, we need to define evaluation criteria.
The key criteria are:
(a) Processability—the ability of the representation
language to be efficiently processed by programs
tasked with inferring truth values and providing
interoperability.
Enterprise knowledge modeling is to a large extent
about developing or generating views of different
spaces, aspects and perspectives, and representing
them in a knowledge base for direct reuse by role
performers, or as a base for other derived views or
even as base for new models. There are many types
and kinds of views, and view ownership by roles.
Types of views can be defined based on various
principles and criteria, and be characterized and
form categories The need to structure views in a
logical way is apparent in order to be able to give
meaningful support to users. We have found that it is
useful and correct to differentiate between knowl-
edge defining, representing and presenting types of
views and kinds of views (role views) with the
meanings described below.
Knowledge defining views are of these four main
types and categories:
- Descriptive views
- Context views
- Functional views
- Content views
A descriptive view is a view that contains metadefinitions, a view that is used as language definition for other views. The reason for calling it a descriptive view rather than a meta-view is that industrial practitioners do not think in terms of meta- and
instance views. It is a lot easier for them to understand the term descriptive, in the meaning that one
view can act as a description of another view.
A context view is a view that is used to define the
context required by a functional view, to be able to
make the functional view fully specified.
A functional view is a view that is used to define
the details of a given function/activity as e.g. a process model that describes all the execution tasks and
GUIs of a process. Diagrams are other examples of
functional views
A content view is a view that contains operational
information and data – the domain data.
A type of view specifies the design, the purpose
and the behavior of a view, and must be supported
by a technical implementation.
Kinds of views are used to configure the types of
views according to a purpose or a role that is going
to use it. It could be a management view or a development view of the same enterprise object that use
the same type of view but looks different and shows
different content. The different content may be controlled by data access and/or by preferences, while
the view style may be controlled by style sheets or
other means.
The authors have worked to find scientific evidence and principles as a base to implement support
for improved view management, and will later be
reporting on their findings.
4 ENTERPRISE KNOWLEDGE SPACES
An enterprise has many Enterprise Knowledge
Spaces (EKS). These spaces will be implemented as
Enterprise Visual Scenes (EVS) by developing and
applying the Active Knowledge Modeling (AKM)
technology and realizing that we have to be trained
to think and work in multiple dimensions [8]. Visual
scenes will transform the World Wide Web into the
innovative, high-value multi-medium envisioned.
EVS, and model-driven working environments will
augment the capabilities of our senses and minds.
This will have great impact on the future of computing, and on most sciences by enabling human minds
to extend the use of the visual powers of the brain.
Currently less than 10% of the capacity of the lefthalf of the brain is activated by current learning and
training methods, and by our ways of working [15].
The four main types of knowledge spaces we
have to better understand and support for future enterprise design and development of visual scenes are
briefly defined as being:
ƒ The Innovative Space
ƒ The Operational Space
ƒ The Governance Space
ƒ The Evolutionary Space
These four types are each bounded by four major
knowledge dimensions. The description of the dimensions and their domains and types of views is
work ongoing among the authors, and will also be
reported on in future papers.
4.1 The Innovative Space
The Innovative space supports creative work (invention, reuse, design, implementation, validation and
learning). Its main concepts are the Enterprise
Knowledge Spaces (Industrial War-room principles)
implemented as Enterprise Visual Scenes, and implemented by the POPS (Process, Organization,
Product, System) core modeling language and methodologies. The innovative space enables and manages continuous change and evolution in product,
process, organizational and system structures of the
total Enterprise Architecture modeled and captured
in the Enterprise Knowledge Architecture (EKA).
4.2 The Operations Space
The Operations space supports business and work
operations (plan, assign, operate, generate, adapt,
extend, manage and terminate). Its main concepts
are the Continuous Business Solutions (CBS) generation and the Visual Enterprise Computing (VEC)
delivery approach, supported by the MUPS approach and multiple life-cycle management (adapting and extending the intelligent infrastructure), implemented as steps in the VEC delivery
methodology: PoC – EA - E I/ EAI - Solutions
Generation, User Deployment and Agility Management.
4.3 The Governance Space
The Governance space supports work progress
monitoring and regulatory compliance (govern,
monitor, measure, decide, change, experiment and
strategize). Its main concept is bubble-models, aggregation and propagation of parameters, attributes
and values, the “real-time enterprise”, implemented
as services to explore and investigate, to support decision-making, manage and govern value-creation in
parallel life-cycles, need for powerful analysis and
interaction techniques beyond balanced score-cards,
use of "value-metric charts" and other value matching techniques.
4.4 The Evolutionary Space
The Evolutionary space supports life-cycle performance management and improvement (analyze, configure, compare, align, transform, and manifest). Its
main concepts are continuous Collaborative Business Management (CBM) and Business Transformation, implemented as supporting many concurrent
Collaborative Business Solutions (CBS’s), concurrency is dependent on collaborative models and
EKA services.
A new form of networked organization is being
developed, defining service-teams owning certain
core services, like modeling, training and other categories of basic services. These teams will dynamically and continuously develop and deliver solution
services supported by adaptive and extensible EKA
structures created by executing EKA services.
If the strategy and need is to rapidly generate new
executable solutions, then first time modeling may
not costs so much, but if the strategy is to develop a
model supporting innovative work or transforming
business practices then the first time investment may
be huge. The pay-off should be comparative.
The first project to develop a knowledge model
may be a major investment, as it is important to
adopt a stepwise process and secure the widest possible involvement. The costs will also depend on
customer maturity in most technical, social and nontechnical areas. The second or third time a similar
modeling project is performed with the same or a
similar customer the amount of modeling will be
much less. Figure 5 illustrates that the amount of
modeling is dependent on the No. of users and their
intended use of the model, on the processes in focus
and on the purpose and ambition of modeling.
Models across many companies and different industries should be developed as and composed of
sub-models, so sub-models and views should be easily reused and adapted from model repositories.
5 USING ACTIVE KNOWLEDGE MODELS
The knowledge modeling approach is part of an
overall architecture development process, and it has
to involve the practitioners. Successful models,
models that have value to users actually depend on
involving practitioners in the modeling, and working
in teams. This requires a proven approach, coherent
methodologies, integrated modeling and execution
platforms, and capabilities to integrate the legacy.
5.1 The Extent of Modeling
Many people involved in enterprise modeling and
enterprise knowledge modeling (in our mind two
different disciplines) are skeptical to the extent of
work involved and the costs of modeling. With active knowledge modeling, based on the MPCE and
applying the MUPS approach, industry will find
modeling effective, beneficial and boundarybreaking.
No.of users
1st
Proces-
2nd
3rd
Purpose of model
Figure 5: The amount of modeling first time can be costly and
time-consuming, but less so than systems development, and the
benefits can be manifold.
5.2 The Importance of Customized Approaches and
Methodologies
Many modeling projects fail to deliver to expectations because the project is not properly anchored
in the organizations of the participants and the influencing stakeholders. There is not just one approach
to model an enterprise. The best approach evolves
with the knowledge of the other dimensions.
An example of a very successful architecture and
solution modeling project is the NOSA project on
Earth Science Research [13]. The approach taken in
this project is simple but has worked wonders. It is
therefore worth a study.
6 INTEGRATED ENTERPRISE SERVICE
ARCHITECTURES
In the ATHENA Integrated Project [16] partners are
developing an Integrated Enterprise Service Architecture (IESA) addressing the shortcomings of today’s enterprise architecture frameworks. The IESA
describes the technical architectures of an integrated
modeling and execution platform that allows us to
describe different views of an enterprise using active
models. These models can be explicitly associated
with software services, and not just static documents
and diagrams. This approach enables the enterprise
architecture to be an operational tool that can be
used to ensure consistency and manage dependencies and trade-offs between various concerns in the
business decision-making process.
6.1 Social and non-technical services
The ATHENA and INTEROP NoE [19] projects
have adopted a holistic perspective on interoperability based on the IDEAS framework. However, this
framework does not cover the non-technical aspects
of an enterprise. The framework defines layers of
technical architectures and views where each layer
focuses on particular activities, structures, and services. The framework suggests that interoperability
must be achieved on all layers within and between
cooperating enterprises.
• Interoperability at the business layer can be seen
as the organizational and operational ability to
cooperate and share knowledge and values.
• Interoperability at the knowledge layer can be
seen as the compatibility and the coherence of
common and private knowledge assets.
• Interoperability at the ICT layer can be seen as
the easy with which software components can be
exchanged, changed and developed at runtime.
(Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications Integrated Project) [16]. The work does not
represent the view of the European Commission or
the ATHENA consortium, and the authors are solely
responsible for the paper’s content.
9 REFERENCES
[1]
[2]
[3]
[4]
[5]
6.2 Model-generated workplaces
[6]
Model-generated workplace must be part of any
working environment for knowledge workers. The
ability of any architecture to model, generate, use,
monitor, manage and reuse workplaces in different
life-cycles is decisive for enterprise efficiency and
effectiveness and thus for return on investment.
7 CONCLUSIONS AND FUTURE WORK
[7]
[8]
[9]
[10]
Enterprise Architecture is developing from being a
complex mosaic of static information views to become an integrated Services Architecture supporting
mental and social models and model-driven design.
Modeling approaches, languages and methodologies, platforms and solutions are being worked on
to enable concurrent design and development.
The four main types of Enterprise Knowledge
Spaces and their implementation as visual scenes are
concepts that need to be further developed and validated. The description and expression of spatial dimensions and their domains and types and kinds of
views is work ongoing among the authors. The results are promising, and will be reported on in the
Athena project reports and papers in 2006.
The major contributions of our research are the
development of an active knowledge modeling technique for use in the development of operational and
evolving enterprise architectures and solutions.
8 ACKNOWLEDGEMENTS
The work published in this paper is partly funded by
the European Commission through the ATHENA IP
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
Department of Defense, "DoD Architecture Framework",
Department of Defense Architecture Framework Working Group, 2003.
Department of the Treasury, "Treasury Enterprise Architecture Framework, Version 1", Department of the Treasury, CIO Council, 2000.
The Open Group, "The Open Group arcitectural framework (TOGAF), Version 8", The Open Group, 2002.
http://www.opengroup.org/architecture/togaf8/
IFIP-IFAC, "GERAM: Generalized Enterprise Architecture and Methodology, Version 1.6.3", IFIP-IFAC Task
Force on Architectures for Enterprise Integration, 1999.
ZIFA, "The Zachman Institute for Framework Advancement", 2005. http://www.zifa.com
Lillehagen, F. & Krogstie, J. 2002, Active Knowledge
Models and Enterprise Knowledge Management, in Enterprise Inter- and intra-organizational integration, Kluwer Academic Publishers, Kosanke K. et al (ed.)
Lillehagen, Frank: From Enterprise Modeling to Enterprise Visual Scenes, paper presented at the CE 2003 conference, Madeira, July, 2003.
Lillehagen, Frank: “The Foundations of Active Knowledge Modeling technology”, paper presented at CE 2003,
Madeira, July, 2003.
Lillehagen, F, Enterprise Modelling and AKM technology, ICEIMT, Verdal 1997
Lillehagen, F. & Krogstie J. 2001. Active Knowledge
Models and Enterprise Knowledge Management,
ICEIMT workshop, Paris, December 2001
Karlsen. D, Lillehagen F. Solheim H.G and more: “ The
AKM Intelligent Infrastructure. Paper to be presented at
the CE 2004 conference in Beijing, July 27th 2004.
Senge, P. M.: The Fifth Discipline; The Art and Practice
of the Learning Organization., Doubleday Currency, New
York 1990.
Martin, James, N.: Using an Enterprise Architecture to
Assess the Societal Benefits of Earth Science Research,
paper to be presented at INCOSE, Rochester, July, 2005.
Martin, James, N.: Dr. Dissertation Proposal; Adding
Knowledge Modelling Capabilities to DODAF., Dissertation tbs to George Mason Univ., US, March 2005.
Gazzaniga, Michael: "Minds Past" Book buplished by
Barnes and Noble, see www.barnesandnoble.com,
ISBN 0520224868, published July 2004
ATHENA, "ATHENA Home Page", ATHENA IP, 2005.
http://www.athena-ip.org/
ATHENA A1, "D.A1.5.1: MCPE Specification, Version
1.0", ATHENA IP, Deliverable D.A1.5.1, August 2004.
https://www2.mycomputas.com/Team/Repository/Project
s/Project_204/Upload/Attachments/WPA1.5/DA_1_5_1_
MPCE_Specification_final.zip
ATHENA A1, "D.A1.1.2: "Stae-of-the-art in EM and
EAl", ATHENA IP, Deliverable. will be made avaialble
to the public soon.
[19] Interop NoE, "Interop NoE Home Page", Interop NoE,
2005. http://www.interop-noe.org/