Model-Generated Workplaces: An Interoperability
Approach
R. K. Rolfsen1, D. Boell2, C. Pronios3, T. Knothe2, M. Anastasiou3, B. Elvesæter1
and H. Jørgensen4
1
2
3
4
SINTEF ICT, Forskningsveien 1, N-0314 OSLO, Norway
{rolf.k.rolfsen, brian.elvesater}@sintef.no
Fraunhofer IPK Berlin, Corporate Management, Pascalstrasse 8-9, 10587, Berlin,
Germany
{dieter.boell, thomas.knothe}@ipk.fhg.de
INTRACOM TELECOM, 19,7 Km Markopoulo Ave., 19002, Peania Athens, Greece
{hpro, mana}@intracom.gr
AKM AS, Vollsveien 9, N-1327, Lysaker, Norway
h.jorgensen@akmodeling.com
Abstract. This paper presents an approach to using model-generated workplaces (MGWP)
in tandem with service-oriented architectures in order to meet interoperability needs in a
corporate environment. More specifically, the interoperability study and research undertaken
is based on a use case scenario related to the process of product portfolio management
(PPM) in a large enterprise of the Telecommunication sector, INTRACOM Telecom.
Starting from enterprise modelling constructs, Web-based workplaces are created that offer
navigation and work views to the end user, supporting all his operational tasks as depicted in
the enterprise model. Interaction with enterprise information repositories is facilitated via an
underlying service-oriented architecture.
1 Introduction
A model-generated workplace (MGWP) 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 operation views. This
is achieved through model-configured and user-composable services (MUPS).
These services make use of knowledge models to generate business-oriented and
context-aware graphical user interfaces (Jørgensen et al., 2004) (Elvesæter et al., 2005).
2
R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
This paper presents an approach of using model generated workplaces
(MGWP) in tandem with service-oriented architectures in order to meet the
interoperability needs in a corporate environment. More specifically, the
interoperability study and research undertaken are based on a use case scenario
related to the process of product portfolio management (PPM) in a large enterprise
of the Telecommunication sector, INTRACOM Telecom. Starting from enterprise
modelling constructs, Web-based workplaces are created that offer navigation and
work views to the end user, supporting all his operational tasks as depicted in the
enterprise model. Interaction with enterprise information repositories is facilitated
via an underlying service-oriented architecture. This work has been performed
within the context of the IST integrated project ATHENA (ATHENA, 2004).
The paper is structured as follows: In section 1, the scenario of PPM is briefly
described, while section 2 summarizes the interoperability needs in the scenario
and the interoperability issues that the specific pilot addresses. The technical
solution is presented in section 4 including the infrastructure used in INTRACOM
Telecom and the approach and design of MGWP. Section 5 concludes the paper
with the challenges that need to be dealt with as part of future work of this research
effort.
2 Use Case Scenario: Product Portfolio Management
The PPM is a process involving decisions made at different levels, where the
company’s active products list is constantly updated and revised. Therefore, new
products are evaluated, selected and prioritized; existing ones may be accelerated,
killed or reprioritized; and resources are allocated and reallocated to the active
development projects. The objective is to allocate resources in a way to maximize
sales and profits and minimize risks, as well as to achieve balance of development
projects taking under consideration risks, technology and market trends.
The PPM is of significant importance especially to a large enterprise with many
business units and complex products, the development of which requires the
collaboration of many different engineering teams inside the same business unit or
corporate environment, as well as within a business network of collaborative
enterprise. In this study, the focus is on intra-enterprise level.
The PPM involves many business processes (new product development,
product management, supply chain management), and many actors at various
positions that perform different tasks from strategic level (e.g. Business Unit
Manager, Sector Manager), and tactical level (Product Manager, Project Manager)
to operational level (Team Leader, Engineer).
Within this scenario, we focus on the Product Management and on supporting
the role of the Product Manager. At INTRACOM Telecom the objective of Product
Management is to identify the need for a product/product-line, justify the inclusion
of a product/product-line in the company solutions and control the execution of the
development roadmap. In doing so, it needs to stand between the product
development and manufacturing departments as well as the sales, technical support
and public relations ones. The Product Manager is assigned to a product or product
family and is responsible for developing or overseeing all aspects of the product
Model-Generated Workplaces: An Interoperability Approach
3
including product definition, product development, product launch, current product
management, and product phase-out.
3 Interoperability Needs and Expectations
The analysis of the interoperability needs within the PPM scenario has revealed
several problems as these are perceived by its actors in their daily work.
An important observation is that currently the communication among the
different product portfolios and the collaboration of the various teams is
insufficient. Collaborative work needs to be supported by providing actors with the
tools in addition to information and communication support they need to efficiently
perform their work through a single point of entry (workplaces).
It is worth noting that the PPM scenario reveals interoperability needs for
supporting ad-hoc and event driven collaboration activities as opposed to standard
workflow ones, when events and process variables are well defined.
Furthermore, the efficient performance of the product portfolio process requires
federated information coming from marketing, product development execution, as
well as from the product life cycle management. It is a knowledge intensive
process, as it presupposes a very good and holistic view of the enterprise: strategy
and objectives, skills and competences, as well as experience coming from
previous development projects.
Decision-making activities on various levels of the enterprise are poorly
supported due to lack of information integration from various ICT systems, as well
as timely information updates. The relevant data and information needed by PPM
participants for performing their tasks and make accurate decisions are spread
across several systems. Figure 1 presents a high-level overview of the as-is
situation of the systems and functions needed and used by a set of PPM actors.
Quality Engineer
Team Manager
Product Development Manager
iKnow
ERP System
Warehouse
Management
Project
Planning
Project
Finance
HR
Management
Document
Management
Marketing
Intelligence
SIS
Product Issues
Management
Sales Data
Contract
Management
Production
Planning
ADARES
Product Issues
Management
Business Development
Manager
Product Manager
Fig. 1. A high-level overview of the as-is situation.
4
R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
In addition to the above, cohesion of the decision-making activities with strategic
plans and operational results needs to be supported.
Based on this analysis, we have identified several interoperability issues on all
three levels of the enterprise: Business, Knowledge and ICT levels. The pilot
implementation in ATHENA focused on the following interoperability issues:
1. Link decision-making activities with strategic plans, development and
operational results.
2. Enterprise description and knowledge management in various aspects and
dimensions (organization, role, decision, process, product, system).
3. Product related knowledge sharing within and between product life cycle
phases.
4. Provision of (near) real-time aggregated views of key business information
existing in legacy systems exploiting to the full extend the capabilities of
existing ICT systems.
5. Ability of integrated applications execution via a single point of entry.
4 Technical Solution
It is clear that the requirements presented have, over time, led to various system
architecture implementations in an effort to reach some level of interoperability.
Service-oriented architectures are just entering their maturity phase and can
provide a solid and elegant solution. Of course, investing in the adoption and
implementation of a service-oriented architecture across business boundaries is a
major undertaking that has been shown to be beyond the capabilities of most
present-day enterprises, which have to continuously support and upgrade their
current (legacy) system architectures used in their day-to-day operations. The
situation is more accentuated in cases where the evolution of said systems was not
undertaken under the auspices of a central IT systems planning entity, which could
mediate between conflicting system requirements.
In this respect, it would be of great utility if systems’ interoperability could be
achieved without interfering with the operation of existing systems and the
enterprise’s core business. The aim would to incrementally position existing
systems in a proper service-oriented architecture framework and impose “order”
without resorting to full-scale enterprise system replacement which might be
unattainable for a multitude of reasons.
Figure 2 illustrate the salient differences between current application systems
and modern service-oriented systems. Consider a value chain consisting of n
different enterprises (or divisions of) and corresponding software systems that
together realize different software services to various customers.
In application system architectures 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:
Model-Generated Workplaces: An Interoperability Approach
5
• Business functionality is embedded in applications coupled by several compile
and deployment time dependencies. This inflexibility forces an organization to
implement the same functionality in different and non-interoperable
applications (enterprise n providing functionality y1 and y2).
• Information duplication and inconsistency across application systems.
• Interoperability issues are visible to customers forced to use different
application clients or different ‘portions’ of a Web portal to access the noninteroperable set of services provided by the value chain.
• Rigid value chain hinders introduction and exchange of business partners.
Web portal
Web site
Customers
Application
clients
Rich client
Web site
Rich
client
Service
consumers
Integrated Web portal
Workstation
a
1
b
1
r
s
t
y1
n
y2
z
Legend
Application w/embedded services
x Service providing functionality ‘x’
Interoperability issues
Service dependency
…
Application servers
…
c
n
Enterprises in value chain
Workstation
Usercomposable
service layer
Shared and
network-visible
service layer
r
a
a
y
b
r
b
c
s
s
y
t
t
c
x
y
z
z
z
Service
providers
Server
1
Legend
Business service
x providing
functionality ‘x’
Service
composition
Server
…
Server
n
Server
m
Service dependency
Traceability through layers
[used by |
composed of |
provided by]
Application dependency
(compile & deployment time)
Fig. 2. System architecture: application (to the left) and service-oriented (to the right)
The service-oriented system architecture addresses these problems:
•
•
•
•
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 visible 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.
Since this architecture was designed to facilitate interoperability, it is clearly a
suitable approach to fulfilling the PPM use case requirements, but the problem of
actually designing and implementing the appropriate service layers over existing
systems is by no means trivial.
6
R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
4.1 INTRACOM Telecom Infrastructure
The current IT infrastructure relevant to the PPM case is shown in the figure 3. The
lower (Legacy systems) layer encompasses the existing IT systems, while the next
two layers contain the services that expose legacy data to the service-oriented
architecture. Legacy systems are built on various platforms (Windows, Unix),
using different technologies, of different levels of maturity and are operated by
different entities. Since these systems cannot be replaced in the short to medium
term, the design of the service layers based on a model-driven approach may be the
key to their (an otherwise unattainable) integration in an architecture satisfying the
interoperability needs identified earlier. However, a model-driven approach is a
top-down process that will eventually need to encompass existing functionality in
the bottom layer, functionality which cannot be re-implemented.
Usercomposable
Service
Layer
Java + Apachee
MS Win Server 2K3
Athena Server
Athena Server
Netweaver
Web Services
Service Orchestration
NET Web Services
Web Services
Web Services
MS IIS + ASP.NET
Apachee + Axis
Netweaver 2004 Suite
MS SQL Server 2000
mySQL 5.1
MS SQL Server 2000
MS Win Server 2K3
MS Win Server 2K3
MS Win Server 2K3
Legacy Proxy
Web Server
Netweaver
Shared &
Networkvisible
Service
Layer
Legacy
Systems
REMEDY Platform
mySAP 2004
Oracle DB Server 9.1
Oracle DB Server 9.1
MS SQL Server 2000
MS Windows 2K Server
MS Windows 2000 Server
MS Windows 2003 Server
Product Performance
ERP
iKNOW
Web server Legacy Proxy
ADARES Application
Iknow
ERP
Document Repository
Product
Performance
Other
Legacy
iKNOW app + iVIEWS
SAP Enterprise Portal
Fig. 3. INTRACOM Telecom Infrastructures and Repositories
The infrastructure shown, both legacy systems and systems specifically created
during this study (Athena-project, bieze shaded), instantiates a service-oriented
architecture that is used by the systems instantiating the model generated
workplaces and provides to them the requested information.
4.2 Model-Generated Workplaces
Figure 4 depicts an operational view of a model-generated 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 based on the same knowledge models and therefore ensuring
information consistency. MGWP will typically be implemented as Web portals and
MUPS specify Web elements that can be generated in such portals.
Knowledge layer
MGWP
Model-Generated Workplaces: An Interoperability Approach
Gantt
charts
Web
forms
Graphs
7
Reports
…
MUP
Service
MUP
Service
MUP
Service
MUP
Service
MUPS
BPMM 2
Integrated
BPMM 1 & SCMM
SM
SMM
z
BPM 2
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
Fig. 4. Operational view of model-generated workplaces
4.2.1 Approach
The overall objective of the MGWP approach is to generate workplaces as
customized views (graphical user-interfaces) to a common enterprise model. The
views can be either navigation (presentation) views or work (operation) views.
A navigation view reflects a particular enterprise model at a given time, while
work views are interactive views to a common active (live) enterprise model, i.e. a
customized view to active knowledge modelling (Jørgensen et al., 2005). The models
in concern are enterprise models and workplace models, including:
•
•
•
Reference models that describe enterprise specific object types like product
type structures, department organization, document templates and forms,
and reference processes.
Instance models that describe the actual enterprise such as work progress,
product portfolio, organization and IT systems and services.
User-interface models that describe the layout and interaction design of the
model-generated workplaces
A workplace model describes the workplace structures, object views and available
services for an organization group, person or role.
4.2.2 Framework and Design
In the ATHENA project the MGWP approach has three main components:
•
•
The enterprise models modeled in MO²GO and Metis/Metis Enterprise
Server.
The MPCE (Modelling Platform for Collaborative Enterprises) is an
ATHENA result that store and exchange enterprise models (Jørgensen et al.,
2005). Another ATHENA result, POP* (Product, Organization, Process and
other enterprise dimensions), is a kernel language to support the exchange
of enterprise models, both vertically from high level abstraction down to
detailed views as well as horizontally between the business partners.
8
R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
•
The Web portals Process Assistant (PA) and Troux Internet Portal (TIP),
respectively as workplace environments for MO²GO and Metis enterprise
models.
In order to generate useful customized views from an enterprise model, it is
necessary to ensure an appropriated level of model granularity (Knothe et al., 2007)
(Knothe et al., 2006) (Knothe et al., 2005). In the INTRACOM Telecom cases the
model has to contain detailed information about process flow as well involved
roles, relevant documents and IT applications. In order to achieve the necessary
granularity level the following modelling procedure was applied (see figure 5).
Define the
enterprise
processes
(main activities)
Model tasks
(particular
activities)
Assign roles
to every task
Assign relevant
documents
and IT systems
to tasks
Derive views
for each role
Fig. 5. Modelling procedure for an MGWP aware enterprise model
Based on the MGWP-aware enterprise model in MO²GO, the Process Assistant
generates documentation of reference models in HTML. Figure 6 shows examples
of the Process Assistant for INTRACOM Telecom. To the left we see the front
page, which is a navigation entry to the different reference models defined in the
MO²GO enterprise model. To the right is an example of a process presentation
view in HTML and a model view of the same process in MO²GO Web-based
model client.
Fig. 6. Process Assistant for INTRACOM Telecom enterprise model
Model-Generated Workplaces: An Interoperability Approach
9
It is also possible to model (make available) contextual link connections between
Process Assistant and TIP, in such a way that a user may invoke TIP from Process
Assistant and vice versa.
The MGWP in TIP is a work view of the underlying enterprise model stored in
Metis Enterprise Server. Technically, we operate with two kinds of enterprise
models, a general enterprise model that represents the substantial knowledge of the
enterprise as a whole, and workplace models that define the content, layout and
functionality of the model-generated role specific workplaces in TIP.
The reference process model from MO2GO is imported into Metis through
MPCE and POP*. This model is used as a baseline for the instance process models.
The Metis enterprise model is then populated with organization dimension, product
dimension and system dimension. The system dimension constitutes the user
interface and functionality of the TIP work places. Respectively through user
interface models and service models. Integrations with external services and legacy
systems are modeled either as Active Knowledge Modelling (AKM) services or
Web services. The AKM service type is used both for internal queries into the
enterprise model and for invocations or calls of external parameterized URL
services. Web services are made available in the models through bottom-up import
from WSDL into Metis. Modelling is thus used both bottom up and top down to
create a visual arena where top down business concerns and bottom-up technical
realities can be aligned. Figure 7 shows an example of typical models in the system
dimensions and how these models are assigned to a specific role based workplace.
In this case the workplace for a product manager.
Fig. 7. Types of system dimension models and role assignment
In the ATHENA project we have defined the metamodel User Interface Modelling
(UIM) as a metamodel in Metis. The metamodel is just partly implemented. The
following concepts are central for our scenario:
•
•
Page (UIM): Objects of Page (UIM) are Web pages in TIP. The contents of
the page are derived from the objects that “is content of” this page. The
content may be organized by a sequence number. For those objects of Page
(UIM) with property filename equals “index” or empty, are start pages for
the current workplace.
Explorer (UIM): An Explorer (UIM) object is a content of a page, and it
consists of two vertical divided frames. The left frame is a Tree View
(UIM) and the right one is the target frame for the service result of current
selected tree node.
10
R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
•
Item (UIM): An object of Item (UIM) may represents a service (AKM
service or Web service), a collection of sub items, and a placeholder for a
certain type of objects. The Item (UIM) object is used as a placeholder in
order to model features to objects in run-time. E.g. if one need different
services available for tasks depending on the status of the tasks.
Since the workplaces in TIP are generated by or based on models that are stored in
a repository, the functionality and the user interface of the workplaces can easily be
change in run time. Traditionally, it has been common to make a distinction
between end-user applications and development tools. When having configurable
applications and/or applications that are partly configured at run time such as TIP,
the distinction becomes less clear.
Fig. 8. The user interface model and corresponding user interface in TIP
The workplace for the Product Manager is based on a workplace model with the
UIM-model shown in figure 8. The UIM-model describes an explorer view. The
explorer tree consists of an organized sequence of nodes, modeled as Item (UIM):
•
•
•
•
•
Process Assistant: Represents an AKM service that invokes the start page
of Process Assistant for INTRACOM Telecom.
Product management (reference processes): Represents an AKM service
that returns the reference processes the Product Manager are responsible
for.
Products: Represents an AKM service that gives access to all product
objects in the enterprise model.
WIBAS Documents: Represents an AKM service that returns all document
objects related to the tasks that are connected to the WIBAS product.
WIBAS Product Management: Represents an AKM service that returns all
WIBAS tasks the Product Manager is responsible for.
Figure 9 shows an operational view for a task. The resources available for the task
are modeled in the workplace model. The model describes that each task, which is
a WIBAS Product Manager task, will have relevant documents and a link to the
description of the task in Process Assistant available as sub nodes in the tree view.
The documents are accessible through iKnow, a document management system at
INTRACOM Telecom. The model also describes that TIP will use a Web service
to get the document location in iKnow.
Model-Generated Workplaces: An Interoperability Approach
11
Fig. 9. A task operational view
The GUI of the process work view (the right frame in figure above) is currently not
modeled by UIM models. It is based on a default object viewer, but configurable
through configuration files regarding e.g. what attributes to be avaliable.
5 Challenges and Future Work
Present experience with the development of Model-Generated Workplaces in the
PPM scenario strongly supports the effectiveness of the approach for creating role
specific application spaces that can support day-to-day tasks while adhering to the
corporate standards captured in the enterprise model. The actual usefulness and
usability of the MGWP for the selected role (Product Manager) will be evaluated
in the near future but it has been clearly shown that the generated workplaces can
go far beyond a traditional application development approach. However, in its
current state this approach does not extend to the actual execution layer and it does
not guarantee or propose some proper support from the actual information
retrieving services. Further work or technologies will be needed in order to bridge
this gap. Future directions for extending the MGWP concept so it can evolve into
an end-to-end interoperability solution framework may be inspired by the
following observations and challenges:
•
The actual design and implementation of underlying information retrieving
Web services does not stem from the Enterprise Models. The services preexist and are currently “linked” to appropriate tasks in the models. This
creates a “boundary” or “mismatch” between the model-generated
workplace, which is formally created, and the services supporting it, which
usually are not. This is not a problem in services supporting documentrelated tasks, which can be uniformly designed, but it is a problem in all
other types of data services. The main issue is the need to “match”
constructs resulting from two very different processes at the boundary of
the Enterprise Model and the existing (legacy) systems (in other words, the
Shared and Network-visible Service Layer).
12
R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
•
•
•
Even more so, TIP User-Composable Services (MUPS) presuppose the
existence of a “complete” set of visible services or the ability to
transparently combine and orchestrate existing services in order to support
all tasks modeled and supported by TIP. This is not a workplace task but is
a barrier in the effective utilization of such a workplace. Further efforts
should identify ways of formally creating a description of this “complete”
set of services needed and expected by the workplace.
The last step in the modelling procedure is quite fuzzy (Fig. 5). The
question is how to derive the role specific view from a model
“automatically”. An approach could be the customization of appropriated
services (e.g. Web services) based on the enterprise model on demand.
Subsequently the model has to contain all necessary information in order to
customize the right service. This means a high level of granularity and
increase of model complexity. A solution to manage this issue has to be
developed.
In order for model-configured solutions to really achieve knowledge
sharing across the roles and disciplines involved in PPM, actual product
structures must be captured in the models, so that workplaces can be
adapted to them. This is implemented by recent extensions to the Metis/TIP
Web service plug-in, where large data structures from XML business
documents (e.g. Web service results) can be mapped to model concepts and
automatically imported. The workplaces can also update legacy system
data by replicating the tasks that invoke update Web services for each
component, element, or parameter in the product models.
6 References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
ATHENA IP, IST 507849, 2004. Homepage: http://www.athena-ip.org.
B. Elvesæter, R. K. Rolfsen, F. Lillehagen, and D. Karlsen, (2007) Integrated
Enterprise Service Architecture. In Proc. of the 12th ISPE International Conference on
Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005.
Jørgensen, H. D., Krogstie, J., Ohren, O. P., and Johnsen, S. G. (2004): Interactive
Models for Tailorable and Evolving Information Systems, Journal of Applied Systems
Studies, Vol. 5 (1).
Jørgensen, H.D., Karlsen, D., Lillehagen F. (2005): Collaborative Modeling and
Metamodeling with the Enterprise Knowledge Architecture, Enterprise Modeling and
Information Systems Architectures, An International Journal, Vol. 1 (1)
Thomas KNOTHE, Timo KAHL, Dieter BOELL , Kristof SCHNEIDER, (2007)
Framework for Establishing Enterprise Modeling in the Context of Collaborative
Enterprises contributed to HICSS Conference, Haway USA, 2007.
Knothe, T.; Jochem, R., (2006) Quality Criteria for Enterprise Modelling in the
context of networked Enterprises, Conference I-ESA 2006, 20-24 March, Bordeaux,
France, 2006.
T. Knothe, K. Schneider, D. Böll, T. Kahl, S. Schuster, F. Lillehagen, J. Krogstie, H.
Grenager Solheim, (2005) First Version of Establishing and management approach,
Deliverable - A1.4.1, ATHENA, Integrated Project - Contract n°:IST-507849,
http://www.athena-ip.org.