Академический Документы
Профессиональный Документы
Культура Документы
Table of Figures
Figure 1: Service Provider, Service Registry & Service Consumer......................................... 14
Figure 2: Problem Statement in Practice .................................................................................. 18
Figure 3: Research Objectives coping to Problem Statement .................................................. 19
Figure 4: Context of Architecture [ISO11] .............................................................................. 30
Figure 5: The Core of Architecture Description [ISO11] ........................................................ 31
Figure 6: Matching of MDA Models vs. Abstraction Levels .................................................. 34
Figure 7: The Business Process Management System Paradigm ............................................. 48
Figure 8: The Value Configuration Meta-Model [GPZ10] ...................................................... 50
Figure 9: Refined Abstraction layer Strategy adapted from [DP07] ........................................ 51
Figure 10: The Strategic Alignment Model (SAM) [HV93].................................................... 52
Figure 11: e3value model for problem analysis ....................................................................... 53
Figure 12: I* illustration [DP07] .............................................................................................. 54
Figure 13: Business Motivation Model OMG (BMM) ............................................................ 55
Figure 14: Business Motivation Model enriched [Ber08] ........................................................ 56
Figure 15: Inter-organizational alignment model [DG06] ....................................................... 58
Figure 16: The VbMF modeling framework and the Core meta-model .................................. 63
Figure 17: Overview of Transformation Mechanisms between models/notations and
Abstraction Layers ................................................................................................................... 65
Figure 18: Strategic Objectives in cause-and-effect chain ....................................................... 69
Figure 19: Strategic Objectives linked to business functions .................................................. 70
Figure 20: EPC Model explaining the ―To Be‖ Order Management process .......................... 71
Figure 21: BPMN Model explaining the ―To Be‖ Order Management process. ..................... 72
Figure 22: Models & Standards for the introduction Case Study ............................................ 73
Figure 23: Example of a Method Engineering Process ............................................................ 78
Figure 24: Configuration Process for Situational Methods ...................................................... 79
Figure 25: Method Fragment is containing Process Fragment and Product Fragment ............ 79
Figure 26: Method Engineering Classes used .......................................................................... 81
Figure 27: Overview Chapter 3 ................................................................................................ 88
Figure 28: SOA Method Domains ........................................................................................... 89
Figure 29: SOA Domain and SOA Sub-Domain Terminology ............................................... 90
Figure 30: Type of Industries: Percentage per Industry (n=52) ............................................. 114
Figure 31: Size of Organization: Percentage per employees‘ category (n=53) ..................... 114
Figure 32: Number of Applications: Percentage per application category (n=53) ................ 114
Figure 33: Respondents and enterprise Framework (n=54) ................................................... 116
Figure 34: Respondents and Modelling Types for SOA (n=54) ............................................ 117
Figure 35: Respondents and BPM usage Scenarios (n=54) ................................................... 119
Figure 36: Respondents and Available SOA Methods (n=54) ............................................... 120
Figure 37: Respondents and available BPM Design Tools (n=54) ........................................ 121
Figure 38: Respondents and available BPM Runtime Tools (n=54) ..................................... 122
Figure 39: Respondents and Service Orientation (n=53) ....................................................... 122
Figure 40: Respondents SOA Security (n=54) ....................................................................... 123
Figure 41: Respondents about proposed SOA Domain Model (n=54) .................................. 124
Figure 42: Alignment Model between SOA Domain and Method Fragment (only for SOA
Domain ―Modelling‖) ............................................................................................................ 128
© Jan Ricken, University of Namur, Computer Science Department Page 5
Figure 43: Example of Alignment Model use ........................................................................ 129
Figure 44: Engineering Process for SOA implementation Workflow View .......................... 136
Figure 45: Legend for SOA Engineering Process Models ..................................................... 137
Figure 46: Object Re-Use between Static and Dynamic Views ............................................. 137
Figure 47: Process: Create Method Fragment ........................................................................ 138
Figure 48: Process Manage situational context of organization for SOA project .................. 140
Figure 49: Process: Selection of Method Fragment ............................................................... 142
Figure 50: Process: Perform Project ....................................................................................... 143
Figure 51: Process: Update method fragments after project close ......................................... 144
Figure 52: SOA Engineering Method Framework (Screenshot) ............................................ 151
Figure 53: Method Fragment ―Service Oriented Business Process EPC‖ in EPF Tool
(screenshot) ............................................................................................................................ 153
Figure 54: Method Fragment ―EPC Process Model‖ in EPF Tool (Screenshot) ................... 154
Figure 55: SOA Domain Model for Situational Method application (Screenshot from Excel
Tool) ....................................................................................................................................... 155
Figure 56: Field trial Method for Method Fragment Application .......................................... 160
Figure 57: Cargolux Airlines Int SA Total Income 2008-2011 ............................................. 162
Figure 58: Cargolux BPM Roadmap ...................................................................................... 164
Figure 59: Cargolux EA Model .............................................................................................. 165
Figure 60: Application support to main processes ................................................................. 165
Figure 61: Situational SOA Implementation Method Cargolux Action Case (Screenshot
Eclipse) ................................................................................................................................... 168
Figure 62: Selected Modelling Languages for Cargolux Case .............................................. 170
Figure 63: LBBW Overview & Key Figures [LBBW09b] .................................................... 173
Figure 64: Project Set-up and Objectives LBBW [LBBW09b] ............................................. 175
Figure 65: Key Figures for Implementation Project .............................................................. 175
Figure 66: LBBW Situational SOA Method Action Case ..................................................... 177
Figure 67: Selected modelling languages for top-down modelling ....................................... 179
Figure 68: Cargolux SOA Strategy Context .......................................................................... 183
Figure 69: Cargolux Balanced Scorecard Model with Cargolux SOA Objectives ................ 184
Figure 70: Value Chain Model for scoping and high-level Process Overview ...................... 185
Figure 71: Example for Cargolux Functional Requirement Process, EPC, CIM Level ......... 187
Figure 72: Example for Cargolux Technical Process, BPMN, PIM Level ............................ 188
Figure 73: Strategy for AVALOQ Project [LBBW09b] ........................................................ 190
Figure 74: Value Added Chain Model of Macro Processes LBBW ...................................... 191
Figure 75: Value Added Chain Model "Account Closure" Process LBBW .......................... 191
Figure 76: EPC Process Modell Manage Equities Deal LBBW ............................................ 193
Figure 77: Access Diagram AVALOQ/Web-Service LBBW ............................................... 194
Figure 78: Web-Service Requirement Model GLB-AVA$SWT LBBW .............................. 195
Figure 79: Field trial Decision Summary of Modelling Language Path ................................ 197
Figure 80: Levelling of Design Time Tool vs. Run Time Tool ............................................. 233
Figure 81: IDS Scheer link between SOA Design Time and SOA Run Time ....................... 234
Figure 82: Process Service Transformation ........................................................................... 234
Figure 83: Business Driven SOA Roadmap by IDS Scheer .................................................. 235
Figure 84: Modeling links of IDS Scheer approach ............................................................... 235
Figure 85: SAP SOA ESA Overview ..................................................................................... 238
Figure 86: deployment of BPMN Diagrams into Process Engine ......................................... 240
Figure 87: Web Service Development Life Cycle Hierarchy ................................................ 246
Figure 88: Phases of service-oriented design and development methodology ...................... 247
Figure 89: The layers of a SOA in SOMA Methodology ...................................................... 250
Figure 90: OUM for SOA Overview...................................................................................... 253
© Jan Ricken, University of Namur, Computer Science Department Page 6
Figure 91: OUM SOA Core Workflow .................................................................................. 253
Figure 92: ORACLE Levelling for Process-Notations .......................................................... 255
Figure 93: Example of ORACLE Levelling for Process Notations Using UML................... 255
Figure 94: ORACLE SOA BPMN Example .......................................................................... 256
Figure 95: ORACLE SOA Functional Modeling Example ................................................... 257
Figure 96: Gartner SOA Adoption Model Overview ............................................................. 260
Figure 97: Gartner SOA Adoption Model Implications ......................................................... 260
Figure 98: Gartner SOA Adoption Model Implications Details ............................................ 261
Figure 99: Gartner SOA Adoption Model Implications Skills .............................................. 261
Figure 100: OASIS SOA Reference Model ........................................................................... 266
Figure 101 Principal concepts of the OASIS SOA Reference Model .................................... 266
Table of Tables
Table of Definitions
1.1. Motivation
1.1.1. Background of Research
1.1.2. Why SOA
1.1.3. Problem Statement
1.2. Research Questions and Proposal
1.2.1. Research Proposal
1.2.2. Research Questions
1.2.3. What the PhD is not…
1.3. Scope of Work
1.3.1. Research Design
1.3.2. Research Structure
This chapter introduces the thesis by explaining the motivation for the chosen research topic
(section 1.1.) with the background and proposed research, why SOA is important and where
the problems are. Then, the proposed research contribution is explained (section 1.2.)
including research objectives and research questions and how this thesis will contribute to
resolve the identified research problem. The scope of work is detailing the research design
(section 1.3.) and the overall research structure to ensure efficient organization and usage of
research standards.
1.1. Motivation
Recently, we can observe that established business rules have been constantly redefined
[KBS06] and organizations are constantly hunting for effectiveness and efficiency in their
daily operation. New business models emerged: speed, growth and innovation were the
critical success factors to survive the wave of mergers & acquisitions that changed the overall
industrial landscape. IT has played a major role in all of this and without any doubt IT is the
key enabler for the hot topic of business agility. The agility and flexibility [Sch04] of an
organization today to react as quickly as possible on different opportunities & threats
(mergers & acquisitions) strategic partnership and alliances, new product launches which are
based on customer requirements is key. This agility and flexibility turned into a success factor
to survive in the aggressive and competitive markets pushed by the globalisation and the
European Union enlargement. In this context, Service Oriented Architecture (SOA) became
since the early 1990s an interesting philosophy [Pez06].
© Jan Ricken, University of Namur, Computer Science Department Page 11
Initially pioneered on technologies such as peer-to-peer network protocols, SOA got a boost
in adoption in the second half of the 1990s. Enabled by Common Object Request Broker
Architecture (CORBA) and Distributed Component Object Model (DCOM), SOA began to
become a more popular concept and reached another step in maturity with the development of
platforms such as Java 2 Platform, Enterprise Edition (J2EE) and .NET, increased adoption of
Business Process Management (BPM) and the emergence of Web Services (WS). The SOA
paradigm is defined as an
Through this, the concept of SOA became more mature and reached the top of the hype cycle
in 2003 [Pez06]. The SOA paradigm has been identified as the magic bullet to first and
foremost enable rapidly an adaptation to the quickly changing business environment [Alo04].
SOA meets the definition of an architectural style and represents a technical view of a
business automation solution based on service-orientation principles [Erl05]. An architectural
style needs to be understood as ―a group of principles that provides a framework for a family
of systems‖ [Pon12]. The key principles of service orientation are:
loose coupling,
service contracts,
autonomy,
abstraction,
re-usability,
composability,
statelessness and
discoverability.
The main objective of a SOA is consequently to provide mechanisms for allowing old and
new technologies to be integrated and implemented dynamically by focusing into ―business
© Jan Ricken, University of Namur, Computer Science Department Page 12
services‖ rather than applications. Presentation, business logic and data are all on separate
tiers and are loosely coupled, allowing the quick change of business processes. An
organization can get new best-of-breed applications and integrate them easily with existing
systems. A SOA is promoting reuse, so the time it takes to deliver new business functionality
can be reduced [ATHEN03].
As described earlier, SOA is an architectural style using web services. This thesis will not
focus in detail on technical specificities but more on the engineering method to implement
such a SOA.
As the name tells, services play the major role. Actors can take the three different roles:
1. Service Registry
2. Service Provider
3. Service Consumer
Before understanding what happens between these three different roles, it is important to
know what we understand as a service, IT service and finally also web-service.
The term ―service‖ has strongly evolved from the early marketing-centric definitions in the
60ties to a more general understanding of services in the 80ties.The definitions of services
vary on the different levels or topics they are related to.
“Services include all economic activities whose output is not a physical product or
construction, is generally consumed at the time it is produced, and provides added
value in forms (such as convenience, amusement, timeliness, comfort or health) that
are essentially intangible concerns of its first purchaser[QBP87].”
New perspectives of services such as ―systems design and operation‖ were defined by
researches and are shifting over time.
A service encapsulates business logic within a distinct context. The context can be specific to
a process or a business activity. Next, the business logic can include the business logic
provided by other services, which is also called composition [Bri06].
Within a SOA system, services can be used by other services or other programs. In order to
interact properly in-between them, these web-services must be aware of other services. Web-
service descriptions (such as name, location and data exchange requirements of the service)
explain exactly what the service is about to do. The manner in which services use service
descriptions results in a relationship classified as loosely coupled. As we want services to
interact meaningfully, they must exchange information. Therefore a framework called
―messaging‖ can preserve their loosely coupled relationship [Erl05]. The description of a
service is done with languages that are classified as platform specific (PSM) e.g. IDL
(Interface Description Language) or WSDL (Web Service Description Language). A
complete, independent and updated list of web-service standards can be found under
[WIKI10b]. The following figure below is explaining what we will later define as SOA
Heartbeat adapted from [Dos05]:
The service provider creates a service. This is also known as ―service deployment‖. To allow
service consumers to use this service, it is necessary to publish it in a service registry (1). The
service is stored in the registry and can be found through a search (2) from a service
consumer, who wants to use this service. The registry tells the service consumer through the
© Jan Ricken, University of Namur, Computer Science Department Page 14
service description that the service is available and indicates the related service provider,
physical location, contact person, usage fees, technical constraints, security advice and
available service levels (3). It is important to note two different types of registries: registries
just for internal enterprise usage and registries for cross enterprise service integration, which
have different requirements. The service consumer will then request the service from the
service provider (4). The exchange of messages between service provider and service
consumer is done with SOAP. Once, the service consumer has done the authentication and
authorization, the service can be used by the service consumer (5).
The enterprise service bus connects the participants of a SOA – services and application front-
ends – with each other. If two participants need to communicate, e.g. if an application front-
end needs to invoke some functionality of a basic service, the service bus makes it happen.
The service bus is not necessarily composed of a single technology. The main characteristics
of a service bus are the following [KPS06]:
Connectivity: The primary purpose of the service bus is to interconnect the participants of a
SOA. It provides facilities enabling the participants‘ application front-end and services to
invoke the functionality of services.
Technical functionality: the main purpose is primarily communication, but it must also
provide technical services such as logging, auditing, security, message transformation, or
transactions.
The ―SOA Heartbeat‖ is defined as a number of processes and interactions taking place
between service registry, service provider and service consumer with the objective to execute
a web-service to fulfil a business requirement.
A lot of organizations are facing the practical problem that they want to build a flexible,
modular and easy to adapt IT environment to cope with business requirements. The SOA
architectural style is promising advantages in comparison to traditional architectures. Grand
challenges of the technical SOA and web-service aspects are resolved. But when is SOA
© Jan Ricken, University of Namur, Computer Science Department Page 15
successful? Which promises have to be achieved? How can we measure SOA success against
traditional architectures?
Early 2007, independent worldwide studies conducted by GARTNER [Pet07] with more than
1.400 Chief Information Officers (CIO), came to the result of decreasing importance of SOA
for CIOs, while the level of SOA readiness and implementation did not progressed
substantially SOA ranked only number 7 of Top 10 CIO priorities. The reason for this shift of
priorities is linked mainly to two issues: first, the approach on implementation method and
what abstraction models to use is very complex and today unclear. Second, the ROI of SOA
can hardly be calculated. Recently, some research initiatives such as Mueller et al. [MVLR10]
are on the way to explore the different categories of benefits (Organizational, Strategic, IT
infrastructure, Operational and Managerial) with an economic potential model (SOA-EPM).
Obviously, there is a complexity in this architectural style on how to achieve the promised
benefits. This includes also the way to achieve a SOA implementation in an efficient and
effective way. Which process is succesfull to implement such a SOA in an efficient and
effective manner? This thesis will address with the SOA Method Engineering Framework the
problem of complexity and also which process might be efficient and effective for an
implementation of SOA.
The challenges materializing from the GARTNER study and other observation is also
formulated within a service oriented computing research roadmap by Papazoglu, Traverso,
Dustdar and Leymann [PTDL06]. They state: ―What is required is a service-engineering
method that allows enterprises to efficiently design and deploy services and which can easily
embed changes into service-based applications at the rate and pace of change in the business
design. It is from the correspondence that SOA deliver on the promise of more flexible
business through a more flexible IT environment. This correspondence is represented as the
service-oriented engineering methodology, in which business processes are modelled,
analysed, assembled (possibly out of pre-existing components), deployed and monitored in a
continuous and iterative manner.‖ Papazoglu and Dustdar are also doing research in this area,
but they are not comparing different available SOA methods indicating strengths and
weaknesses. Furthermore, concrete advice how to link strategy to processes and finally to the
IT layer is missing. We will address this academic problem with the proposed SOA Method
Engineering Framework.
This concrete need has been confirmed by a recently published work of identifying and
classifying on-going SOA research. Viering et al. [VLA09] therefore name one of 4 SOA
research types ―How to design, implement, and manage SOAs?‖ and “specifying how
organizations should apply the SOA concept, and might be most valuable from the
practitioner‘s point of view. It is associated with a constructivist type of research or design
science, resulting in frameworks, reference models, methods, and management practices.‖
Consequently, the above mentioned challenges related to SOA implementation are still
underserved and are still an original domain of SOA research. Consequently, we will ask
ouerselves if and in what conditions the proposed SOA Method Engineering Framework will
be successful or not.
Related research areas to the SOA Engineering Method are the following:
Process-orientation:
The ―process-driven SOA‖ might be a possible solution for the open issue to resolve. Zdun
and Dustdar [ZD06] describe the central challenge for the modelling of process-driven SOAs.
Key issue is the integration of the different kinds of models and abstractions. This problem is
© Jan Ricken, University of Namur, Computer Science Department Page 16
challenging, because so far there is no formal and precise modelling approach for integrating
all kinds of models. The missing integration of process-driven SOA models for different
levels of abstractions needs to be further analysed.
Model-driven concept:
In BPM as management discipline, many different languages and tools exist. The
functionalities and characteristics are different and can lead to misunderstanding and failure.
Furthermore, executable languages used to implement the models (e.g. process execution
languages like BPEL [OASIS07], [IBMSS03] or programming languages) are also diverse.
These identified issues are based on Model-Driven Software Development (MDSD) concept
[SV05], which is a specialization of Model Driven Architecture (MDA) [Fra03] [OMG03].
The MDA defines an approach whereby new principles are promoted to separate the system
functionality specification from its implementation on any specific technology platform.
MDA is trying to achieve an architecture that will be language, vendor and middleware
neutral [Fra03].
“defines the approach that considers diverse business process realization scenarios
evaluated in terms of costs, risks, benefits and ROI in accordance with business
requirements and priorities [PvdH06]”.
Deliverables based on literature review and practical cases described in the INTEROP
[BGBDK+05] and ATHENA [ATHEN05] – projects come to the result that a top-down
method has more strengths than weaknesses. In our research, though not excluding other
perspectives, we favour a top-down implementation strategy as changing to SOA must be
motivated and supported from the IT strategy. The bottom-up strategy is coming from the
web-service inventory and neglecting the business motivation for SOA. The first assessed
SOA implementations in case studies [TTJ09] showed a clear tendency towards successful
implementation if top-down strategy was selected.
These areas or principles are somehow related to the SOA Engineering Method question.
SOA requires development discipline and methods that must be defined and enforced [Bar05].
Therefore, we will consider in the present work these principles in the context of the method
definition with the objective to find out what role they play in practice and what decisions are
linked to these principles.
The previous section showed that there is a need for research in SOA method to develop a
service engineering method as one of the identified grand challenges in service design and
development. Since research has insofar been ineffective to cover this need, this still
represents an original research domain. The academic proposals just include small parts of the
target objective or miss important parts or use other principles as described in [Zim09] or
[Tran09]. There are no proposals using an engineering approach as described and required in
the SOA research roadmap [PTDL06]. Following to this, figure 2 is explaining the practical
problem:
Different SOA development projects exist in many organizations. These organizations are all
in different situations meaning available systems, modelling tools, IT knowledge, scope,
budgets etc. There exist many different available SOA Methods, which are proposed by
various industrial service providers or academic researchers. These SOA Methods (list in
chapter 2.5.) are defined following a specific viewpoint and specific concerns (details in
chapter 2.1.). It is possible that for a given SOA development project and a specific situation
the SOA method fits perfectly and delivers the expected result. Obviously the situation will
differ in different SOA development projects as well as the used SOA Method e.g. the IBM
SOA Method will be different from the ORACLE SOA Method, which will be different from
the SAP SOA Method. One of the practical problems is that these SOA Methods do not
necessarily fit to various situations (x). Also, modelling languages used in the SOA Methods
are quite different on various levels. Furthermore, the integration between these modelling
languages seems not to be trivial and also an original domain for research [ZD06].
Particular important is the focus on the modeling domain, which means a focus on modeling
languages and also on what abstraction level to model and which modeling languages might
be good candidates to be used in a SOA context. The present work will focus on this
particular domain of modeling but in the context of a SOA Method application. There are
certainly other relevant domains related to SOA concerning for instance web-service details.
We use the terminology domain, a model, modeling as defined by Lankhorst [Lan05]
explained in details through definitions 18,19 and 20 in the state-of-the-art (chapter 2.1.).
Next, the expected impact for the SOA development project of using a SOA Method in a
particular situation might be positive or negative. This measurement is in practice very
difficult, as project managers or CIOs cannot redo a project applying another SOA Method to
compare. This behaviour would not be efficient in practice; therefore just lessons learned are
recorded at the end of these SOA development projects.
© Jan Ricken, University of Namur, Computer Science Department Page 18
1.2. Proposal & Research Questions
In order to resolve the identified challenges and problems, the following proposal is made:
First, the state-of-the art review should identify available SOA methods. It is important to
understand the different viewpoints of these SOA methods and their degree of SOA topics
coverage. The literature review is leading to the definition of a conceptual model (SOA
Domain Model) taking different viewpoints and related SOA sub-domains. Based on this
broad conceptual model the comparison of existing SOA method proposals is done.
Furthermore, a feedback will be asked from practitioners‘ on available SOA methods, suited
candidate modeling languages and the proposed SOA Domain Model. Finally, the need for
resolving the academic and practical problem should be confirmed.
In order to find out, if a SOA Engineering Method Framework as claimed by academia can
efficiently solve also the practical problem in organizations, method engineering principles
should be used and linked to the SOA Domain Model. Therefore, method fragments should be
created and formalized following method engineering principles. These fragments are
compiled in a configuration process for SOA situational method using a tool to prototype the
approach and allow efficient re-use in field trials for real-life application and will allow
investigation whether practical efficiency problems in method application could be removed.
Based on the problem statement the following SOA Method Engineering Framework (SOA-
MEF) is proposed:
Firstly, a model (here: SOA Domain Model) is required to summarize and generalize
various aspects (here: SOA sub-domains) that must be covered in a model-driven and
process-oriented SOA development project. The SOA Domain Model should summarize
contents of available SOA Methods. This model may indeed narrow the communication
gap that often exists between managers (business) and developers (IT) by providing them
a common reference framework, concepts and vocabulary. This is particularly done by
describing SOA Domains which include sub-domains and activities. Domains can be
considered as clusters (e.g. SOA modelling) with sub-domains (e.g. SOA modelling
notation). Each sub-domain includes a series of activities (e.g. model business
requirements with BPMN [OMG09]).
Secondly, it is required to think about a possibility to get an idea what range and how deep
available SOA Methods are covering SOA domains. SOA Methods are very broad and the
before identified domains and related SOA sub-domains could be a way to compare in a
structured way SOA Methods and identify areas of strengths and weaknesses of these
available SOA Methods.
Third, with the help of Method Engineering (details in chapter 1.2.1.1.) the necessary
academic deepness is achieved by proposing a situational SOA Method. Other than the
SOA Methods, the situational SOA Method is able to adapt to particular situation. A
Configuration Process for SOA Situational Method (CP-SOA-SM) should in general be
able to describe the process of creating fragments and applying them in a specific
situation. The problem of non-fitting SOA Methods to a specific situation can be avoided.
To achieve this, SOA method fragments should be created and formalized from available
SOA Methods. With these SOA Method Fragments, a perfectly fitting SOA Method could
be configured as only the relevant fragments are chosen that cope with situation for
concrete SOA definition project.
Due to space restrictions and also the range of complexity in other domains, it is important
to emphasize that the focus of this thesis is lying on the details of the SOA modelling
domain.
It is important to mention that ―evaluation‖ in this thesis does not mean automatically coping
to deep statistical evaluation requirements, but to consider the evaluation more on a
qualitative level. Furthermore, the qualitative validation is only a first cycle of many iterations
that could be done. As the proposed topic and the SOA Method Engineering Framework is so
broad and complex, more iterations have to be done to achieve ―evaluation‖ with results
which can be generalized. What can be understood by ―evaluation‖ of the different proposed
artifacts is detailed in every relevant chapter.
In order to cope with the ―Engineering‖ dimension for methods, the thesis will apply Method
Engineering (ME) principles. In order to engineer a SOA implementation method, the
definition of ME concept developed by Harmsen and Saeki [HS96] as well as Brinkkemper,
Lyytinen and Welke [BLW96] is used: ―Method engineering in the field of information
© Jan Ricken, University of Namur, Computer Science Department Page 20
systems is the discipline to construct new methods from existing methods. It focuses on the
design, construction and evaluation of methods, techniques and support tools for information
systems development.‖ Furthermore, according to Roland [Rol08] ―method engineering wants
to improve the usefulness of systems development methods by creating an adaptation
framework whereby methods are created to match specific organizational situations.‖ Here,
the objective lies in the demonstration that SOA method fragments can be formalized.
1.2.1.2. Tooling
In order to demonstrate that the generated artifacts can be used and applied in case studies, it
is required to think about a tool, which can be used to ensure effective and efficient structure
and application of CP-SOA-SM. The tool used can also be summarized as a prototype with
the objective to demonstrate the applicability of artifacts in real-life cases.
Following to Satzinger, Jackson and Burd, [SJB09] ―prototyping is the process of building a
model of a system. In terms of an information system, prototypes are employed to help system
designers build an information system that is intuitive and easy to manipulate for end users.‖
and ―The prototypes are not built for full functionality but are built to see if the prototypes are
feasible for what goals the business is trying to achieve.‖ As a prototype tool, it seems that
extensible process engineering tools can support the described objective in that context. For
example, such a tool should provide method authoring, process authoring, library
management and configuration functionalities [Eclipse09].
With method authoring we understand the possibility to capture re-usable method building
blocks with an underlying meta model. The method blocks should be re-used through
inheritance-type relationships.
Process authoring ability is about construction of reusable method fragments in processes may
for example define how to create BPMN model. This method fragment can now be reused in a
variety of processes and delivery processes.
The tool should provide a database allowing flexible configuration of method fragments,
XMI-based exchange format, packaging of method fragments and processes into plug-ins for
exchange to other databases. To summarize this, the tool should integrate ME principles,
freely available, use open standards and extendable to other process engineering tools.
After defining the contribution, it is important to mention what is out of scope for this thesis:
Investigating into technical details of SOA or technical issues of SOA related to the
implementation method [Gün05] or web-service problems related to semantics,
ontologies etc.
Achieve full statistical validation of results. We are proposing a first cycle with more
iterations to be done in future work.
As explained in the problem statement and addressed in the research proposal, the following
questions are posed:
Q1.: How can differences of available SOA Methods be identified and characterized?
Q3.: How can the configuration process for SOA situational Method support the decisions
taken in practice by organizations?
Q4.: Which candidate modelling languages are suited to serve in the SOA implementation
context and on what level of abstraction?
Q6.: What about the quality of generated SOA Method and the achieved results out of SOA
Method?
Q6.1.: Is the quality of generated SOA Engineering Method satisfactorily?
Q6.2.: Is the achieved result from SOA Engineering Method satisfactorily?
After having defined the different types of problems to address, we need to propose a research
method.
Hence, as Jick [Jic79], Mingers and Broclesby [MB97] and Blaikie [Blai05] argue, research
methods should be combined meaning to gather quantitative and qualitative data. In the
specific context of the present research, this might provide a research design to allow a more
holistic study and validation of the research questions. Furthermore, they argue that
experiments may not fit within the proposed research design as experiments need to take
© Jan Ricken, University of Namur, Computer Science Department Page 22
place in a controlled environment. In order to enrich the proposed research method, we will
use exploratory research style elements (without going too far as this would be a thesis for its
own) with the objective to collect information for a better understanding of the problem of
SOA complexity and the motivation by practitioners to implement SOA. The perceived
problems both from academia and also from practicioners should be taken as an input helping
to better and more precicely formalize the research design mix in table 1. It is not the
objective to prepose a complete exploratory research cycle before the design science method
mix, but to embed literature review and also a practicioners survey into the method mix.
If we follow the research framework outlined by March and Smith [MS95] combining
research activities and research outputs, we can show the scope and method mix of the thesis:
Research Output Research Activities (Theorize and Justify are out of scope)
(Artefacts)
Build Evaluate Research-Questions
SOA Con- Literature Review Survey Artifact:
sub- structs Artifact: ―Feedback on SOA
domains ―SOA sub-domains for Complexity by Q1 and Q4
SOA Method Exploratory Survey‖
Implementation‖
SOA ―Testing SOA domains
Domain and sub-domains‖ Q1 and Q4
Model
Models Literature Review Survey Artifact:
Artifact: ―Testing of SOA
SOA ―SOA Domain Model‖ Domain Model‖
Fragmen Q2 and Q5
ts & Methods Method Engineering Not possible
Process Artifact:
―Configuration Process
for SOA Situational
Result Method‖ and „Method
from Fragments― Q3 and Q6
Instantia Instanti- Method Engineering Application case
tion ation Artifact: Artifact:
―Application of SOA ―Evaluation of SOA
Method Engineering Method Engineering
Framework on two Framework on two
application cases‖ application cases‖
―Prototyping of a
Tooling Support‖ for
SOA Method
Engineering
Framework‖
March and Smith [MS95] state natural science tries to understand reality, whereas design
science attempts to create things that serve human purposes. Rather than producing general
theoretical knowledge, design research produces and applies knowledge of tasks or situations
© Jan Ricken, University of Namur, Computer Science Department Page 23
in order to create effective artefacts. Its products are of four types, i.e. constructs, models,
methods, and instantiation. In our research, the artefact is a framework including a SOA
Domain Model, SOA Methods Evaluation, a Configuration Process for SOA Situational
Method and SOA Method Fragments. The instantiation of this artefact will be built through
the model and applied in two real-life case studies. This evaluation of the proposed artefacts
will allow refinement and practical inside how to apply the artefacts.
Research outputs or artifacts cover constructs, models, methods and instantiations [MS95]:
―Constructs are the concepts, vocabulary and conceptualizations that are used to describe,
think about and solve problems and tasks within a given domain.
Methods are a set of steps, algorithms or guidelines used to perform a task. It is based on a set
of underlying constructs and a representation (model) of the solution space.
Research activities comprise building, evaluating, theorizing on and justifying artifacts. The
two former activities are the domain of design science, whereas the two latter are the domain
of natural and social sciences.
Building refers to the conception and construction of viable and purposeful artifacts – in the
form of constructs, models, methods and instantiations - aiming at resolving a problem. Their
successful development demonstrates their feasibility.
Evaluating refers to the assessment of the proposed artifacts according to suitable metrics.
The relevance and contribution of a specific design science research artifact is generally
judged on the basis of its value or utility to a community of users, be it for its novelty,
increased efficiency or effectiveness compared to existing artifacts.
Theorizing refers to the construction of theories that try to explain how or why some
phenomena of interest happen.
Justifying finally refers to proving that theories are truthful through the gathering of empirical
scientific evidence that supports or refutes them.‖
Note that a more detailed discussion of the applied research methods proposed at each stage is
provided at the beginning of each corresponding chapter.
In chapter two we review the state-of-the-art about SOA Methods but also to related topics
like Enterprise Architecture (EA), modeling languages, interfaces and translation between
models. EA has been chosen as starting point, because the „helicopter view― on strategy,
processes and IT is addressed by EA. It is therefore important to understand first what
different components, views and relationships are important in the context of SOA Method.
With the state-of-the-art analysis, available SOA Methods should be summarized and
evaluated where different levels of abstractions and related modeling notations suited for
SOA implementation are of particular interest. The identified issues on current SOA
implementation methods will confirm the relevance of the research.
Chapter three is about the detailed construction of the SOA Domain Model which is a
conceptual modeling exercise. Based on the state-of-the-art elements gathered, sub-domains
are classified, structured, condensed and finally a SOA Domain Model is proposed. Under the
chosen angle of Top-Down, Model-Driven and Process-Oriented (TD-MD-PO) SOA
implementation method, there will be a link to notations and process modeling languages, as
this is the way to abstract from the complex reality a model allowing concentrating on details
important for SOA Method. Therefore, a focus will be done on the domain ―SOA Modeling‖.
Then, the available SOA Methods are evaluated with the SOA Domain Model.
Chapter three is also dedicated to the survey that has two objectives: First the survey should
test the proposed SOA Domain Model by experienced practitioners and second gather
knowledge on important questions e.g. used and successful modeling notations and the degree
of satisfaction with available SOA Methods.
© Jan Ricken, University of Namur, Computer Science Department Page 25
Chapter four is detailing the configuration process for SOA situational method. Next, SOA
Method fragments are created from available SOA Methods. Two standard SOA Methods are
formalized with ME into method fragments referring to the SOA Domain criteria‘s of
modeling.
In chapter five, existing tools are used to create a prototype supporting the approach. This
way, the conceptual work from chapter two and especially chapter three with the research
contribution is implemented and principles such as ME are enforced. Method fragments are
created and stored in a method engineering tool and are then ready for re-use in application
cases chapter six.
Chapter six describes the application of the CP-SOA-SM to 2 field trials. The objective is to
apply the SOA Engineering Framework with the main artifacts of SOA Domain Model, SOA
Method Fragments and Configuration Process for SOA Situational Method. The field trials
should demonstrate applicability of the assembled generic method and show in detail the
design rationales or decisions that have been taken for the specific implementation examples.
To mitigate the risk of generalizability [Ben87] which represents a weakness of case study
method, both cases have followed the same process using the same guidance documentation.
Chapter seven concludes this thesis by making a summary of its various contributions and by
proposing further interesting research directions.
Chapter two is focussing on literature review for the posed research questions in the
introduction specifically related to a top-down, model-driven and process-oriented viewpoint
(Section 2.1. to 2.4.) and a SOA Engineering Method (section 2.5 and 2.6.). Consequently,
the chapter is starting with Enterprise Architecture (section 2.1.) because the conceptual
© Jan Ricken, University of Namur, Computer Science Department Page 27
foundation and understanding for the SOA Domain Model is built. Modelling languages are
an essential part of a model-driven and process-oriented SOA implementation and therefore
identified on each level of abstraction (section 2.2.). Next, the interfaces of conceptual
modelling (section 2.3.) between the abstraction layers and how these modelling notations can
be transformed or interfaced (section 2.4.) is described. Available SOA Methods are
introduced (section 2.5.) and first SOA sub-domains are identified. All available and current
proposals are listed and a preliminary grouping of relevant SOA sub-domains covered in the
methods is presented. Method Engineering is introduced (section 2.6.) as an engineering
approach for methods, which needs to be applied in this present work to allow situational and
context tailored method application. At the end of this chapter, a summary recaps the main
conclusions (Section 2.7.) of literature review.
EA is about essential aspects of an organization that can be formalized and shown. These
include but are not limited to [JV90] [VZ93]:
We will refer to the definition of IEEE [IEE00] which has been further developed together
with ISO and IEC into the ISO/IEC/IEEE 42010 standard [ISO11]. For the definition of this
standard, ISO has conducted a survey [ISO10] on 52 architecture frameworks. This list of
architecture frameworks can be probably considered as one of the most exhaustive
enumerations. Shortcomings on the initial IEEE definition [IEE00] identified by Lankes et al.
[LMW05] on management views and software maps have been addressed in the latest
reworked version of ISO [ISO11] as presented in the next section.
The standard ISO/IEC/IEEE 42010 [ISO11] specifies terminologies which is relevant for the
research topic and defines architecture framework and requirements on architecture
frameworks. This is also including architecture descriptions of systems, architecture
description languages (ADL) and architecture viewpoints (AV). An Architecture Framework
(AF) is defined as follows:
Figure 4 explains the context of conceptual architecture with an existing system, which is
situated in its environment. Following to ISO [ISO11], that ―Environment‖ could include
other ―Systems‖. ―Stakeholders‖ have interests (here: ―Concerns‖) in a ―System‖. A
―Purpose‖ (earlier version of the standard: mission) is one very common ―Concern‖.
―Systems‖ have ―Architectures‖ and ―Architecture Description‖ is used to express
―Architectures‖.
“Every System exists in its Environment. A System acts upon that Environment and
vice versa. A System's Environment determines the range of influences upon the
system. In the Standard, Environment is intended in the widest possible sense to
include operational, developmental, regulatory, and all other influences which can
affect the architecture. These influences are captured as Concerns.” [ISO11]
Systems have Architectures. In the Standard, the architecture of a system is defined as:
The following diagram depicts the content of an architecture description and the relation
between those content items when applying the standard to express the architecture for some
system of interest [ISO11]:
“A Concern is any interest in the system. The term derives from the phrase
"separation of concerns" as originally coined by Edsgar Dijkstra. Examples of
concerns: (system) purpose, functionality, structure, behavior, cost, supportability,
safety, interoperability.” [ISO11]
“A Model Kind defines the conventions for a type of Architecture Model.” [ISO11]
Following to Lanckhorst [Lan05], analysts and modellers may decide to zoom into a
particular part of the universe they observe. Then, they will zoom into a particular part of their
conception of the universe, here the enterprise. Related to the communication of actors,
different terms need to be defined. Consequently, a domain needs to be defined as
“A Domain is any subset of a conception (being a set of elements) of the universe that
is conceived of as being some “part” or “aspect” of this universe.”[Lan05]
“Modelling is the activity of purposely abstracting a model from a part from the
universe.” [Lan05]
We will base terminology for the artefact of conceptual ―SOA Domain Model‖ on the
terminology defined by Lankhorst.
The Platform-Independent Model (PIM) describes the operation of a system while hiding the
details necessary for a particular platform. The model focuses on specifications that are not
changing from one platform to another.
A Platform-Specific Model (PSM) combines the specifications in the PIM with the details that
specify how these systems are using a specific type of platform [Lan05] e.g. CORBA.
Figure 6 is illustrating the matching between the MDA method abstraction levels and the
higher grained abstraction levels of Strategy, Processes and IT.
UML is considered as the ―de facto‖ modeling language for both PIMSs and PSMs. The first
reason is the fact that it is the modeling language developed by the OMG [OMG01]. Second,
UML is considered as a ―semantically rich‖ language [Fra03]. This means that based on a
meta-model, the objects used are semantically defined and allow a translation from the PIM
view to the PSM view [PM06]. In the same context, Kleppe et al. [KWB03] distinguish
between well-defined languages and not well defined languages. Following to [KWB03],
UML is ―a well-defined language because of form (syntax), and meaning (semantics), which
is suitable for automated interpretation by a computer‖.
At the CIM level, it is more complicated as we have the notion of different views. This issue
is explained in the ―4+1‖ views on architecture design defined in the Rational Unified Process
(RUP). Following to Kruchten [Kru95], the ―4 + 1 View Model‖ describes ―software
architecture using five concurrent views, each of which addresses a specific set of concerns:
The logical view describes the design's object model, the process view describes the design's
concurrency and synchronization aspects; the physical view describes the mapping of the
software on hardware and shows the system's distributed aspects, and the development view
describes the software's static organization in the development environment. Software
designers can organize the description of their architectural decisions around these four views
and then illustrate them with a few selected use cases, or scenarios, which constitute a fifth
view.‖ The architecture is partially evolved from these scenarios.
© Jan Ricken, University of Namur, Computer Science Department Page 34
MDA has been developed as a new philosophy for the software development (based on object
oriented design). Nevertheless the principles could also be used for a SOA implementation if
a semi-automatic and automatic transformation from one level (CIM, PIM, PSM) to another
should be realized. The separation of modelling languages corresponds to the separation of
concerns at the architectural level. Therefore languages are needed on the different levels of
abstraction to describe functional (business requirements) and non-functional characteristics
(transactional behaviour, security and persistence).
The Enterprise Architecture Framework is the starting point for the analysis of available
methods for SOA implementation and the underlying modelling techniques. As described,
many different frameworks exist, whereas in all frameworks modelling related to a conceptual
level plays a key role.
The term ―Architecture Model‖ has already been defined in the context of the latest
Architecture Framework [ISO11], but Enterprise Modelling (EM) has different roots and is
rapidly introduced.
Historically, this journey started in the 70ties with research on database design with models
like the ―Entity Relationship Model‖ [Che76]. During 80ties, large Computer Integrated
Manufacturing (CIM) [Sch83] projects started e.g. ICAM (Integrated Computer Aided
Manufacturing) led by the US Air Force or CAM-I (Computer Aided Manufacturing –
International). Early 90ties, first software appeared offering toolboxes for process modelling.
These tools became more and more mature and offered new modules or completely new
software to manage ―workflow‖, meaning the automated execution of processes. Most of
these process modelling tools disappeared again, and new, based on new customer
requirements, were created and marketed. Beginning of the 20th century, the big back-end
software companies well-known for their ERPs (SAP, ORACLE) or platforms (IBM,
Microsoft, SUN) started to integrate processes into their software.
Following to Vernadat [Ver96], modeling is looking at the what, how, when and who aspects
of an enterprise.
“EM is the set of activities or processes used to develop the various parts of an
enterprise model to address some desired modelling objectives.“ [Ver96]
and
Ross and Schonman [RS97] identified 15 main principles for modelling techniques:
Following to ISO 19439:2006 for Enterprise Modelling [ISO06b], the standard ―serves as a
common basis to identify and coordinate standards development for modelling of enterprises,
emphasising, but not restricted to, computer integrated manufacturing. ISO 19439:2006 also
serves as the basis for further standards for the development of models that will be computer-
enactable and enable business process model-based decision support leading to model-based
© Jan Ricken, University of Namur, Computer Science Department Page 36
operation, monitoring and control…‖ and ―…four enterprise model views are defined which
are: function view to represent the processes and activities of the enterprise; information view
to represent the enterprise information used and obtained during the operation; resource view
to represent the enterprise assets needed for carrying out the enterprise operations; and
organization view to represent the organization, organizational relationships and the decision-
making responsibilities in the enterprise operation.‖ The standard is based on CIMOSA and
GERAM [BN94]. Chapter 6 of the standard defines requirements on models and modelling
method.
Furthermore, ―Additional views for particular user concerns can be generated but these
additional views are not part of this International Standard. Possible additional views are
identified in ISO 15704 [ISO00b].‖
No complete enterprise modeling method currently exists and there is serious doubt that it
will ever exist. The most of the methods will also hardly address all these principles
described. There exist a wide range of model types which can be used to describe aspects of
an enterprise [Ver96]. Vernadat is referring to descriptive which are generally used for
communication and common understanding for people in an enterprise, because of their
informal, easy-to-learn syntax and formalism. Usually this type of models uses boxes, circles
and arrows. Typical examples are IDEF [MM98], [MCFKP+95]), BPMN
[BPMI03][OMG09], EPC [Sch93] [Kin04] and UML notations. And there exist more
technical models with more formal description techniques such as Petri Nets [GAJV08].
Other researchers are looking for similar criteria‘s to categorize modelling languages i.e.
Jablonski and Bussler [JB96], Zur Mühlen and Becker [zMB99] or Eder and Gruber [EG02].
Table 3 is summarizing modeling notations found in existing states. The following states have
been considered: [ATHEN03], [BHABT+04], [Lan05], [UEML03]. These states will be
introduced very briefly about their context and objectives.
This document analysed is titled ―State-of-the art for Interoperability architecture approaches‖
with a focus on ―Model-driven and dynamic, federated enterprise interoperability
© Jan Ricken, University of Namur, Computer Science Department Page 37
architectures and interoperability for non-functional aspects‖. The aim is to provide a
foundation for further analysis and work in the context of defining solution approaches and
research issues related to the roadmap for interoperability related to Architecture&Platforms.
Specifically, the analysed deliverable is stating modeling notations, modeling tools, modeling
concepts, web-service based business processes and workflows.
This book is first giving a state of the art on EA Frameworks and modelling languages to then
propose ArchiMate, which is an EA description language and EA Method. This has been
created as an outcome from a project ―Archimate‖, a Dutch research initiative that provides
concepts and techniques to support enterprise architects in the visualisation, communication,
and analysis of integrated architectures. The project consortium was consisting of Telematica
Instituut, ABN Amro and many others.
The UEML project was set up in an attempt to contribute to the solving of the problems of
multiple Enterprise Modelling Languages (EML). It is an IST Thematic Network funded by
the European Commission in the Sixth Framework Program with the objective to create a
European consensus on a common EML and to facilitate interoperability in the frame of on-
going standardisation efforts in this domain. The state of the art is about enterprise modelling
focusing on: Enterprise Modelling Languages (EMLs), Enterprise Engineering Tools (EETs)
and Enterprise Modelling Methods (EMMs). This terminology has been re-used in table 3 to
distinguish between these three categories. UEML has re-used definitions introduced by
GERAM [BN94].
“EML defines the generic modelling constructs for enterprise modelling adapted to
the needs of people creating and using enterprise models. In particular enterprise
modelling languages will provide construct to describe and model human roles,
operational processes and their functional contents as well as the supporting
information, office and production technologies.”[BN94]
“EMMLs are languages that are used to describe enterprise modelling languages
(their concepts, syntaxes and semantics), and to describe enterprise modelling
methods.” [BN94]
Metamodels can help in the selection of application specific modelling language [zMue99] or
supporting automation of processes in workflow [zMR99] [zMue02] [JBS97]. We will not
focus on EMMLs and exclude this from the list in table 3.
A comparative study by zur Muehlen and Becker [zMB99] is today outdated as standards,
methods and modelling languages are evolving very quickly. It will be more useful to
concentrate on EMLs as they will be linked to available SOA methods in the next chapter.
Finally, Van der Aalst, ter Hofstede and Weske [vdAtHW03] state that ―all attempts to give
an exhaustive overview over all methods, modeling languages and model types is predicted to
fail.‖ Hence, we will not claim to gather an exhaustive list, but a rather complete list, allowing
preparing the ground for the picking of some notation candidates being suited to be used for
the presented scope.
The presented list is a summary of existing state-of-the art of EMT, EML and EMM. They
have been classified in alphabetical order including following information fields:
Name
Long Name
Developer/Organization
Year of Development
Enterprise Modelling Tools (EMT), Enterprise Modelling Methods (EMM),
Enterprise Modelling Languages (EML)
Popularity in SOA & BPM conference articles
Links between modelling notations
Standard Organization Support
The last 3 criteria‘s will be used to get an indication on notations which are potentially suited
as modelling notations in this thesis context. Therefore, the 3 criteria‘s need to be explained in
more detail:
The popularity in SOA & BPM conference articles is important to identify the notations
playing a role in the academic world fitting within the subject of process-oriented and model-
driven SOA implementations. We can assume that published articles went through thorough
evaluation process by specialists. Therefore, these articles using specific notations in that
context can be considered as a reliable indicator. The main conferences on processes have
been chosen in the period 2008-2012. Therefore, the Business Process Management
(BPM2008 to BPM2012) conference articles (details table 5) and relevant IEEE conference
papers (details table 6) have been screened and notation citations extracted. This is not
claiming exhaustivity on BPM and SOA conferences, but is more intended to provide
illustrative character. The details will be explained after table 3 in table 4.
The Standards Organization Support criterion has the objective to provide some information
on industry acceptance and utilization of standards. Furthermore, it can be considered that a
well maintained standard notation achieves a level of quality and formalism such as meta-
model, tool adaptation etc.
Generally, the different state-of-the art deliverables from important EU-funded projects
e.g. INTEROP, ATHENA, UEML are unfortunately not exhaustive because of rapid
changes in model language evolution. To underline that, the following list gives an
overview, in which deliverable, book or paper the enterprise modelling languages are
explained.
Table 4 is indicating the sources, where information about the modelling languages can be
found and which states have considered the review of these standards.
The following chapters will classify each notation on a specific level of abstraction. The
execution code languages (XML) are not modelling languages per se, but are helpful for the
execution of web-services in an orchestration language such as BPEL.
All notations that are not used anymore (BPML) or replaced by other notations are excluded.
The following table is the response from the exploratory feedback from practitioners on
suited SOA modelling notations. The alphabetical list with notations had to be rated if the
notation was A.) not known, B.) Known, C.) Known, used and meeting expectations or
D.) Known, used and not meeting expectations. The details on survey design, method
participants etc. are detailed in section 3.3.1.:
The table filters the notations on top, which are the mostly known (low percentage on ―not
known‖.
This selection has been done based on citation of these notations in accepted papers of BPM
conferences 2008 to 2012. Only one occurrence per modelling notation per paper was
possible.
Additionally to the BPM conference papers, a broader request on modelling notations within
all IEEE conferences has been launched on IEEE Explore [IEEE12]. The search has been
done for the time range between 2007 and 2012. The notation has been put in the SOA
context by requesting: ―Modeling notation‖ AND ―SOA‖ - as a full-text and metadata search:
The citations count of notations in academic papers give an indication of academic popularity
of notations. The ranking indication can be used to identify notations which might be more in
the focus of interest than others. Again, notations on strategic level seem generally to be less
cited in conference and workshop papers.
One quality property of modelling notations as proposed by Hommes and Van Reijswoud
[HR00] based on the FRISCO report [FHLNH+98] is expressiveness. By expressiveness we
understand
“the degree to which a given modelling technique is capable of denoting the models of
any number and kinds of application domains.” [FHLNH+98]
Formalized meta-models and also the ability to transform from one denotation into another
are measures for high expressiveness [HR00].
The following table will indicate with a rather basic scale (high-medium-low) the
expressiveness of notations related to the MDA abstraction levels introduced in section 2.1.3.,
where research such as from [NK06] [RRIG09] is used as input:
The presented tables 5 to 7 will help through the next sections to concentrate on the notations
seeming the most suitable for a top-down modelling approch using popular notation in
practice and academia with high expressiveness of notations on their respective level. On the
strategic level, most notations are de facto not known and also not very expressive. However,
these notations are in our scope important as we motivate an approach where also strategy
should be formalized in models. This will be further detailed in section 2.2.5.
When entering the field of business process modeling, an overwhelming number of tools and
modeling languages are available. Often these languages and tools have very little in
common. In most of the cases, the conceptual domains that are covered differ from language
to language. Some emphasize elements of workflow in the models, others concentrate on
quantitative analysis and others try to integrate business processes and supporting information
technology. Moreover, software tools are an important success factor for a language; some of
the most popular languages e.g. ARIS [Sche93] are proprietary to a specific tool. It is clear
that none of them has succeeded to become "the standard language" [BHABT+04].
In figure 7, Karagiannis et al [KJS96] have defined different processes exemplarily for BPM.
The content of the processes has no relevance for the SOA Method, but it illustrates the
different levels of abstractions. The ability to structure and perform these processes is
enhanced by tools represented as a list on the right side of the figure 7 [KJS96]. Additionally,
4 levels are used, which are similar to the earlier introduced abstraction layers of CIM added
by an additional level which is strategy.
A myriad of other examples for BPM systems and components could be found such as in
[JK04] or [BR10b] with the same content but different words or ontologies. Important in this
context is to recognize the different level of abstractions with strategic level, CIM, PIM and
PSM. Available modelling notations can be linked to these levels to formalize the necessary
modelling content following the specific objectives. The next sections will illustrate this in
detail.
This section will quickly introduce business strategy concepts and different approaches. These
Strategy definition approaches will be described and finally strategy definition elements in
SOA discussed. The reason is that SOA requires a more business value view than technical
viewpoints as declared in the SOA Manifesto [SOA09] where a working group developed a
set of objectives and guiding principles aiming to provide a better understanding of SOA. Key
prioritizations were ―Business Value over Technical Strategy‖ and Strategic Goals over
“Strategy is the creation of a unique and valuable position, involving a different set of
activities.” [Por96]
and
“Strategy is about knowing where your company is today, where you want to take it,
and how you are going to get there.” [Dru94]
and
“Strategy is aiming to set the direction, to focus effort, to define organization and to
provide consistency.” [MAL98]
Business strategy concepts are a very complex and vast area related to different views. The
concept of views has been already introduced in section 2.1. Mintzberg, Ahlstrand & Lampe
in their book ―Strategy Safary‖ [MAL98] describe 10 different views on the strategy process:
To comply with the research subject, the strategies need to be translated into a model. This
means that we need to find a description language and a tool with the ability to do so. Known
methods for strategy implementation and support by a tool are the ―Balanced Scorecard‖ and
―Value Chain‖.
Kaplan and Norton [KN92] [KN93] introduced the BSC as a management system that helps
an enterprise to clarify and implement its vision and strategy. The BSC therefore suggest to
view an enterprise from four perspectives (Financial, Customer, Process and Learning and
Growth) decomposed into a three-layered structure: 1. Mission (e.g. become the customers‘
preferred supplier), 2.Objectives (e.g., to provide the customers with innovative products) and
3. Measures (e.g., % of turnover generated by new and innovative products).
The original concept of Value Chain was created by Porter [Por85]. The chain consists of a
series of activities that create and build value. They culminate in the total value delivered by
an organization. The concept of ―margin‖ is equal to added value. The organization is split
into ―primary activities‖ and ―support activities‖. These functions can be linked to one
another in the form of a sequence of functions and thus form a value-added chain. The value
© Jan Ricken, University of Namur, Computer Science Department Page 49
chain is a systematic approach to examining the development of competitive advantage. The
drill-down of each business function is necessary to show how the functions are performed.
Giannoulis et al. [GPZ10] have analysed the formalization of strategy maps [KN04a]
[KN04b] and Balanced Scorecards [KN92] [KN93] with the objective to formalize strategy
maps in the form of a meta-model, usage scenarios and constraints to achieve a unified
language/ontology for business strategy modelling:
The meta model consists of classes and cardinality constraints for the relations between
classes. Following to [NEKZ+05], a process is executed to satisfy a goal (goal class). This is
where the link is to next deeper levels of process landscapes expressed by value chains. This
is also a future work area of [NEKZ+05] to provide enriched meta-models with the objective
to transform business strategies to lower-level model e.g. business process models.
Following to Rigby [Rig07], the most used approach is strategic planning. After the first place
in 2005, strategic planning also ranked in 2006 at the top-level [RB07]:
So far, no modelling notation for strategic planning has been discovered. The key criteria for a
consistent and integrated approach and method for the implementation of SOA is therefore the
ability of the tool to link the strategic model to the processes or process models.
Recently, some work [DP07] has shown the relationship between business model, business
process model, business goals and business requirements:
This figure above is a finer grained overview of the strategy layer introduced in figure 6.
The business Strategy can be derived from the vision and mission of an organization. Next,
business model and business goals can be positioned on the strategy level. The business
requirement is the link to business processes. ―Strategic fit‖ can be checked between business
model and business processes.
© Jan Ricken, University of Namur, Computer Science Department Page 51
The Strategic Alignment Model (SAM) developed by Henderson and Venkatraman [HV93] is
considered as the key reference alignment model:
This alignment model includes four main components to consider for alignment, i.e. business
strategy, IT strategy, organizational infrastructure and processes and IT infrastructure and
processes. Next, it also specifies two types of integration which is a.) the strategic integration
between the business strategy and the IT strategy in the context of the external domain and b.)
the functional integration between the business organizational infrastructure and processes
and the IT infrastructures and processes in the context of the internal domain.
In the context of SOA implementation method, the strategic direction (Business Strategy and
IT Strategy) has to be aligned with the processes and architecture defined as the internal
domains. Following to Prado [Pra09], ―alignment is a continual adjustment process of
conscious and coherent interrelation of all business and IT components and personnel in order
to contribute appropriately and quickly to the business goals and needs over time‖
Next, we will explore another area of the strategy layer, which is about the business model:
“A business model is a conceptual tool that contains a set of elements and their
relationships and allows expressing the business logic of a specific firm. It is a
description of the value a company offers to one or several segments of customers and
of the architecture of the firm and its network of partners for creating, marketing, and
delivering this value and relationship capital, to generate profitable and sustainable
revenue streams.” [OP10]
4 pillars composing nine building blocks have been identified [DP07] in this Business Model
Ontology (BMO):
The pillars of this BMO are partly similar to the ―strategic objectives‖ defined and suggested
by Kaplan & Norton in their Balanced Scorecard approach [Rig07].
The e3value business ontology was originally proposed to model the value networks of
cooperating business partners [GAV00]. The ontology aims at identifying the exchanges of
objects of economic value (value objects) between the involved actors in business
collaboration. The e3value ontology provides a rich set of software tools to design and
analyse value webs, including a graphical notation. It also provides a minimal set of concepts
and relations, thus making it easier to be understood by all the involved stakeholders. Figure
11 is taken from a case study [GA03] about online news provisioning is illustrating the
e3value ontology:
This model notation has been initially developed for e-business scenarios. A considerable
effort is done to expand this notation also to other use cases not directly linked to e-business.
The promise of this notation and the research done in that area is about deriving from the
business model notation (strategic) a process model notation (business process). There are
also different researchers enhancing the e3value model by complementary views and
notations e.g. the e3forces ontology is introducing constructs for representing and modelling
© Jan Ricken, University of Namur, Computer Science Department Page 53
strategic motivations from environmental forces [GP07]. Pijpers, Gordijn and Akkermans
[PGAa09], [PGAb09], [PGAc09], are exploring e3strategy and e3alignment to business and
organizational aspects. The work is based on Porter‘s five forces [JS02], [Por80], [Por85]:
bargaining power of suppliers, bargaining power of buyers, competitive rivalry among
competitors, threat of new entrants and threat of substitutions.
An example [GP07] taken from the passenger aviation industry is the introduction of e-ticket
system. The business model highly depends on this IT system providing significantly cost
reduction per booking process, which can be used to reduce price to achieve more value for
money and attract more customers. An e3forces model helps by determining where IT can
create competitive advantage by providing a graphical overview of relationships with markets
[GP07].
Another model in the strategy abstraction layer is the OMGs Business Motivation Model
(BMM) [OMG10]. BMM positions itself as a structure for ―developing, communicating, and
managing business plans in an organized manner.‖ According to OMG, the BMM
All the used terms in the BMM are described in detail and expressed through a meta-model
and a fact based model.
BMM is also showing in their referenced elements box ―Business Process‖. As notation,
BMM in the specification document [OMG10] is referring to the BPMN standard through the
externally defined element.
Berkem [Ber08] is arguing that the reason for performing processes always is starting on
strategy level. Business processes realize then actions with the objective to fulfil strategic
objectives and goals.
Some of the logic of business processes may be expressed in business rules. Business rules
are derived from business policies.
Since much of the motivation for what an organization does is based on people in the
organization deciding what is best for it, the organization should be able to say who decided,
and on what assessments of what influences. In practice, real businesses do not have complete
traceability of motivation. But, as and when they choose to move towards it, the BMM is a
possibility to support it.
This can be used to make strategy and goals more visible. Tools exist (e.g. Select Business
Modeler) in supporting the presented BMM and linking to process modelling notations.
© Jan Ricken, University of Namur, Computer Science Department Page 56
The link of earlier mentioned strategy models to a SOA is the following: these types of
models such as BSC, i*, e3forces and e3-value can be used to formulate strategy and business
model into a graphical notation.
This section has provided some insight into what strategy is and which tools or methods can
be found on this level of abstraction.
The next section will therefore focus on the interface between strategy models and process
models.
The following sections will explore which could be candidate modelling notations on
different levels of abstraction. In particular the positioning of notations and their possible
transformation and mapping mechanisms are interesting.
E3-value
E3-forces
i*
Balanced Scorecard
Strategic Planning
BMM
All analysed SOA methods neglect this type of strategy modelling. Some are giving advice to
include strategic objectives, but no SOA method includes one of the 6 mentioned notations.
E3value and e3-forces are quite close to each other, as e3forces has been developed based on
e3-value. Both notations have their roots and basic idea from Porters work on strategy. The
alignment of business strategy of an enterprise with the required information technology
needed to enable the e-service in a networked value [PGA08] was analysed. Their approach is
claiming to enhance other frameworks for Strategy-IT/IS alignments as described in
[Bae92][HV93][LPB95]. One recent approach is proposing the following constellation setting
[DG06] in figure 15:
We see an example independently from the SOA context of aligning modelling methods on
different level of abstractions. E3value and e3forces modeling is used on the strategy level
which is connected to the processes (petri-nets) and IT/IS using TOGAF as EA model. BPMN
is used as interfacing notation between the petri-nets.
A semi-automatic translation from e3-value to BPMN has been proposed by Edirisuriya and
Johannesson [EJ08] by exploring how a process model can be systematically derived from a
business model. The paper presents an enhanced solution towards proposed e3transition
model introduced in Pijpers and Gordijn [PG07]. A developed Activity Dependency Model
(ADM) is used to interface e3-value on strategy abstraction layer and BPMN on process
abstraction layer. The purpose of an ADM is to bridge the gap between business models and
process models. An ADM provides more details than a business model and fewer details than
a process model. It identifies and classifies the activities that are necessary to exchange
resources, produce resources, deliver services, and the relations that exist among these
activities. Transformation rules from e3value to ADM (6 rules) and between ADM and
BPMN (9 rules) define the mapping from one model to another. Furthermore, four primitive
value transfer process patterns are used to show exchange of business objects between
provider and recipient. Future research will test the completeness and correctness of the
mapping rules in other case studies. The BMM and Strategic Planning are more a set of
guidelines and frameworks than real modelling notations. They might be helpful and act as a
starting point to fill/construct e3-forces, i* or BSC models.
This link from strategy to process is very difficult to make and also mostly a manual process.
For the decision model, it is therefore recommended to consider the following notations:
The e3-value and e3-force notation are already recognized notations by academia. A
restriction might be the focus on business models based on web technology. Classical
industries e.g. manufacturing, logistics, supply mgt. where the focus is not put on the web as
sales channel could lead into issues in translating the business model into e3-notations. On the
other hand, case studies on air carrier [PG07] or banking [KG07] have been conducted.
The translation from e3-value to BPMN is possible via ADM mapping rules. Strategic
objectives should also be linked to processes. Therefore the I* or the BSC could be used. The
content of BMM can be taken as input for the I* and/or the BSC.
Abstract models and semi-formal notations are stepwise refined and linked to the next deeper
layer. Business-oriented process models tend to be incomplete representations of processes
according to implementation relevant details. For instance exception handling for unexpected
events, such as special cases from a business point of view or technical failures, is often
omitted [DvdA04]. Another path described by Stein et al. [Stei08] is starting with business
requirements formalized in an EPC process model. An automatic translation into BPEL is
demonstrated through an eGovernment case study. However, notations to formalize strategy
and linked objectives and business requirements have been neglected. EPC is an excellent
alternate solution to BPMN as standard transformation engines are able to automate from EPC
to BPEL (ARIS SOA Architect) [Stei08].
The strategy can be formalized in different notations as presented. Strategy models and
process models are two types of model in a chain of models used by enterprises to describe
different aspects. Hence the strategic model provides a high level view of the activities taking
place within and between actors, how value is generated and what strategic objectives are set.
The process models are taking into consideration the given strategy models, but the presented
notations will more focus on explaining operational details how business is executed. When
entering the field of process layer, different modelling notations are available. We will first
list the notations where a bridge from strategy can be made:
Petri Net
IDEF
The OMG Profile SoaML, which is a specification for the UML Profile and Metamodel for
Services Version 1.0. beta [OMG09b] addresses a modelling solution focussing on web-
services choreography, interfaces and interaction. A meta model (based on UML2) is
proposed and integrating MDA principles. Following to OMG [OMG09b] ―SoaML focuses
on the basic service modeling concepts, and the intention is to use this as a foundation for
further extensions both related to integration with other OMG meta models like BPDM and
BPMN 2.0, as well as SBVR, OSM, ODM and others.‖ Chapter 9 of the beta version
document is indicating a connection to the OMG BMM model. The motivation element (a
Vision, Goal, Objective, Mission, Strategy, Tactic, Business Policy, Regulation, etc.) is linked
to UML scenarios or UML activity diagram.
An already presented academic approach [ZD06] is taking care of translating process models
into execution notations on the IT layer. In most of the cases BPMN and UML play a central
role. The BPMN standard developed by BPMI [BPMI03] has been taken over by OMG
[OMG06] in 2006. Initially OMG positioned BPMN as a ―notation that is readily
understandable by all business users, from the business analysts that create the initial drafts of
the processes, to the technical developers responsible for implementing the technology that
will perform those processes, and finally, to the business people who will manage and
monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the
© Jan Ricken, University of Namur, Computer Science Department Page 59
business process design and process implementation.‖ In 2006 at an early stage, this was not
completely true, but meanwhile the standard has much evolved and the latest version BPMN
2.0. [OMG11] became a real alternate choice to the business requirements modelling
notations. Both can be used to translate into BPEL and WSDL. As UML has been created and
used for software development, the notation is well suited to specify implementation details.
The more promising notation with better connection to execution level with technical
orchestration models is certainly BPMN with associated schema files of XMI, XSD, XSLT
[OMG11]. No bridge has been identified for Petri Nets and IDEF.
In order to outline the selected notations for a model-driven and process-oriented SOA
implementation on the various levels, the table below is summarizing the notations. It is
important to note that this is not an exhaustive and detailed abstract – to do this by also
including details on strengths and weaknesses would be a topic of another thesis. The
objective here is to resume the presented notations candidates found along the different levels
of abstraction.
Table 10: Notation Description Summary
Notation Description
Strategic Strategy formulation and formalization with mission and vision
Planning Model statements, strategic objectives, action plans with budgets.
Balanced Strategic objectives based on cause-and-effect relationships, not only
Scorecard Model focussed on financial objectives but also on other dimensions e.g.
learning/education (internal), processes, customers and finance.
E3forces Strategy Modeling notation including environmental criteria‘s (based on
Porters 5 forces) and based on environmental strategy school.
E3Value Business Model Notation with focus on value exchange between actors.
I* Is used to show in an explicit way the goals of an organization. A goal
can have sub-goals and influence other goals.
Value Added Based on Porters Value Chain used for ―big pictures‖ or functional
Chain Diagram processes / macro processes overview.
BPMN 2.0. Business Process Notations (Business Requirements) issued by OMG,
process capabilities, process choreography, business rules management.
EPC Business Process notation (Business Requirements) ability to enhance
process sequence by data, application, organization elements and rules.
UML Diagrams Modelling notation (Requirement but also technical), linked to meta
model MOF, ability to represent processes with a comprehensive set of
profiles such as SoaML.
IDEF Business process notation (Business Requirements) with IDEF0 for
functional modelling, IDEF3 for workflow and IDEF1X for data
modelling.
Petri Net Business process notation (Business Requirements) with main focus on
workflow (tokens) mainly used in the manufacturing industry.
BPEL (= Coordinating the execution of business process including web services
BPEL4WS) (call, loop, run, exceptions etc.) ―orchestration‖ language.
WSDL XML based language to describe web-services.
YAWL De-facto standard for executable workflow models.
When deciding for a specific notation and a path down through the different abstraction
levels, an important criterion is the ability of notations to transform to the next deeper layer.
We need to distinguish between ―model translation‖ and ―language translation‖. The first is
about the definition of mappings between models in the same language and the second is
about mappings between models in different languages [Ken02]. We will in this context only
look at ―language translation‖ as different languages are involved on the different layers of
abstraction. We therefore refer to the following definition
model-to-model and
model-to-code
Some tools on the market (open source vs proprietary) are able to support those two
transformation types. The objective within this thesis is to provide a complete view on
different approaches related to automation and specific types of models on each abstraction
level.
The most research in this area is done by research teams with an informatics background.
Business analysts usually design processes in high abstraction languages, such as BPMN,
EPC, or UML Activity Diagram, and developers implement them using executable languages,
such as BPEL/WSDL. An important issue that hinders the interoperability and the reusability
of existing process models is the huge divergence of these modelling languages. This issue
occurs because there is no explicit link between two modelling languages at the same or
different abstraction levels. For instance, developers could not re-use or integrate the whole or
part of a process described using BPEL in another process developed using BPMN or EPC,
© Jan Ricken, University of Namur, Computer Science Department Page 61
and vice versa. The most popular solution for this issue is to define direct transformations
based on pre-defined semantics between the different process modelling languages [MLZ05],
[MZ05], [ZM05], [RM06].
A main view with the concern to show business rules is dedicated to the control flow within a
process model. Even after more than ten years of standardization efforts [Hol04], the primary
BPM languages are still heterogeneous in syntax and semantics. This problem mainly relates
to two issues: Firstly, various BPM language concepts that need to be specified in terms of
control flow [vdAtHK+03] and data flow [RtHE+05] have been identified, and most BPM
languages introduce a different subset of these [MNN04]. Secondly, the paradigm for
representing control flow used in the BPM languages is another source of heterogeneity. This
issue has not been discussed in full depth so far, but it is of special importance when
transformations between BPM languages need to be implemented. In essence, two control
flow paradigms can be distinguished, graph- and block-oriented [MLZ06]:
Graph-oriented BPM languages specify control flow via arcs that represent the temporal
and logical dependencies between nodes. A graph-oriented language may include different
types of nodes. These node types may be different from language to language. Workflow nets
[vdA97] distinguish places and transitions similar to Petri nets. EPCs [KNS92] include
function, event, and connector node types. YAWL [vdAtH05] uses nodes that represent tasks
and conditions. Similar to XPDL [WFMC02], these tasks may specify join and split rules.
Block-oriented BPM languages define control flow by nesting control primitives used to
represent concurrency, alternatives, and loops. XLANG [Tha01] is an example of a pure
block-oriented language. BPML [Ark02] and BPEL [ACDGK+03] are also block-oriented
languages but they also include some graph-oriented concepts (i.e.links). In BPEL, the control
primitives are called structured activities. Due to the widespread adoption of BPEL as a
standard, we will stick to BPEL as an example of a block-oriented language.
Based on the work in [MLZ05], [MZ05], [ZM05], [RM06], a new research approach has been
defined to address limitations regarding extensibility [TZD07]. The research extends the
concern/view of control flow by other concerns such as collaborations, data processing and
fault handling. Second, the framework extends the transformation approach for integration of
two specific kinds of process models, but provides interoperability with process models
realized in other languages than those two specified.
Figure 16: The VbMF modeling framework and the Core meta-model
© Jan Ricken, University of Namur, Computer Science Department Page 63
The presented method [TZD08] also exploits the model-driven software development
(MDSD) paradigm [VS06] to separate the platform-neutral views from the platform-specific
views so that the business experts ― in their views ― can get rid of technical details. Platform-
specific models or executable code, for instance, Java, or BPEL and WSDL descriptions, can
be generated from the views by using model-to-code transformations. The separation of view
abstraction levels helps in enhancing the adaptability of the process-driven SOA models to
business changes. For instance, the business experts analyze and modify the abstract views to
meet the requirement of changes. Then, these modifications can be transformed into code in
executable languages. The technical experts work with platform- specific views to define
necessary configurations such that the generated code can be deployed into the corresponding
runtime (i.e., process engines and Web service frameworks).
In the context of process-driven modeling, there are a number of standard languages in which
some provide high-level descriptions, for instance, BPMN [OMG06], EPC [Kin04], [vdA97b]
and Abstract BPEL in WS-BPEL 2.0 [OASIS07]. EPC and BPMN provide high-level
diagrams that consist of graphical notations for visualizing representations of processes.
These diagrams are relevant to the business analysts.
In [TSD08] they argue that there is no explicit link between these languages and the
executable languages. This has meanwhile evolved. Today, BPMN and EPC have formal
meta-models and transformation is possible. Furthermore, a complete method should also
integrate strategic modelling. It is true, that other approaches than [TSD08] might be a bit less
efficient, but they still work. The presented case study in [TSD08] called ―shopping process‖
is also not detailed how to derive automatically from Macro-Micro Flow technique in UML
activity diagrams into BPEL and WSDL.
Two actual research teams are also dealing with model transformation. Stein for instance
[Ste08] has shown through a case study an automatic transformation from EPC to BPEL
based on workflow patterns. Stein has included validation steps with model checker
technology with the objective to check if models satisfy a given temporal statement. The
BPEL process was deployed on ORACLE SOA Suite, whereas Microsoft BizTalk failed.
Issues on translation bugs for XML Schemas, integrating business rules into EPC without
using XPath (technology dependent) were identified. As conclusion, the top down approach
worked well, but a roundtrip scenario is almost impossible.
Another initiative presented in [ATHEN06] is about the PIM4SOA Meta model [BL06],
which allows model transformations using the MDA principles. The meta model is arguing to
enable the exchange of business process specifications between modelling tools and between
tools and execution environment. MAESTRO, ARIS EPC and EXPRESS can be interfaced to
PIM4SOA, which is then providing a link to web service integration (XSD, WSDL, BPEL).
Thomas [Tho07] has developed a process driven SOA based on EPC, BPMN, BPEL and
WSDL. The reasoning is also top-down, based on a semi-formal approach. The EPC is used
as an information model in a semi-formal graphical language. The configuration level is
solved with the BPMN including process logic and technical details for the execution. The
© Jan Ricken, University of Namur, Computer Science Department Page 64
execution level contains information for the execution that can be expressed e.g. by BPEL.
WSDL is used to describe the web services. The research is illustrating a creative manual
process of translating EPC-Model into a BPMN model. Reference models and patterns can be
used for model construction. The semi-formal intermediate result through BPMN needs to be
transformed to a BPEL model. BPEL is considered as the de-facto-standard for business
process implementation based on web services. Transformation rules assign each BPMN
element and attributes to BPEL representation. However, it is not fully automated as
sometimes it is necessary to adjust the BPMN process design according to execution
constraints required by BPEL compliance with the conceptual determining factors. Thomas et
al. [Tho07] argue that a robust tool support is needed to allow graphic modelling (SemTalk
for MS Visio or Intalio) and to enable BPMN to BPEL translation. Integration Platforms e.g.
BizTalk Server with embedded tools like Visual Studio allow import, creation, processing and
export of service orchestrations. Unfortunately, the research takes not into consideration how
to derive from strategy the business requirement model EPC, but the approach illustrates for
the process and IT level besides UML the most common languages used in a process oriented
SOA implementation. The transformation mechanisms are not explained in detail, but it is
obvious that EPC2BPMN is semi-automatic or manual, whereas BPMN2BPEL or
BPMN2YAWL [DDDG08] is mostly automated process.
Finally, the latest approaches on languages and transformation from one level to another can
be recapitalized in the following conceptual model indicating the sources names for the
proposed solutions. An issue might still be the separation of process models concerns, explicit
relationships between abstract and executable modelling languages. An additional manual
effort to maintain the integrity, consistency and validation of models is necessary for semi-
automated and manual approaches:
Figure 17: Overview of Transformation Mechanisms between models/notations and Abstraction Layers
© Jan Ricken, University of Namur, Computer Science Department Page 65
2.4.3. Summary on Model Transformation
Model transformation and interoperability is a complex topic with a lot of actual research
issues. Basically, there are different ways to approach the issue: First, in the context of top-
down modelling for SOA, the question of meaningful transformation on what level needs to
be resolved (Strategy2CIM, CIM2PIM, PIM2PSM). Due to the fact of a broad range of
available process models, interoperability and reusability becomes an important question.
Either direct transformations between specific process models are defined and used or a
broader approach based on meta-models is used. To use the concept of different views and
related concerns is obviously a good way to deal with different aspects other than just the
control flow.
The strategy layer should not be neglected despite the fact that automation into process
models seems not to be possible today. Within the strategic level, strategic planning turned
out to be the most used approach to formalize strategy. The BSC deals with strategic
objectives and related activities that can be directly linked to the value chain. To formalize
business model, e3forces and e3value can be used. Both have a slightly different viewpoint as
discussed in section 2.2.7. The I* stands on the same level as a BSC Model, and the link
between e3value and I* is possible. It is very crucial to understand the different viewpoints
and concerns for the models presented in the strategic layer.
As the concluding figure in this section illustrates, different path can be used. A valid question
for practitioners is the ability of tools to cope with these transformation rules and to make sure
the identified languages are consistent between each other. In terms of pure transformation
objectives and transformation efficiency, MDA principles can be applied, which means also
the usage of the UML notation family. It is imaginable to describe strategy with the BMM
model and link to UML Activity diagrams or BPMN directly. But as this is not the only and
first criteria, because UML has also shortcomings on strategy level and CIM level, the choice
need to be designed related to the specific context the method will be applied in. This will be
further elaborated in design rationales for modelling notation choices and used in the
application cases.
The pattern movement is a software engineering success story. In 1995, the Gang of Four
published their seminal Design Patterns book [GHJV94]. Many different types of patterns
have been published since then, for example Patterns of Software Architecture (POSA)
[BMR+96], domain analysis patterns, and even patterns for non-IT topics. Examples for
recent contributions are Patterns of Enterprise Application Architecture (PoEAA) [Fow02],
messaging [HW03], remoting [VKZ04], and SOA [HZ06],[ZHvdA06].
In this context Zimmermann et al. [ZZGL08] state that ―a pattern is a proven solution to a
problem in a context, resolving a set of forces‖.
These researchers are explaining in their work [ZZGL08] that ―the context refers to a
recurring set of situations in which the pattern applies. The problem refers to a set of goals
and constraints that typically occur in this context and influence the pattern‘s solution, called
the forces of the pattern. To systematically explain how to apply a number of patterns in
combination, many pattern authors document patterns as part of larger pattern languages,
© Jan Ricken, University of Namur, Computer Science Department Page 66
containing rich pattern relationships and extensive examples and known uses sections.
Patterns in a pattern language are applied in an incremental refinement process. The decision
making in this process is based on the pattern‘s forces‖. In the architectural realm, these
forces include non-functional requirements and software quality attributes. Mostly, a
compromise needs to be found to balance the forces. Zimmermann et al. [ZZGL08] argue
further that ―the pattern describes how the forces are balanced in the proposed solution, and
why they have been balanced in the proposed way. In addition, the advantages and
disadvantages of such a solution are described as consequences. Applying patterns during
software design requires a broad view on how to select from a large body of patterns possibly
eligible for a particular domain. Patterns do not focus on a single, domain-specific solution in
a particular business context, but on generic design knowledge.‖ For instance, the INVOKER
pattern [VKZ04] describes how a middleware invokes remote objects in general. The pattern
applies to all kinds of middleware, but does not explain the specifics of INVOKERS in a
particular application context such as a specific SOA middleware implementation.
To illustrate the approach of using patterns, a case study worked out by [ZMCO04] was
suggesting six steps [BMR+96] to implement the BROKER pattern. The case study reports
about the issue to connect retail banks with a shared core banking backend provider. To
resolve technology mismatches between the heterogeneous systems, a SOA concept based on
web services has been implemented.
By definition, patterns are not the documentation of an individual system, but one source of
(reusable) architectural knowledge to be considered and brought to bear when architecting a
system. Therefore, applying a pattern is making a decision; the consequences of applying a
pattern engender more decisions. This links patterns to a decision model called ArchPAd
developed by IBM researchers [ZZGL08]. This is an architectural pattern-and decision-based
design method. They propose 4 refinement stages:
―The first stage deals with requirements analysis and executive decisions as entry points into
the architecture design work. The motivation for this stage is that some non-technical analysis
and planning has to happen before any technical patterns can be applied. Executive decisions
reside here. The runtime platform and programming language
In Stage 3, technological decisions are made and detailed design patterns are selected. For
instance, the six implementation steps in the BROKER pattern as described in [2BMR+96]
fall into this stage.
The case study was looking for the application of IBM‘s best practice by reusing architectural
decisions gathered during the different phases in various projects. Additionally, a tool has
been developed to integrate the gathered best practice architectural decisions [ZGK+07] This
© Jan Ricken, University of Namur, Computer Science Department Page 67
approach developed by IBM researchers is for sure an added value for a top-down SOA
method and will be considered as an enabler for the SOA domain model.
This section will show exemplarily one scenario for a process-oriented SOA implementation.
The objective of this case consists in introducing the reader to the principles of process-and
model orientation with a top-down design strategy as introduced in the first chapter as one of
the major concerns to address.
The case illustrates a fictive company looking for improvements in the order-to-cash process
which is a process that exists in all companies world-wide. The chief executive officer (CEO)
of CaseStudy INC. has the wish to improve the order-to-cash process because of internal
complaints from the financial division regarding the delay of sending invoices and the related
credit collection. A project with external consultants found out, based on an industry
benchmark, the cause for this delayed invoicing process was manual work and a non-
standardized billing process. Furthermore, no exception handling was in place to deal with
decisions on billing with a need to escalate to the top. The IT systems were also not able to
support in the best way the process as a lot of manual work and corrections were necessary.
Due to the innovative product and high level of service quality, the company has grown very
quickly without being able to update and reorganize the complete IT infrastructure and to
make sure that the business processes can be supported in an efficient way. Another weakness
identified, was the missing organizational link between production and finance. In order to
address all these issues (concerns), a SOA has been proposed to the stakeholder. A portal
should consequently be built to offer easy-to-use screens following the process logic through
different business divisions. The financial system and the production planning system
currently used can be re-used without being forced to purchase and integrate completely new
systems. Available and needed functionalities were analyzed and covered the requirements for
the new and improved process. The organization with a historical grown culture should step
by step merge from the ―silo mentality‖ to a more common view on processes with well-
defined interfaces and responsibilities.
For the strategic business model, several methods could be used. In this introduction, the
Balanced Scorecard (BSC) [KN92] [KN93] model has been chosen.
Has an
Influence on
Legend
In base level, within the Learning & Growth view, three objectives can be found, whereas
―Ensure IT capabilities for high quality support‖ has an influence on the other two objectives.
Because of SOA principles, processes can be improved (―Finance-to-Cash‖ and ―Production
Planning‖). These two improved processes will impact the customer satisfaction positively,
which means a high number or re-purchase rate. Finally, this has an impact of revenue
increase. The improvement of processes has also an immediate effect on cost reduction
objective. This type of (strategic) argumentation structured into a model is understandable for
executives and therefore a good communication and formalization possibility.
Each strategic objective is measured with Key Performance Indicators (KPI) and is related to
activities and/or projects to make the strategic objective happen. The connection down to the
abstraction level of processes can be made by linking the strategic objective to the process
(e.g. order-to-cash) in the process landscape.
The next deeper layer describes the design of business requirements in the form of a process
model. This view provides a high-level insight into the general operations of a company. The
high-level overview (figure 19) can be shown by a value-added chain diagram (VACD) and
specifies the functions in a company which directly influence the real added value of the
company [Por85]:
Legend
Process
In this specific case study the strategic objective ―Improve order-to-cash process‖ is directly
linked to the processes ―Order Management‖ and ―Invoicing‖ which is part of the primary
activities or core processes.
EPC‘s have been promoted by Scheer [Sche93] and are used to represent the „procedural
organization―[STA05] of the company, i.e. the links between the objects in the data, function
and organizational view and, as a result, the processes are represented. The procedural
sequence of functions is represented in process chains. In this context the start and end events
of every function can be specified. Events trigger functions and are the results of functions.
The conceptual foundation of EPC is based on Petri-Nets and PERT diagrams.
To allow more complex information on workflow, used data as input and output as well as
who is carrying out the functions and with the help of which systems, the EPC model
illustrates the details of the ―order management‖ function. As described in the strategic
objectives, we want to improve the process by replacing manual workload by automatic and
intelligent web-services. The business rules are modelled as operators allowing in this
example to formulate a decision path.
Legend
Sales Order
created
Supporting
Manual Function
Service
Position or Job
Sales Order
Received
Operator AND Operator XOR
Sales Order
Sales Order
Schedule
SYS SYS
SYS SYS
Production
Production Price o.k. Price not o.k.
Scheduling not
scheduling o.k.
o.k.
Production
Product
delivered to
customer
Sales Order
Create Invoice
Invoicing
SYS
SYS
Send Invoice to
Invoice customer
SYS
SYS
Invoice sent to
customer
Figure 20: EPC Model explaining the “To Be” Order Management process
Figure 20 illustrates the simplified billing process from a service oriented angle: events
formulate a decision in a certain point of time. Once the contractual details are fixed, the sales
order is created and sent by sales to the department billing & collection department (finance)
as well to production planning department. This is an incoming message for the finance
department and triggers the price calculation service and the production planning service.
Both functions are performed with the purchase order as entry and are supported by the
scheduling service and the invoicing service. For each, a manual control is done by the
divisions‘ supervisors. If production planning is fine, the production process is triggered.
© Jan Ricken, University of Namur, Computer Science Department Page 71
Once the product is delivered to customer, the invoice is created and sent to the customer
(outgoing message).
In the next step, the EPC process model is translated focussing on relevant information into a
BPMN model. This is necessary to add more technical information to the model. The logical
workflow is going through the pools of sales, finance (billing & credit collection), production
planning and production. Within those pools, actors will perform the different tasks. The
pools are separated by lanes.
The BPMN standard developed by BPMI [BPMI03] specifies a graphical notation that is
foreseen serving as a common basis for a variety of business process modeling execution
languages. The BPMN notation has been taken over by OMG and has since that time strongly
evolved (further details in chapter 2.2.5.).
Sales order
Sales Confirmatio Create Sales
Send Sales Order created and
n received Order
sent
No
No
Product
Receive
Production delivered to
Production Plan
... customer
Figure 21: BPMN Model explaining the “To Be” Order Management process.
Important is the definition of incoming message and outgoing message between the pools. If
the granularity of the service is too high, then decomposition is necessary. Different types of
sub-processes can be identified: ―embedded‖, ―independent‖ and ―reference‖. This needs to
be done with the goal to end on a level of granularity that allows re-using or creation of new
services.
The project team of CaseStudy Inc. decided to focus on the billing process as this was one of
the strategic objectives. The BPMN model helps now to identify the services required for the
execution of this process. One or more web-services (depending on granularity) can be
assigned to an activity. As the process is executed horizontally throughout the company,
different business divisions are involved which means that the improvement objectives are not
Another goal, but not less important, is to ensure that XML languages designed for the
execution of business processes, such as Business Process Execution Language for Web
Services (BPEL4WS or BPEL), can be visualized with a business-oriented notation. As the
utilization of re-usable services is a key criteria in SOA, the Web Services Description
Language (WSDL) will be used [W3C01], [Chi04]. WSDL is an XML-based, platform
independent meta language used to describe the interface definitions of a Web service. In
WSDL, the externally accessible functions of the Web service and the parameters and return
values of these operations are defined. WSDL describes the communication format in which
function calls to Web services are transmitted.
BPEL links WSDL descriptions into a logic process flow. A BPEL process is according to
this logic a bunch of service executions in a logical and timed sequential order. This is also
well known under the term ―service orchestration‖ [Bla03].
Following the project plan, BPEL Code with the integrated WSDL service description needs
to be implemented to make a process-driven SOA happen.
However, the reality in CaseStudy Inc. is that fully automated processes represent only a
small fraction of the processes that are actually executed. Most comprise manual activities
that must be carried out by staff e.g. the manual controls of price and production plan. In a
later phase, this could eventually be automated. A further problem is the performance of
complicated calculations or data transformations that are necessary for preparing or
processing the data used by the invoked web service. This issue needs to be solved by the IT
developers in the project.
The strict and deterministic Rules in BPMN allow the automatic generation of BPEL Code.
Tools with the ability to transform BPMN models into BPEL code (e.g. Visual Studio with its
integration platform BizTalk Server from Microsoft) are able to import, create, modify and
orchestrate web-services.
The case study focused just on specific aspects for a model-driven SOA implementation. In
such projects, many other decisions in areas like adapters, security, orchestration, technical
communication, transformation etc. need to be addressed.
Figure 22: Models & Standards for the introduction Case Study
© Jan Ricken, University of Namur, Computer Science Department Page 73
The dimension of data modelling has not been focussed on, as in general data modelling is
more advanced and mature than strategy or process modelling notations. In general, data
management is defined as [BD07]:
The fictive, but practical example has illustrated a top-down approach for SOA
implementation without using a particular SOA Method. A particular concern that needs to be
addressed is the model transformation mechanisms between the modelling notations on
different levels of abstractions.
Traditional software engineering methods are simply not adapted any more to the changed
requirements related to modern SOA implementations. Especially a risk of failure is the
increased number of stakeholders with potential conflicting business needs [Ars04], more and
more dynamic environments and issues of decision-making between design-time
environments and run-time environments need to be considered.
Novel techniques must be developed to support the refinement from the early phases of
requirement analysis to the final steps of implementation and deployment. Similarly, novel
techniques must be devised to construct compositions of web services that at run-time can
provide feedback and significant information to business analysis and stakeholders, who can
use this information to devise new business strategies or take strategic decisions at design
time [IEEE00].
The lack of method for SOA construction, identified by Papazoglou, Traverso, Dustdar and
Leymann in the ―Service-Oriented Computing Roadmap‖ [PTDL06] as the main challenge for
SOA, is a key academic driver for the present thesis.
Therefore, this thesis will propose a coherent method to implement SOA using a situational
ME approach, taking into account strategic business aspects. The expectations on such a
method will depend of the enterprise context, enterprise size, enterprise industry, etc. The
enterprise context (e.g. the financial situation, enterprise culture, IT maturity and IT
competencies) will drive the expectations towards a SOA implementation. The enterprise size
will also have a big impact on the potential savings that can be achieved, whereas the
enterprise's industry and the business model will also influence the expectation. Generally
speaking, the bigger and the more complex a company and the supporting IT is, the higher the
The objectives of this first steps are to (i) oversee SOA implementation methods with their
capabilities (ii) to identify a list of sub-domains to consider for a SOA implementation (iii) to
summarize the identified SOA sub-domains into a SOA Domain Model.
or
Creswell [Cre98] is stating that ―Method refers to more than a simple set of methods; rather it
refers to the rationale and the philosophical assumptions that underlie a particular study.‖ and
―Another key (though arguably imprecise) usage for method does not refer to research or to
the specific analysis techniques. This often refers to anything and everything that can be
encapsulated for a discipline or a series of processes, activities and tasks.‖
Methods in and of themselves are meaningless without clear expectations. Expectations can
include terminology definition, process or procedure guidelines, etc. It will not matter how a
problem is approached, if the expectation on the method was not defined and its achievement
evaluated, the solution is worthless.
and
With these definitions in mind, we will analyze different proposals and evaluate them in a
structured way.
To be able to propose a sound method, it is first necessary to analyse and structure available
SOA implementation methods. Therefore, a set of approaches known in academia and
practice have been carefully analysed.
Generally, the listed methods have very different viewpoints and focus such as high-level vs.
detailed, functional vs. technical, academic vs. best practice, non-profit vs. profit organization
and top-down vs. bottom-up. These viewpoint(s) depend strongly of the origin of the author.
The table 12 gives an overview of available approaches identified as relevant for SOA and
studied in general in alphabetical order:
Flexibility without control can hardly be considered a method, since any systematic and
coordinated approach to establishing work methods is absent. For such an approach to be
systematic and coordinated requires the technique of ME [BLW96]. This section is
introducing the details about ME and is preparing the ground for chapter 4 for the creation of
research artefacts. First, situational ME is explained. Second, the formalisation mechanisms
for process fragments are explained.
ME and Situational Method Engineering (SME) in general propose a way to formalize how
method can be used for various developments. Following to Brinkkemper [Bri96], ME ―is
defined as the engineering discipline to design, construct and adapt methods, techniques and
tools for systems development.‖ Following to Henderson-Sellers and Ralyté [HSR10], SME
can be considered as a component of ME, which ―encompasses all aspects of creating a
development method for a specific situation.‖ During the analysis of available methods for
SOA implementation, methods turned out to be not complete, difficult to apply and simply
not flexible enough. Therefore, SME seems to be the solution to the problem of an
engineering method being the best appropriate for specific organization with its SOA
implementation project. The modular method construction as presented by ME allows
selecting predefined method fragments that are matching to the context and objective of the
project. All method fragments are stored in a method database. These method fragments are
assembled using rules depending on the specific project decisions the project manager will go
for. With this approach, an effective, efficient, complete, and consistent method for SOA
implementation is intended to be achieved.
Once defined, this fragment is stored in a method database. When these method fragments are
used for a specific project application, they need to match to the specific project
characteristics. Rolland & Pracash [RP96] are arguing that further information is needed ―for
the usage context‖ of these fragments. Context is defined as a pair of ―situation and decision‖
Therefore, the further description or knowledge of these method fragments is describing the
situation and the decision in which the fragment could be relevant.
Mayer et al. [MCFKP+95] illustrate the ME process (using IDEF3 notation) as follows:
Initially a motivation document should argue (1) on why a new method is required (specific
user needs, shortcomings, improvement opportunities etc.) then (2) searching what methods
are available to (3) re-use existing methods and/or (4) tailor them in order to satisfy needs or
if adopting (3) and tailoring (4) cannot satisfy needs, then the development of new method (5)
becomes necessary. The methods should then be designed (6) and (7) tested to finally
iteratively refine (8) the method.
In the context of the present thesis, we will be in favor for the situational method as we need
to apply the method to the project environment, context and objectives. Therefore, a
configuration process is guiding the assembly of these building blocks into a situational
method. Figure 24 illustrates this process and has been adapted from Brinkkemper [Bri96]:
Method fragments can be distinguished into two kinds: product and process fragments.
Product fragments model the structure of the products (deliverables, diagrams, tables, models
etc.) of a SOA implementation method. Process fragments are tasks to support the solution
path for issues or questions to resolve. In other words, process fragments represent phases,
activities and tasks to be carried out. The term ―method chunk‖ used by Harmsen [Har97] and
Ralyté [Ral99] needs to be understood as the combination of a process fragment and a product
fragment which are tightly coupled. In this present thesis we will stay with the term of method
fragment as described in figure 25:
Method Fragment
ID
Name
Description
Purpose
Discipline
Mandatory Input Condition Fragment
Mandatory Tool Condition
Alternatives
1
includes 1
1..*
Process Fragment
Name includes
Brief Description
Purpose
Main Description
Key Considerations 1..*
Alternatives Product Fragment
Steps Name
Role(s) Brief Description
Mandatory Input(s) Purpose
Optional Input(s) Main Description
Output(s) Key Considerations
Guidance Guidance
Discipline Discipline
1..* is input/output for 1
Figure 25: Method Fragment is containing Process Fragment and Product Fragment
© Jan Ricken, University of Namur, Computer Science Department Page 79
Conditions or business rules are important for every process fragment, because they are
specifying constraints [Bri96] and can influence strongly the process fragment or even stop it
in some cases. A business rule is therefore a necessary or required condition or prerequisite.
The attributes will be explained in detail in chapter 4 when the alignment between the SOA
Domain Model and ME is done.
ME and SME is a very broad field and actual research directions [HSR10] such as ―how to
best gather requirements and how to move from requirements to semi-automated or
automated way of identifying the optimal collection of these fragments‖ are named.
Furthermore, most of researchers have looked at creating method fragments from scratch, but
how to formalize existing methods and to drive software vendors and consulting organizations
to formalize and provide their methods in SME method fragments to cope with quality
concerns such as consistency and completeness are so far not explored in detail.
In order to create efficient representation of method fragments, the UML profile extending
UML for the specific domain of fragment description is used. Software Process Engineering
Metamodel (SPEM) [OMG08] is a meta-model and an UML profile that has been defined for
standardizing software engineering process.
SPEM 2.0. is a highly formalized UML Meta-Model and is the ―de-facto method‖ for ME
application and therefore the meaningful parts out of this concept is used. The concepts of
SPEM 2.0. related to ―Method Content‖ and ―Process‖ will be used to demonstrate the
application. The SOA Domain model can therefore be considered as ―input‖ information for
the formalized application of ME.
SPEM 2.0. Meta-Model is compliant to MOF Meta-Model and is re-using UML2 notation.
Furthermore, SPEM 2.0 is containing a Meta-Model and an UML profile as well. SPEM 2.0
separates reusable core method content from its application in processes. A development
process defines the structured work definitions that need to be performed to develop a system,
e.g., by performing a project that follows the process. Similar to SPEM 2.0., other ME meta
models exist e.g. ISO/IEC 24744/2007 initially developed by Gonzalez-Perez and Henderson-
Sellers [GPHS08] and could also be used instead. Using SPEM2.0. in this thesis is related to
tooling on-hand with Eclipse Process Framework (EPF) [Eclipse09]. The tooling capabilities
are further explained in section 5.3.
Name
Brief Description
Purpose
1..* is input/output for
Main Description 1 Product Fragment
Key Considerations Name
Method Fragment
Alternatives Brief Description
ID
Steps Purpose
Name
Role(s) includes Description includes Main Description
Mandatory Input(s) 1 1..* 1 1..*
Purpose Key Considerations
Optional Input(s) Guidance
Discipline
Output(s) Discipline
Mandatory Input Condition Fragment
Guidance 1..*
Mandatory Tool Condition re-use
Discipline
Alternatives 1
1..* Capability Pattern
includes
1
Name
Activity 1..* 1 Brief Description
re-use
Purpose
Name
Main Description
Key Considerations
1..*
Alternatives
The capability patterns are a group of activities, which can be re-used in a specific context.
The attributes used specify purpose, description, key considerations and alternatives that
could be used. The work is re-using two patterns which are strategy modeling and CIM
© Jan Ricken, University of Namur, Computer Science Department Page 81
modeling top-down. Therefore, these patterns can help ensuring easier re-use of best practice
already identified as successful and efficient on other cases.
Table 14: Attributes of Activity Class
The activity term is used to ―neutralize‖ the specific semantic used for the fragments. It is
necessary to provide a common or objective understanding of general activities. Activities are
linked to one or more available fragments proposed in order to solution the underlying
question raised. Following to Weerd and Brinkkemper [WB08], activities are used for
capturing the process-view of a method.
The method fragment is linked to activity and needs to be explained. A method fragment is
containing process fragment and product fragment allowing the method engineer to
understand, where this method fragment is coming from and to what discipline it is linked to.
Mandatory input conditions, tool conditions are important to understand potential impact.
The process fragment is part of the method fragment and describes the details of the process
fragment with name, brief description, purpose, main description, key considerations,
alternatives, steps, roles, mandatory input, optional input, output, guidance and discipline.
Similar to the process fragment, the product fragment is creating an artefact which will help to
resolve the raised question. The product fragment is part of the method fragment and is input
or output for the process fragment.
The following table is matching the terms between the ME definitions and definitions used in
SPEM 2.0. This table is necessary to unambiguously identify corresponding definitions and to
align on used semantics.
The example description is further explaining how these terminologies need to be understood.
A key step in the proposed configuration process is the selection of method fragments. These
fragments need to be assembled and combined in such a way that the outcoming situational
method does not contain any defects or inconsistencies. Several types of defects can appear
[Hid93]:
Inconsistency, which is the case if the selection of a method fragment, contradicts the
selection of another method fragment. For instance, two similar data modelling
techniques have been selected without any additional reason.
All these issues relate to the internal or situation-independent quality [HH95] of a situational
method, i.e. the quality of a method without taking into consideration the situation in which
the method is applied. The two most important criteria are [BSH99]:
Completeness: ―SME includes the method fragments that are referred or linked by
other fragments in the situational method. Completeness is decomposed into: Input-
Output completeness, content completeness, process completeness, association
completeness, support completeness.‖
© Jan Ricken, University of Namur, Computer Science Department Page 84
Consistency: ―all activities, products, tools and people plus their –mutual-
relationships in a situational method do not contain any contradiction and are thus
mutually consistent. Consistency is decomposed into: Precedence consistency,
perspective consistency, support consistency, granularity consistency, and concurrence
consistency.‖
In order to cope with the ME quality requirements for method assembly, it is necessary to use
a Computer Aided Method Engineering (CAME) tool including a Method Engineering
Language (MEL). This specific language should be able to support the method assembly
(project characterization, fragments selection, choice validation, fragments assembly,
situational method consistency check) and provide some generation engine (help & training
facilities generator, tool infrastructure generator, project mgt. facilities, activity generator and
project repository generator) [Bri96].
To current state, the tool MetaEdit+ developed by Kelly, Lyytinen and Rossi is not able to
provide method assembly functionality yet [KLR96]. Mr. Juha-Pekka Tolvanen being the
CEO of Metacase company confirmed on request that assembly techniques are not available
in acceptable maturity to present state. Taking the non-availability of assembly tools neither
the objective to create a domain specific language (DSL) in the present application case, a
freely available and broadly used tool integrating SPEM2.0. was available at hand to be used
as technical infrastructure for the application of method fragments. This will be explained in
detail in chapter 6 tooling and prototyping.
As method users can understand method rationale differently, it is required to explain them a
bit further. It can help to explain better, why a rational has been used. The details allow the
method user more explicit and detailed understanding of the application and therefore the user
can then better decide, if the rationale should be applied in his own context or not. Tolvanen is
explaining that ―the rationale of method use is normally not well documented because tools
do not allow the capture of decisions about method use; only decisions about design choices.
Therefore, it is the task of method engineers to collect the rationale of method use.‖ [Tol95].
Jarczyk et al [JLS92] explain that ―a design rationale is the explicit listing of decisions made
during a design process, and the reasons why those decisions were made.‖ Following to
Horner and Atwood, [HA06] ―the primary goal is to support designers by providing a means
to record and communicate the argumentation and reasoning behind the design process.‖
Therefore, Lee [Lee97] explains what should be included in design rationales:
The way how design rationales are represented, as the capture and usage should be as efficient
as possible. Lee is arguing that three categories (formal, semi-formal, informal) exist. All type
of recording are possible, but e.g. for formal design rationale, a computer must be able to read
and process the design rational. If this is the case, the design rationale can hardly be
understood by human beings [KR70].
In the present work, we will use a more semiformal representation which should combine the
strengths of a formal and an informal representation. Semiformal representations try to
combine the advantages of informal and formal representations. Lee [Lee97] is arguing that
―on one hand, the information captured should be able to be processed by computers so that
more computer based support can be provided. On the other hand, the procedure and method
used to capture information of design rationale should not be very intrusive. In the system
with a semiformal representation, the information expected is suggested and the users can
capture rationale by following the instructions to either fill out the attributes according to
some templates or just type into natural language descriptions.‖ [Lee97]. Again, we stick to
SPEM standard rationale descriptions, which are implemented as specific attributes in a
formalization tool.
We will re-use ME later in section 4.2. for the purpose of formalizing available SOA methods
into method fragments to populate the method fragment database.
The chapter on literature review was done with the purpose to elaborate and prepare the
presented research questions posed in the first chapter. First, the viewpoint of a TD-MD-PO
was explained in sections 2.1. to 2.4., second the objective of SOA Engineering Method was
prepared through sections 2.5. to 2.6.
The chapter has introduced EA as starting point and underlined the viewpoint approach on
different levels of abstraction. It was shown what EA methods are available and how the term
―domain‖ has been defined and applied to the research subject. Modelling languages
supporting the process-oriented approach have been analysed and classified on the different
levels of abstractions. Interfaces between abstraction layers and model transformation
mechanisms have been analysed and explained.
SOA and the term ―SOA heartbeat‖ has been explained and defined in the introduction. Next,
available SOA implementation methods were listed and will be qualified through the SOA
Domain Model in chapter 3. Finally, ME with its basic concepts has been introduced to
explain the value for an efficient SOA implementation method application for situational use
as present or available methods do not offer a situation specific approach.
Chapter three is detailing and focusing on the original research contribution of this thesis.
First, an overview is provided by showing how the contribution chapter fits to the indicated
research questions in the introduction and which artefacts are created. The value of these
artefacts is described (section 3.1.). Then the details are explained in depth by starting with
the SOA Domain Model (section 3.2.). The 5 domains of the main contribution ―SOA
Domain Model‖ are identified, defined and the SOA context is discussed. Once the domains
are defined, they are used to create the SOA Domain Model which will then structure the
analysis of selected methods. The methods are qualified and positioned through the SOA
Domain Model.
Next, an evaluation of research artifacts by data collection through survey design is done to
complete state-of-the-art with practitioners‘‘ feedback (section 3.3.).
© Jan Ricken, University of Namur, Computer Science Department Page 87
The following overview model in figure 27 is illustrating the big picture on the research
contribution in chapter 3 (artefact 1 & 2) and chapter 4 (artefact 3 & 4):
The value provided by resolving the posed research questions in chapter one has been
detailed. Nevertheless, we will quickly remember the key value contribution areas in brief:
1. The SOA Domain Model (Artifact1) summarizes sub-domains required for SOA
implementation. This SOA Domain Model enables the qualification of existing SOA
Methods and finally also directions on method capabilities (Artifact 2).
As the term ―domain‖ and ―conception‖ has been defined in section 2.1.2., we consider
―conception‖ as the SOA Method and the ―domains‖ as any subsets related to this conception.
A first attempt to conceptualize the different subjects encountered through desk review and
structuring them into domains has been done to visualize the state-of-the art. This is a
personal view, where clusters have been created as a first attempt to structure the
overwhelming number of terms, issues, criteria‘s etc. If all domains around the proposed
conception of SOA Method are taken together, the following landscape can be drawn in a
non-formalized mind-map:
The domains have been gathered through the analysis of the state of the art of SOA methods
and the principles of applying a model-driven and process-oriented implementation approach.
Figure 28 enumerates domains and components relative to the proposed conception of ―SOA
Method‖.
The formalized SOA Domain Model presented in the next sections is structured into a table
format, which is easier to oversee and exploit. Also sub-domains have been created to
facilitate the structure of the model. These sub-domains are sub-groups within the domains.
The SOA Domain Model is an artifact from this thesis which includes 5 different SOA
domains. The respective SOA domain is including sub-domains identified in the state-of-the-
art and described in detail in section 3.1.
The SOA sub-domains are further described by a unique number, definition and the context to
be applied for the SOA situation. The sub-domain is defined in general and then a description
with SOA context is given. Furthermore, questions to be resolved are explained.
This SOA Domain Model (table 21) is a summary of the state-of-the-art for a process-oriented
and model-driven SOA Implementation. Each of these 5 domains is including sub-domains in
the context of a SOA implementation project:
Each sub-domain is rapidly defined to ensure a common understanding and is then explained
in the context of SOA method application. As already emphasized in the introduction, only
the domain ―Modelling‖ will be detailed and method fragments created. The interrelationship
between sub-domains and deeper layers (here: activities) will be introduced and explained in
detail in table 22.
The SOA domain ―modelling‖ is grouping all sub-domains relative to models created and
used in SOA engineering.
The issue to resolve in the context of SOA is to select the best suited modelling languages for
representing ideal candidate notations to use for SOA implementation. On each level of
abstraction, different models (refer to definition 19) are available and need to be evaluated for
the best path to follow. Some modelling notations are more suited or used than others. This
has been explained in detail in section 2.2.3. Between strategy and process layer, the issue of
bridging between models is essential, whereas for process and IT layer the specific
characteristics of model language (process language and implementation language) becomes
more important (section 2.4.). The notations on the strategic abstraction layer can hardly
adhere to all of the three criteria‘s (syntax, semantics and automation) as automation is very
difficult to achieve. Business Rules, Events and organizational information are an important
part of (process) modelling notations as they indicate when activities are triggered, by whom
and how exactly specific rules need to be applied. Method fragments will later in the method
application create artefacts, which are instances of e.g. EPC or BPMN models which are
resolving a specific issue on each level of abstraction. These artefacts are then called ―product
fragments‖.
Directly related to modelling notation is the underlying issue of Meta Models. We will not
consider meta models as a separate issue item as they are differentiation criteria of various
models. A meta-model does not in general describe a process but the abstract syntax of a
language. It is a model of models (expressed in one language) and as such describes all
possible models expressible in that language (=syntax). Furthermore, every meta model is
based upon another meta model whereas flexibility and reuse are important criteria‘s for the
modelling languages to be used on a high level of abstraction [Gru93][Gru04].
Meta models become important in case of translation or mapping of languages to other model
languages on same abstraction level (e.g. UML class diagram, BPMN, EPC) or between
different abstraction levels (business process notations vs. implementation notations).
Modeling notations relying on meta models can help to translate these notations easier
because they are more formalized than languages without. On the other hand, notations
without meta-model are often also well described through conventions (objects to use,
symbols to use, attributes to use, connections to use, how to model etc.) and specific
mappings or translation mechanisms are proposed in academia. UML class diagram with
MOF is the most known and used meta- model. EPC and BPMN have meanwhile also
reasonably formalized meta-models, which allow also better interfacing to other models
related to the model transformation problem.
Mata data is an important issue to resolve as web-service will need to create, read, update and
delete metadata (CRUD) in the repository. Therefore, metadata needs to be under control
through data governance and reliable tools. Data as input or output for a business service is
crucial to describe in processes (e.g. EPC, BPMN, UML-class etc.). Data models can help to
repertorize data and to show relationships between each other (e.g. UML-class diagram, ERM
etc.) A specific meta-model for metadata has been developed by the OMG and is called
© Jan Ricken, University of Namur, Computer Science Department Page 92
Common Warehouse met model Specification (CWM) [IEEE00]. These models become
important for applying MDA as formal models need to be transformed by generators.
In order to be as efficient as possible with the effort to conceptualize SOA strategy and
business processes and then to translate business requirements into web-service description
and implementation, the question of how to interface the different kinds of models is crucial.
If MDA principles are applied, the transformation (refer to definition 30) between models can
become real. Therefore, the notation itself is important (relying on meta model) but also the
tool allowing a transformation between models. The automation of information exchange and
the so called ―round trips‖ is in an automated way so far only possible on the deepest level of
detail within the UML family of notations and tools. MDA principles do claim to translate
formal machine readable process and data models to code via code generators. The
investment in MDA can pay off since the PIM and PSM abstraction levels are addressed. By
MDA principles, a huge issue discussed in academic and industrial world known as the
―exchange problem of semantic information‖ between layers is addressed. Code generators
are usually used to understand the semantics described in modelling languages to translate
into code (XML, WSDL, UDDI, SOAP) [IEEE00].
Projects managers and architects need to carefully evaluate the different approaches (refer to
definition 6) such as e.g. top-down, meet-in-the-middle, bottom-up upfront to ensure a
successful SOA implementation (in time, in budget, in required quality) meaning to spend the
optimal amount of resources. Terlouw et al [TTJ09] have defined a so called ―Delivery
Strategy Assessment Method‖ (DSAM) determining the most appropriate SOA delivery
strategy for an organization as introduced in chapter one.
Each SOA Domain can be further detailed with generic activities to be performed and related
artefacts. The term ―activity‖ has been introduced in section 2.6.3. Basically, the term is used
for generic activities, which would be required for a SOA engineering method. These
activities have been gathered through the state-of-the-art on SOA Modelling. The related
artefacts are indicating what outcome could be expected. Mostly, it is a model, which is an
outcome of this specific activity. This will be fine-grained and further explained in in table 15
which is formalizing the identified sub-domains into ―activities‖.
In order to overcome the issue of specific method fragment semantics, an important term of
―activity‖ is introduced.
As this thesis is focussing on the SOA Domain Modelling, only the activities and artefacts of
this domain are enumerated in table 22. These activities are finally producing artefacts, in this
case different type of models based on different notations. It could be well imaginable to
detail similarly to the Modelling domain also other domains in future works (Chapter 7).
The SOA domain web-services is grouping all sub-domains relative to web-service aspects.
This domain will not be detailed and applied to SOA fragments.
The issues are more technical nature to ensure a proper functioning between the three actors
with an ESB integration between Service provider and Service consumer. For the definition,
pls. refer to definition 5 in the introduction.
There are many approaches to defining enterprise business architecture. Some architects base
their interpretation of business architecture on a corporate organization. A business function
or process model can be used as a starting point to draw connecting lines between vertical
functions and horizontal processes to describe a cross-functional process within the business.
The key component of a business model is the description of the enterprise business
processes, which defines their supporting activities, inputs, and outputs. Process activities
provide the foundation for defining the enterprise services. Using the business model as the
starting point in decomposing the solution into services facilitates the alignment between
business and technology—one of the objectives of the SOA approach. Decomposition is a
well-established technique. Depending on the objective, many decomposition criteria can be
applied. The decomposition criteria have a significant impact on architecture goals such as
performance, flexibility, comprehensibility, development time, changeability and reuse
[Lub07].
SOA patterns & best practice are preconfigured processes and embedded web-services to
import into the BPM design tool or the BPM run-time tool.
Patterns and best practice can help to realize efficiency gains, meaning not to invent
everything from scratch. The issue related to this is that these preconfigured proposals are
rather generic and not necessarily on the right level of detail than what is expected or needed.
QoS for web-services is defining the level of real time availability and performance metrics
and is measured through a service-level agreement. A quality system is supporting
deployment, configuration, versioning, monitoring, management and auditing of web-
services.
To achieve the QoS defined by the business, each service endpoint should be managed as a
resource. This includes the invocation of services (service consumer) as well as the
© Jan Ricken, University of Namur, Computer Science Department Page 95
application functionality exposed as a service (service provider). When down, the
management tooling should provide a means of troubleshooting, and, better still, a method of
monitoring and alerting of issues before failure.
SLA is a contract or product fragment which describes in detail the expected levels of services
(for web-services e.g. performance, downtime, etc.) or business requirements in order to a.)
improve service levels and is b.) used as baseline for measuring the service performance (e.g.
metrics like processing time, messages per hour, rejected transaction counts and queries per
day) between service provider and service consumer.
Agents can be deployed to gather the desired metrics, and code can be added to applications
to process these metrics and behave accordingly. In practice, this is rather difficult, because
service end points may be added or changed. New services might be offered or existing
service levels need to be improved. Therefore, a process needs to be implemented in order to
enforce policies (per message basis, policy compliance verification etc.) [CH06].
The SOA domain ‖BPM‖ groups all sub-domains relative to process management aspects.
This domain will not be detailed and applied to SOA fragments.
Brocke and Rosemann [BR10a] in their Handbook of BPM, the management of this approach
is focusing on aligning all aspects of an organization with the wants and needs of clients. It is
a holistic management approach that promotes business effectiveness and efficiency while
striving for innovation, flexibility, and integration with technology. Business process
management attempts to improve processes continuously. Supporting business processes
using methods, techniques, and software to design, enact, control, and analyze operational
processes involving humans, organizations, applications, documents and other sources of
information [vdAtH05]. It could therefore be described as a "process optimization process." In
general, BPM will enable organizations to do ―the right things right‖ meaning to be effective
and efficient.
Business process knowledge is the summarized information about business process content in
order to efficiently improve the process by applying web-service technology. This can
materialize in guidelines, procedures, databases, human knowledge etc. The knowledge and
experiences need to be made available to be exploited in an efficient manner.
A generic software system that is driven by explicit process designs to enact and manage
operational business processes. The system should be process-aware and generic in the sense
that it is possible to modify the processes it supports. The process designs are often graphical
and the focus is on structured processes that need to handle many cases [AHW03].
For SOA implementation, an important task is to find the appropriate tool to execute process
and to enhance the process with needed web-service descriptions, orchestration information
and business rules execution. The platform independent models need to be exported into the
technical environment. Once web-services are deployed, the technical BPM system needs to
provide testing functionalities as well as performance monitoring as input for SLA
measurement.
The SOA domain ―Tool‖ is grouping all sub-domains relative to useful tooling for SOA
implementation. This domain will not be detailed and applied to SOA fragments.
A BPM design time tool used in the SOA context is providing the design facilities to model
different types of models on different abstraction levels in order to define business services
and to translate them into web-services.
A BPM run-time tool for SOA is providing the tool support to implement, test, execute,
simulate and control processes including the related web-services.
The integration of design tool and run-time tool is key. Interfacing models from design layer
into execution layer should be possible. The functionalities need to support the
implementation, testing/simulation, execution and control of processes including web-services
and business rules.
3.1.6.3. Sub-domain 4.3. SOA Project Mgt & Change Mgt Tool
A project management tool is supporting the project manager with planning organizing and
managing resources of project (activities, time, cost, dependencies) and execution of project
(Status on progress) to meet specific SOA project goals and objectives.
A change management tool is supporting the project manager to ensure all changes are
assessed, approved, implemented and reviewed in a controlled manner.
The project manager needs to be supported by a flexible tool allowing him the construction of
a situation-specific project method depending on requirements of the organisation such as the
guidance on the different issues mentioned through the SOA Modelling Domain and the Web-
Service Domain. Project manager needs also this tool for communication purpose in the
organization such as e.g. evangelization about the SOA topic, training preparation and to
communicate between the various different types of profiles needed for this specific type of
project.
3.1.6.4. Sub-domain 4.4. SOA Process & Web-Service Simulation and Testing
Process & web-service simulation tools is about providing a system to support assessment,
control and testing processes and web-services related to business requirement fulfilment
(functional testing) within an acceptable performance (technical testing).
The system functionalities needed should be integrated into the BPM & Web-service run time
environment. Simulations can be very helpful and value added. The extent needs to be
decided on. The risks to mitigate are important: If web-services are released without thorough
testing, showing malfunctions or non-performance, business users or clients will be upset and
business support for the project will be seriously damaged.
The SOA domain ―Project‖ is grouping all sub-domains relative to project management
aspects. This domain being will not be detailed and applied to SOA fragments.
According to BPtrends [IA07], a SOA maturity model is used to assess the current state of
SOA adoption of an organization. The model is used as a yardstick to take stock of AS-IS
state and develop a transition plan to lead the enterprise to the TO-BE state. The ultimate aim
would be to achieve optimized business services that can nimbly adapt to changing business
scenarios.
The issues to clarify are related to the decisions on scope of SOA adoption (Department,
Business Division, Cross Division, Enterprise Wide), SOA Maturity Level (capabilities of the
architecture e.g. initial services, architected services, business services, measured services,
optimized services). Furthermore, it needs to be decided what progress is planned or to be
achieved on timescale e.g. different stages to achieve. This is linked to culture, budget, risk
appetite etc. Buckow et al [BGPPW+10] have analysed and evaluated available SOA
Maturity Frameworks (ACMM, Inaganti/Aravamudam, Sonic, Oracle). Based on the SOA
Maturity Framework reviews, they have also developed a framework to analyse SOA abilities
of available standard platforms on the market.
Leusse, Dimitrakos and Brossard [LDB09] are defining the SOA Governance as ―processes
with roles & responsibilities used to oversee and control the adoption and implementation of
SOA. This governance is using recognized practices, principles and government regulations in
order to provide optimum service quality, consistency, predictability and performance of web-
services through the application of policies.‖
There are two areas to address: a.) the governance process of web-service implementation
during the project and b.) the set-up of the service level agreement with the objective to
control, measure and improve web-service. Within the governance set-up, roles &
responsibilities need to be created, control processes have to be implemented and finally to be
assessed during the implementation. On-going measurement of web-services is also an
important process. The SOA heartbeat as introduced in chapter 1 with registry, service
consumer, service provider needs to be managed based on efficient policies. Furthermore, the
costing model needs to be measured based on the SLA.
SOA objectives are targets to be achieved to reach the quantified benefits or benefits that are
not possible to quantify for the SOA projects. SOA critical success factors enable the easier
achievement of these objectives. The SOA Return of Investment (ROI) is the quantification of
benefits in relation to the overall cost.
The provided approach in this thesis will facilitate this task to identify the relevant process
fragments and related product fragments following the principles of the method engineering
approach. This is important as we will later re-use the term ―SOA phase‖ within the method
engineering method. The SOA phase decomposition for the application here is done on 9
generic phases. These phases are:
The introduced SOA Domain Model is a reference model that is describing domains and sub-
domains as defined in the introduction under the premise of a process-oriented and model-
driven architecture. These domains structure or cluster a group of topics, which are relevant
when SOA is implemented. For sub-domains very precise activities can be defined, which are
producing artefacts. These activities can be done, but at this state, there is no indication in
what context these activities apply and what conditions are related to it.
The outcome of this section will show how the SOA Domain model will serve to evaluate
existing methods on domain completeness and underline the initial research need of defining a
SOA engineering method. There is none of the available SOA Methods using ME principles
The exhaustive analysis and evaluation of all existing methods and pieces of information
would take too long fearing the added value would be limited for the huge time-investment
needed. This does not mean that pieces of information towards specific topics are not
valuable, but the objective in this section consists in showing how the SOA Domain Model
can be applied on ―SOA implementation methods‖ and that available proposals are not
covering the complete span of the SOA Domain Model. Also, some industry-specific SOA
methods exist e.g. for education [BGLOS+09].
In order to select relevant methods for the detailed analysis, some need to be discarded as they
do not fit within the proposed definition of method. The definition of method is around
phasing and grouping activities in a plan, to use modelling to abstract from the very complex
reality related to a specific chosen viewpoint [ISO06a] and to recognize the necessity of tools
to work efficiently and to cope with complexity. As defined by Kruchten [Kru95], he
introduced the definitions of ―conception‖ and ―domains‖. In his terminology, ―conception‖
corresponds to the SOA Method and the ―domains‖ correspond to ―any coherent subsets of
issues related to this conception.‖ This is the reason why software engineering methods were
not included into the analysis as they have not SOA as a conception.
To justify the choice, table 23 is summarizing the methods in a table evaluating if the three
defined criteria are met and - finally cope with the proposed definition:
Third, by tools we understand the possibility to use any software tool helping to
structure, formalize, re-use and facilitate methods and models. It should be mentioned
how a tool can contribute to this.
Table 23: Selection criteria’s for current SOA Methods
Therefore, the following SOA implementation methods from the analysed list meet the 3
criteria‘s:
These candidates have been carefully analysed along the domains of the SOA Domain Model
with the objective to compare them in a structured way and to evaluate on which dimension
the methods are strong or weak meaning if and how activities mentioned earlier as subset of
criteria‘s in specific domains are addressed or not. The criteria‘s are further detailed by
activities as illustrated in table 22. The activities are a rather complete view of the sub-
domains. The completeness of a method for a particular sub-domain is not dependent of
addressing all activities rather than proposing a consistent and logical
view/approach/explanation.
A sub-domain was not covered at all, meaning that the method is containing no sign or
evidence that this topic has been addressed or considered (= No Star). Second, the sub-domain
was partially covered. This includes an explanation on what it is about but only on high-level
of detailand no advice is given on how to solve it (= 1 star). Third, the sub-domain was
largely covered (= 2 stars) meaning that the sub-domain was explained in detail.If a sub-
domain was alomost fully covered (= 3 stars) meaning the sub-domain was almost fully
covered with also an explanation or recommendation on possible solutions.
In order to mitigate risks of subjective comparison, the marks have been applied in the most
objective manner as possible.
The sections 3.2.2. to 3.2.8. are providing a condensed description on the evaluation of each
existing SOA Method, which is summarized at the end in an overall comparison table. For
space reasons, the details per method can be found in the Annex B. However, the first two
methods are detailed on the SOA Domain ―Modeling‖ sub-domains which are 1.1. SOA
Modeling Notation, 1.2. SOA Model Transformation, 1.3. SOA Modeling Strategy. These
two methods will be used to exemplarily show how method fragments can be formalized
(section 4.2.) and applied in case studies (chapter 6).
The method from IDS Scheer (Software AG) is based on their companies‘ roots, which is
BPM with an academic background. The developed ARIS Toolset was the first application in
the early eighties being able to introduce different views and modelling languages. The
method AVE for SOA is derived from the method AVE for BPM with the different
application scenarios.
The method is strong for the modelling part, as different model types (+150) depending on
viewpoints is integrated in one tool. A weakness consists of giving just high-level advice on
how all these models fit together from an SOA perspective. As the SOA Method is directly
related the state-of-the-art modelling tool [GAR11],which is positioned in the leading
quadrant of GARTNER‘s market analysis, the domains ―Modeling‖ and ―BPM‖ are very well
developed (see appendix B for details). Unfortunately, important topics e.g. the link to MDA
levels is not made neither a proposition of Enterprise Architecture with conceptual levels.
BPM component is also rather strong but only for knowledge and business BPM. The
technical side is left to vendors with tools for BPM Run-time without explanation. Also, on
the tool side, Design Time is very strongly elaborated, whereas Run-Time and SOA
Performance & Simulation are weak areas. An integration with Software AGs webMethods
execution engine is planned but not mature yet. The domains ―SOA project‖ and ―Web-
Service‖ are also weak points of this method because only SOA phasing within a project and
some issues about SOA governance are explained.
Related to the SOA Domain Modelling, the following criteria‘s have been rated as follows:
This method is focussed on the ERP (SAP) environment. The method explains how web-
services in an architecture that is driven by SAP technology can be implemented. This is the
reason why the domains ―modelling‖ and ―BPM‖ are much weaker than the domains ―Web-
Service‖, ―Tool‖ and ―SOA-Project‖. The explanation around Enterprise Architecture with its
different layers is a big strength of the method. Again, here the method is related to SAPs
technology vision around their service enabled platform XI with SAPNetWaever. In the
update of the method [SAP08] TOGAF is recommended for capturing Enterprise
Architecture. The Configuration Environment (CE) allows a process-oriented approach
starting with BPMN notation. This BPMN modelling is done in the ―design-time‖
environment and allows deploying and executing these models directly in SAP run-time
engines. This is done through the Configuration Environment (CE). The Process Integration
(PI) module enables the shift from pure technology view towards a more business oriented
process view. A second strength is the procedural model for service discovery. The strategic
layer is not formalized in models. All other domains & issues are also not well developed.
Related to the SOA Domain Modelling, the following criteria‘s have been rated as follows:
Zdun & Dustdar describe in their method based on model-driven software development
(MDSD) an academic approach with UML2, domain specific languages (DSL), a meta-meta
model (MOF) and the own developed pattern language ―Frag‖ for the syntax. Both are
recognized computer science researchers with a more technical background. As the method
starts on the technical PIM-level in MDA, Modelling & Interfacing within the ―Modelling‖
cluster is well addressed but refers to interfacing technical UML2 models. Therefore, the
technical design part is well explained, whereas the Strategy, MDA, Knowledge & BPM
business parts are missing because not in scope. There is some explanation about the model-
driven design process (SOA phases) and how to decompose process into ―Macro-Microflow‖
(decomposition & granularity). If this method could be enhanced by missing SOA domains, it
could be a valid method for SOA architects to apply, if UML2, DSL and ―Frag‖ [Zdu09] are
the decisions related to language and syntax.
Tran, Zdun and Dustdar [TZD08] [TZD08b] describe an approach to eliminate issues related
to interoperability and reusability of process models (refer to chapter 2.4.2.). They describe
shortcomings in extensibility of models related to direct transformation mechanism from one
model to another. The presented View-based model-driven framework is based on the view-
concept and meta-models for different views such as control flow, collaboration, information,
transaction and new concerns that could come up. The ultimate objective is to develop an
approach for automatic translation between models by using an approach based on views,
concerns, MDSD, Meta-Meta Model and Meta Models.
3.2.5. PIM4SOA
This method from Papazoglou and Van der Heuvel is a refined method based on IBM‘s
SOMA Method. In SODD, shortcomings in IBMs SOMA Method have been identified and
mostly closed e.g. the view on Business BPM or SOA Governance. Some Model types are
stated, yet, there is no description on how they fit together and how to match them to MDA
abstraction levels. Key principles as the foundation for service-based process design are well
explained. The planning and design phase gives important information about scoping of
processes, how processes can be identified and the different realization options. Furthermore,
service design concerns are well explained and how services could be specified. Service
design has been further developed and detailed with a methodology for ―business service
© Jan Ricken, University of Namur, Computer Science Department Page 106
engineering‖ [NvdHP+09]. The objective of this further method development is to identify
candidate business services including criteria‘s such as functionality, scope, reuse and
granularity applying a gap analysis approach. Papazoglou does not mention the MDA
principles nor is the focus to give an overview of models that could be used other than to use
BPMN as a candidate business process language, WSDL for services and BPEL for
orchestration. UML or any other business process modelling language does not play any role
whilst the method focus on the importance of process modelling, design, analysis etc. The
strategy phase, strategy concepts and methods are also not taken into consideration.
3.2.7. SOMA
Based on Arsanjanis‘ work, Zimmerman [Zim09] an IBM researcher has enhanced the
presented method. The thesis is presenting a framework which is called SOA Decision
framework (SOAD) consisting of 7 steps and a re-usable architecture model (RADM). The
advantage of the thesis is the deepness of the framework with nearly 389 decisions. A tool is
proposed for enhancing the structure of architectural SOA decisions. The thesis is not
detailing them as these decisions are protected assets harvested from IBM projects. Only one
decision ―Invocation Transactionality Pattern‖ is exemplary shown in the Annex, Table 34.
The framework is not taking a specific viewpoint e.g. process-oriented and model-driven, but
focuses more on technical issues and related architectural decisions such as protocols,
patterns, infrastructure, service descriptions etc.
For organizations starting with SOA, the framework is complex to understand and/or to apply.
Furthermore, the framework is designed in a way, where the SOA architect needs
considerable experience and understanding of this domain. The solution is more intended to
be proposed and guided by (IBM) consultants that are well experienced using this model. If
this condition is met, then this presented framework and architecture model is an excellent
approach to successfully facilitate SOA implementation considering a wide range of (mainly
technical) issues to work on.
This is the most complete among the industrial methods. However, the domains ―modelling‖
and ―BPM‖ could be improved. There is very little information about what model types to
choose and nothing is said about how to link them. The ―SOA Reference Architecture‖ is one
of the strength. It describes well the composing blocks of the EA and differentiates between
conceptual, applicative and technical views. The domain ―SOA Project‖ includes all issues
including ―SOA maturity model‖, ―SOA Governance‖, ―SOA Objectives & KPIs‖. For the
domain ―tool‖ the authors are giving capabilities that should be met for the different issues
(e.g. SOA tools in design time and run-time, which is very useful in a concrete method). It is
the only industrial method referring to and explaining high-level MDA. However, the whole
method has a good coverage but stays relatively high-level without giving detailed
explanation for most of the named issues.
None of the existing SOA Methods is covering in full details all SOA domains. The
qualification also says nothing about SOA Method quality, but only related to the coverage of
SOA Domain Model. A root-cause for this consists in the provenance of these SOA Methods.
For example, AVE for SOA from IDS has its roots in BPM and Modelling and not as such in
components related to run-time or web-service domain. Or PIM4SOA is very much model &
tool oriented and neglects completely the BPM domain and SOA project domain. The reason
is clearly related to the root and objective of these methods which is based on specific
viewpoints.
The methods having the largest span of mentioned sub-domains are ORACLE Unified
Method for SOA (industrial) and SODD (academic). Most of the methods propose a top-down
approach and underline the business benefit and the resulting high quality of SOA architecture
as deliverable. Only the method of IBM and Mike Papazoglou justify the bottom-up approach
in some circumstances. Deliverables in the INTEROP [Dou07] and ATHENA [ATHEN05] –
projects also come to the result that a top-down method has more strengths than weaknesses.
Some methods are specially developed for the context of SOA (e.g. Zdun & Dustdar) others
are derived from existing methods and adapted to SOA flavour (e.g. AVE for SOA).
MDA is sometimes mentioned, but never mapped to the different layers of abstraction. Also
model types are sometimes mentioned, but not in a systematically way. Certain modelling
languages and standards are more frequently cited or used than on others (e.g. EPC, UML,
BPMN, BPEL and WSDL). If we compare how modelling and modelling notations are
explained and used in the methods, major differences can be noted. The VbMF is using UML
as modelling standard, whereas AVE uses EPC, SODD uses BPMN etc. Table 25 summarizes
the evaluation of rated methods using the SOA Domain Model as framework:
All presented methods have their right to exist with areas on which there are more complete
or less complete than others. As we have these differences in coverage, the research need
introduced in the first chapter is relevant.
Disadvantages:
Not everyone has access to the Internet, so the response rate may be limited;
Many people are not receptive to completing questionnaires online [PRCLM+04].
Studies indicate that the population that responds to online questionnaire
invitations are generally biased to younger people (demographic
representativeness issue) [PRCLM+04].
Response rates are frequently quite low and there is a danger that they will
continue to drop due to over-surveying of web-users.
Three main factors namely respondent ability, respondent motivation and questionnaire
design determine the success of the questionnaire and the likelihood of achieving decent
levels of response [GFFCM+04].
Based on these considerations and on the literature about setting up questionnaires, a web
questionnaire has been chosen for the survey, mainly because of its efficiency (quick
collection of responses, low effort for analysis and low cost). The objective of the qualitative
survey is three-fold: first the motivation for the present research should clearly show the need
also in industrial practice, second, the state of the art-analysis should be completed and
refined by opinions based on practical experience. Third, the identified issues with the related
questions should be given to practitioners for feedback.
In order to cope with research question 1 about SOA Methods identification and
characterization, the whole SOA domain model with its issues has been transformed into
questions to get insights in industrial expertise and possible solutions. Second, research
question 4 about suited candidate modelling languages for SOA implementation is
investigated.
In relation with the posed research question 4 about suited candidate modelling languages on
different levels of abstraction, the level of knowledge including application & satisfaction
towards available SOA Methods has been asked. Here, knowledge gathering objectives as
well as testing objectives are set:
A1) which modelling notations seem the most suitable for SOA implementation?
A2) what are critical success factors? Is BPM knowledge in particular a critical
success factor?
A3) what is the degree of popularity and awareness of academic SOA implementation
method proposals?
Other research questionnaires about SOA implementation such as from Viering and Legner
[VL09] conclude that SOA implementation is still on-going and relevant on a broad level.
To test the questionnaire on content, design and relevance, a trial group of three specialists
being subject matter experts filled the questionnaire and provided feedback.
The empirical study was performed from August 2008 to January 2009. The survey was
accessible by following a web-link, available 24h/7 and recording all entries in a database.
The chosen channels for the announcement of the survey were professional communities
related to SOA including qualified profiles of managing IT members (i.e. BPtrends
[BPTRE09], IT Nation [ITNAT09] and SOA Know-How [SOAKN09]). Due to this specific
target, the issues of demographic relevance and of respondent‘s ability can also be strongly
reduced. CIOs as owner of the overall IT strategy, of which SOA method can be considered a
sub-part, should be able to respond in a competent manner. By nature, CIOs are also used to
novel research technology. The motivation issue has been faced by the promise to provide an
executive summary report of the survey results by e-mail to respondents. It is true that the
questionnaire was more complex and longer to answer than other simple industrial
questionnaires, but this could not be avoided due to its academic background and objectives.
With the chosen approach, it was unfortunately not possible to calculate a ratio of
participation. Furthermore, it was not possible to measure how many visitors in that
timeframe have seen the link, clicked on it and then decided to participate.
A first attempt getting access to worldwide IT specialists in companies was to ask IT market
research providers to participate e.g. Gartner, Forrester, AMR Research. Unfortunately, this
initiative failed as the questionnaire was rated too academic and too time consuming to fill.
Out of the total number of answers (79) 54 relevant ones were selected by eliminating
responses not being serious or complete (less than 80% of answered questions). The total
population of the sample is 54. However, in the next sections, figures might sometimes not
match 100% as respondents within the 54 might not always have responded 100% of all
questions. The population sample will be shown in each statistic with n=x. The top five
countries to respond were Luxembourg (16,7%), USA (16,7%), Germany (14,8%), Belgium
(11,1%), Australia and Brazil (9,2%). The respondents‘ countries are obviously correlated
with the distribution over countries of the members of the community of the three BPM/SOA
websites.
72,2% of respondents are Managers, Directors, CIO/CPOs or CEOs. The profiles show
clearly that those who responded have a good overview of the subject. Obviously most of the
respondents are also profiles who will decide about implementing SOA and how this will be
done. This is on the one hand a strength and positive aspect because the survey collected the
viewpoint of deciders, but on the other hand this might represent also a weakness as SOA
analysts and programmers are underweighted. On the other hand, the responsible managers
have filled the technical questions together with their analysts and architects. Unfortunately,
the research design was not able to provide a validation that respondents have well understood
the questions and eventually have referred to analysts being more competent to answer the
questions. However to reduce this risk, it was proposed in the survey introduction to ask
questions by email to get clarification if necessary. Some CIOs in Luxembourg have asked to
fill the questionnaire with my assistance to ensure a correct understanding of questions.
In total, the number of 54 respondents is not sufficient to deduct highly statistically significant
final conclusions for a quantitative survey with the final objective to validate issues.
Furthermore, the sample of respondents can be considered as interested and experienced in
BPM and SOA. Those, who have no interest or belief in SOA, also had no interest in
responding to the questionnaire as this was a time consuming commitment.
The proposed steps by Walonick [Wal04] for a research survey have all been followed such as
1.) Design Methodology, 2.) Determine Feasibility 3.) Develop Instruments, 4.) Select
Sample, 5.) Conduct Pilot Test, 6.) Revise Instruments, 7.) Conduct Research, 8.) Analyze
Data, 9.) Prepare Report.
The design of the questionnaire has been done with the objective to reach interested target
groups from specific websites. The whole questionnaire has been structured following the
domains of the SOA domain model. Due to the large number of issues to get information
about, it was not possible to shorten below 36 questions. The goal of the questionnaire has
© Jan Ricken, University of Namur, Computer Science Department Page 112
been communicated and an incentive to fill the questionnaire has been given. On the other
side, the filling of name, position and e-mail address was also asking for a limited personal
amount of information – which could have threatened some respondents. Unfortunately, no
survey design experts for the survey design were available for detailed review. However, the
following principles of questionnaire design have been applied:
Non-threatening questions,
Multiple responses possible,
using 4-likert scales to avoid ―neutral‖ responses,
Reduction of ambiguity in the question understanding to a minimum by short
questions and well-known and industry standard terminology (IEEE Definitions),
Variability in responses for statistical analysis,
Grouping of questions in related domains,
Mistake reduction on pre-assumptions such as ―knowledge‖ pitfalls by adding always
a free-text option ―other‖,
Question wording as objective as possible, not implying a desired answer.
As said in the introduction to this chapter, the profiles are rather senior: 72,1% of respondents
are Managers, Directors, CIO/CPOs or CEOs. The profiles show clearly that those who
responded have a good overview of the subject. Obviously most of the respondents are also
profiles who will decide about implementing SOA and how this will be done. The survey
provides the perspective of individuals from a wide range of industries as shown in the figure
below. 74% of answers come from headquarters and 26% from subsidiaries.
Energy 7.70%
Logistics 5.70%
(Tel)Communication 3.80%
Electronics 1.90%
2.00%
Other
15.00%
9.40%
10.00%
5.70%
5.00%
1.90%
0.00%
<50 50-100 101-500 501-1.000 1.001-1.500 1.501-10.000 >10.000
An important criterion for the utility of SOA implementation is the size of the
company/organization. With the size, usually also the number of applications is increasing.
The panel of respondents have the following size and number of applications:
30.00%
24.50%
25.00%
20.00% 17.00%
15.00% 11.30%
10.00% 7.50%
5.70%
5.00%
0.00%
<10 11 to 25 26-50 51-100 101-500 >500
In this section, we analyse the global situation and context (maturity) of respondents
regarding knowledge and use of SOA.
98 % of the participants know the SOA concept, whereas nearly 50% started to know about
SOA within 2005 and 2006.
96,2% of respondents will use the SOA concept against 3,8% who decided not to use the SOA
paradigm in the IT Strategy. This ratio shows clearly the relevance of thinking more in detail
about possible ways of usage in the organizations. As mentioned in the beginning, we can
assume that only BPM and SOA aware respondents were interested in contributing to this
research.
Out of the 96,2% of respondents deciding to go for SOA, 50% have planned to go for the
project 26% are involved in an on-going SOA project, 10% have already finished the project
and 14% are in the discovery phase of SOA (investigating what it is and how it can be
tackled in the best way). In summary, 64% have not started whereas 34% have started or
finished.
If we examine the 10% of respondents with already implemented SOA project, these are very
big companies with a clear business case and a high level of education and maturity around
SOA technology and Business Process Management.
When asking about the benefits that SOA can bring to organizations and companies, the usual
benefits are nominated. An interesting result is the ranking starting with the strongest
argument for the implementation of SOA:
Opposed to benefits of SOA are also challenges faced. Here are the reported challenges in
decreasing order of importance:
Interestingly the respondents were much more aligned on what are the biggest advantages
than on the challenges. Within the list of challenges it clearly states the issue on missing
According to our state-of-the-art analysis, EA is an entry point and is playing and important
role in the context of SOA implementation. The thought about how an EA can support the IT
strategy is a key success factor to include also the SOA concept in the IT strategy. Finally, EA
is key for SOA implementation, as method, modelling, process management, abstraction
layers views and linked components need to be considered. The list of EA presented in the
questionnaire was populated with the most common in academia and industry. It is highly
interesting to know which standards are known or used by industry. If an EA is used in
practice, it is also interesting to see if the respondents are satisfied with it. Therefore, for the
modelling domain, most of the questions asked for one answer among the following possible
ones: not known, known, used meeting expectations used not meeting expectations. The result
clearly shows that some EA (e.g. CEN ENV 400003, GRAAL, GERAM, TOVE, TEAF,
AKM) are not known and therefore not used at all. On the other hand there are clearly EAs
that are known and used by most of the respondents (e.g. Zachman, ARIS, 4+1 View Model
of Architecture, MDA, RUP).
Similar to EAs, modelling languages are important to analyse in the context of a SOA
implementation. Which are the modelling languages suited to accompany conceptual
processes with the objective of SOA implementation? As we take a processes-oriented
viewpoint, candidate notations or modelling languages elaborated in chapter 2 were asked for
practitioners‘ feed-backs.
In general, strategic model types such as e3value, Balanced Scorecard (BSC) or VACD are
less known and used than business process requirement languages such as Business Process
Modelling Notation (BPMN), Event driven Process Chain (EPC) and UML Activity Diagram
or than technical process implementation languages (such as BPML or WSDL).
81,48%
e3 Value 12,96% 1,85%
3,70%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Not known Known Known,used, meeting expectations Known, used, not meeting expectations
Clear trends are visible about modelling languages usage on the three different levels of
abstraction (Strategy, Processes, IT). For Strategy, the most known and used model type is the
BSC model and Value Added Chain model. Most of business requirements at the process
level are captured through BPMN, BPML, EPC, IDEF, UML Activity Diagram. For IT or
implementation languages, BPEL, WSDL, WPDL are particularly often known and used.
Regarding the way SOA is implemented 57,4% of respondents have chosen the top-down
approach, 20,3% meet-in-the-middle and 22,3% Bottom-up. The result shows a clear trend
towards top-down approach and even more decide for meet-in-the-middle than for bottom-up.
The MDA approach of the OMG for software development is gaining popularity. The way
abstraction levels are defined and what types of models are used is also important for the
context of SOA implementation. Most of respondents know MDA for software development
(46,30%) and also use it with satisfaction (16,67%), not meeting expectations (3,7%) and a bit
more than a third (33,33%) do not know about MDA. In the context for SOA developments
the knowledge about MDA is similar and approximately 13% claim also to use it in this
specific context. Notably, MDA is known and used successfully by the respondents coming
from the leading worldwide IT service providers. They have a high level of knowledge and
maturity in software development and also apply MDA to their SOA implementation
approach.
Another important dimension, the BPM, is considered as critical success factor and enabler.
Therefore, in total 83,3% of respondents manage (completely: 46,3% or partly: 37,0%) their
processes in a real BPM programme including strategy, design, implementation & controlling.
Within their BPM initiative, various usage scenarios are covered or addressed:
1 Meaning that more than 85% of respondents do not know nor use it.
© Jan Ricken, University of Namur, Computer Science Department Page 118
Respondents and BPM Usage Scenarios
Process-Driven
53.70% 27.78% 18.52%
Application Development
Yes Planned No
Most of respondents have already documented processes (85,19%) and use BPM also for
other objectives e.g. certification (37,04%), risk management (31,48%), cost control (50%),
process driven application management (53,70%) and process-driven web-service
construction (40,74%). In the context of SOA, it is very interesting to observe the planned
scenario for the two last cited with 27,78% and 35,19%. Consequently, more than 77% of
respondents are using or have planned to use processes for the web-service identification and
construction. Furthermore, the planned process-driven web service construction of 35,19% is
the highest value for the planned usage scenarios in BPM. This is clearly the area with the
biggest increasing potential of re-utilisation of BPM content.
Generally, the BPM knowledge is rated as very important with 90,74% for SOA
implementation. Only 9,26% of the respondents rate it neutral (7,41%) or as not important
(1,85%).
Maturity models can help to identify the current status and can support thoughts on targeted
maturity and the way to get there. Originally developed by CMMI, maturity models are these
days also proposed for SOA maturity. Only 20,4% of respondents use a maturity model for
SOA. Exactly half of these respondents (10,2%) declare to use the Gartner SOA Maturity
model, the other half (10,2%) is using their own developed model.
The Return Of Investment (ROI) is a key figure for IT projects decision making. The biggest
challenge as indicated by the respondents is also substantiated in the following result: 77,78%
of respondents did not succeed in calculating the ROI. The ROI calculation is related to the
business case the companies/organizations have for SOA: 46,30% argue to have a strong
business case for SOA with 51,85% claiming to possess the right skills to understand SOA
© Jan Ricken, University of Namur, Computer Science Department Page 119
and 44,44% with the right skills to implement SOA. 48,15% of respondents need external
consultants to implement SOA.
An important issue to address is IT project management that could be adapted to manage the
SOA project. 72,2 % use their own project management methodology, 18,5% follow PMI and
9,3% follow Prince2. Within the 72,2%, a considerable number of respondents has adapted
and mixed PMI and Prince2 for their specific needs.
Next, the respondents were asked to evaluate a list of SOA methods that resulted from our
state-of-the-art analysis of all current availably SOA methods in the academic and practice
worlds, as shown below:
Service Oriented Modelling & Architecture (SOMA), IBM 50.00% 42.59% 7.41%
1.85%
ARIS Value Engineering for SOA, IDS Scheer AG 51.85% 42.59% 3.70%
5.56%
Enterprise SOA, SAP AG 57.41% 35.19% 1.85%
0% 10 20 30 40 50 60 70 80 90 100
Not known Known
% % % % % Known,
Known,used, meeting expectations
% % % % %
used, not meeting expectations
In general, most of respondents are not aware of the wide range of existing methods. The
most known methods are industrial ones e.g. IBM (known by 42,59%), IDS Scheer (42,59%),
SAP (35,19%) and ORACLE (27,78%). The academic proposals are even less known than the
industrial SOA methods. Unfortunately, the number of reported successful application of such
methods is too low to deduct reliable findings. IBM was the first IT company to invest in
SOA run-time engines and SOA method (SOMA). Therefore, their solutions and methods are
more known than these of the competitors. (The business motivation model has not been
introduced in the questionnaire as it has been considered too new and not mature enough.)
The root cause for the weak knowledge on SOA methods is related to the fact that 87,04 % of
respondents rate SOA method as a very complex issue and not easy to tackle at all. If IT-
service providers are taken out of the panel, the figure is increasing up to 98,15%. As already
mentioned, the IT service-providers have a good understanding of mainly technical SOA
knowledge and therefore see in most of the cases no huge complexities to solve.
3.3.3.4. SOA Domain: BPM Design Time Tools & BPM Runtime Tools
BPM is a key enabler for SOA. Therefore processes need to be supported by robust tools.
This is true for the so called ―design time‖ environment as well as for the ―runtime
environment‖ What tools or platforms are known and successfully used on both levels? The
following chart gives an overview of the respondent‘s situation:
5,56%
Metis 85,19% 7,41% 1,85%
1,85%
Popkin 87,04% 7,50% 3,70%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Not known Known Known,used, meeting expectations Known, used, not meeting expectations
On the ―design time‖, it clearly shows ARIS platform ahead as well as known and also used
successfully. Furthermore, Visio is also well known and used, but with a higher rate of non-
satisfaction related to BPM and SOA modelling. Visio is still more considered as drawing
tool that can be used and mastered very quickly than a real BPM design tool.
On the ―runtime environment‖, IBM, Oracle and SAP are most known and used for
implementing and running BPM. The BEA products as well as SUN were taken over by
Oracle, which consolidates a bit the runtime environment providers. Within other runtime
environments, e.g. Mircosoft or HP is cited.
A central domain in the SOA paradigm is for sure the service concept. Related to services,
63,16% of respondents answered that service orientation is part of their business strategy.
This is partly true for 21,05 and 15,79% argue their business strategy is not service oriented.
Interesting in that context is the IT situation of respondents: 34,21% are in full outsourced
mode, 5,26% partly and 60,53 have their IT in-house. If we analyse the other way around,
more than a third of respondents (answers: ―yes‖ 26,32% and ―partly‖ 10,53) deploy business
web services measured by a Service Level Agreement (SLA) to other companies.
© Jan Ricken, University of Namur, Computer Science Department Page 122
81,5% of respondents use already web service technology, 18,6% don‘t. Web-service
technology can well be used just to interface applications. It is not an indicator for service
oriented architectures.
Web service security is also considered as an important issue to tackle. Within SOA security
management authentication, authorization and identity management need to be addressed. The
following graphic illustrates the results:
25,00%
Full security Partly implemented Not realized
All respondents having answered ―no‖ have so far not started their SOA project.
Web service granularity and decomposition is still for 87,04% a major issue. Only 12,96%
think this is no issue for them. Again, 100% of these respondents arguing granularity is not an
issue are within the group of IT service providers having already implemented SOA.
37,04% have a data management programme implemented, whereas 31,48% have it partly.
(No data management for 31,48%)
48,15% of respondents claim to master the interfaces between applications, whereas 40,74%
do partly. (No interface mastering for 11,11%)
Only 37,04% have automated application interfaces, 48,15% have it partly. (No interface
automation for 14,81%)
90,74% of respondents agree that the presented SOA Domain Model is reflecting all domains
to consider for an exhaustive SOA implementation method based on a process-oriented
approach. Within the 9,26% not agreeing, respondents were pointing to change management
or top management support. The mentioned issues are part of the SOA project management
domain and are addressed in the model. Some other respondents were pointing to related
approaches e.g. Web-Oriented Architecture (WOA) or Representational State Transfer
(REST) approach.
Smith [Smi08] is arguing that ―WOA, like SOA, is an architectural approach to system
design, though WOA is resource-oriented rather than service-oriented. While the core SOA
design unit is a reusable service that fulfils a distinct business function, resource-oriented
services are more limited and data-focused. SOA and WOA work at different layers of
abstraction. SOA is a system-level architectural style that tries to implement new business
capabilities so that they can be consumed by many applications. WOA is an interface-level
architectural style that focuses on the means by which these service capabilities are exposed
to consumers. Governance, quality of service, security, and management are of equal
importance, whether the functionality is being delivered via SOA or WOA.‖
Therefore, WOA and REST are approaches standing for their own. They could certainly add
value for specific questions.
In this chapter, we presented the results of a survey on the knowledge and practice of SOA in
industry. 54 respondents gave complete and relevant answers. The answers are satisfyingly
representative of companies from around the world. From the results obtained, we can draw
some general conclusions.
Several reasons have impacted the number of respondents: First, due to question deepness,
filling the questionnaire required substantial effort and time. Second, respondents needed a
certain level of knowledge, maturity and understanding of the topic to contribute seriously to
the survey. Third, the financial crisis 2009 stroked just in the period of launching and
advertising the questionnaire and induced, as we could observe in our contacts with the sector,
a swap of priorities from strategic IT investments (among which ―SOA implementation‖
projects) towards a more ―IT cost control‖ focus.
Overall, the results show clear tendencies and underline statements from the state-of-the-art
analysis and will lead into two detailed field trial studies to apply the SOA domain model for
further refinement. Related to the research question number three posed at the beginning of
this chapter, we can conclude the following:
A1) Which modelling notations seem the most suitable for SOA implementation?
The modelling notation candidates mentioned as the most appropriate are BPEL,
UML, BPMN, Value Chain and WSDL. This result is matching with the state-of-the-
art research in chapter 2. Other notation usage depends on countries or regions such as
EPC modelling is well known for German speaking countries using mostly IDS
Scheers‘ Tool ARIS.
90,74% of respondents rate BPM as critical for SOA Implementation. A clear trend
shows which process model notations are successfully used for SOA implementations.
Process knowledge will in the future be re-used by 35,19 % to do process-oriented
web-service construction.
A3) What is the degree of popularity and awareness of academic SOA implementation
method proposals?
Regarding the validation and completeness of our preliminary SOA domain model,
90,74% of respondents agree that the presented model is reflecting all domains to
consider for an exhaustive SOA implementation method based on a process-oriented
approach. Within the 9,26% not agreeing, respondents were pointing to change
management or top management support as lacks. However, the mentioned issues are
WOA and REST as described above were mentioned as missing topics but it can be
considered that these approaches are standing for their own.
B2) Is the lack of method perceived as an issue? Is the subject of SOA method perceived as
complex and do users know where to start?
Two out of three top issues related to SOA are ―complexity of subject‖ and ―missing
method and where to start‖. 87,04% rated SOA implementation method as complex. If
IT providers are eliminated out of the panel, the percentage is increasing to 98,15%.
Finally, we can conclude that respondents do not rate available SOA method proposals
as insufficient, which is clearly confirming the need for a SOA engineering method.
Moreover, the SOA Domain Model seems to be ―de-facto complete‖ and candidate
notations for a process-oriented approach are clearly identical to the state-of-the-art
research findings.
Chapter 4 is the second chapter on research contribution artifacts. First, the configuration
process for SOA situational method (section 4.1.) is created, formalized and explained in
detail.
Finally, the last outcome is the formalization of fragments (section 4.2.). The SOA Domain
Model and ME principles are applied for formalizing an available standard SOA Method
piece with the objective to demonstrate the formalization into a method fragment. This has
been shown on the selection of process models for different levels of abstractions but only for
the SOA domain of modelling. A summary at the end of each section concludes the most
important findings.
First, an alignment model is presented to explain the relationship between the SOA Domain
Model and ME. Based on this meta model, parts of 2 available SOA implementation methods
are formalized into method fragments. We will concentrate on the model-driven and process-
oriented part. It is explained, how this is done. Additionally, supporting tools and guidelines
are presented to facilitate the application into concrete cases. These concrete cases are
detailed in chapter 6.
The SOA Domain Model introduced earlier is summarizing criteria‘s identified in the state-
of-the art with the objective of implementing a process-oriented SOA. The criteria‘s related to
the SOA domain model have been defined and described in the context of SOA. Therefore, a
link between SOA domains with its sub-domains towards method fragments needs to be done.
© Jan Ricken, University of Namur, Computer Science Department Page 127
Only this way, it is possible to check what coverage of criteria‘s has been achieved in the
application of the situational method in a specific project application. The following model
cannot be generalized for all SOA Domains, as only the SOA Domain ―Modelling‖ has been
formalized in fragments and applied in the action cases. Further work (section 7.3.) could
investigate further into the formalization of method fragments in other domains.
The Class ―SOA Domain Model‖ includes sub-domains. These sub-domains have been
defined and described earlier. The alignment model below integrates attributes to
unambiguously describe and classify the SOA sub-domains. Every sub-domain is related to an
―activity‖ (refer to section 2.6.) which is a term to ―neutralize‖ the semantics of vendor
specific method fragments. Such an activity can include one or more available method
fragments. One specific method fragment includes a process fragment and a product
fragment. A product fragment is input/output to one or more process fragments. Figure 42
shows the link between the SOA Domain Model and ME terminology:
Name
Brief Description
Purpose
1..* is input/output for
Main Description 1 Product Fragment
Key Considerations Name
Method Fragment
Alternatives Brief Description
ID
Steps Purpose
Name
Role(s) includes Description includes Main Description
Mandatory Input(s) 1 1..* 1 1..*
Purpose Key Considerations
Optional Input(s) Guidance
Discipline
Output(s) Discipline
Mandatory Input Condition Fragment
Guidance 1..*
Mandatory Tool Condition re-use
Discipline
Alternatives 1
1..* Capability Pattern
includes
1
Name
Activity 1..* 1 Brief Description
re-use
Purpose
Name
Main Description
Key Considerations
1..*
Alternatives
is related to
SOA Domain
Name
Figure 42: Alignment Model between SOA Domain and Method Fragment (only for SOA Domain
“Modelling”)
4.1.2. Concrete example for relationship between SOA Domain Model and
Method Engineering
The class SOA Domain ―Modelling‖ is containing the sub-domain ―1.1 SOA Modeling
Notation‖. This sub-domain is defined, further described in the SOA context and related
questions are raised: What is to be modelled on what level of detail? For the different levels of
detail or abstraction layers, different activities can be found to resolve the question. Such
activities are concretely ―Define SOA Strategy Model‖, ―Define CIM Model‖, ―Define
CIM2PIM Model‖, ―Define PIM Model‖ etc. Each activity includes one or more method
fragments: e.g. the activity ―Define CIM Model‖ can be resolved with 3 available fragments,
which are: SAP2 Services Modelling, AVE4 Enterprise Process Map and AVE5 Service
oriented business Process. Every of these 3 method fragments is including ―Process
Fragments‖ and ―Product Fragments‖. For example the fragment ―AVE5 Service Oriented
Business Process‖ includes the process fragment with details on how to apply and realize the
process fragment. Conditions such as mandatory input or mandatory tools are indicated and
© Jan Ricken, University of Namur, Computer Science Department Page 129
can influence the decision. If the conditions are fine, in this case IDS Scheers‘ Modelling tool
is required. The details on the process fragment are important, because the context of applying
this process fragment is explained and alternate options are mentioned. For instance instead of
using AVE5, also SAP2 using BPMN product fragment could be used. The process fragment
output will be a product fragment, in this case an EPC-Model. If this seems not to be
satisfactory, a new method fragment could be formalized including e.g. UML Activity
Diagram.
In order to facilitate re-use, capability patterns can be used to increase efficiency. For instance
the capability pattern ―SOA Strategy‖ is including the activities ―Define SOA Strategy‖ and
―Model Strategy‖. These two activities are linked to more than just one sub-domain and
consequently also to one or more method fragments.
The explanation of figure 43 is now further detailed by re-using the tables from section 2.6.3.
The attribute is now filled with the concrete name and descriptions are detailing the concrete
examples:
Table 26: Attributes of SOA Domain “SOA Modelling”
Table 29: Attributes of Activity “Model Business Requirements with EPC Model”
The activity here ―Model Business Requirements with EPC Model‖ is one of the activities
from the capability pattern ―top-down modeling CIM‖. In the present case, the activity is
including one fragment (AVE5) but could include some more if formalized and available.
Table 30: Attributes for Method Fragment “AVE5 Service-oriented business process”
Product Fragment Key This Process Model Notation on CIM Layer needs to be
Considerati considered if the process design tool integrated EPC
ons notation. Generally, it is difficult to execute or transfer
into an execution environment. This notation can be
used, if ARIS SOA Architect as tool is foreseen with a
later transformation into BPEL notation. A semi-
automatic transformation CIM2PIM is available in ARIS
SOA Architect.
Product Fragment Guidance Example Model
The following section will define and formalize the method to follow for a SOA engineering
method. This method is referring as described earlier to the definition of method from
Vernadat [Ver96] which is ―a (1) set of methods, (2) models and (3) tools to be used in a
structured way to solve a problem.‖ The SOA engineering method is a set of processes,
which are realized or performed with the help of tools (method fragment creation, situational
assessment, selection&assembly of fragments). The facilitation by tools will be described in
detail in the ―Tooling & Prototyping‖ chapter 5. We consider that either the project manager
or a method engineer is performing or executing the processes as described. The process of
describing the creation of SOA Domains and SOA Sub-Domains is available but not
formalized and described in detail here. The description of attributes and relationship between
both classes were introduced in section 3.1.1. As method, we use as already mentioned
situational ME.
© Jan Ricken, University of Namur, Computer Science Department Page 135
4.1.3.1. Engineering Process for SOA implementation
The application process overview is containing 5 different processes. The definition of these
processes has been inspired by the ME-processes as illustrated by Mayer et al. [MCFKP+95]
(figure 23) and Brinkkemper [Bri96] (figure 24). These 5 proposed processes are the
following:
For the formalization of these 5 processes EPC modelling is applied. The following objects
are used:
The next sections will detail the 5 processes re-using Event-Driven-Process Chains (EPC)
method following the legend description in figure 45. To ensure object-oriented modelling,
and the usage of object re-use, the link between dynamic (processes) and static (application,
system and data) views is the following:
A detailed report on object information is provided on the accompanying CD. The object
information explains exactly where objects are re-used and which connections they have to
other objects.
This process has as an objective to populate the method fragment database. This prerequisite
is necessary as input to allow the availability of method fragments in the fragment database.
This process has as objective to capture the situational context of the organization with the
SOA domains developed in this thesis.
The SOA Domains are containing the sub-domains defined earlier. Each sub-domain
definition as well as the SOA contextual issues needs to be understood. Based on this,
priorities are set and considered for the decision on how to address the criteria‘s. Organization
specific context needs to be gathered; similar to the field trial application examples in chapter
6 (e.g. section 6.3.2. and 6.3.7. for details). Based on organization specific content, priorities
must be decided on e.g. what implementation strategy to use, what systems to use, how big
the scope of the project is etc. Based on these organization priorities, the generic activities can
be selected. As between the activities chosen, there is a link to the SOA sub-domains, the
method user can decide if each sub-domain is sufficiently addressed by activities or if
eventually some risks should be taken by non-addressing. If the sub-domain is not sufficiently
covered and the risk estimation is too high, it needs to be evaluated if method fragments are
available and also meeting requirements. If a method fragment is not available, the process
executer needs to decide if this fragment has to be created or not. If the creation is not an
option, the process loops back to the decision on SOA sub-domain coverage. If a method
fragment is available in the fragment database, the process continues with the selection of
method fragments.
This process has as objective to select the fitting method fragment to the situation identified in
the earlier process.
First, a delivery process has to be created for the individual project. The delivery process
attributes such as ―name‖, ―description‖, ―purpose‖ and ―scope‖. Next this delivery process
needs to be populated with fragments. For this, fragment candidates are checked in detail in
the method fragment tool. Based on the attribute descriptions of method fragments, the
method applicant has to judge if the fragment candidate is still a good choice. Here, several
important information are made clear: the product outcome of the fragment, the process steps,
the actors performing the fragment, the prerequisites or conditions related to other related
fragments or tools necessary. If this is accepted, the fragment is selected.
The selected method fragments are re-used from the ―method content‖ area into the ―process‖
application area. The method fragments are compiled into a sequence. Then a control to
identify method coverage of SOA Domains is performed. If the coverage needs to be
improved, a process link refers back to the process ―manage situational context of
organization for SOA project―. If a project mgt. tool is used, a merge or input needs to be
done to have a ready-to-use project plan:
The objective of this process is to describe the activity around starting the project and
communicating the method to project team and stakeholders.
Once the project-plan is finalized, the approach needs to be explained to the project team and
stakeholders. Method fragment tool are normally providing a functionality to create html-files
to allow project team and stakeholder information and guidance along the project execution:
This process has as objective to record project experience on used method fragments in order
to enrich already available information or to generate new process fragments.
The next section will illustrate the application of the first mentioned process ―Creation of
Method Fragment‖.
The relevant attributes to identify and describe a fragment has been introduced in table 15.
The following work products have been defined based on fragment input/output required
[WM06] [Yva06]:
Access Diagram (Data and Ontology Model with the objective to show
relationships to activities, organization, applications)
Balanced Scorecard Model (Strategy Model integrating BSC method)
BPEL Diagram (Technical model representing web-service orchestration)
BPMN Process Model (Business Process Model using BPMN notation)
EPC Process Model (Business Process Model using EPC notation)
EPC2BPEL Transformation (Transformation Mechanism from EPC to BPEL)
IT Strategy Document (IT Strategy description)
KPI Allocation Diagram (Model for details on how objectives are measured
with KPIs)
Value Added Chain Process Model (Value Chain Model based on Porter)
WSDL (Web-service description language document)
As the previous sections have shown exemplarily the detailed class descriptions (refer to table
13-17) of the alignment model (figure 43) and one concrete example (refer to table 26-32)
some more method fragments have been formalized from available methods.
In case that the organizations in the field trials (chapter 6) would have had other tools such as
Rational Rose, the IBM method SOMA or SoDD would have been formalized instead.
A difficulty consists certainly in detailing the right level of granularity and decomposition of
method fragments. To solve this, the term activity can help to indicate the right level of detail.
The next tables will illustrate this decomposition and the related details to identified method
fragments.
Table 33: Formalized Method Fragments Enterprise SOA Adoption (SAP)
Further SAP fragments were not formalized as these were more addressing other SOA
Domains than the SOA Domain Modelling.
Table 34: Method Fragments ARIS Value Engineering for SOA (IDS Scheer)
1.) ―Envision Service Architecture Management‖ which is the AVE1 fragment and
2.) ―Discover Vision and Opportunities‖ which is the SAP1 fragment.
Both have the same objective to represent the strategic consideration for SOA in natural
language. The difference of both fragments is the source of method provider and the possible
connection to other fragments. The SAP1 one is more a stand-alone and has no direct link to
the next fragment SAP2. The AVE is much more focussing on strategy and also on how to
represent this strategy in models (AVE2, AVE3) and a link is made into the Enterprise
Process Map (VACD Diagram), which does not exist in SAP method.These connections are
described in the attributes of the method fragment description.
Again, activities are needed to provide a generic activity basket, which is including one or
more process fragments among which to select.
The following table is classifying the fragments by abstraction layer and by additionally
indicating the activities from SOA sub-domain Modelling:
The benefit of this consists in the capability to select one of the different fragments available
in the database for a concrete delivery process.
First, the SOA Domain Model has been constructed based on the input from the state-of-the-
art on available SOA methods, SOA modeling candidate notations, model interfacing
mechanisms etc. The construction process of the Domain Model has been explained as well as
the details of each SOA Domain with its sub-domains (Artifact 1).
Available SOA methods have been analyzed and qualified against the SOA Domain model.
The result was that none of the available methods is covering all SOA Domains as explained
in table 25. This result confirms the research gap as introduced in the first chapter (Artifact 2).
A worldwide questionnaire should test the created SOA Domain Model with the related sub-
domains. 90,74% of respondents agreed on completeness of the SOA Domain Model.
Furthermore, knowledge was gathered on industrial basis to complete and fine-grained desk
research and state-of-the-art.
In order to link the identified sub-domains with an engineering method, ME principles have
been used. The SOA Domain Model has been aligned with ME terminology to allow common
understanding of the concept. Each class of the model has been explained and examples were
given. Exemplarily, the alignment model was only applied for the SOA Domain ―Modeling‖.
Next, five configuration processes for SOA situational methods were created. These processes
explain how to create process fragments, how to apply them in a situational method, how to
assemble and select these fragments, how to perform the project and finally how to update
method fragments after project experience (Artifact 3).
For demonstration of feasibility, several method fragments have been created from available
SOA methods. These fragments have been formalized by describing the attributes and also by
providing detailed examples of this formalization (Artifact 4).
For the instantiation of method fragments (refer to table 1), it is required to prototype a
tooling support for the SOA Engineering Framework aligning with method engineering
terminology (refer to table 37). Chapter 5 is about formalizing research contribution artefacts
from chapters 3 and 4 into an applicable and structured prototyping of a tooling support for
SOA method engineering framework. An introduction on used tools and produced artefacts is
given (5.1.). The second section (5.2.) is introducing the framework tooling allowing an
overview on the main outcomes such as the SOA Domain Model, SOA Alignment Model and
the SOA Engineering Process. For formalizing and structuring method fragments, the Eclipse
Process Framework (EPF) Tool is used. Section (5.3.) is detailing on how available method
content is formalized with EPF Tool. Next, an Excel-based facilitating guideline to apply the
SOA Domain Model in a situational context with its content is explained (5.4.). The chapter
concludes with summarizing tooling and prototyping experience (5.5.).
The tools have mainly two objectives: First, the user (all persons who have an interest in this
work) should have a user-friendly framework to allow understanding of SOA Engineering
Method components. The tool should easily present the framework with the main artefacts.
A modelling tool has been used to create artefacts and a decision aid file under Excel format
supports fragment selection process:
© Jan Ricken, University of Namur, Computer Science Department Page 150
Table 36: Overview on used tools and produced artefacts
All three tools with artefacts are available on the CD-ROM supporting this PhD document.
The SOA Framework modelling Tool with the html generator is the single point of entry for
the overview of the produced 4 research artefacts as introduced in chapter 1.
The framework as shown in figure 52 is available for users in HTML-format, meaning that
the complete content can be browsed through. This way, researchers or practitioners get an
easy-to-use tool, which is concentrating and summarizing the main contributions.
Furthermore, the framework is easy to share and distribute as the content can be published
through web or intranet sites. The user of this framework tool can drill-down into the
following artefacts: SOA Domain Model (section 3.1.) and SOA Alignment Model (section
4.1.1.), the SOA method qualification results (3.2.), the configuration process for SOA
situational method (section 4.1.) and the list of available method fragments in EPF (section
4.2.):
Conventions/Legend
This facilitating view is containing 7 building blocks, which are the SOA Domain Model
(refer to table 21) and the alignment model between SOA Domain Model and ME alignment
© Jan Ricken, University of Namur, Computer Science Department Page 151
(refer to figure 46), the SOA Method Qualification table (refer to table 25), the Configuration
Process for SOA Situational Method (refer to figures 47-51), and a list of method fragments
(refer to table 33-34). Furthermore, a link to the SOA domain guidance Excel tool (section
5.3.) is available as well as a static repository on data, application & systems, (refer to figure
46). Next, a conventions/legend as guidance is available on how to read processes (refer to
figure 45).
The presented tooling approach is aligned with the definition of ―method‖ as we have created
a method to be ―a (1) set of methods, (2) models and (3) tools to be used in a structured way
to solve a problem.‖ (refer to definition 32, Vernadat [Ver92]).
The objective of this section is to demonstrate the application of available methods and to
show the ability of formalizing them with ME. As introduced in chapter 1, the tooling should
support the validation of ideas and support the field trial studies in chapter 6. In order to
restrict the scope to a meaningful size, only the SOA Domain ―Modelling‖ with its ―sub-
domains‖ has been formalized in fragments (refer to section 4.2.). It is important to
demonstrate that the conceptual foundation in chapter 3 and 4 can be implemented with tools.
All definitions related to concepts in that specific part of the method with presented artefacts
have been carefully gathered and applied in the ME context using SPEM 2.0. and EPF
[Eclipse09] to formalize the method. The alignment model to bridge conceptually the SOA
Domains and the method fragments has been introduced and explained in chapter 4 (refer to
section 4.1. and 4.2.).
As mentioned earlier, the formalized methods into fragments are taken out of documentation
provided by IDS Scheer [Yva06] (refer to section 3.2.2.) and SAP [WM06] (refer to section
3.2.3.). The SOA Domain Model sub-domains have been introduced as ―customized
categories‖ (EPF tool terminology) into the tool and are linked to the fragments. Each process
fragment is formalized with name, description and purpose of the fragment. The fragment is
further detailed by steps. Work products are indicated and can be distinguished in mandatory
input, optional input and output. Rules have been added by defining mandatory or optional
fragments, input/output relationships on work products and predecessors in a work-
breakdown structure (Refer to table 33 and 34) e.g. as an example: ―EPC Modelling is
mandatory for EPC2BPEL‖ fragment. Guidance is giving an illustration or helping
information to the fragment. Within the category selection, we distinguish two criteria‘s: the
disciplines (EPF tool terminology) are indicating the abstraction level (Strategy, CIM, PIM,
PSM) and the customized category is indicating the relationship to the SOA Domain Model
criteria‘s. One or more criteria‘s can be selected. Additionally, the term alignment table is
enriched with semantics that EPF tool is using:
Table 37: Terminology alignment table between SPEM2.0. and EPF Tool
This table ensures understanding of different terminologies and semantics used in SPEM and
EPF. SPEM has been introduced in detail in section 2.6.3. and requirements for such tools
have been introduced in detail in section 2.6.4. In order to illustrate the implementation in the
EPF tool, figure 53 summarizes exemplarily the content and relationships of method fragment
―Service Oriented Business Process EPC‖ between objects:
Figure 53: Method Fragment “Service Oriented Business Process EPC” in EPF Tool (screenshot)
The task is called Service Oriented Business Process (short name AVE5) and is categorized
on CIM level. As defined in chapter 3, formalized attributes are describing the process
fragment as defined in table 25. The full content of this fragment has been detailed in table 32.
The relationships such as outputs (EPC Process Model) are listed. The detailed steps of this
process fragment are given as well as a guideline which is in this case an EPC process
example illustration.
Similarly as for the process fragment, attributes are describing the product fragment as
defined in table 18 and table 33 (full details of fragment). For space reasons, the description
has not been expanded. Additionally to the defined and explained attributes, EPF
automatically indicates relationships to other fragments (Input or Output) and where the
product fragment is used. Again, a guideline is given with an illustration of a concrete EPC
process model example.
With these formalized set of method fragment in the EPF tool, the ground is prepared for the
concrete application in two real SOA implementation field trials in chapter 6.
The objective of this tool is the support of the method fragment selection as described in
figure 49. In order to select the matching fragments to the specific project requirements,
required tools mandatory input/output and alternate solutions are evaluated.
For each SOA Domain Model sub-domain a definition and an explanation about the sub-
domain context is given (chapter 3.1.). The excel tool recaps this information to allow the user
to understand the sub-domain and to evaluate which activities (table 22) to select.
Ideally, for each sub-domain a separate worksheet should existing allowing guidance. Again,
only the sub-domain ―1.1. SOA Modelling Notations‖ is detailed. Within this sheet, the link
to activities and fragment names (table 35) is done. The following example shown below
illustrates the overview on the sub-domain 1.1. (SOA Domain Modeling):
© Jan Ricken, University of Namur, Computer Science Department Page 154
Figure 55: SOA Domain Model for Situational Method application (Screenshot from Excel Tool)
Concretely, an entry page with the complete SOA Domain Model and its sub-domains is
provided. The figure above shows the details for the sub-domain 1.1. First, a definition of the
sub-domain is given followed by the sub-domain context within SOA implementation project.
Further down, questions are raised. In this case ―What level of abstraction detail to model?‖
Second, ―which notations to select on what level of detail?‖ On every question, activities can
be identified. These activities have been introduced earlier in table 22. Each activity has one
or more fragments for consideration. For instance for the strategy level, 7 activities are
available, with in total 4 different and available fragments. Two fragments are proposed using
natural language, one of these is using Balanced Scorecard and the last one is a Key-
Performance Indicator Diagram. The fragment ID with the number is unambiguously
identifying the fragment. The condition of mandatory input is giving advice if fragments can
© Jan Ricken, University of Namur, Computer Science Department Page 155
be used without restrictions or not. As example, AVE3 can only be used after AVE2. Lastly,
the mandatory tool field is indicating the tool which is enabling the fragment. In this case
AVE2 and AVE3 product fragments need to be created by using ARIS Business Architect
with BSC extension (Mandatory Tool). Next, there is a guideline as support for the
application of addressing the SOA Sub-domains. The sequence proposal is based on the
experience gathered from the application cases.
This support file is created manually and also updated manually. The support file in this first
iteration cycle is somehow ―hardcoded‖. This file could also be improved and made more
explicit once more iteration cycles are achieved. There is no automatic link to EPF method
fragment tool. This might be an improvement and future work as detailed in section 7.3.
The presented work has shown how the original research question of an engineering method
for SOA has been addressed in the last chapters and has implemented the conceptual work
with the prototyping of a tooling support.
For the demonstration of application, content from SOA Value Engineering of IDS Scheer
and SAPs Enterprise SOA has been selected. Both SOA methods have been analysed in
chapter 3 where the qualification of sub-domain coverage in the SOA Domain Modelling has
been illustrated. The method content has been sliced into method fragments and each
fragment has been categorized with layer of abstraction and related sub-domain from the SOA
Domain Model.
Process fragments (figure 53) were defined and also linked to the product fragments (figure
54). Additionally, work-steps (refer to table 30 for details) have been added (as very time
consuming only to some of the fragments) enabling the user to understand how to achieve the
indicated work products. For efficiency reasons, these method fragments have been
documented and stored in the EPF and are available for re-use.
This chapter illustrated the static part of the tooling detailing how the information has been
implemented. It is not detailing functionalities of the tools neither the process of using the
tools. For this, embedded help-functionality or freely available web-tutorials can be used and
are out of scope here.
First, the semantics between SPEM and ME needed to be aligned and understood. Therefore,
the alignment table has been created.
Second, the provided methods are in various formats and supporting materials and sometimes
not detailed enough to understand the content. Then, the content needs to be sliced and
categorized. Eventually borderlines on abstraction layers are not always sharp enough or
decisions need to be taken when formalizing the fragment. This decision, if content is not very
clear, need to be captured and explained for the method fragments. Doing this, the risk is high
to produce too much explanation where the method user could get lost. It seems to be more
important to align used terminology avoiding confusion. Therefore, guidelines can be a
helpful support in better understanding fragments by showing concrete examples, templates,
checklists etc.
© Jan Ricken, University of Namur, Computer Science Department Page 156
Third, the population of such a tool with method fragments for further re-use needs some
knowledge on method engineering, tooling and also on content to be able to formalize method
fragments on the right level of granularity. For efficient population, a method fragment
population tool might be useful. This might be a further future development also stated in the
final conclusion in section 7.3.
Finally, the formalization and population of method fragments into EPF is time-consuming if
all relevant details are filled to allow non-specialists to achieve effectiveness and efficiency in
method application. This is also a central feed-back from project teams during the field trial in
chapter 6.
The next chapter will apply this approach in a real SOA project environment in order to
identify strengths, weaknesses and validation of the proposed configuration process for
situational SOA implementation.
Chapter 6 will apply and validate the Configuration Process for situational SOA Method in
two field trial cases. First, (section 6.1.) field trials are prepared and introduced. Next, the
field trial objectives with related research questions to clarify as well as the field trial method
(section 6.2.) are explained. Next, the evaluation of Configuration Process for situational SOA
Method is conducted (section 6.3.). After this, the content of the method fragments is
explored (section 6.4.). The conclusion is about the validation discussion on configuration
process application, satisfaction on generated outcome as well as conclusions on applied
research method (section 6.5.).
The two real-life field trials will demonstrate practical application of the configuration
process for situational SOA Method and is seeking getting answers to posed research
questions in chapter 1. This is detailed in section 6.2.1.
Next, the field trials will allow the practical application and instantiation of method
fragments. The two field trials are ―typical‖ organizations in Luxembourg. Both are very
different, but typical for Luxembourgish companies. Cargolux is the national airfreight
transportation company, whereas LBBW bank constitutes a subsidiary of a major bank in
Germany. These subsidiaries exist from all mayor banks mainly from France, Belgium,
Germany, Italy and Great Britain.
We will only describe the application of method fragments which are related to SOA Domain
modeling only.
The objective of this field trial is to validate the process of managing situational context of
organization as described in detail in section 4.1. in figure 48. The research questions posed in
section 1.2.1. are worthwhile to be remembered:
Q3.: How can the configuration process for SOA situational Method support the decisions
taken in practice by organizations?
Q6.: What about the quality of generated SOA Method and the achieved results out of SOA
Method?
Q6.1.: Is the quality of generated SOA Engineering Method satisfactorily?
Q6.2.: Is the achieved result from SOA Engineering Method satisfactorily?
Research question 3 will be answered through textual description of the field trial, where
question 6 requires the definition of validation criteria‘s for the posed questions. The
evaluation is consisting of 3 processes
2. Perform Field Trial by applying the Configuration Process for SOA Situational
Method in two real projects.
Following to Wieringa [Wie10], the field trial is a validation method under a controlled
context with realistic examples. The method designer himself is applying or using the
service/product to be investigated. In our case, the controlled context is a specific project,
where we have been invited to apply the configuration process for situational SOA.
For both field trials we apply the described process in section 4.1.:
We are defining our own evaluation criteria‘s, which seems to be reasonable for the concrete
context. The following table is summarizing these evaluation criteria‘s:
These criteria‘s will identify if the applied method can be considered as successful or not.
At the end of the SOA project implementation, the CIO gave feed-back on the thesis
evaluation objective. For the evaluation, a 4-range scale is used: 4: High Acceptance, 3:
Acceptance, 2: Disagree 1: Fully Disagree.
Cargolux, founded in 1970, is one of the leading cargo airlines worldwide, operating
scheduled and charter services on a network covering all continents. The company offers
almost 40 years of experience and, measured in ton-kilometers flown, today ranks in 9th
position worldwide. In Europe, Cargolux is the largest all-cargo airline. The Airline is an
integrated transportation company, operating exclusively for freight forwarders. Cargolux is
using a fleet of 16 B747-400 freighter aircraft and 20 trucking contractors to move valuable
and time-sensitive commodities through the worldwide network, covering over 90
destinations with over 1530 employees world-wide. The staff is multinational originating
from over 30 countries. The network links many of the world‘s most important production
centers of industrial, automotive and consumer goods through our hub in Luxembourg.
Cargolux is constantly adapting its network to changing market demand and trade flows.
and is specialized in the transportation of outsize shipments, perishable goods and live
animals [CAR09].
Cargolux is directly and indirectly responsible for around 5,000 jobs in a small economy
dominated by the financial services industry. For instance, Cargolux is the principal customer
of Luxair Cargo Center, which employs over 1,000 people. Luxair is also Luxembourg‘s flag
carrier and the Luxembourg state is its largest shareholder. Cargolux uses mostly
Luxembourgish trucking companies. The Government is seeking to diversify the economy
away from the financial services industry and the development of the logistics/transportation
Cargolux has decided for the next-generation Boeing 747-8F and was together with Japanese
carrier NCA, the launch customer of this new aircraft type. Cargolux has mid 2012 4 new
generation aircraft in its fleet. This decision shows the clear ambition to operate innovative
aircraft allowing increased efficiency: less fuel burn, whilst the freight capacity is increasing.
The total income increased steadily since 2005 (figures in US$ Millions) [CAR11]:
The net revenue however decreased 2007, 2008 and 2009 three years in a row into a loss.
2010, Cargolux ended with profit of 60mEUR but due to striking crisis in 2011 again reported
a loss end of 2011 [CAR11].
The fleet average is 8.5 years, which is young in relation to other carriers. The uniform B747
fleet allows low maintenance cost and efficient crew training. The specific type of Aircraft is
low in fuel consumption, long range and high payload allowing fast turnarounds. This will
even be increased through the new generation B747/8 Aircraft. In comparison to its
predecessor, the new 747-8 features improved performance in terms of payload, range,
environmental compliance through carbon emission (less 17%), noise reduction (less 30%)
and fuel efficiency (less 17%) with modern ―GEnx‖ engines from General Electric. It is 5.6
Flexibility is one of Cargolux‘s strongest assets and the company successfully builds on long-
term cooperation with their customers. In February 2000, Cargolux took into operation the
world‘s first simulator for the B747-400 freighter. Other carriers e.g. Lufthansa send their
pilots to Luxembourg for simulator training. Due to the flexible strategy of the network and
good customer relationship, the crisis started to affect airfreight markets in June 2008,
Cargolux has gained market shares in important markets like Germany, Italy and across Asia -
always to the detriment of the home carrier. Except for its home base in Luxembourg,
Cargolux does not have any significant ground infrastructure [CAR09].
Therefore, Cargolux can quickly open or close stations to respond to market conditions. While
Cargolux will always be careful to avoid that its operational decisions harm its customers, this
flexibility is a key advantage, in particular in a bear market.
Furthermore, the turn-over of the company is very low which is materializing in very
experienced and knowledgeable employees with high seniority.
The organizational structure is mainly grown in history and very divisional or silo oriented.
Due to high seniority of employees, the dynamics related to change mgt. could sometimes be
improved.
The outsourcing fashion has been followed by preparing a spin-off in 2004 with the objective
to outsource the complete IT department. This challenge has been done and a new IT service
company called Champ Cargo Systems (CCS) has been created. The installed SLA between
both companies was through the first years difficult to manage as there was no experience in
that area. However, the situation is step by step improving. During 2007, Cargolux sold 51%
to SITA and is holding still 49% of CCS shares.
Furthermore, two mayor threats consisting in exploding fuel price and the financial crisis have
negatively impacted the results in 2007, 2008 and 2009 and gave Cargolux a very hard time.
Consequently, IT budgets were downsized to a minimum.
As mentioned before, a key fact to consider is the full IT outsourcing meaning that Cargolux
has only 3 employees to manage the SLA, Cargolux IT strategy, IT projects and Business
Process Management. CCS is serving its main customer Cargolux but also other customer
airlines or handling agents. Therefore, both companies have similar but also divergent
interests.
© Jan Ricken, University of Namur, Computer Science Department Page 163
2005, Cargolux started a serious BPM project with the help of IDS Scheer to design and
record processes in a structured way. This project took one year to finally reorganize
processes with improvement potential bigger than 1mEUR, which was 5 time the cost for the
project. Cargolux decided then to create a centre of excellence for BPM within IT to allow
continuous improvement and a sustainable BPM effort. The top management sponsoring was
crucial and the CEO involvement particularly motivating for the project team. The head of
controlling and head of IT were driving the project forward to make sure a benefit could be
materialized at the end of the day.
Consequently, BPM became a real asset to be re-used for all IT projects. In that period, a
continuous improvement program, BPM Governance, BPM change Management were
defined and implemented.
A massive investment into Master Data Management was done. All data has been modeled in
ARIS. Cargolux was able to classify data into master or transactional data, who is responsible
for it, who has what rights (r/w/m/d) and what application was hosting which data.
Next, EA has been built to show the links and relationship between the components e.g.
Organization, Data, Applications, Processes, Strategy, Network etc. as well as guidelines and
principles to follow.
One of these principles is the SOA paradigm, which is materialized in the EA overview
By having these prerequisites for a successful SOA implementation, Cargolux was able to go
forward with the concept, because considerable process assets/knowledge and BPM design
tool were available.
It is important to mention that for instance the application SAP can be divided into 18 sub-
modules e.g. MM, SD, FI/CO, Treasury, BI, AM, OM etc.
Cargolux BPM management knows exactly to the deepest level of detail what activities are
supported and who is using the application.
For the middleware, Cargolux is using SAP Netweaver and SAP Process Integrator (PI),
which will play an important role for the SOA IT architecture.
This section describes the application of the process ―Manage situational context of
organization for SOA project‖ as described in figure 48 (section 4.1.3.3.) to the Cargolux
SOA project.
The process is starting with two activities on reading and understanding SOA Domains and
sub-domains. This has been done based on information provided in the Method Fragment
Wizard Tool. In our concrete case, this was the facilitating guideline tool (section 5.3.).
The third activity is about the decision on organization-specific priorities. This activity has
been described through section 6.3.2., which permitted to harvest information on the
identification of requirements and technology choices. Cargolux has decided to first start a
proof-of-concept project limiting risks and investments. Furthermore, it has been decided to
re-use available tools and technologies to avoid additional investments.
With the help of the facilitating guideline, activities were selected. It was checked, if and how
the sub-domain ―Modeling‖ was appropriately covered or not. If not, the risk of non-
addressing was discussed.
Next, available method fragments were investigated and evaluated. The same has been done
for available patterns. For this evaluation of method fragments, the details have been
investigated in the method fragment tool/repository.
Next, there was no need to create a new fragment or go for back loop.
The following summarizing table is giving an overview of Cargolux situational context and
constraints:
Table 39: Summary of Cargolux Situational Context and Constraints
This section describes the application of the process ‖Selection of Method Fragment‖ as
described in figure 49 to the Cargolux SOA project.
The process is starting with the creation of a delivery process in the method fragment tool.
This is necessary to ensure an own ―process application‖ instance in the method fragment
tool.
Next, delivery process attributes are filled, which are describing the project scope.
Based on first evaluation of method fragment candidate in previous process, method fragment
attributes are checked clear and understandable. Based on this, Cargolux decided to select 6
fragments. The detailed selection description is summarized in table 40. An iteration of
fragments was not necessary.
Figure 61: Situational SOA Implementation Method Cargolux Action Case (Screenshot Eclipse)
Each abstraction level (e.g. SOA Strategy) is decomposed into one or more activities (Define
SOA Strategy), which is containing different tasks to be chosen. In this case, Cargolux has
selected AVE1 Envision Service Architecture Management.
The selection of method fragments and putting activities into sequences is as stated earlier a
completely manual task. This represents also an improvement direction, which is further
discussed in section 7.3. future work.
A last control on SOA sub-domain coverage was performed. All sub-domains were addressed:
The selected fragments were aligned and sequenced into a top-down approach (sub-domain
1.3.) addressing all layers of abstraction and product fragments as outcome (sub-domain 1.1.)
Cargolux has decided not to use MDA principles (sub-domain 1.2.) as number of processes to
transfer from design-time into run-time too limited and workload too high or not worthwhile.
As a last step, the chosen activities with related method fragments and sequence were
transferred from Method fragment tool into MS project for proper project planning.
Based on the fragment list elaborated earlier, the following fragments have been selected:
ARIS SOA Architect tool was used for the conceptual modeling, SAP for the technical
modeling and the web-service run-time environment. Finally, it was rapidly evident that a full
vendor-driven method could not be used, as a combination of two vendor tools with complete
different methods and viewpoints had to be combined.
The validation discussion is decomposed into 2 key conclusions: First, is quality of generated
SOA Engineering Method satisfactorily? Second, is the achieved result from SOA
Engineering Method satisfactorily?
This section is summarizing the application of both processes on the configuration process for
situational method. The details of the Cargolux field trial fragments are further explained in
section 6.4. As we have ourselves applied the method, this feedback is also our own
observation.
Particularly interesting was the fact that the evaluation of method fragments was done by the
project manager in discussion with the project team. This discussion fueled also the project
team commitment, as the team had a common understanding and evaluation of selected
method fragments. This discussion was possible by using the proposed SOA Domain Excel
tool. Based on the detailed description of criteria‘s and the detailed description attributes of
the method fragment (refer to chapter 4). Based on the SOA Domain Model criteria‘s, 4 AVE
method fragments were combined and assembled with 2 SAP fragments. These fragments
were selected in the EPF tool repository and assembled respecting conditions (e.g. AVE 1 is
input for AVE 2).
In general, the SOA engineering method worked well, the CIO and the development team
were satisfied. On usability, Cargolux was very positive, as the proposed Excel tool allowed
rapid understanding for the SOA domains with the related questions to resolve. Despite the
fact that the method could not be re-used in another project, they were confident that this
would be possible to do. The CIO was satisfied with the way the method was described (SOA
Domain Model, generic method processes, tooling) and the details provided on available
method fragments. On efficiency, the update of fragments requires a lot of discipline after the
project closure. Furthermore, it needs to be considered as an investment for next or upcoming
implementations. As individual situations or context of specific fragments need to be detailed,
this formalization was seen as time consuming. Practical considerations are sharply linked to
permanent cost-benefit evaluations.
Globally, the quality of generated method seemed to be very good. However, the complete
method had to be applied manually. This could be dramatically improved to increase
© Jan Ricken, University of Namur, Computer Science Department Page 171
efficiency and ease of use. Also the integration of the modelling tool, the method fragment
tool and facilitating guideline tool could improve efficiency and increase user friendliness
during application and generation of the configuration process. These observations are
summarized in future work (section 7.3.).
This section details the feedback on the satisfaction with the result of the applied method. The
Cargolux project team providing feed-back is including 5 people with different profiles (CIO
Cargolux, Project Coordinator/Method Architect Cargolux, Project Manager Champ Cargo
Systems, SAP Senior Consultant, SAP Senior Architect). The evaluation has been done in a
workshop by explaining the feedback criteria description. All members gave their feedback on
scaling followed by an alignment discussion on agreeing finally to 4 on the scale.
Globally, the result out of the applied SOA method was satisfactory. However, the two most
important comments on weaknesses were seen in the limited number of available fragments
and the manual selection and assembly process.
This field trial showed clearly, that pre-configured and vendor-driven methods would have
been difficult to apply, as they would not have respected the special conditions, available IT
application landscape or scope to be applied. Consequently, a situation specific application
seemed to be advantageous, as process fragments were applied depending on the situation or
context. This is particularly true for medium size companies like Cargolux with limited IT
budgets and the wish to re-use available tools and technology.
During the field trial study with the AVALOQ-project, the bank was structured into 4
business lines:
The LRI Invest has been sold to financial investors (Augur Financial Holding V.S.A.) which
are running the fund management business to date.[LRI12]
The case study projected started with LRI S.A. and was merged during the project into the
LBBW S.A.. This was a first cultural change to digest with huge impact as organization
structures changed and reporting lines to the new head office were established. Then, the
financial crisis hit the market and the German Landesbanks suffered a lot as some of them
were invested into sub primes and high risk investments. The losses of the German
Landesbanks caused an important discussion within the German Government (as owners)
about the business model of German Landesbanks. Despite the healthy and efficient
Luxembourgish business model, the head office in Stuttgart decided to sell their major part of
international branches to refocus more on credit and loan business for the German midsize
market. With the confession of having failed in risk management and having revealed lacks in
the business model and positioning, the LBBW was forced to act as prescribed by the
government and the public opinion and decided to sell their Luxembourg branch within a
transition period of two years meaning by end of 2011.
The LBBW S.A. is a very profitable entity, despite the huge losses the mother company had
with other international branches caused by high risk investments. The bank is very well
organized and has a state-of-the art efficient process landscape with modern straight-through
processes. The organization with the reporting lines is process oriented and the new core
banking system can be considered as the latest state-of-the art system available on the market.
A high seniority and a very experienced employee‘s base is an asset of the bank.
Firstly, the banking system ―IBSY‖ was outdated and old fashion, a modern IT architectural
style e.g. SOA not possible. This weakness has been recognized to increase business
efficiency and realign business processes.
A weakness in this context is the permanent exposure and dependency to the mother bank,
first situated in Mainz (LRI) and later after the merge in Stuttgart (LBBW). Important
business lines have been already sold as part of a downsizing roadmap to digest the financial
crisis.
Next, employees are not sure about the future owner and therefore incertitude could lead to
the leaving of best staff.
SOA itself was not considered as an objective per se, but SOA came on the table as integrated
part of a new core banking system. The old core banking system ―IBSY‖ was out phased and
simply not any more suited to serve the banking business in an accurate way. The bank had
already since 2003 a comprehensive BPM system as part of the IT and Organization
department. The bank is using ARIS Toolset and has a dedicated organization service of 4
FTE to care about processes and procedures. Through their BPM system, the bank had a very
good knowledge on existing processes, what data and documents were used and how the IT
systems were supporting the processes and activities. The organization knowledge also
included methodological experience and the process management was well accepted and well
known through business units. As said, SOA was an underlying mechanism and architectural
style that enabled the new core banking system. To find the suitable system, the bank
performed a detailed two year analysis project together with KPMG. A questionnaire with
approximately 3000 questions has been developed and given to the software provider as a
request for proposal (RFP). Within this extensive catalogue, software requirements and also
underlying technological capabilities have been formalized. The project set-up can be
summarized as follows [LBBW09b]:
As new system, the leading Swiss software provider for banking systems ―AVALOQ‖ has
been chosen and the consulting company ―ORBIUM‖ as integrator has been selected. Once
selected, a 6 months period prior to the project kick-off was used to develop the process-
oriented implementation method. The implementation project itself took another 1.5 years for
go-life. The summary of key figures and project organization structure [LBBW09b]:
The section 6.3.7. explained the general context of LBBW bank. This section is related to the
application of process as shown in figure 48 (section 4.1.3.3.).
To start the process, a kick-off meeting was held were SOA domains were presented and sub-
domains further explained. Based on this, a workshop has been organized to gather all LBBW
specific information as earlier presented in the kick-off. The most important situational
context was described by a radical process and-organization re-engineering on the occasion of
a new core banking system implementation. For the process design part, a modeling tool was
on hand, whereas the banking core system AVALOQ has been selected.
With the help of the facilitating guideline, activities were selected. It was checked, if and how
the sub-domain ―Modeling‖ was appropriately covered or not. If not, the risk of non-
addressing was discussed.
Next, available method fragments were investigated and evaluated. The same has been done
for available patterns. For this evaluation of method fragments, the details have been
investigated in the method fragment tool/repository. Due to the special set-up with AVALOQ
as new core banking tool and related non-availability of AVALOQ SOA method, only AVE
fragments have been evaluated.
Based on this, there was a need to create 2 new fragments: LBBW1 and LBBW2. The process
―create method fragment‖ (figure 47) has been applied as the available AVE fragments were
not covering the needs of the situational project context. The LBBW1 fragment has as
objective to show details on used web-services per AVALOQ module. The generated product
fragment is an access model (details section 6.4.2.4.) on PIM level. The LBBW2 fragment has
as objective to show technical web-service process descriptions details. The product fragment
outcome is under EPC notation. The conventions for the EPC notation are different than for
AVE5. Consequently, an EPC product fragment is positioned on CIM level and another EPC
product fragment on PIM level.
The situational context and constraints for the LBBW field trial can be summarized as
follows:
Table 43: Summary of LBBW Situational Context and Constraints
This section describes the application of the process ‖Selection of Method Fragment‖ as
detailed in figure 49 to the LBBW SOA project. The process is starting with the creation of a
delivery process in the method fragment tool for LBBW SOA project. Next, delivery process
attributes were filled, which are describing the LBBW project scope. Based on first
evaluation of method fragment candidate in previous process, method fragment attributes are
checked clear and understandable. Based on this, LBBW decided to select 3 evaluated AVE
fragments and to select 2 custom-made LBBW fragments. The detailed selection description
is summarized in table 44. Next, the selected method fragments were manually compiled (by
drag and drop) into the LBBW delivery process by manually defining sequences. The selected
method fragments are then consequently assembled into a coherent sequence. The work-
breakdown structure for LBBW, which is the Eclipse wording for an activity plan with
selected fragments, can be shown as following:
Based on the fragment list elaborated earlier, the following fragments have been selected:
Following to the method fragment selection, the solution path on abstraction levels is showing
ARIS Tool for the design time on Strategy, CIM-level and PIM-level, whereas the technical
implementation in AVALOQ was done with web-services. Related to the project objective,
the following modelling design path has been chosen:
Similarly to the Cargolux field trial study, the validation discussion is decomposed into 2 key
conclusions: First, is quality of generated SOA Engineering Method satisfactorily? Second, is
the the achieved result from SOA Engineering Method satisfactorily?
6.3.10.1. Feedback of Configuration Process for SOA situational Method Application LBBW
The main difference of generating the method was the fact that only 3 method fragments have
been selected. The reason for this was the non-availability of SOA method from AVALOQ.
Here, 2 new method fragments were created to mitigate the risk of missing formalization on
PIM level. For this, the process as described in figure 48 has been applied successfully.
The insight gained from this method application is the following: because auf situational
context, a fragment has been re-used on two different levels, which was not foreseen at the
beginning of the project. Therefore, the fragment AVE5 has been copied and modified to the
PIM requirements of LBBW. The LBBW project created consequently its own fragment,
which is a variant of AVE5. Instead of using it on the CIM-level for modeling the business
requirements, the LBBW fragment has been used on the PIM-level for the specific purpose of
detailing the web-service behavior/interaction and details. This was a consequence of non-
availability of AVALOQ method. This example is demonstrating the successful application of
the configuration process for situational SOA.
Next, based on this field trial experience, AVALOQ announced the wish to create own
method fragments to be used for coming projects to overcome the lack of method availability.
The LBBW project team was approximately 23 persons from the total team of 112 project
team members. As explained in figure 65, the project management and applied method was
part of the project office. Therefore, the CIO being the responsible project manager and
heading the project office gave feedback together with the key resources in the project.
Similarly to the Cargolux case, a discussion took place to agree on effectiveness of method
application result. The rating was estimated ―acceptance/good‖:
Generally, the project situation was complex, as 3 parties (LBBW, AVALOQ, Orbium) with
different viewpoints and objectives were involved into the project. The required steps and
activities were build-into the overall project plan. The project management and the method-
team worked closely together, and communicated to project team groups about requirements.
Overall the generated situational method was not as efficient as expected, as the complete
project was more seen as a ―new core banking system‖ and not a ―SOA project‖. SOA
objectives were implicitly described by the project objectives. The centre of process
excellence was managing the processes and method acting as project office and quality
assurance body consisting of more people than in the first trial case. This fact made the
communication and alignment effort with project teams much higher.
In total, the implementation of the new AVALOQ core banking system was successful
meaning in time, in budget and in required quality. SOA principles have been successfully
implemented by allowing web-services to perform business activities but also to interface
business functionality such as data interfacing with other applications. As AVALOQ had no
dedicated process-oriented SOA implementation approach, the complete conceptual design
The following sections will focus on the Cargolux field trial and describe in detail the applied
method fragments, starting with Strategy layer going downwards into Processes and IT layers.
The content of selected method fragments as described in section 4.2. is now further
explained to give more details on research questions 4 and 5 which are the question about
candidate modeling languages and the integration of product fragment artifacts into the
applied configuration process for situational SOA Method.
In order to show the application of the method, it is also important to illustrate the content to
ensure proper understanding of the approach. The following subsections will detail and
illustrate the produced content of selected method fragments for Cargolux field trial.
6.4.1.1. Fragment AVE 1: Envision Service Architecture Management (Activity: Define SOA
Strategy)
The chosen strategy was consisting in first defining a Proof-of-Concept (PoC) to allow a first
experience on small scale instead of taking a high risk in uncertain times for a full blown
project.
As Cargolux faces a fragmented and heterogeneous application landscape, the SOA paradigm
seems to be promising. The following potential benefits have been identified:
Enterprise Agility
Cargolux is looking for the ability to quickly react to changing conditions by configuring and
extending quickly application functionality. Second argument is the agile reconfiguration of
technical infrastructure and organizational structure as business requirements change because
it becomes easier to add, remove, or modify services than to change hard-corded applications.
© Jan Ricken, University of Namur, Computer Science Department Page 182
Securing IT Investments
Another benefit identified by Cargolux consists in a better protection of IT investments on the
long term due to service encapsulation. The interface of the service may change while
protecting the internal code, or vice versa, the internal code can be upgraded without affecting
the rest of the architecture.
The Cargolux strategy set-up and the matching to the top-down pyramid can be shown as
follows:
Cargolux has a well-defined market strategy and an underlying business model, which is
called ―Cargolux heartbeat‖. The business model is relying on a very flexible network to serve
in the best way customers. Customers are defined uniquely as forwarders e.g. Panalpina,
Kuehne&Nagel or DHL. The green indicated areas process, data and systems is owned by the
divisions and facilitated by the IT department.
As major strengths, Cargolux identified the knowledge on BPM as critical success factor for
SOA construction as well as theoretical SOA knowledge. Furthermore, the top management is
a strong supporter of IT division with its vision for SOA. As SOA has practically not been
implemented so far, it is evident that the missing experience has been identified as a potential
weakness. The timing with 2009-2011 was clearly an advantage as the crisis allowed to
concentrate on internal conceptual work. Traditionally, Cargolux is not a pioneer for the latest
technology or fashion but follows very close by monitoring exactly if a new technology is
worth to be adapted. The pitfalls of heavy investments at high risk are by this approach
reduced to a minimum. As Champ Cargo Systems (CCS) which is the outsourced full IT
provider of Cargolux has the latest technology available, it was evaluated also as opportunity
to convince CCS to go towards a SOA evaluation exercise. This fact is also a major threat as
CCS has so far no experience with SOA and therefore lacks on method, experienced staff.
Cargolux is completely dependent on the ability to execute this type of projects, as the
implementation of the conceptual work is completely done on CCS side.
The conclusion on this SWOT was to use SAP technology with CCS as Cargolux is
dependent on their resources in medium and long term. SAP consultants were used as ―train-
the-trainers‖ for CCS SAP specialists.
6.4.1.2. Fragment: AVE2 Business Goals with Balanced Scorecard (Activity: Model Strategy
with BSC)
The selection for the SOA Proof-of-Concept has been done on an extensive process landscape
analysis, which has been driven by strategic objectives of the company formalized in the
Balanced Scorecard Model:
Figure 69: Cargolux Balanced Scorecard Model with Cargolux SOA Objectives
Independently from the pure modelling part, the strategy also includes the SOA Governance
definition with roles & responsibilities, policies and procedures. This is not further detailed as
this is not related to the focus of showing the top-down model and process-oriented SOA
implementation.
Furthermore, one process has been selected to improve dramatically performance, namely
―Travel Expense Mgt.‖ to prove rapidly the value of SOA principles. This is a high volume
process with a considerable amount of interfaces to other systems to retrieve and re-use
information. As the underlying technology is mainly SAP, this fact was another argument to
stay within SAP run-time environment. The completely manual and paper oriented process
should be transformed into a high-performance process using leading technology (SAP portal,
SAP PI, SAP CE) to dramatically improve the process. Once feasibility of SOA and also
benefits illustrated, the further roll-out was planned in a second phase. This is a good example
how scope, culture and available IT Architecture influence SOA objectives.
6.4.1.3. Fragment: AVE4 Enterprise Process Map (Activity: Model Value Chain for Process
Overview)
In order to define the business requirements, it is necessary to model the process first from the
business user perspective. In order to have a good overview of the processes in scope, a high-
level diagram is used. Furthermore, the relationships and dependencies in between process are
illustrated by using a value chain model:
Figure 70: Value Chain Model for scoping and high-level Process Overview
Different guidance documents have helped as input to identify the specificities such as the
―Collective Work Agreement‖ and ―Cargolux Travel Policy‖. Each process in the high-level
process map has been detailed on activities level. Beside the standard EPC information with
events, activities, positions and application systems, the process models were enhanced with
required information such as data used, potential web-services used and potential screens.
Each task has been drilled down into work steps and allowed therefore a very detailed
explanation of business requirements and system behaviour. The result out of this business
requirements analysis was a functional blueprint document as outcome.
6.4.1.4. Fragment: AVE5 Service Oriented Business Process (Activity: Model Business
Requirements with EPC)
As described in section 6.3.4., Cargolux decided for EPC as modelling language for
representing business requirements. All other available Cargolux processes (approx. 700)
were since 2005 designed with EPC-method and therefore well-known by analysts and users.
EPC notation is allowing business analysts to formalize the requirements which are then
understandable for IT roles. Each of the activities is further described on work-step level to
unambiguously make requirements clear how the user and the system should work. Figure 71
illustrates the process for managers ―Travel Expense Management for Managers‖:
SAPs ―Service Modelling‖ fragment is modelling and designing the BPMN process
containing the identification of SAP Business Objects, the description of user interfaces and
interaction and the determination of Service Candidates. The EPC-Model containing the
business requirements is translated manually into BPMN and enriched with required technical
information.
The modelling notation in SAP is BPMN 2.0., which is executable in the SAP SOA Run-time
environment. As an example illustrating the difference between these levels of abstraction, the
technical process is shown following BPMN 2.0. Modelling conventions:
Figure 72: Example for Cargolux Technical Process, BPMN, PIM Level
The actors are positioned at the top of the swim lanes, which are executing activities. Decision
flows and rules are used.
© Jan Ricken, University of Namur, Computer Science Department Page 188
6.4.1.6. Fragment: SAP 3 Build Services (Activity: Create Services with WSDL)
Every activity in the technical model gets a screen assigned, which is built in Web DynPro.
Related to this, services are re-used from the Enterprise Services Repository (ESR) which is
an integral part of PI and SAP CE components. It is used to design, model, manage and
discover enterprise SOA based objects. The following table illustrates (an excerpt) of the list
with required web-services derived from the business requirements. Some of these are already
available as best-practice in the SAP Registry. Others are already available and can be re-used
because of earlier web-service developments. 60% of total number of required services need
to be developed.
Table 47: Excerpt of Required Web-Services List
Again, as the focus of this present thesis is lying on the process- and model-driven part, the
technical SOA Web-Service issues are not detailed but only enumerated in table 47.
The following subsections will detail and illustrate the produced content of selected method
fragments for LBBW field trial.
6.4.2.1. Fragment AVE 1: Envision Service Architecture Management (Activity: Define SOA
Strategy)
LBBW S.A. was considering SOA not being the first strategic objective by itself, but acting
as an enabler for the new core banking system with the main goal to increase efficiency and
therefore to significantly reduce cost. Interestingly, this primary objective gave the
opportunity to radically re-engineer the whole organization and to structure the business units
with corresponding organizational impacts strictly following products and end-to-end
processes. Therefore, the second main objective was a consequent alignment of the overall
banking organization with the products and services and realize efficient straight through
processing. The long term objective (5 years) is to offer single business processes as a service.
IT is playing the role of service provider towards internal needs. It is also planned to analyse
possibilities to sell these services to the external e.g. other banks. To enable the technical
platform, service orientation has been introduced as basic principle for the IT architecture.
The new system brought in nearly 6000 functionalities or services which were structured into
6 groups:
© Jan Ricken, University of Namur, Computer Science Department Page 189
Cash Management,
Securities,
Deposit,
Investment Funds,
Administration: Master Data and
Administration: Private Banking Sales Support.
The organization strategy with the mentioned objectives, were input for the project
preparation as well as the organization culture and the IT Budget with two-digit Mio Euro.
Unfortunately, the Return on investment has not been calculated the business case was valid
and top management support obtained. Roles and Responsibilities were agreed. The project
office, quality assurance and risk management were assured by the organization department
also responsible for the BPM system.
Similar to the first case study the following principles and decisions have been taken:
Top-down approach,
Knowledge of Processes and Process Documentation,
Tool driven approach,
Extensive Change Management,
Holistic Approach
The box on the upper-right corner in figure 73 indicates clearly SOA as a strategic objective.
The modeling of strategy has not been done, as the description in natural language and
presentations were satisfactory for the project group.
Figure 74 illustrates a high-level strategic business process landscape showing the executed
processes by the bank. Due to complexity, it is necessary to model details of illustrated 25
macro-processes (olive colour):
With this overview, the scoping of processes is done. There are no relationships modelled
between macro processes. ―Data Management‖ is decomposed into further sub-processes
which are Account Closure, Account Opening, Account Change etc. We exemplarily drill
down into the ―Account Closure‖ process, which is again a value added chain diagram:
Figure 75: Value Added Chain Model "Account Closure" Process LBBW
6.4.2.3. Fragment: AVE5 Service Oriented Business Process (Activity: Model Business
Requirements with EPC)
The next fragment is about the modelling of business requirements with EPC. Exemplarily,
we present the produced EPC model ―Manage Equities Deal‖. The same EPC conventions
apply as introduced in figure 20 and 45 :
For the activity e.g. ―Check Volume and Maintain prices‖, a specific AVALOQ service is
requested. The intermediary model (Access Diagram) is showing what service (web-service)
is needed:
The LBBW2 fragment again has been created for a specific purpose to model web-service
requirements. A so called ―AVALOQ Reference Database‖ proposed by the AVALOQ
project team could not be used as descriptions of functionality were not process-oriented.
Therefore, LBBW required detailed description of processes allowing technical
implementation of the system. Exemplarily, the web-service object ―GLB-AVA$SWT‖ can
be further drilled down to get the technical web-service process description model. This
model explains in EPC-notation, what exactly the web-service is supposed to do. It is
indicating the platform, the technology and the conditions to perform the requested service
(PIM). From there, the web-service is programmed in WSDL in order to implement and
deploy it in the AVALOQ-system (PSM). To achieve this, the AVE5 fragment has been
copied and modified in the method fragment database. The same conventions for EPC apply,
but additionally also IS Services Objects and Information Carrier Objects are used:
The conclusion is structured into 3 parts: first, conclusions a made on validation discussion
for the applied configuration process. Second, the outcome of the generated method fragments
with the integration of modelling notations into the SOA Method and third, some conclusions
on the applied field trial research method.
The main conclusions out of these cases can be summarized to following findings:
New was the utilization of EPC model to illustrate the details of web-services. On this deep
level of detail, we would normally assume more technical models such as BPEL, UML
sequence, state chart etc. but the chosen approach was successful. Hence, the method
fragment of modeling EPC which is normally used on CIM level has been used on PIM level
(LBBW2 Method Fragment), where it is normally not expected. AVE5 fragment has been
copied and modified by LBBW and re-used for the PIM – Level, which was normally not
foreseen in the description of the method fragment. This specific style of applying the method
was a bit unconventional, but finally successful.
Overall the field trials showed successfully that existing SOA implementation methods are
not good enough to be applied in the two real life field trial projects. In order to find a way to
tailor the available methods to the situation-specific project, the decomposition of available
methods into single fragments using an engineering method (section 4.1.) was successfully
applied (section 6.3.). The validation discussion in chapter 6.3. Summarized feed-back on
method application (section 6.3.5.1. and 6.3.10.1.) and satisfaction level with outcoming
results (6.3.5.2. and 6.3.10.2.). The achieved method satisfaction by CIOs including also the
project team showed clearly the benefit of the proposed approach.
Related to the applied model fragment for selecting different modelling notations on different
levels of detail, the following summary is showing the work products (natural language
description for strategy not considered as modelling notation):
Field trial Cargolux formalized strategic Objectives in a BSC Model. For the high-level
business process overview, Value Chain Model has been used. Then the link to EPC has been
done to formalize business requirements. Then, the cut between SOA design time and SOA
run-time was done. Technical BPMN models were created in SAP and enriched with WSDL
web-service description.
Conclusion on the applied field trial method can be summarized to following remarks:
Generally, the validation by the field trials has shown that the Configuration Process for
situational Method can be used in practice. Following to the field trial observations, the
applied method could also work in other projects or practical cases.
The SOA projects were successful, but the positive impact of the applied method could not
been measured with the field trial method.
Next, the field trial cannot be redone using another SOA Method or selecting other fragments.
Each case with its context and constraints is unique which is creating uncertainty. Contrary to
a laboratory experiment, the field trials cannot be redone nor trial context can be changed.
The influence of the author applying the configuration method in these trials related to the
taken decisions for/against method fragments could not been measured.
This chapter is summarizing the research contributions (7.1.) related to the four research
artefacts of the SOA Engineering Framework. First, the SOA Domain Model sets the
conceptual frame (section 7.1.1.) for the SOA Method Qualification (section 7.1.2.). The
configuration processes for situational SOA Method (section 7.1.3.) and the formalisation of
SOA Method Fragments (7.1.4.) are four composing blocks of the SOA Method Engineering
Framework. A conclusion on chosen viewpoints of top-down, model-driven and process-
orientation (section 7.1.5.) is made. Next, identified limitations of current work (7.2.) are
explained. Future work and areas of further development are highlighted (7.3.) and finally
closing remarks is pointing to publications in relation with this thesis (7.4.).
During the last years, SOA reached more maturity and left the ―hype‖-topic area. New topics
such as Software as a Service (SaaS), Process as a Service (PaaS), ―Apps‖ and ―Cloud‖ topics
are attracting now more interest as ―new‖ and upcoming technologies and process innovation.
Nevertheless, SOA is still on the agendas of organizations to explore the promised benefits
the SOA paradigm can deliver. But to do so, it is required to apply a method which is adapted
to the context and the situation in which the organization wants to apply the project. ―One size
fits all‖ for this particularly complex project type is not realistic. Consequently, the original
research topic of a missing SOA engineering method has been addressed and a proposal
taking the process-oriented and model-driven perspective has been shown through this thesis.
This thesis has shown that available methods through state-of-the-art are not complete enough
to cope with a consistent SOA engineering method. The existing SOA methods use specific
views or are designed to accompany industrial software products. The method presented in
this thesis is built on four main research contributions:
The first and second ones are the definition of the SOA Domain Model and the qualification
of existing SOA implementation method proposals with focus on recommended SOA
modeling languages on different levels of abstraction. Under the chosen viewpoint, the
research question 1 (Differences of available SOA Methods?) has been investigated. Also
The third main research contribution is the creation of Configuration Process for SOA
Situational Method using method engineering principles linking to the SOA Domain
Model particularly for the SOA Domain Modeling. This third research contribution
investigates the research question about requirements for situated SOA methods (research
question 2: what is required for decomposing/recomposing a SOA Method?). This question is
also addressed through the fourth main research artifact about the formalization of SOA
Method Fragments from available SOA Methods.
The application of these 4 contributions in real industrial field trial cases investigates the
questions on practical decisions taken (research question 3: what are decisions taken by
organizations, when applying configuration process for SOA situational Method?) on
applying the method.
Next, as we are particularly interested in the SOA Modelling Domain, the research question 4
(research question 4: Which candidate modeling languages are suited?) and 5 (research
question 5: How to integrate the different kinds of modeling in a single SOA Method?) are
key. Finally, the overall satisfaction with the generated and applied situational configuration
process for SOA and the satisfaction of result are investigated (research question 6: what level
of satisfaction for generated method achieved? and what is the level of satisfaction with
situational SOA Method content outcome?).
As we have chosen the viewpoint of modelling, a particular focus was made on best suited
modelling languages for SOA implementation. Therefore, a complete overview model
positioning the different modelling languages on related level of abstractions has been
constructed (section 2.3 and 2.4.). The analysis of state-of-the-art followed by the validation
of questionnaire participants (section 3.3.3.) has confirmed that specific modelling languages
are more suited than others. The results have also confirmed that some modelling languages
compete on the same level of detail. Additionally, transformation mechanisms between the
levels of abstractions have been investigated.
© Jan Ricken, University of Namur, Computer Science Department Page 200
7.1.2. SOA Method Qualification
The SOA Domain Model has been used to analyse and rate available SOA method proposals
(section 3.2.). The qualification of SOA Methods has confirmed that SOA engineering
principles are not applied and that currently available proposals are not adapted to the
particular situation of organizations. The qualification tells nothing about the quality of the
SOA Method, but more on the coverage of SOA Domains and SOA Sub-Domains.
Depending on provenance of the SOA Method, the results vary a lot related to sub-domain
coverage. The fact that SOA Methods are not adaptable to situation has also been expressed
through the questionnaire results (section 3.3.3.) where the need for a situational SOA
Engineering Method has been underlined.
The configuration process for SOA situational method has been applied and instantiated in the
field trial cases (section 6.3.) to gather information on what concrete decisions practical
organizations take. In both cases, valuable validation discussions (section 6.3.5.1 and
5.3.10.1.) on the application of the configuration process including the decisions taken for
specific situations were made.
Furthermore, the quality of generated configuration process for SOA situational method has
been evaluated (section 6.3.5.2. and 6.3.10.2.) and summarized (6.5.). It showed in both cases
that the quality of generated method was satisfactorily because the applied method permitted
consideration of individual situations.
Finally, the applied process with related decisions also indicated clearly suited modeling
languages and how these languages were integrated in the SOA Method (figures 62, 67 and
79).
The SOA Method fragments were created (section 4.2.) from available SOA Methods (section
3.2.2. and 3.2.3.) To do this, ME principles have been used (section 2.6.) and a tooling
support (section 5.3.) provided an efficient way of creating and storing method fragments in a
fragment tool (Eclipse Process Framework) implementing SPEM 2.0. as defined by OMG.
These fragments were formalized and stored in the fragment database and were made
available for re-use during the two concrete field trial project applications. Based on
situational context, different fragments were selected (section 6.3.4. and 6.3.9.). In the LBBW
case, 2 new fragments (LBBW1 and LBBW2) had to be created as available method
© Jan Ricken, University of Namur, Computer Science Department Page 201
fragments could not satisfy the needs related to the specific situation. Generated method
fragment details of these two field trials (section 6.4.) were explained and illustrated in detail
including produced models. The conclusions on generated method fragment outcome (section
6.5.2.) were valuable as the selected and used modeling notations could be positioned on the
different levels of abstractions and therefore closed the loop to the state-of-the-art and posed
questions on candidate modeling languages and the integration into a single SOA Method.
The re-use of available method fragments showed exactly how organizations took individual
method design decisions for the SOA implementation project. We have shown that both
customized approaches were different from the standard SOA implementation methods.
Consequently, it was necessary to assemble method fragments because of situational context.
These decisions were mainly driven by the SOA run-time operating system and the
possibilities to interface with the design-time environment. The constructed method fragments
are available in the method fragment database and can be re-used if situational context is
similar or fitting.
Hence, through positive feedbacks of Cargolux and LBBW, the application cases showed
therefore the value of the SOA Domain Model in relationship with the configuration process
for situational SOA and the application of SOA Method Fragments.
The chosen viewpoints, as introduced in chapter 1 and detailed through the state-of-the-art in
chapter 2, were also scoping this work and drawing the borderlines. The chosen viewpoints
are of course not excluding or qualifying other viewpoints which could have been selected
instead.
Both field trials used the same principles being top-down, model-driven and process-oriented.
Modeling was used and process orientation was followed, but the MDA principles have not
been applied to a full extent for good reasons. The applied approach with chosen modeling
notations on the various levels of abstraction has shown in a consistent way, how these
principles were used and what decisions were taken to implement a tailored and situational
SOA implementation method.
The SOA Domain Model is including a lot of sub-domains and related broad content to
address and includes a wide range of topics. It is in this thesis not possible to detail all
domains as deep as the SOA Modeling domain. This choice is necessary, as the thesis is
taking the specific viewpoints as explained earlier. However, the other domains could be
investigated in more detail through future work.
The questionnaire could not ―validate‖ findings as statistically seen not enough participants
responded to the questionnaire. As indicated already in the questionnaire limitations (section
3.3.), the statistical relevance with 54 valid respondents was unfortunately a bit low to
conclude with empiric ―validation‖ of asked questions.
The modeling language domain is very broad and de-facto completeness very difficult to
achieve. Van der Aalst, ter Hofstede and Weske [vdAtHW03] were stating that an exhaustive
list of modeling languages and comparing them was not possible. Consequently, the list was
called ―de-facto exhaustive‖ by summarizing state-of-the-art references to conclude with a
long list of descriptive modeling languages. Another limitation to this consists in the difficulty
to identify clearly and separate sharply quickly evolving modeling languages, notations,
frameworks, meta-models and the degree of formalism.
SOA Implementation methods could only be evaluated on available information. The level of
detail was varying between the methods and also related to the requirements and decisions
within the methods. Proprietary methods from industrial vendors were sometimes not
available to full extent and full detail because these were considered as a competitive
advantage towards market competitors.
Method fragments were created taking specific choices (SPEM2.0. and Eclipse Process
Framework Tool). It is not clear if other decisions would have led to other results.
The field trial cases were conducted only for 2 projects and two different industries and scope.
The conclusions are only valid for these specific cases. The results can therefore hardly be
generalized to many other cases. Finally, we conducted only a first cycle of the validation in
the action cases. There could be more iterations helping to achieve another level of validation.
The contribution to project success of using the proposed method could not be measured. It
was not possible to extract the effect of using an efficient method against the effect of other
criteria‘s could have e.g. ―top management buy-in‖ or ―skilled project team‖. Furthermore, it
was not possible to redo the field trials and apply another method e.g. complete available
―SOA Methods‖ or ―pure technical approaches‖ being not process-oriented and model-driven
to see if in that case the project would not have been successful or less successful.
The SOA Domain Model tool could be enhanced by extending the model with content
towards related SOA Sub-Domains from other or remaining SOA methods. Following to this,
the SOA Domain Model could be updated (SOA Domain Modeling), enlarged (other SOA
Domains) and similar application cases done in other SOA Model Domains.
The SOA Domain model is the baseline work for developing a complete ontology for SOA
implementation. The first model with its method fragments examples could be refined and
enlarged. Next, an increasing number of available method fragments e.g. with formalization
of academic and industrial approaches in one database open for everybody could help to
accelerate notoriety and finally also usage of the proposed situational engineering method.
Therefore, owners/creators of SOA methods would need to translate their methods into
method fragments and post them into an online method fragment database. In reality, this is
resource intensive and probably mostly interesting for consulting companies as they are
selling SOA Implementation projects. As these consulting companies compete with each
other, an open and shared method fragment database between various providers seems to be
difficult.
Another area of work is to apply goal-driven analysis for the fragments in relationships to the
criteria‘s. So far, there is a link between method fragments and SOA sub-domains, but there is
no automatic mechanism e.g. such as dependency graphs who could evaluate automatically
how well certain objectives are linked to these sub-domains. This research is ongoing
[BCDV+11]. Next, other SOA Domains could be further formalized into fragments using the
SOA alignment model (section 4.1.1.) between SOA Domain Model and ME terminology.
This model so far cannot be generalized, as the mechanisms have been only applied on the
SOA Domain ―Modeling‖.
The guidance dimension is certainly also an area for future work. In particular, the guidance
procedure on how to use the SOA Domain Model could be more enlarged to other
implementation strategies such as meet-in-the-middle or bottom-up modeling. The best
solution for this requirement might be a smart wizard tool proposing automatically different
options based on requirements and project situation. Ideally, the SOA Domain Tool could be
implemented into the Method Fragment Tool such as EPF. The configuration processes for
situational SOA could be implemented into a workflow tool, which would ensure proper
process execution enforcement.
The validation of proposed method could be further improved, by applying the method to case
studies in bigger sized organizations outside Luxembourg with the objective of obtaining
more feedback on practicability, strengths and weaknesses of the proposed SOA engineering
Framework. Here, more iteration cycles could be done with the objective to achieve more
robust evaluation and finally also possibilities to fine-tune the proposed framework.
The impact of the applied method on project success could be further investigated. So far,
there is some work on success impact of deploying method (top-down, meet-in-the-middle,
bottom-up) but not on exposing the impact of the situational SOA Implementation method to
project success. This would be probably a thesis for its own, as a higher number of
applications would be needed and a method to extract the effect in parallel projects to
compare success rates.
The following publications related to this thesis are covering most of the scientific
contribution:
[RP09] Ricken J., Petit M.: Requirements for BPM-SOA Methods: Results from an Empirical
Study of Industrial Practice. Business Process Management Workshops 2009: 453-464,
BPM2009, Springer, Volume 17, Part 8, 621-632, DOI: 10.1007/978-3-642-00328-8_62,
Ulm, Germany, 2009
[Ric09] Ricken, J.: Results on Testing a SOA Domain Model through an empirical study –
Executive Summary, Technical Report, University of Namur, Computer Science Faculty,
Namur, Belgium, 2009.
[RP08] Ricken, J.; Petit M.: Characterization of Methods for Process-Oriented Engineering of
SOA, in: Procedures of Collaborative Business Processes Workshop. BPM2008, Springer,
DOI: 10.1007/978-3-642-00328-8_62 01.09 – 04.09.08, Milano, Italy, 2008
[Ric07]: Ricken J.: Top-Down Modeling Method for Model-Driven SOA Construction. OTM
Workshops (1) 2007: 323-332 in: On the Move to meaningful Internet Systems (OTM):
Volume 4805/2010, DOI: 10.1007/978-3-540-76888-3_54, Springer, LNCS, 2007
[ACDGK+03] Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F.,
Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I., and Weerawarana, S.: Business
Process Execution Language for Web Services, Version 1.1. Specification, BEA Systems,
IBM Corp., Microsoft Corp., SAP AG, Siebel Systems, 2003
[AGAAG+08] Arsanjani A., Ghosh S., Allam A., Abdollah T., Ganapathy S., Holley K.:
SOMA: A Method for developing service-oriented solutions, IBM Systems Journal 47
(3):377-396, 2008
[AHW03] van der Aalst, W.M.P., Hofstede, A.H.M., Weske, M.: Business Process
Management: A Survey. In: van der Aalst, W.M.P., ter Hofstede, A.H.M., Weske, M. (eds.)
BPM 2003. LNCS, vol. 2678, pp. 1-12. Springer, 2003
[Alo04] Alonso G., et al.: Web Service, Concepts, Architectures & Applications, Springer,
Heidelberg 2004
[Ark02] Arkin, A.: Business Process Modeling Language (BPML). Spec., BPMI.org., 2002
[Ars04] Arsanjani A.: Service-Oriented Modelling and Architecture (SOMA), IBM
developer-Works 2004
[ATHEN03] ATHENA: Deliverable DA 1.1.1.: First Version of State of the Art in Enterprise
Modelling Techniques and Technologies to Support Enterprise InteroperabilityWork package
– A1.1, 2003
[ATHEN05] Advanced Technologies for interoperability of Heterogeneous Enterprise
Networks and their Applications: Deliverable D.A5.1: Perspectives in Service-Oriented
Architectures and their Application in Environments that Require Solutions to be Planned and
Customisable, Nov 2005
[ATHEN06] Advanced Technologies for interoperability of Heterogeneous Enterprise
Networks and their Applications: Deliverable A6.3 : Model-driven and Adaptable
Interoperability Framework, July 2006
[Bac00] Bachmann F. et al., Technical Concepts of Component Based Software Engineering,
Technical Report, Carnegie-Mellon UniversityCMU/SEI-2000-TR-008 ESC-TR.-2000-
007,2nd Edition, May 2000
[Bae92] Baets. W. Aligning information systems with business strategy. Journal of Strategic
Information Systems,1(4), 1992.
[Bar03] Barry D.K : Web Services and Service Oriented Architectures, Morgan Kaufmann
Publishers, 2003
[Bar05] Barnes M.: Benefits and Challenges of SOA in Business Terms, Gartner Whitepaper
G00130078, Sept. 2005
[BCDV+11] Birkhölzer T., Chiniforoshan H., Dickmann C., Vaupel J., Ast S.: Goal-Driven
Evaluation of Process Fragments Using Weighted Dependency Graphs, ICSSP 11, Honolulu,
USA, 2011.
[BD07] Berson A., Dubov L.: Master Data Management and Customer Data Integration for a
Global Enterprise, MCGraw-Hill, 2007
[Ben87] Benbasat, I. et al.: The Case Research Strategy in Studies of Information Systems,
MIS Quartely, Vol 11, No 3, pp369-386, 1987
[Ber08] Berkem B.: ―From BMM to SOA‖, in Journal of Object Technology, vol. 7, no. 8,
November –December 2008, pp. 57-70 http://www.jot.fm/issues/issue_2008_11/column6/
[BGBDK+05] Bourey J.-P., Grangel R., Berre A., Doumeingts G., Kalampoukas K., Bertoni
M., PondrelliL., Daclin N.: Report on Model Establishment, Deliverable DTG2.1,
Interoperability Research for Networked Enterprises Applications and Software, Network of
Excellence (INTEROP), Contract no.: IST-508 011 (2005)
© Jan Ricken, University of Namur, Computer Science Department Page 206
[BGLOS+09] Blinco K., Grisby T., Laird A., O‗Neill O., Srikanth V., and Smythe C.:
Adoption of service oriented architecture (SOA) for enterprise systems in education:
Recommended practices.Technical report, IMS Global Learning Consortium, 2009
[BGPPW+10] Buckow H., Gross HJ., Piller G., Prott K., Willkomm J., Zimmermann A.:
Analyzing the SOA Ability of Standard Software Packages with a dedicated Architecture
Maturity Framework: in Klink, Koschmider, Mevius, Oberweis (Hrsg): Proceedings: EMISA
2010: Einflussfaktoren auf die Entwicklung flexibler, integrierter Informationssysteme,
Karlsruhe 07.10-08.10.2010
[BGR07] Bandara W., Gable G., Rosemann M. : Critical Success Factors of Business Process
Modeling, QUT e_prints, 2007, http://eprints.qut.edu.au/8755/1/8755.pdf
[BHABT+04] Berre, A-J., Hahn, A., Akehurst, D., Bezivin, J., Tsalgatidou, A., Vermaut, F.,
Kutvonen, L. and Linington, P. : Deliverable D9.1: 'State-of-the-art for interoperability
architecture approaches', EU INTEROP Network of Excellence., 2004
[BL06] Benguria, G., Larrucea, X. et al.: A Platform Independent Model for Service Oriented
Architectures, I-ESA conference 2006, March 22-24, Bordeaux, Springer
[Blai05] Blaikie, N.: Designing Social Research, Cambridge, UK, Polity Press, 2005
[BLW96] Brinkkemper S., Lyytinen K, Welke R.: Method engineering: principles of method
construction and tool support : proceedings of the IFIP TC8, WG8.1/8.2 Working Conference
on Method Engineering 26-28 August 1996, Atlanta, USA. Springer. ISBN 041279750X
[BMR+96] Buschmann F., Meunier R., Rohnert H., Sommerlad P., Stal M.: Pattern-oriented
Software Architecture - A System of Patterns. J. Wiley and Sons Ltd., 1996.
[BN94] Bernus P., Nemec L.: CSIRO Division of Manufacturing Technology, Manufacturing
Technology Management Research Report # MTM366, 1994,
http://www.cit.gu.edu.au/~bernus/taskforce/geram/report.v1/report/report.html
[BNSSW+04] Bradburn, Norman M., Sudman, Seymour, Wansink, Brian, Asking Questions:
The Definitive Guide to Questionnaire Design – For Market Research, Political Polls, and
Social and Health Questionnaires. Jossey-Bass. 2004
[BPDM08] Business Process Definition Metamodel, OMG Spec Version 1.0. published
3.11.2008, http://www.omg.org/spec/BPDM/1.0/volume1/PDF/
[BPTRE09] http://www.bptrends.com/, Website, 2007
[BR10a] Brocke, J. & Rosemann, M.: Handbook on Business Process Management 1:
Strategic Alignment, Governance, People and Culture, International Handbooks on
Information Systems, Springer, Vol. 1, 2010
[BR10b] Brocke, J. & Rosemann, M.: Handbook on Business Process Management 2:
Strategic Alignment, Governance, People and Culture, International Handbooks on
Information Systems, Springer, Vol. 2, 2010
[Bri06] Brittenham, P.: Web-Services Development Concepts, IBM Software Group,
http://www-06.ibm.com/software/solutions/webservices/
[Bri96] Brinkkemper S, : Method Engineering : engineering of information systems
development methods and tools, Information & Software Technology, Elsevier Science, 1996
[BRH99] Brinkkemper S., Saeki M., Harmsen F.: Meta-modelling based assembly
techniques for situational method engineering, Information Systems, Volume 24, Issue 3, 10th
International Conference on Advanced Information Systems Engineering, May 1999, Pages
209-228
[Bue07] Buecker A. et al: IBM: Understanding SOA Security: Design & Implementation,
RedBooks, http://www.redbooks.ibm.com/redbooks/pdfs/sg247310.pdf, Nov 2007
[But09] Butler J. et al in CBDI Journal: CBDI-SEA SOA Reference Framework,
http://www.cbdiforum.com/secure/interact/2007-03/the_architecture_component.php,
retrieval 15.12.2009
[C4IS97] C4ISR Architecture Working Group (1997), US Department of Defense,
18.12.1997, http://www.c3i.osd.mil.org/cio/i3/AWG_digital_library/pdfdocs/fw.pdf
© Jan Ricken, University of Namur, Computer Science Department Page 207
[CAR09] Cargolux, www.cargolux.com
[CAR11] Cargolux Annual Report 2011
[CBDI09]: CBDI-SAE Meta Model For SOA Version 3, http://everware-cbdi.com/mm-v3
[Cen90] CEN ENV 40 003: Computer–Integrated Manufacturing – Systems Architecture
Framework for Enterprise Modelling, CEN/CENELEC, Brussels, Jan 1990
[Cen95] CEN ENV 12204: Computer–Integrated Manufacturing – Constructs for Enterprise
Modelling, CEN/CENELEC, Brussels, December 1995
[CH06] Chanliau M., Hynes D.: SOA Governance: What‘s Required To Govern And Manage
A Service-Oriented Architecture ORACLE Whitepaper , October 2006
http://www.oracle.com/technology/tech/standards/pdf/governance.pdf
[Cha03] Channabasavaiah K. et al, : Migrating to Service Oriented Architecture – part 1, IBM
Developer Works, 2003
[Chi04] Chinnici R. et al.: Web Service Description Language (WSDL) 2.0., March 2004,
http://www.w3.org/TR/wsdl20-soap11-binding/
[Che76] Chen P.: "The Entity-Relationship Model: Toward a Unified View of Data" , ACM
on Database Systems, Vol. 1, No. 1, 1976
[Cre98] Creswell, J. : Qualitative inquiry and research design: Choosing among five
traditions. Thousand Oaks, California: Sage Publications, 1998
[DDDG08] Decker G., Dijkman R., Dumas M, Garcia-Banuelos L.: Transforming BPMN
Diagrams into YAWL Nets, in Proceedings of Dumas, Reichert Ming-Chien: Business
Process Management: 6th International Conference, Milan, Sept. 2008
[DG06] Derzsi Z. and Gordijn J.: A framework for business/it alignment in networked value
constellations. In T. Latour and M. Petit, editors, Proceedings of the workshops of the 18th
CAiSE conference, pages 219–226, Namur, B, 2006. Namur University Press.
[Dos05] Dostal W. et al : Service-orientierte Architekturen mit Web Services: Konzepte –
Standards – Praxis. Heidelberg; München : Elsevier, Spektrum Akad. Verl., 2005
[Dou07] Doumeingts G. et al, Report on Model Establishment, Deliverable DTG2.1,
INTEROP (Interoperability Research for Networked Enterprises Applications and Software,
Network of Excellence - Contract no.: IST-508 011), 2007
[DP07] Dubois E., Pigneur Y. et al.: Deliverable DTG5 : Final Report on the
comparison/mapping/evolution between business models, INTEROP , April 2007
[DvdA04] Dehnert, J., van der Aalst, W.M.P.: Bridging Gap between Business Models and
Workflow Specifications. International Journal of Cooperative Information Systems, 2004
[EBFG+02] van Eck, P.,, Blank, H., Fokkinga, M., Grefen, P., Wieringa, R.: A Conceptual
Framew for Architecture Alignment Guidelines.
http://graal.ewi.utwente.nl/GRAAL_whitepaper_20021017.pdf (2002)
[Eclipse09] http://www.eclipse.org/epf/
[EG02] Eder J., Gruber W.: A Meta Model for Structured Workflows Supporting Workflow
Transformations. ADBIS 2002: 326-339
[EJ08] Edirisuriya A., Johannesson P.; On the Alignment of Business Models and Process
Models, Workshop Processing BPM2008 in Business Process Design, Milano, Italy Springer
2008
[Erl05] Erl T.: Service Oriented Architecture: Concepts, Technology and Design, 2006
[FHLNH+98]: Falkenberg ED., Hesse W., Lindgren P., Nielsson B., Oei H., Rolland C.,
Stamper RK., van Asche F., Verrijn-Stuart S., Voss A.: A Framework of Information System
Concepts (FRISCO), Computer Science Department University of Leiden, Netherlands, 1998
[Fow02] Fowler M.: Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
[Fox92] Fox, M.S.: The TOVE Project, Towards a Common Sense Model of the Enterprise,''
in Enterprise Integration, Ch. Petrie (Ed), Cambridge, MA, MIT Press (1992)
[Fra03] Frankel D.: The Zachman Framework and the OMG‘s Model Driven Architecture,
Whitepaper, Sept 2003
© Jan Ricken, University of Namur, Computer Science Department Page 208
[GAJV08] Gottschalk F, van derAalst W. M. P., Jansen-Vullers W. M. P., Verbeek H.
M.W.:Protos2CPN: Using colored Petri nets for configuring and testing business processes.
In: International Journal for Software Tools for Technology Transfer (STTT) 10, Springer,
2008
[Gar03] Gardner, T.: UML Modelling of Automated Business Processes with a Mapping to
BPEL4WS. In Proceedings of the First European Workshop on Object Orientation and Web
Services at ECOOP 2003.
[GART06] The Gartner SOA Adoption Model, GARTNER Leading Toolkit, December 2006
[GFFCM+04]Groves, Fowler, Floyd, Couper, Mick, Lepkowski, Singer, Eleanor, Tourangeau
: Questionnaire Methodology, John Wiley & Sons, Inc. 2004
[GAR11] Gartner: Magic Quadrant for Business Analysis Tools, G00219247, Published:
12.12.2011
[GHJV94] Gamma E., Helm R., Johnson R., Vlissides J.: Design Patterns: Elements of
Reusable Object-Oriented Software.
[GPHS08] Gonzales-Perez C., Henderson-Sellers B: Meta Modelling for Software
Engineering, Wiley, 2008
[GPW06] Gordijn J, Petit M., Wieringa R: Understanding business strategies of networked
value constellations using goal and value modeling, In: 14th IEEE International Requirements
Engineering Conference (RE'06), 11-15 September, Minneapolis
[GPZ10] Giannoulis C., Petit M., Zadravkovic J.: Towards a Unified Business Strategy
LAnguage : A Meta-Model of Strategy Maps, in: P.van Bommel et al (Eds): PoEM 2010,
LNBIP 68, pp. 205-216, 2010
[Gru04] Gruber T.: Interview with Tom Gruber: Bulletin of AIS Special Interest Group on
Semantic Web and Information Systems (SIGSEMIS), 1(3), 2004
[Gru93] Gruber T.: Towards Principles for the Design of Ontologies Used for Knowledge
Sharing. In N. Guarino and R. Poli, editors, Formal Ontology in Conceptual Analysis and
Knowledge Representation, Deventer, The Netherlands, 1993.
[Gün05] Güner S.: Service Oriented Architecture, Master Thesis, University of Hamburg,
2005
[GP11] Greefhorst D., Proper E.: Architecture Principles, 1st Edition SPRINGER, 2011
[HA06] Horner, J.; Atwood, M.E.: Effective Design Rationale: Understanding the Barriers",
in Dutoit, A.H.; McCall, R.; Mistrík, I. et al., Rationale Management in Software Engineering,
Springer Berlin Heidelberg, 2006
[Har97] Harmsen, A.F.: Situational Method Engineering, PhD Thesis, University of Twente,
The Netherlands, January 1997
[HBO94] Harmsen, A.F., Brinkkemper, S., Oei, H.: Situational Method Engineering for
Information Systems Projects. In Methods and Associated Tools for the Information Systems
Life Cycle. Proceedings of the IFIP WG8.1 Working Conference Cris/94, T.W. Olle, A.A.
Verrijn-Stuart, Eds. North Holland, Amsterdam, 1994, 169-194.
[HH95] Hoef, R., Harmsen, F. : Quality Requirements for Situational methods. In: Grosz, G.
(Ed.) In proceedings of the Sixth Workshop on the next generation of CASE tools, Jyväskylä,
Finland, June 1995
[Hid93] Hidding G. et al: Modeling large processes with task packages, workshop on
modeling in the Large, AAAI conference, Washington DC, 1993
[Hil00] Hilliard,R. , IEEE-Std-1471-2000 IEEE-Std-1471-2000 Recommended Practice for
Architectural Description of Architectural Description of Software-Intensive Systems
Software-Intensive Systems, http://www.enterprise
architecture.info/Images/Documents/IEEE%201471-2000.pdf, 2000, date of download 1.7.07
[HO93] Heym M, Oesterle H: Computer-aided methodengineering, in Information and
Software Technology Vol 35 No 6/7 pp345-354, 1993
Please take 30 minutes to fill the online questionnaire. You will benefit from the executive
summary published on BPtrends and IT News after having filled the questionnaire. This
research is supported by the Luxembourgish Ministry of Education (Ministère de l‘ Education
Nationale et de la Formation Professionnelle) and a close collaboration with Luxembourg‘s
research institute CRP Henri Tudor, Center for IT Innovation (CITI). Should you have any
questions or should you have interest in my published articles, please do not hesitate to
contact (email to: jan.ricken@fundp.ac.be) me!
4) Please enter your e-mail address. It is required to send you the promised executive
summary after research analysis.
10) Do you know the concept of SOA? If yes, since when (pls. indicate year)?
Yes
No
Other:
13) What is following your expectations the biggest advantage of SOA? (Put into a ranking)
Reduction of IT cost
Flexibility and Agility in IT Architecture by re-using services
Business and IT Alignment by common views and language
Enforcement to think in processes
Re-utilisation of existing BPM content
Automatically enforces data quality / data management
14) What are following your expectations the biggest challenges of SOA? (Put into a ranking)
ROI difficult to calculate
Tangible benefits hard to identify
Complexity of subject
Knowledge & right profiles
Missing approach and where to start
17) What approach do you have chosen for modelling and implementing SOA?
top-down
meet-in-the-middle
Bottom-up
Other (Please Specify):
18) Our Company is using a management method (e.g. Balanced Score Card, Management
Cockpit etc.) to derive from business strategy the process objectives and IT objectives...
Yes
No
19) Principles of Model Driven Architecture (MDA) from the OMG are...
Known & Known &
Not used, used, Not
Known Other (Please Specify):
Known Meeting Meeting
Expectations Expectations
Software Development
SOA Implementation
20) Question related to above Figure: What type of models do you use for the different
abstraction levels?
Platform-independent level (PIM)
Computer-Independent level (CIM)
Platform specific level (PSM)
21) Do you transform automatically technical models e.g. UML into Software Code or service
descriptions?
© Jan Ricken, University of Namur, Computer Science Department Page 224
Yes
No
22)
used & used &
used n/a Other (Please Specify):
successful failure
e3value2ADM
ADM2BPMN
EPC2BPMN
EPC2UML
EPC2BPEL
BPMN2BPEL
UML2BPEL
BPEL2WSDL
UML2WSDL
23) Do you manage our processes through a Business Process Management (BPM) –
programme (e.g. Strategy, Design, Implementation, Controlling, Change Mgt.)?
Yes
No
Partly
Documentation
Certification
Risk Mgt
Cost Improvement
Process-Driven Application
Development
Process-Driven Web Service
Construction
27) If your answer above is YES, which maturity model do you use?
28) Did you succeed to calculate ROI for your SOA project?
No, We did not succeed
Yes, ROI 1-2y,
Yes, ROI 2-3y,
Yes, ROI 3-5y,
Yes, ROI >5y
30) We use the following project management method for all (IT) projects
PMI
PRINCE2
SUMMIT
Own Methodology
Other (Please Specify):
31) For SOA specifically, please rate the following SOA Methods (alphabetical order):
© Jan Ricken, University of Namur, Computer Science Department Page 226
Known & Known &
Not used, used, Not Remark / Please
Known
Known Meeting Meeting Specify:
Expectations Expectations
ARIS Value Engineering for SOA,
(IDS Scheer AG, 2006)
Enterprise SOA, (SAP AG, 2006)
Enterprise SOA Adoption
Strategies, (Capgemini 2006)
Model-Driven Integration of
Process driven SOA Models,
(Distributed Systems Group,
2006)
Platform-independent model for
service-oriented architecture,
(European Software Institute (ESI)
Spain, DFKI GmbH Germany,
SINTEF ICT, Norway)
Service-oriented Design and
Development
Method(Papazoglou, University of
Tilburg. June 2007)
Service oriented Modelling &
Architecture, (IBM, 2006)
Oracle Unified Method for SOA
Other Methodology
32) In general, SOA method is very complex and not trivial to tackle...
True
False
33) Do you have written SOA Objectives, Key Performance Indicators, SOA Drivers & Critical
Success Factors identified?
Yes
No
Partly
Planned
Other (Please Specify):
34) What Tools BPM/SOA Design & BPM/SOA Runtime Tools do you know? What is your
experience?
Known & Known &
Not used, used, Not
Known Remark/ Please Specify:
Known Meeting Meeting
Expectations Expectations
36) The presented model is reflecting all domains to consider for an exhaustive SOA
implementation method based on a process-oriented approach...
I agree
I do not agree, this is missing:
Viewpoint: Mostly, the background of the authors is determining if the method is technical,
functional or equilibrated
The chapter is outlining the content; the summary gives a detailed neutral explanation of the
methodology, whereas the comment explains the strengths and weaknesses of the
methodology.
Chapters:
1. Introduction
2. Service Orientation Basics
3. Standard Message Composition
4. Headers Are for Standards Too
5. Achieving Interoperability
6. Best Practice Summary
7. More Work to Do
8. Conclusion
Summary:
After a very brief introduction (187 words), the author describes in the next chapter ―Service
Orientation Basics‖ the four core tenets:
The next chapter ―Standard Message Composition‖ lists related to experience in industry four
key standards architectures:
The four categories are described and the concept of service orientation is introduced. An
example of a poorly defined web-service in WSDL is given and compared to an accurately
factored message. The difference between both examples is explained in detail. Schemas and
how messages are technically decomposed is explained.
The next chapters are used to explain about web service policy, integrity, security and
message versioning. The two levels of web-service interoperability are explained. The best
practice summary focus on how web-services should be designed:
Compose granular messages. Use a data dictionary to build discreet and granular
messages that will leverage a namespace to align the data payload to the service and
data.
Avoid payload bloat.
Create service-to-message correlation.
Use strong naming techniques. Use <import> of global types.
Avoid schema bloat.
Support industry standards.
Use WS-Policy statements to enforce compatibility. Support the XML Schema
discovery and Web Service Proxy Model.
Follow interoperability guidelines for services.
Support a mainstream Web services stack.
Comments:
Chapters:
Summary:
Overall, the method is structured into 4 phases: Strategy, Design, Implementation, and
Controlling
The first chapter clarifies about strategic positioning and the related strategic objectives.
General common objectives from CEO, CIO, and CFO are explained.
The second chapter tells in brief what SOA is and distinguishes business goals and IT goals.
Business goals such as
Enabling fast production of new business models
Attaining adaptability to support on-going change
Accomplishing a closer alignment of IT with business needs
Achieving higher productivity of Business Processes
IT Goals such as
Enabling greater re-use of IT assets
Reducing development cost and project times
Achieving faster delivery of value to the business
Accomplishing a higher degree of effectiveness in implementation, modification, and
integration of IT systems.
Therefore, processes answer SOA questions e.g. the identification of services, impact of
services to business etc.
Figure 80: Levelling of Design Time Tool vs. Run Time Tool
The solution scenarios that can be covered by the method are three-fold:
The ARIS AVE method differentiates conceptually the SOA design time and the SOA run
time:
All the steps of the SOA roadmap per phase can be seen in the following picture:
The next chapter shows the service architecture repository and the links between processes,
services, systems, and components. (See picture)
Furthermore, the method foresees an upload of available WSDL services and the link of those
services within UML models. The services are embedded into process logic, including rules
and events, and can then from the process model (Event-driven-process-chain) automatically
translated into Service Orchestration Models in BPEL models/language. This is done on the
above mentioned level 2, where the integration interface starts to the technical SOA or run-
time environment. BPEL models can then be implemented and executed in tools such as IBM
Websphere, SAP Integration Builder, or ORACLE JDeveloper.
The method is well structured into 4 main phases, beginning with strategy. Here is one of the
main strengths of the method, because the strategy effect is related to a consistent top-down
method. Only business relevant strategies, objectives, critical success factors, and scoping are
the starting point for questions that could be resolved by web service enabled IT structures. It
is well explained, what different models can be used on each level but not very exhaustive.
Also worth mentioning the strictly functional approach based on modelling that IDS Scheer
positions itself on the functional or the so called ―SOA design time‖ against the other big
commercial vendors as ―SOA run time‖ (SAP, IBM, Microsoft, ORACLE, BEA etc.) with
their technical implementation solutions. However, MDA is not linked to the levels, but the
available method and models can be mapped to MDA. Beside the method, IDS Scheer is
using BPM tools allowing designing business requirements in a controlled and integrated
way. The method could be enlarged by subjects explained more in detail in other methods
such as governance, QoS, Web service granularity, technical environments, service
decomposition, Master Data Management etc.
Principal Author: -
Company/Organization: SUN Mircosystems, [SUN04]
Year of Release: 2004
Category: Whitepaper
Nb. of pages: 9
Web:
Source: Commercial Organisation/Software Endor
Viewpoint: functional
Approach: Top-down
Chapters:
1. Overview
2. What is SOA?
3. The Benefits of SOA
4. Challenges in Moving to SOA
5. SOA Impact Analysis
6. Technology and Tools
7. Organizational Alignment
8. Method and Process
9. Recommended Approach
10. SUN´s SOA Readiness Assessment
11. Additional SUN SOA Service Offerings
12. Getting Started
Summary:
© Jan Ricken, University of Namur, Computer Science Department Page 236
After a quick introduction and a brief clarification, what SUN understands about SOA, the
potential benefits are listed and challenges are described. SUN structures the explanation in
design-time-environment and run-time environment. Exchange patterns are considered as
critical and more success factors are explained: Identity, Registration/Discovery, Service API,
Tiering/Layering, Loose Coupling, Pattern Usage, Creation&Deployment, Standardized Data
Model, Separation of Business and IT Services, Interoperability and Open Standards. Next,
the organizational alignment strategy critical success factors are: Shared Service Strategy and
Funding Model. Furthermore in the section ―method and process‖ the author focus on
Governance Model and Model-Driven-Architecture. The recommended SUN method is based
on 4 steps: Education, Assessment, Planning and Execution. The last three chapters are
dedicated to the SUN service offer related to SOA implementation: a readiness assessment is
proposed to identify context, maturity and opportunities.
Comments:
The paper gives a short, well-structured introduction in SOA, the challenges and critical
success factors. The paper is written in a business/functional language and is easy to
understand. The chapters ―method and process‖ and ―Recommended Approach‖ are related to
the other chapters too short. Nevertheless, the paper gives a brief first introduction into the
subject by focussing on the main areas of interest. The paper gives ideas of things to take into
consideration, but it is not going into details how to do so e.g. what models to use, how a
technical set-up can be made etc. The target audience of this paper are CIO‘s, Enterprise
Architects or divisional IT representatives with the objective to provide a first introduction
into the subject.
Chapters:
Summary:
The entire book is about ESA (Enterprise Services Architecture) in relation to the Enterprise
Resource Planning (ERP) System SAP from SAP AG.
The first chapter is positioning the book: Audience, challenges, why ESA, web service
history, ESA supporting Infrastructure, ESA objectives and benefits and ESA business case.
Next the steps for evolving toward ESA are identified and explained: First big obstacle is the
enterprise culture and organization that needs to be changed or adapted to new concepts. The
role of IT is explained in detail and what new roles and skills are required. Governance in
ESA context is roughly explained and the question of modelling interoperability is raised.
They state that no standards body or language has so far been recognized as de-facto standard.
However, SAP is working with different industry leaders to develop standards. The next
chapter ―ESA fundamentals‖ explains again ESA infrastructure, ESA challenges, web-
services. The authors differentiate web services and enterprise services and put composite
© Jan Ricken, University of Namur, Computer Science Department Page 238
applications into the context of service oriented architecture. The SAP NetWeaver technology
solution map is explained and the concept of event-driven architecture is introduced.
Modelling is seen as an important part of ESA: low-specification models and high
specification models, pattern based models and requirement models are explained in one
sentence. Every ESA Stack is explained layer by layer: User interface, Process orchestration,
enterprise service, business objects and persistence.
The chapter of ―ESA community‖ is describing the programme of SAP to bring together
partners and customers to share ideas, innovations and web services. Then the chapter
―Creating a Roadmap with ESA Adoption Program‖ presents the method of ESA adoption:
Discover, Evaluate, Implement, Operate. Each phase is explained in detail and practical
examples from projects are given. The authors refer to SAP methodology. It is said what to
do, but not how to do it and by whom. Three case studies with the application of the before
explained methodology, Manchette Publicité, Wacker Chemie AG and LHI Leasing, are
helping to understand how SAP applies the method.
The chapter ―The Enterprise Service Repository and the Enterprise Service Inventory‖
explains from the ESA viewpoint the utility of the Enterprise Services Repository. One of the
fundamental principles of ESA is the business processes as starting points for the design of
strategic services that will support those processes. ARIS is a tool to design processes and
services is available as separate product, but ESA integration is foreseen in the future. The
Enterprise Service Repository based on SAP XI technology is explained (Process Models,
Integration Objects, Service and Business Objects). A detailed top-down method and
procedural model to define services is explained (p205-211) and a concrete example of the
process ―purchasing a new component‖ is given (p. 212-215). ―Project Mendocino‖ is
explained: The aim is to integrate desktop applications like Outlook, Excel and Word into
SAP tools. Time management of projects through Outlook calendar, budget monitoring, leave
management and organization management can be organized more efficiently as processes
with related data (times, budget, cost etc.) can be automated. The next chapters are dedicated
to composite applications and available development tools (SAP NetWeaver Visual
composer, Guided procedures design time for modelling user-centric composite processes, the
SAP composite application framework, ABAP Development Workbench and SAP
NetWeaver Development Studio). The authors focus on data and especially on master data as
a key element to consider. The SAP Master Data Management is explained.
The chapter ―Web Service Basics‖ is introducing a definition for services, SOA, XML, XML
Schema, SOAP, WSDL, UDDI followed by a chapter with detailed explanation how to create
Web-services / enterprise services with ABAP tools and JAVA tools.
The chapter ―ESA and IT Governance‖ gives an overview about the history, objectives and
challenges of managing services in the ESA environment. The last chapters talk about ESA
life-cycle (Implementation, Operation, Change Mgt./Continuous Improvement), ESA Security
and ESA Standards.
Comments:
The authors describe a possible SOA scenario from the perspective using SAP ERP systems
in the latest version with XI technology and SAP NetWeaver. The book spans a lot of subjects
– but the focus is clearly on the integration of SOA paradigm into the ESA environment.
Some explanations in chapters are redundant and definitions are sometimes not very detailed.
Some subjects are spread over different chapters instead of focussing into one chapter. (E.g.
governance p.83, 379 or web-services, p.24, 99, process orchestration p. 19, 117, 150)
Concepts are introduced but only deeply explained in a later chapter. From a didactical point
of view, this could be improved. The book mostly describes what needs to be done, but not
how it should be done. A pleasant exception is chapter 8 where the approach of creating
Enterprise services also explains how it should be done. Sometimes, content is related to SAP
system descriptions with rather limited added value. It will be interesting to see if the concept
of SAP´s ―Enterprise Services Community‖ will be accepted by companies. The question of
ROI for instance is not answered, it is not clear what types of model types the authors
recommend on which level and who should do what exactly. The case studies are rather high-
level than detailed – again the added value is limited.
Overall, this book is written in functional/business language with target audience CIO,
Enterprise Architects, Business Analysts, Senior Executives. It is also only relevant and useful
for audience in the context of used SAP ERP and SAP XI / NetWeaver - technology.
The method described in chapter 8 is for sure not complete, but some elements could well be
considered for a later definition of an own method.
Chapters
1.) Context
2.) Executive Summary
3.) Abstract
4.) Introduction
5.) Overview
6.) A common starting point
7.) Start at the Top
8.) Terminology
9.) Collaborative Working
10.) Creating a Service Architecture
11.) Developing the complete architecture
12.) Managing Change
13.) Summary
Summary:
The authors directly from the beginning of the first chapters say that the objective of their
proposed method is a top down methodology, based on business visions and not on new
technology concepts. The key to SOA is clearly the services. This method does not focus on
how to deliver software projects, but to provide the architecture to ensure that the delivery is
service oriented. The authors say in the ―Overview‖ that they will cover
Why services need to be defined
The importance of a common language
How to discover what are the primary business services
How to identify shared and supporting services
How to define the interactions between services at a high level and
How to categorize services to help with management.
The method starts by the identification of the different divisions/departments their actors and
their primary tasks. Once this is done, the interaction between external actors (customer,
Logistics Company, suppliers etc.) and divisions/functions is drafted. Then the authors
describe a drilling down to level 1 where divisions are split into areas and links and relations
are drafted. Virtual Services, Support services and Shared Services are identified. To conduct
such a project, the authors describe in chapter 11 the different roles with their responsibilities.
The final result should be a big picture showing all services within divisions and sub areas.
Comments
Principal Authors: Uwe Zdun and Schahram Dustdar, [ZD06], [ZD08], [Tra10]
Company/Organization: Distributed Systems Group, Information System Institute Austria
Year of Release: 2006
Category: Academic Whitepaper
Web: http://drops.dagstuhl.de/opus/volltexte/2006/820/pdf/06291.ZdunUwe.Paper.820.pdf
Nb. of pages: 32
Source: Academic Organisation (University)
Viewpoint: technical (PIM-PSM)
Approach: Top-down
Chapters
1.) Introduction
© Jan Ricken, University of Namur, Computer Science Department Page 242
2.) Background on MDSD
3.) Model Driven Tool Chain
4.) Meta Model for SOA Integration
5.) DSLS for Flow Models
6.) DSL For Architectural Models
7.) SOA Model Integration
8.) Related Work and Evaluation
9.) Conclusion
Summary:
The first chapter gives a quick introduction into SOA and describes the central challenge,
which is the integration of different kinds of models and abstractions. Different languages and
tools exist with highly different characteristics. It is said that meta-models on the domain-
specific languages (DSL) level resolve the issue identified. The approach is based on patterns
whereas UML2 and OCL are used to develop a formal modelling language.
The second chapter introduces in detail the used DSL met model and the used UML2 models:
Activity diagrams to model flow abstractions and class/component diagrams to model object
oriented design and architecture models. The ultimate goal of all transformation consists of
generating code in executable language or programming languages.
The third chapter states that UML is the only language that can be considered as a real
standard. Related to tools, it is crucial that they support meta models and adapters enable
interoperability through code generation. A syntax is describing how the DSL meta model is
mapped to language elements and grammar. The authors use Frag textual syntax because of
easiness to parse and to map onto Frag meta models. The meta models for SOA integration
(Chapter 4) focus the explanation of the UML2 Activity Diagram Meta-Model and
differentiates flow models for long-running business processes and short running technical
processes. The DSLS for flow models (chapter 5) is a pattern language for process oriented
integration of services and can be distinguished in macro flows (long running processes) and
micro flows (short-running technical processes) An example of configuration for a process-
based integration architecture is given and process flow refinement, steps, macro-flow-model,
micro-flow-model and macro-micro flow refinement are explained. Furthermore, the next
chapter 6 (DSL for Architectural SOA Models) focuses on architectural components in the
system of business object models. Again UML is used in this context: Class diagrams are
used for business objects, Component diagrams are used to represent architectural
abstractions. To capture semantics of a call-back architecture, the authors propose 5
stereotypes: IEvent, ICallback, EventPort, CAllbackPort, and Callback. The chapter 7 ―SOA
model Integration‖ explains the formal integration. Correlation identifiers are used to match
events and call-back‘s between the components. In the component model, it need to be
modelled which correlation identifier as multiple identifiers can be used. In addition, it is
important to ensure that macro and micro-flow-models pass a valid correlation identifier type
to all asynchronous invocations. The next chapter tells about planned extensions of the model
with organizational models or human-interaction models. The key criteria is the approach
based on a meta-meta-model, primitives as modelling constructs, and model validation tools
for these concepts. Finally, the authors conclude their paper by a quick summary of their
concept.
The approach is very academic and not at all easy to understand for others than experts in this
domain. Very specific terms are not explained and the authors presume that the reader knows
about complex and technical concepts already. The focus is made on meta-meta-models,
UML2, a method consisting of 7 steps for the model-driven design process, micro-macro-flow
concept, and the own developed pattern language and syntax ―frag‖. The question here is to
find out how complex this is and if this can be applied without huge effort in practice.
There is so far no trace of a proven implementation or a successful case study, where this
method has been applied in practice. Even, if the authors state that their approach is based on
proven practices, it would be interesting to test this method in a practical environment.
However, MDA as classification criteria is not mentioned at all and it is not clear how
services are defined and integrated. The micro-macro flow shows the drilling down
functionality, but it is not clear how complex processes, events, actors and data are
considered. Furthermore, the strategic aspect is completely neglected. The platform
independent layer with business models is not discussed. It would also be interesting to see, if
the mentioned tools (ARIS, ADONIS) can be used to follow the approach.
This method can certainly bring its value related to the technical aspects of model translation,
verification and integration into business applications.
Summary:
PIM4SOA is an open-source modelling tool with an underlying Meta model to support the
design of SOA in a platform-independent (PIM) or technology neutral manner following the
OMG MDA approach. The met model defines an abstract language to specify executable
business processes for exchange between modelling tools and execution environments and is
based on UML and EMOF. Four dimensions are covered: Service, Process, Information and
Quality of service
The tool can be used within the Eclipse platform. Model transformations are available for
Comments
The development of this method seems to be in an early stage. A strength of the method might
be the development based on open OMG standards UML and MDA. The method tackles in an
example in a BtoB scenario the following issues:
business processes are not defined using the same language. This barrier makes difficult
the definition of a coherent and consistent process where the stakeholders have a common
and unified view of the process.
systems are not interoperable. They use proprietary format for their applications and their
connections are made ad-hoc.
business processes and their systems supporting their business processes are not related in
a systematic way.
The proposed method focus mainly on interoperability issues between two companies.
It will be interesting so test the method in practice and to see how this method might be re-
used for the development of a practical and condensed method in chapter 2.
For the analysis, the paper A model driven approach to agent-based Service-Oriented
Architecture, (Zinnikus A., Benguria G., Elvesaeter B., Fischer K., Vayssière J.)
Principal Authors: Mike P- Papazoglou & Willem-Jan van der Heuvel, [PvdH06]
Company/Organization: INFOLAB, Department of Information Systems and Management,
Tilburg University, Netherlands
Category: Whitepaper, Int. J. of Web Engineering and technology (IJWET), 2006
Web: http://infolab.uvt.nl/pub/papazogloump-2006-88.pdf
Book: http://www.pearsoned.co.uk/bookshop/detail.asp?item=100000000029294
Nb. of pages: 16
Source: Academic Organisation (University)
Viewpoint: functional & technical
Approach: Top-down
Chapters:
1. Introduction
2. Characteristics of service development Life cycle Methodology
© Jan Ricken, University of Namur, Computer Science Department Page 245
3. Web Services Development Life Cycle Method Baseline
4. Service Oriented Design and Development Principles
5. Phases of the service oriented design and development methodology
6. the service design phase
7. Service construction phase
8. The service Provisioning Phase
9. Service development phase
10. Outlook
Summary:
The introduction states directly the objective of the paper: to provide an overview of the
methods and techniques used in service oriented design and development and to examine a
service development method from the point of view of both service producers and requesters
and review the range of elements in this method that are available to them.
The second chapter explains the web service development life cycle hierarchy based on the
work of IBM researchers Arsanjani and Brown. The starting point is clearly the business goals
and requirements through software design, code assets and composite applications.
The authors clearly describe the top-down approach with Business domain, Business
processes, Business Services, Infrastructure Services; Component based service realizations
down to operational systems.
During the planning phase, the project feasibility, goals, rules and procedures are set and
requirements are gathered. The business case is conducted during the design phase
considering various alternatives for implementing business processes, identifying web
services. The next phase is service construction and testing including functional correctness,
completeness and interoperability. The provisioning phase encompass issues like service
metering, service rating and service billing. The service deployment and advertisement is
done through the repository system. The final phase includes execution and monitoring of
web services.
The fourth chapter focus on key principles which are 1) service coupling and 2) Service
cohesion 3) Service granularity. The three principles are explained and recommendations are
given.
Chapter 5 focus again on the first of the 8 phases described in short before. This time is
explained more deeply. The analysis phase encourages a radical view of process (re)-design
and supports the re-engineering of business processes. Its main objective is the reuse of
business process functionality in new composite applications. To achieve this objective the
analysis phase comprises four main activities: process identification, process scoping,
business gap analysis, and process realization.
Chapter 6 describes the service design phase with concerns 1) Component granularity 2.)
service re-usability 3.) Service composability. Then, it is said how services should be
specified including service interfaces, messaging and coupling. WSDL is used to show
operation parameters and how services should be programmed. Service policy concerns
including Quality of service issue are explained and for the service orchestration, BPEL is
recommended. The author also recommends tools such as IBMs WebSphere Business
Modeler to perform analysis, what if simulation to estimate business benefits and the
transformation into UML and BPEL models. The authors are also highlighting the BPMN
notation as a standard to define unambiguously business logic and information requirements.
© Jan Ricken, University of Namur, Computer Science Department Page 247
Non-functional business process requirements such as performance, payment model, security
model and, transactional behaviour. These concerns are explained through a Service Level
Agreement (SLA) example.
Chapter 7 explains very quickly the service construction without going into details.
Chapter 8 describes briefly two methods of testing 1) dynamic testing and 2) functional
testing. (Brown 2002). The testing includes performance, response times, transaction rates,
stress testing, interface testing, assembly testing, network congestion, security, and upgrade
tests. The objective of the testing is to make sure service requirements such as privacy,
message integrity; authentication, authorization and non-repudiation are met.
Chapter 9 ―The service provisioning phase‖ is central to operating revenue generating web
services between organisations. Aspects such as service governance, service certification,
service enrolment, service auditing, metering, billing and mapping needs to worked on.
The last 3 chapters are again very brief and provide an overview what is meant by the service
deployment, service execution and service monitoring
The outlook finally sums up the introduced method and states that the authors will gather real-
life case studies in different sectors and develop an own toolset to effectively support the
methodology.
Comments:
The whitepaper positions itself with the objective to ―…provide an overview of the methods
and techniques used in service-oriented design and development‖. Indeed, one method has
been chosen (IBMs SOMA, Arsanjani & Brown) and has been enhanced by the authors.
Unfortunately, there is no comparison to other methods. However, the paper explains well for
functional profiles the method and starts by defining the SOA infrastructure hierarchy. The
structure of the phases is the classical approach (RUP, Component based development,
Business Process Modelling), which make sense to apply it also for web-service
developments. Key principles as the foundation for service based process design are well
explained. The planning and design phase gives important information about scoping of
processes, how processes can be identified and the different realization options (Brittenham
2001) 1.) Green field development, 2.) Top-down development 3.) Bottom-up development,
and 4.) Meet-in-the-middle developments are explained. I do not agree with the issues stated
for the options 2 to 4 being ambiguous related the priorisation of the processes to start with. It
depends rather on the context of the specific organization to apply the method with the best
fit. The authors are giving reference models as solution e.g. RosettaNets standard processes.
Normally, priorities can well be set up relating to the conducted business case in the planning
phase.
Furthermore, service design concerns are well explained and how services could be specified.
The authors do not mention the MDA method nor is their focus to give an overview of models
that could be used other than to use WSDL for services and BPEL for orchestration.
Furthermore, they name BPMN as a business process language. UML or any other business
process modelling language does not play any role whilst the authors focus on the importance
of process modelling, design, analysis etc. The strategy phase, strategy concepts and methods
are also not taken into consideration
© Jan Ricken, University of Namur, Computer Science Department Page 248
Overall it is a well-structured method based on SOMA (IBM) explaining well the critical
concepts and success factors for service development. The authors have so far not gathered
practical experience with their enhanced SOMA method, but this could be an interesting area
to see in future. The intent to develop an integrated toolset to effectively support the method
needs to be monitored carefully. It is not said, if these tools should be supported by software.
Chapters:
1.) Introduction
2.) SOA a conceptual model
3.) The architectural style and principles
4.) Context
5.) An architectural template for SOA
6.) How to approach service-oriented modelling and architecture
7.) Service-oriented modelling: The analysis and design of services
8.) Conclusion
Summary:
The objective of the article describing the SOMA method contains techniques required for the
identification, specification and realization of services, their flows and composition, as well as
the enterprise-scale components needed to realize and ensure the quality of services required
of an SOA.
In the introduction, the author states that SOA is not a product but more about business-
aligned IT services using a set of design principles, patterns, and techniques. SOMA is
enhancing the object-oriented analysis and design (OOAD) by addressing services, flows, and
components.
The conceptual model in chapter 2 describes very brief the link between Service consumer,
service provider and service broker. Chapter 3 focuses briefly on the SOA benefit such as
business agility and defines what a web service is.
In chapter 4, Arsanjani says that the context in which the company is plays a key role.
Therefore a maturity model can help. When starting a SOA project, assessments with
eventually pilots should be done. Important is also strategy and planning activities including
© Jan Ricken, University of Namur, Computer Science Department Page 249
migrating plans, tools, methods, training, technologies, standards, roadmap, governance and
implementation of best practices (security, performance, compliance with standards for
interoperability, change management).
Chapter 5 explains the layers of SOA: presentation, Business Process Choreography, Service,
Enterprise Components, Operational Systems, Integration Architecture, and QoS, Security,
Management and Monitoring
The next chapter‖ how to approach service oriented modelling and architecture‖ describes
how to combine a top-down, business driven approach with a bottom-up approach. The best
approach seems to be first top-down, then goal-service modelling, and finally bottom-up
legacy analysis of existing assets. The faster the project is scoped down to a manageable
realistic set; the sooner value by focusing on key services can be achieved.
The next chapter dedicated to design and analysis says that SOA is more strategic and
business aligned. Web services are a tactical implementation of SOA. Arsanjani talks about
roles and activities of Service providers and service consumers. The service identification in
the top-down view includes a blueprint of business use cases for business services e.g. a
domain composition, which consists of the decomposition of the business domain into its
functional areas and subsystems, including its flow or process decomposition into processes,
sub-processes, and high level business use cases.
The bottom-up method is used for existing system analysis. Service candidates are identified
in order to analyse and leverage API‘s, transactions, and modules from the legacy and packed
applications.
Then services are classified and categorized, then a subsystem analysis is performed.
Components are specified such as Data, Rules, Services, Messaging, event specification
configurable profile, and variations.
Services are then allocated to identified subsystems and realized: Services are integrated and
transformed. Here the following mix of approached is recommended: Top-down domain
decomposition (process modelling and decomposition, business rules analysis, and domain
specific behaviour modelling). Bottom-up should be done in parallel analysing existing legacy
assets that are candidates for componentization and service exposure. To catch the business
intent behind the project and to align services with the business intent, goal service modelling
is conducted.
The conclusion sums up but underline the importance of the combination of the three
approaches top-down , bottom-up, and goal model analysis (middle-out) should be done.
Comments:
The approach is well structured and based on IBM´s best practice from projects. The most
interesting part of this method is the combination of different approaches (top-down, bottom-
up, middle-out). Proven methods like object oriented analysis and design (OOAD) are re-used
and adapted to the SOA requirements. However, some chapters are really short, it is said what
to do but not how. There is no link to MDA or types of models and tools that could be used.
The method seems to be well known in the practice and academia world, as IBM was one of
the first commercial organizations to create an own method. The success of the method has
also influenced Papazoglou for the enhancement of his proposed method SODD (chapter 5.8.)
It will be interesting to see in the empiric research how successful this method is in practice.
Principal Authors: Adam Korczak, Girish Krishnan, Piotr Skrobisz, Stephen Verba, Stephen
Bennett, Sigrid Gylseth, Jan Kettenis [ORAC11] , based on former method BEA[Shu06]
Company/Organization: ORACLE
Category: Framework Tool, 2011
Web: OUM is restricted access and not available on the web.
Nb. of pages or Size: 92MB Browser Tool Framework, 2396 Pages
Source: Commercial Organisation
Viewpoint: functional
Approach: Top-down
Chapters or Structure:
© Jan Ricken, University of Namur, Computer Science Department Page 251
1. SOA Program Scope Engagement (typically, at the enterprise-level) - The tasks for
these type engagements are found in the OUM Envision focus area.
2. SOA Project Scope Engagements - The tasks for these type engagements are found in
the OUM Implement focus area.
3. The Service-Oriented Architecture (SOA) Core Workflow view - is used to provide a
conceptual view of the SOA approach that is provided by OUM.
Summary:
Service-Oriented Architecture (SOA) in OUM covers the entire lifecycle for services. It is
important to have an overall picture of the different dimensions for planning and delivering
SOA. SOA efforts may vary in their scope and level of effort and the approach taken. OUM
supports all these dimensions across the Envision and Implement focus areas.
1. Roadmap Creation, which focuses on assessing the current state of the enterprise in
respect to their SOA goals and the maturity of the capabilities, required to execute
SOA successfully. The tasks to support Roadmap Creation can be found in the
Envision focus area.
The main artefacts at the end of a program scope engagement are an incremental SOA
implementation roadmap that maps out the build-out of the infrastructure, the solution
roadmap and services roadmap.
For engagements with a project scope, enterprises start to execute their incremental SOA
implementation roadmap and start to deliver value to the business. Such project engagements
cover the different lifecycles of delivery of solutions and delivery of services and the
associated service infrastructure. The tasks to support project scope can be found in the
Implement focus area.
3. The SOA Core Workflow describes the sequential method of OUM for SOA:
Every box is detailed with different activities to perform and expected work products.
Templates and examples are provided for some activities. As the framework is very
comprehensive, we will focus on the modeling part of the method. Therefore, the activity of
―functional or process modelling‖ is explained.
Figure 93: Example of ORACLE Levelling for Process Notations Using UML
To determine an improved future process, begin by working with business analysts and end
users analysing an ―as-Is‖ process and capturing the issues and challenges facing this process,
i.e., delays, disconnects, etc. A business process can be decomposed into several sub-
processes, which have their own attributes, but also contribute to achieving the goal of the
super-process. The analysis of business processes typically includes the mapping of processes
and sub-processes down to activity level.
It is often easier to first model the as-is process (if not already available), before thinking
about the improvements.
You could also start with doing a functional analysis of the enterprise in levels similar to the
way it is described here. For each level, you could use a different modeling approach.
For example a Value-Added Chain Diagram (VACD) is typically used for levels up to
business process (level 2). Other modeling approaches, such as BPMN (Business Process
VACD (Value-Added Chain Diagrams) is a less formal approach as it has a rather informal
notation standard that allows for deviations from ―text-book‖ notation and inclusion of non-
standardized symbols. BPMN (Business Process Modeling Notation) is standardized, as is
UML activity diagramming. Because of its informal nature, VACD might be easier for
business people to understand but tends to be less precise and as a result harder to map on
analysis and design models
To model the lower level business processes, you may choose to use BPMN, UML activity
diagrams, or some other notation.
BPMN is formalized to a level where there is a clear mapping to BPEL (Business Execution
Process Language). For example, a tool such as the Oracle BPA Suite can do a mapping from
BPMN to BPEL automatically (to some extent). However, the client may already have
standardized on a specific modeling approach. If so, consider using that approach in that it is
well known to the client.
In case of BPMN or UML activity diagrams, the diagram shows the events (initial state), the
steps and decision points as an actor performs them, and their sequence, by drawing flows
between pairs of activities or between an activity and a decision point or join. When there are
decision points that split a process into more directions, first identify the main flow before
going into all the exceptions routes.
An example of BPMN business process model with horizontal swimlanes is shown below:
When getting down to the requirements analysis (refer to the Enterprise Requirements
Management technique), groups of requirements can be attached at level 2 (Business Process)
and below. Requirements encountered at a parent node need to be interpreted that they apply
at the child levels (and grand child, and so on) and below. This is an especially useful method
for scoping or establishing a hierarchy of requirements which can be disseminated into service
candidates as well as ensuring complete coverage. It is also a useful way to broadcast non-
functional requirements (rather than repeating them at every node in every child level).
Further, this strategy can be used to document higher granular requirements prior to breaking
them down in to finer grained requirements.
A Function Model that prevents duplication of enterprise functionality across the model is one
of the aspects that make it useful for application within SOA deployments. One of the major
issues that the SOA strategy attempts to overcome is the duplication of critical business
function across systems. In many cases this happens simply because there is a lack of
visibility with respect to requirements and existing IT business function. In other cases the
inter-departmental rivalries/differences are the cause. A Function Model that eliminates
functional duplication and is scalable with respect to enterprise class data sizes is an ideal fit
for supporting the service identification and discovery aspects of an SOA from a functional
point of view.
Function models are trees and as such, the following rules apply to them:
Function Models have a fixed number of functional levels. However the detail
incorporated within each level can vary.
Each decreasing level is finer grained with respect to functional representation when
compared to the level(s) above.
Each node in the graph may have exactly one parent (excluding the root node, which
has no parent).
Cycles are not allowed in the model.
A Function Model is navigated by narrowing functional granularity, and not by
organization structure.
QUALITY CRITERIA
Comments:
This framework is well structured, derived from the Unified Process (UP), and much ―best
practice‖ oriented. The audience is functional oriented and written in clear and easy-to-
understand text. The description is not adapted to a specific industry or customer type. The
decomposition of the framework into program scope and project scope separates the strategic
reflection from the SOA implementation project. The ―Envision‖ part explains in detail how
to create a SOA Roadmap based on Maturity Assessment. Next, the ―SOA Planning‖
dimensions (Engineering, Modelling, Architecture, Governance) give method guidance on
how to perform the preparatory work for the SOA implementation project. Once the SOA
program is established, the SOA project implementation method details the SOA application
integration Architecture, the SOA tactical and the SOA project delivery.
The SOA Core Workflow presents a sequential order of macro processes with related
activities to explain details. This part of the framework is within the scope of SOA
implementation method as defined in this thesis.
The framework offers for each part activity description and in some cases also with concrete
examples. All the recommended tools are only ORACLE family tools and the examples and
templates are not necessarily added value. The details on notation usage can be summarized to
VACD, UML Scenario, BPMN and BPEL. The transition between the levels is inherent to the
proposed notations, which are supported by ORACLE products.
In total, the latest version is very comprehensive and complete method framework, where
SOA is one of five different scenarios (BI/Enterprise Performance Management, BPM, CRM,
Software Implementation and SOA). However, ORACLE has weaknesses in harmonizing the
wide range of different tools and related methods acquired during the last years. This becomes
clear in the proposed framework, as links between topics, phases and tool integration seem
not to be smooth and mature.
Principal Authors: -
Company/Organization: GARTNER, [GART06]
Category: Guideline, SOA Adoption Model, Gartner Leader‘s Toolkit 2006
Web: -
Nb. of pages: 8
Source: Commercial Research Organisation
Viewpoint: functional
Approach: -
Chapters:
Content:
The first chapter differentiates between ―Top-down‖ Enterprise drivers (M&A, Multichannel
sales support, Time to Market etc…) ―Bottom-up‖ Business Unit drivers (Call centre
integration, process integration, real-time B2B etc.) and ―Perennial‖ IT challenges (―doing
more with less‖, Business/IT alignment, Data consistency/quality etc.)
Chapter 4 describes the roles and their implications into each stage:
The Gartner adoption model is a mixture between maturity model and approach. On the one
hand, stages are defined describing an incremental approach. The categorization of different
drivers in ―top-down‖ , ―bottom-up‖ and ―IT challenges‖ is an interesting view on strategic
objectives. Following the Balanced Scorecard method, the objectives are structured into 4
views with bottom-up relationships. Gartner also recommends a top-down approach starting
with business objectives and a careful Return on investment calculation which is not as easy
as Gartner is saying. The step-by-step approach takes into consideration a change mgt. as
organizational and technical challenges need to be addressed. Without mentioning
―Governance‖, Gartner is explaining parts of it by defining required roles& responsibilities,
technology, skills, and capabilities per stage. As the stages with their scenarios are not
described in detail, it is difficult to evaluate, if the recommendations are right. This is hard to
verify, as the technology and skills are not explained e.g. Service-oriented development of
applications, SOA operation management, Service life cycle management etc. There is no link
to MDA and model types to use. BPM is a recommended skill to be considered as from stage
2.
Overall the recommended approach is a high-level attempt using the classic top-down
incremental approach to structure the main activities through the introduction of SOA. This
approach could be complementary to more technical and comprehensive approaches.
Principal Authors: Thomas Erl: SOA – Concepts, Technology and Design, Chapman Hall
2006, [NL05]
Company/Organization: -
Category: Book
Web: -
Nb. of pages: 8
Source: Commercial Author
Viewpoint: functional
Approach: -
Chapters
1.) Introduction
2.) Case Studies
3.) Introducing SOA
4.) The Evolution of SOA
5.) Web Services and Primitive SOA
6.) Web Services and Contemporary SOA (Activity Management & Composition)
7.) Web Services and Contemporary SOA (Advanced Messaging, Metadata, Security)
8.) Principles of Service Orientation
9.) Service Layers
10.) SOA Delivery Strategies
11.) SOA Analysis: Introduction
12.) SOA Analysis: Service Modeling
13.) SOA Design: Introduction
© Jan Ricken, University of Namur, Computer Science Department Page 262
14.) SOA Design: Composition Guidelines
15.) SOA Design: Service Design
16.) SOA Design: Business Process Design
17.) Fundamental Web Services Extensions
18.) SOA Platforms
19.) Appendix A: Case Studies conclusions
20.) Appendix B: Service Model Reference
Content:
Comment:
The relevant chapters describing the method are 10 to 16. Erl describes 3 method scenarios:
―top-down‖, ―bottom-up‖, and ―agile‖ strategies.
The ―top-down‖ strategy promotes the formal definition of corporate business models prior to
modelling service boundaries and can result in the highest quality level of SOA. It imposes
also a significant volume of up-front analysis work.
The ―bottom-up‖ strategy is not considered as a strategy at all, because this makes just sense
when adding web services to their existing application environments. Neither Service
orientation principles nor business strategy can be considered in the right way.
The ―agile‖ strategy proposes a combination of top-down and bottom-up, where on-going
analysis is supported, while allowing the immediate delivery of services. As analysis
progresses, existing services are revisited and revised as required.
Erl also states clearly, that a SOA without clear business objectives will fail. Erl is stating
that, but is not showing how this could work and what methods (BSC, Value Chain) or model
types to use. Erl is showing in his approach what should be done and how, but he is more
focussing on explaining in detail the concepts of services (WSDL), orchestration (BPEL), and
messaging (SOAP).
He is not mentioning MDA levels of abstractions nor related model types and interoperability.
In his practical examples, he is using ERM, BPML and UML charts, but does not explain that
the chart is based on BPMN or UML language.
In total, the method is helpful on technical aspects, but is by far not enough for a complete
and comprehensive method.
Chapters:
Content:
Summary:
Krafzig et al describes in chapter 7 well the importance of BPM related to the service oriented
architecture. He is mentioning MDA and CASE (Computer Aided Software Design) as
methods as part of Business Process Management Systems (BPMS). Modeling languages are
mentioned in chapter 7.1.3.1 such as BPEL, XLANG, WSFL, BPMN, UML, PetriNet, but the
authors are not putting the languages into the MDA context. UML is mentioned and MDA is
proposed as preferred approach for transformation of models from one level of detail to
another.
Related to the strategy of the method, the authors opt clearly for a top-down method for
service design to ensure that all service definitions meet business requirements, are designed
on the right level of granularity, provide potential for re-use, ensure scalability and integrity,
independent from any underlying implementation and provide appropriate service level
specifications.
The presented approach starts with the objectives and benefits, but not in a structured, model-
driven way. Interesting is the description of the different motivation and challenges of
different roles for a SOA introduction (CEO, CIO, Architect, Project Manager, Functional
Department, Developer). In reality, it is not an approach, as this would require phases, which
are not described here.
Some thoughts about project management, SOA Governance and do‘s and don‘ts are useful,
but rather generic. The statement to just take a generic project method and to enhance it with
service orientation components is also rather too generic. I agree to use an incremental
Chapters:
1.) Introduction
2.) Service Oriented Architecture
3.) The reference model
4.) Conformance Guidelines
5.) References
6.) Glossary
7.) Acknowledgements
Summary:
In the introduction, the goal of the reference model is to define the essence of service oriented
architecture, and emerge with a vocabulary and a common understanding of SOA. First, the
reference model is related to other work:
In chapter 2, the SOA paradigm is explained. Services, Service providers, service consumers,
service participants, service descriptions and service interfaces are introduced.
Chapter 3 introduces the reference model. First, the principal concepts are listed. The
relationships between the concepts are developed through the paper:
The following description is then explaining what I have earlier described as ―SOA
heartbeat‖.
The reference model shows an abstract framework for understanding the relationships
between the different mentioned concepts. The method is very formal and explains the
relationships around the service concept. As a reference model does not indicate any method
nor any types of models used etc., the content can just be used to verify and validate some
concepts such as ―service description‖ or ―interaction‖.
The following list is resuming the issues described in the SOA Domain model structured in
SOA Phases to allow better readability. Second, the table is showing which of the analysed
SOA methods is covering the presented issues and to what degree the issues are covered. The
result is identical to the summary model of method analysis, but just presented in another
format.