Integrated Enterprise Service Architecture
B. Elvesæter & R. K. Rolfsen
SINTEF Information and Communication Technology, Oslo, Norway
F. Lillehagen & D. Karlsen
Troux Technologies AS, Lysaker, Norway
ABSTRACT: This paper presents the Integrated Enterprise Service Architecture (IESA). The IESA is a technical architecture that specifies an integrated modeling and execution platform that provides business operational support for modern enterprises structured as virtual organizations. The IESA specification serves as an
architectural blueprint for how to develop integrated, interoperable and evolving enterprise software systems
which combines principles from service-oriented architecture (SOA), enterprise knowledge architecture (EKA)
and model-generated workplaces (MGWs).
1 INTRODUCTION
Modern enterprises are constantly faced with expectations to change in order to meet their business objectives. Enterprises today need to adapt more
quickly to changes in the business and economic
market and is required to become more responsive to
customer needs. Although enterprises are heavily dependent on information communication technology
(ICT) solutions in their day-to-day business operations, the solutions are often inflexible and difficult to
adapt to meet the requirements of those changing enterprises [1]. The current ICT solution space suffers
badly from lack of interoperability. ICT systems are
not able to sufficiently exchange information, and
services offered by one system are not compatible
with other systems. The effect of non-interoperability
results in large budgets being spent on timeconsuming system integration tasks.
To meet these challenges, enterprises are today
looking into enterprise architectures. Enterprise architectures support enterprises in describing and
evolving their ICT infrastructure according to business and organizational needs. Enterprise architecture frameworks provide guidelines to separate and
document different concerns of an enterprise and its
ICT infrastructure into views pertinent to the stakeholders of the enterprise. Examples of such frameworks are: Department of Defense Architecture
Framework (DoD AF) [2], Treasury Enterprise Architecture Framework [3], The Open Group Architectural Framework (TOGAF) [4], Generalized Enterprise Architecture and Methodology (GERAM)
[5] and the Zachman Framework [6]. Shortcomings
of these frameworks are that they tend to be docu-
mentation-heavy or process-heavy; they do not provide operational support; and they are too extensive
for small and medium enterprises (SMEs) [7].
In the ATHENA Integrated Project [8] we are
developing an Integrated Enterprise Service Architecture (IESA) that address the shortcomings of today’s enterprise architecture frameworks. The IESA
is a technical architecture that specifies an integrated
modeling and execution platform. It allows us to describe different views of an enterprise as active
knowledge models (AKMs) that can be explicitly associated with software services, rather than 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.
2 INTEGRATED ENTERPRISE SERVICE
ARCHITECTURE
2.1 A holistic perspective on interoperability
The ATHENA project adopts a holistic perspective
on interoperability based on the IDEAS framework
[9]. The framework describes a 4-layered view of an
enterprise where each layer focuses on certain aspects of an enterprise (see Figure 1). The framework
suggests that interoperability must be achieved on all
layers between two cooperating enterprises.
•
•
Interoperability at the business layer can be seen
as the organizational and operational ability to
cooperate.
Interoperability at the knowledge layer can be
seen as the compatibility of the knowledge assets.
•
•
Knowledge assets are formalized representations
of enterprise knowledge (e.g. methodologies, enterprise models and metamodels) that can be interpreted by ICT systems.
Interoperability at the ICT layer can be seen as
the ability of ICT systems to exchange and make
use of information and services.
The semantic layer is concerned with capturing
and representing actual meaning of concepts to
promote understanding across the business,
knowledge and ICT layers.
Business Operational Architecture
Operations
Strategy
Governance
Laws, rules,
principles
Agreed norms
and practices
Procedures
and routines
Business
ontology
Enterprise
methodology
Enterprise
models
Enterprise
templates
Metamodels
and languages
Product
models
Reference
architectures
Semantics
Enterprise Knowledge Architecture (EKA)
Ontology
methodology
Reference
ontology
Information and Communication Technology (ICT) Architecture
Business and
user services
Infrastructure
services
EKA services
Ontology
tools
Software
platforms
Modeling
tools
Management
tools
Ontology
services
terprise. In this paper we argue that the two categories EKA services and MUP services need to be
mandatory in any IESA. EKA services (including ontology services) are required services for developing
and managing enterprise knowledge assets. MUP
services are required services for developing and
managing MGWs. Business services are here used to
denote services that provide business functionality
specific to different business domains. Other services
include e.g. administration and management services.
The outer ring represents the different user platforms that are consumers of the enterprise services.
Model-generated workplaces are working environments for the users involved in running the business
operations of the enterprise. The workplaces can be
tailored to meet the specific requirements of different
roles or persons, providing customized presentation
and interaction views. MGWs are typically implemented as Web portals. Rich clients are tools and
client applications that require rich graphical user interfaces (GUIs) not supported by Web browser technologies. Modeling tools (including ontology tools)
are examples of tools that require rich GUI capabilities. The MGWs should have functionality that allows rich clients to be invoked.
Figure 1. 4-layered view of an enterprise
2.2 Technical architecture
The Integrated Enterprise Service Architecture (IESA) is a technical architecture that specifies enterprise services that are needed to support the semantic
dimension and the knowledge and business layer of
an enterprise, and a service infrastructure in which
these enterprise services can interoperate.
The architecture combines principles from serviceoriented architecture (SOA), enterprise knowledge
architecture (EKA) and model-generated workplaces
(MGWs). The SOA specifies a service infrastructure
where services can be described, published, discovered and invoked over a network. The EKA bridges
the gap between any knowledge layers by describing
the enterprise logic as metamodels, and by capturing
and integrating views of the enterprise knowledge
spaces and their dimensions. MGWs are modelconfigured and user-composable (MUP) workplaces
that enable persons to interact with the enterprise
services.
Figure 2 illustrates the concept of the IESA. At
the heart of the IESA we find the service infrastructure. It provides basic middleware services that are
common to all networked enterprises. The service infrastructure needs to maximize and utilize wellknown and proven Web and Internet standards and
protocols.
The middle ring represents the network-visible
and shareable enterprise services that are required to
support the knowledge and business layers of an en-
Figure 2. Overview of the IESA
Two important results of the ATHENA project contribute to the development of the IESA. The
ATHENA Modeling Platform for Collaborative Enterprises (MPCE) [10] specifies the EKA and MUP
services, and the modeling tools and MGW capabilities. The ATHENA Integrated Execution Infrastructure (IEI) [11] specifies the service infrastructure.
2.3 The service infrastructure
The service infrastructure of the IESA specifies the
ICT backbone common to all networked enterprises.
This will be implemented by the ATHENA Integrated Execution Infrastructure (IEI) which is a generic service-oriented execution infrastructure that
supports different execution platforms. It provides an
execution environment for deploying and running the
enterprise services. The IEI builds upon the state of
•
•
•
The service interoperability management layer
provides a standardized way of accessing and using services. This layer will provide wrapper
functionality for deploying services using Web
service technology [12].
The service evaluation and negotiation layer
evaluates and negotiates incoming service requests. It makes use of the underlying infrastructure services and directs requests to the appropriate service deployed on an execution platform.
The execution environment layer consists of the
concrete technology and vendor-specific platforms which runs the services implemented in
software.
The service interconnection bus provides middleware services for integrating the various execution platforms.
Tools (as Rich Clients)
Modeling Tools
(& Ontology Tools)
MGWs (as Web Portals)
Other
Tools
Model-Generated
Web User Interfaces
Rich client
Web portal
Web site
Customers
•
or deployment time, adds dynamism and flexibility
required by modern enterprises. The SOA represents
the current best-practice in how to develop new
software services and how to recondition legacy applications in order to design interoperable software
systems.
The service concept applies equally well to the
business as it does to software applications. Services
provide the ‘units of business’ that represent value
propositions within a value chain or within business
processes. Fine-grained services can be used in the
composition of higher-level business services required by different business use cases. A service is
invoked dynamically when required, allowing providers to continuously improve their service and users to
select the best available service at any one time.
Figure 4 and Figure 5 illustrate the differences between current application systems and modern service-oriented systems. Consider a value chain consisting of n different enterprises and corresponding
software systems that together realize different software services to various customers.
Application
clients
the art, but aims to provide new innovative solutions
in combining model-driven architectures and adaptive
architectures. Figure 3 shows a technical view of the
service infrastructure. The IEI is structured as a set
of layers:
Web site
Service Evaluation & Negotiation
EKA Services
(& Ontology
Services)
MUP
Services
Execution
Environment 1
Execution
Environment N
Service Interconnection Bus
Other
Services
Infrastructure
Services
Registry
Services
Repository
Services
ATHENA Integrated Execution Infrastructure
Integrated
Enterprise
Service
Architecture
a
1
b
1
c
r
s
t
y1
n
z
y2
External
System
Legacy
System
Commercialoff-the-shelf
x Service providing functionality ‘x’
Figure 3. IESA service infrastructure
Interoperability issues
Service dependency
Application dependency
(compile & deployment time)
Figure 4. Application system architecture
In application system architectures (Figure 4) different customer services are typically implemented in
segmented application silos, even though the same
organizations participate in the value chain. The silo
effect introduces several system weaknesses with respect to interoperability:
•
2.4 SOA and business services
Service-oriented architecture (SOA) is an evolution
of the application and component-based architecture
by adding support to develop loosely coupled software systems. The notion of late binding where services are referred at run-time, rather than at compile
n
Legend
Application w/embedded services
The IEI will utilize proven Web service standards
such as WSDL [13], SOAP [14] and UDDI [15] together with semantic annotation to ensure service interoperability. In addition, a wide range of infrastructure services are planned and described in [11].
Examples of the planned services are service registry,
model repository, service discovery, adaptive and
dynamic composition of services, semantic search
and matchmaking, and peer-to-peer business resource management.
…
Service Interoperability Management
Application servers
…
Business
Services
Enterprises in value chain
ATHENA Integrated Execution Infrastructure
•
Business functionality is embedded in applications that contain several compile and deployment time dependencies. This inflexibility forces
the same organization to implement the same
functionality into different and non-interoperable
applications (illustrated with enterprise n providing functionality y1 and y2).
Information needs to be duplicated and are not
consistent across the application systems.
•
•
Interoperability issues are surfaced to the customers that have to use different application clients or different ‘portions’ of a Web portal to access the non-interoperable set of services
provided by the value chain.
The value chain is rigid and does not facilitate
easy swapping of business partners.
Rich
client
Service
consumers
Usercomposable
service layer
Shared and
network-visible
service layer
r
a
Integrated Web portal
y
b
r
a
b
c
s
s
y
t
t
c
x
y
z
z
z
Service
providers
1
Legend
Business service
x providing
functionality ‘x’
Service
composition
…
n
m
will support the integration of the four knowledge
spaces; process, organization, product and software
system.
The EKA principles dictate that the IESA must
support the separation of concern between model
representations of knowledge assets and the concepts, defined in metamodels, to capture and describe
those knowledge assets. Thus, in addition to business
services that provide ‘units of business’ required by
business operations, an IESA must also provide EKA
services which allows enterprises to develop, maintain and evolve models and metamodels that fits the
actual business operations. Examples of EKA services are views handling, models and sub-model
management, metamodels and metamodels structures, and type-hierarchies and type management.
A couple of examples showing the benefits of
EKA services are illustrated Figure 6 and Figure 7.
SM
SMM
Service dependency
Traceability through layers
[used by |
composed of |
provided by]
Integrated
BPMM1 & SCMM
z
SCM
SCMM
r
a
Metamodel
Integration
Service
y
Figure 5. Service-oriented system architecture
The service-oriented system architecture (Figure 5)
addresses these problems:
•
•
•
•
a
BPMM1
BPM1
The enterprise knowledge architecture (EKA)
bridges the gap between any knowledge layers by describing the enterprise logic as metamodels, and by
capturing and integrating views of the enterprise
knowledge spaces and their dimensions. The EKA
constitutes the logical centre of the enterprise, and
any metamodel will be an integral part of it. Knowledge management is performed by managing and
governing metadata in the various EKA structures.
All kinds of models can be consistently integrated by
aligning their metamodels to be based on common
structures and type-hierarchies. The enterprise
knowledge architecture being develop in ATHENA
y
z
Integrated
PBM1 & SCM
Legend
SM: Service Model
SMM: Service Metamodel
SCM: Service Composition Model
SCCM: Service Composition Metamodel
BPM: Business Process Model
BPMM: Business Process Metamodel
a r y
Model of business service
Model of service composition
Model of business process
Model of information object
Model – metamodel relationship
Reference to other metamodel
Figure 6. EKA service for metamodel integration
Figure 6 illustrates an EKA service for metamodel
integration that combines metamodels for modeling
services, service compositions and business processes, allowing us to create integrated model where
relationships between business processes and services
can be described.
BPMM12 Mapping
BPMM1
BPM1
2.5 EKA and EKA services
r
b
a
b
The application silos are broken up into shared
and network-visible services that enable better interoperability.
Services are autonomous and can be used by
other services so that information can be shared
across different business networks.
Services can be composed to fit the needs of the
users. This enables support for building integrated Web portals to support the businesses.
Since different clients access the same set of
shared services, interoperability issues are no
longer surfaced to the users.
Flexibility in choosing the service provider (illustrated with functionality z being offered by provider n and m), which enables support for more
dynamic businesses.
a
BPMM2
BPM2
Metamodel
Mapping
Service
a
b
c
b
Partial View1
Partial View2
a
c
b
View
Handling
Service
Integrated View1
a
c
b
Integrated View2
Legend
BPM: Business Process Model
BPMM: Business Process Metamodel
Model – metamodel relationship
Reference to other metamodel
Model of business process
Model of information object
Model of business process
Model of information object
Figure 7. Metamodel mapping and view handling EKA services
based on the same knowledge models and therefore
ensuring information consistency. The models of the
MGWs are themselves knowledge models. Thus
modeling tools must also provide facilities for visual
modeling of MGWs in the IESA. MGWs will typically be implemented as Web portals. An IESA requires MUP services to specify Web elements that
can be generated in such portals.
Web
Gantt
Chart
Class5
*
Class3
*
Class
Class4
0..1
*
Class2
*
*
AggregationPrefixClass1
Class1
Gantt
Chart
Model
2.6 Model-generated workplaces and MUP services
Knowledge layer
MGW
A model-generated workplace (MGW) is a working
environment for the business users involved in running the business operations of the enterprise. It is a
user platform that provides the graphical front-end
for human users to interact with software services
supporting their day-to-day business activities.
The workplace can be tailored to meet the specific
requirements of different roles or persons within an
enterprise, providing customized presentation and interaction views. This is achieved through modelconfigured and user-composable (MUP) services.
These are services that make use of knowledge models to generate business-oriented and context-aware
graphical user interfaces specific to the roles defined
within an enterprise.
Gantt
charts
Web
forms
Graphs Reports
…
MUP
Service
MUP
Service
MUP
Service
MUP
Service
MUP
services
BPMM2
Integrated
BPMM 1 & SCMM
SM
SMM
z
BPM2
b
SCM
a
SCMM
r
a
a
r
c
y
y
Partial View2
b
z
a
Integrated
PBM 1 & SCM
Knowledge
models
c
b
Integrated View2
Figure 8. Operational view of a model-generated workplace
Figure 8 depicts an operational view of a modelgenerated workplace, exemplified with two different
persons accessing ICT services and knowledge assets
using different model-generated views, e.g. Gantt
charts for project monitoring, web forms for activity
reporting, bar graphs visualizing budget spending,
and Web documents reporting on activities. The different views may reflect the same knowledge asset in
a different form or manner that best suit the role or
person using that asset in a given business context.
Information represented in the different views is
Web
Form
Generation
Service
XSLT
Figure 7 illustrates the use of EKA services for
metamodel mapping and view handling. The metamodels mapping service is used to map two different
metamodels of business process models. This mapping could be used in exchanging knowledge models
between two different business process modeling
tools. A view handling service can be used to manage
different views of the same or overlapping business
process models.
A full description of the planned EKA services of
the IESA is given in [10]. In addition to the EKA
services we also need modeling tools that provide
users (knowledge engineers) facilities for visual modeling of enterprise models, metamodels and business
ontology.
Web Template for
Gantt Charts
Model
Mapping
Service
Retrieve
Project
Data
Service
Project
Organization
Model
Import
Model
Data
Service
Legend
Business service
EKA service
MUP service
Figure 9. Example of generation scenario for MGWs
Figure 9 illustrates an example of how MUP, EKA
and business services are combined in developing
MGWs. A business service is used to retrieve project
data. The project data is imported into the knowledge space of the IESA using the import model data
service which creates a project organization model.
The data contained in the project organization model
is mapped to a Gantt chart model using the model
mapping service. The Gantt chart model is used by
the Web form generation service to generate the Web
Gantt chart according to a Web template for Gantt
charts.
2.7 Interoperability discussion
In the integrated enterprise service architecture approach interoperability can be achieved on the
knowledge layer enabling business operational interoperability. This is achieved through the use of EKA
services that allow us to align different knowledge
representations through their metamodels. The EKA
represents a middle-out approach where enterprises
should start developing their knowledge metamodels
and aligning them to metamodels mandated by legislations and metamodels prescribed by business partners. This approach needs to be reflected in other
model-driven development (MDD) approaches focusing on developing the software required by modern enterprises.
Figure 10 summarizes the above discussion and illustrates an operational view of the integrated enterprise service architecture with business, EKA and
MUP services.
Modeling Tools
Class3
*
Cl ass4
0..1
*
Class2
*
Aggregat*ionPrefixClass1
Cl ass1
Gantt
Chart
Model
t
c
EKA service
MUP service
z
f
h
y
s
a
Knowledge layer
• Models of enterprise knowledge
• Metamodels and ontology
describing syntax and
semantics of models
• Models of MGWs
• Models of services and
service compositions
Legend
Business service
Import
Model
Data
Service
e
z
x
Graphs Reports
…
Project
Organization
Model
Retrieve
Project
Data
Service
r
Web
forms
Web Template for
Gantt Charts
Model
Mapping
Service
b
Gantt
charts
XSLT
Web
Form
Generation
Service
Cl ass5
*
Cl ass
4 ACKNOWLEDGEMENTS
MGWs (as Web Portals)
• Modeling of enterprise models
• Modeling of metamodels
• Modeling of business ontology
• Modeling of MGWs
•…
g
i
Enterprise services
• Business services
The work published in this paper is partly funded by
the European Commission through the ATHENA IP
(Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications Integrated Project) [8]. 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.
• EKA services
• MUP services
Legend
5 REFERENCES
Business service
EKA service
1
…
n
m
k
s
[1]
MUP service
Figure 10. IESA with business, EKA and MUP services
[2]
3 CONCLUSIONS AND FUTURE WORK
[3]
In this paper we argue that a service-oriented architecture (SOA) is an appropriate approach to develop,
change, and maintain ICT systems in and between
enterprises. Suchlike architecture approaches enable
better interoperability through autonomous, shared
and network-visible services that can be used in
composition of higher-level services meeting user
and business needs.
Our Integrated Enterprise Service Architecture
(IESA) is a technical SOA that specifies an integrated modeling and execution platform. We argue
for two enterprise service categories to be mandatory
in any IESA. EKA services are required services for
developing and managing enterprise knowledge assets, while MUP services are required in order to develop and manage model-generated workplaces
(MGWs.) These services enable enterprise architectures to be operational business tools, and development and deployment environments for MGWs.
Business operational interoperability is achieved on
the knowledge layer through the use of EKA services
that allow us to align different knowledge representations through their metamodels.
Future work includes finalizing the specification of
the EKA, MUP and infrastructure services that constitute the core components of the IESA. We intend
to implement these services as Web services and thus
need to specify the interfaces and the messages these
services will exchange. Work on developing a methodology for specifying interoperable Web services
[16] will help us in this regard. This methodology
will also incorporate model-driven architecture principles as described in [17]. The implementation of the
IESA will be tested and validated in user scenarios
defined in the ATHENA project.
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
D. P. Truex, R. Baskerville, and H. Klein, "Growing Systems in Emergent Organizations", Communications of
the ACM, vol. 42, no. 8, pp. 117-123, 1999.
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
ATHENA, "D.A1.1.2: State-of-the-art in EM and EAI",
ATHENA IP, Deliverable D.A1.1.2, Will be made available to the public soon (2005).
ATHENA, "ATHENA Public Web Site", ATHENA IP,
2005. http://www.athena-ip.org/
IDEAS, "IDEAS Home Page", IDEAS, 2005.
http://www.ideas-roadmap.net/
ATHENA, "D.A1.5.1: MCPE Specification, Version
1.0", ATHENA IP, Deliverable D.A1.5.1, August 2004.
ATHENA, "D.A6.1: Specification of a Basic Architecture Reference Model", ATHENA IP, Deliverable
D.A6.1, March 2005.
W3C, "Web Services Activity", 2005.
http://www.w3.org/2002/ws/
W3C, "Web Services Description Language (WSDL),
Version 1.1", W3C Note, March 15 2001.
http://www.w3.org/TR/wsdl
W3C, "Simple Object Access Protocol (SOAP), Version
1.2", W3C Recommendation, June 24 2003.
http://www.w3.org/TR/soap12-part1/
OASIS, "Universal Description, Discovery and Integration (UDDI) Specifications", 2005.
http://www.uddi.org/specification.html
ATHENA, "D.A5.2: Model and Specification of service
description and usage as well as advanced concepts",
ATHENA IP, Deliverable D.A5.2, Work in progress
(2005).
B. Elvesæter, A. Hahn, A.-J. Berre, and T. Neple, "Towards an Interoperability Framework for Model-Driven
Development of Software Systems", in Proc. of the INTEROP-ESA 2005, Geneva, Switzerland, 2005.