ABSTRACT: This paper presents the Integrated Enterprise Service Architecture ... architectural blueprint for how to develop integrated, interoperable and evolving enterprise software systems .... The service interoperability management layer.
Next Generation Concurrent Engineering - M. Sobolewski & P. Ghodous (eds) © 2005 ISPE, Inc., ISBN 0-9768246-0-4
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
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.
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 noninteroperability results in large budgets being spent on time-consuming 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-
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. • • 129
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 as-
• •
sets. 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.
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.
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
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 service-oriented 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 model-configured 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 130
the enterprise services. The IEI builds upon the state of 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:
Tools (as Rich Clients) Modeling Tools (& Ontology Tools)
MGWs (as Web Portals) Other Tools
Model-Generated Web User Interfaces
ATHENA Integrated Execution Infrastructure Service Interoperability Management
Other Services
Service Evaluation & Negotiation
Infrastructure Services
EKA Services (& Ontology Services)
MUP Services
Execution Environment 1
Execution Environment N
Service Interconnection Bus
Repository Services
ATHENA Integrated Execution Infrastructure Integrated Enterprise Service Architecture
a
1
Registry Services
Web portal Web site
Web site
b
1 c
Application servers …
Business Services
Rich client
r
s t
y1
n
z
y2 External System
Legacy System
Customers
•
…
•
Enterprises in value chain
•
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.
Application clients
•
vices are referred at run-time, rather than at compile 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.
n
Commercialoff-the-shelf
Legend Application w/embedded services
Figure 3. IESA service infrastructure
x Service providing functionality ‘x’
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.
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 ser131
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
structures and type-hierarchies. The enterprise knowledge architecture being develop in ATHENA 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.
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
SM
Service dependency
SMM
Traceability through layers [used by | composed of | provided by] SCM
Figure 5. Service-oriented system architecture
• •
•
SCMM r
a
Metamodel Integration Service
y
a
The service-oriented system architecture (Figure 5) addresses these problems: •
Integrated BPMM 1 & SCMM
z
BPM1
a
BPMM1
y
b
a
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.
r
z
Integrated PBM 1 & SCM
b 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
2.5 EKA and EKA services
BPM1
BPM 2
Metamodel Mapping Service
a
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
BPMM2
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
132
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.
ferent views is 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
Class2
Class3
* Class4
* *
0..1
* AggregationPrefixClass1 Class1
Gantt Chart Model
2.6 Model-generated workplaces and MUP services
MGW Knowledge layer
Web forms
Retrieve Project Data Service
MUP Service
MUP Service
SMM
z BPM2 b
a
SCMM r
a
a
r
c
y
y
Partial View2
b
z a
Integrated PBM1 & SCM
Business service EKA service MUP service
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.
BPMM2
SM
Legend
2.7 Interoperability discussion
MUP services
Integrated BPMM 1 & SCMM
SCM
Import Model Data Service
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.
Graphs Reports
MUP Service
Project Organization Model
Figure 9. Example of generation scenario for MGWs
…
MUP Service
Web Template for Gantt Charts
Model Mapping Service
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 model-configured 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 Form Generation Service
XSLT
Class5 * Class
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 dif133
Modeling Tools
Cl as s3
* Cl as s4
0..1
* Class2
*
* Aggregat ionP refi xCl ass1 Cl ass1
Gantt Chart Model
t
a
c
Knowledge layer
Business service EKA service MUP service
z
f
h
y
s
e
z
x
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.
• Models of enterprise knowledge • Metamodels and ontology describing syntax and semantics of models • Models of MGWs • Models of services and service compositions
Legend
Import Model Data Service
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
Class5 * Class
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
• EKA services • MUP services
5 REFERENCES
Legend Business service
[1]
EKA service 1
…
n
m
k
s
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]
134
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.
