Interpreting SOA as a Method Framework
Transcript of Interpreting SOA as a Method Framework
Interpreting SOA as a Method Framework
Dr. M. Naci Akkøk
Oracle Nordic, Vollsveien 2, 1366 Lysaker, Norway [email protected]
or
Department of Informatics, University of Oslo, Gaustadalléen 23, Norway [email protected]
Abstract. There are far too many definitions of SOA. This serves to increase
confusion, contributing to less than successful adoptions of SOA, and adding to
skepticism about the actual value of SOA. And offering yet another definition is
no longer the correct remedy. As an alternative, this workshop paper offers an
operational interpretation of SOA, i.e., SOA as a method framework, support-
ing the view that the unique asset of SOA is its focus upon the whole enterprise
– especially upon alignment between business and IT – hence advocating a sin-
gle method framework that encompasses the whole enterprise. Tools to support
the SOA method framework are also indicated, forming a reference for a SOA
compliant tool-set1.
1 Introduction
1.1 Motivation
Service Oriented Architecture (SOA) has been with us for some time now2. The era of
SOA is marked with hectic activity, fueled by analysts like Gartner and Forrester, as
well as practically all major software and consultancy companies, producing literally
thousands of SOA definitions and SOA products.
Despite all the fanfare around SOA, users have been slow to react to the news,
questioning how much of the news is hype. The existence of far too many non-
conforming definitions has not helped improve this skepticism of the skeptics, nor the
1 The work presented in this paper is based upon semi-formal academic surveys conducted at
the University of Oslo, as well as direct experience with some (relatively large) Oracle SOA
installations using primarily Oracle’s Fusion Middleware (SOA & BPM) products and ap-
proaches. 2 Many experts note that SOA is much older than what is assumed to be the “era of SOA” in
this paper. I agree with this view, but SOA did not start to become popular until quite re-
cently. In this paper, I am placing the start of the era at around the time SOAP (Simple Ob-
ject Access Protocol) became a W3C concern on 13th September 2000 when W3C’s XML
Protocol Working Group was founded.
dedicated pioneers: the confusion caused by the cacophony seems to have been lead-
ing to less than successful (or at least delayed) adoptions of SOA.
1.2 The State of SOA
Despite the confusion – or maybe because of the confusion and a need to understand
the reasons behind it, things seem to have started maturing to a certain degree at least
amongst analysts, vendors and consultants, i.e. the “providers” of the software indus-
try, and amongst pioneering adopters. A sign of this is the fact that the tools & tech-
niques offered by the providers of the software industry (and used – actually de-
manded – by pioneers) have started resembling each other, indicating a convergence
towards how SOA needs to be done3.
In the case of the software industry, SOA practice is undeniably converging to what
I would like to call business-centric SOA. This is characterized for example by all
vendors offering BPM components on top of their SOA offerings or, in a few cases, as
integral part of their SOA platform products.
Of course, this observation alone does not ensure that we are actually moving to-
wards business-centric SOA, but the tendency is also in accordance with others’ find-
ings as well as our own surveys and experiences. According to Vollmer [1] “BPMS
and service-oriented architecture (SOA) implementations frequently occur together,
and this is no fluke, as these two technologies complement each other very well, re-
sulting in a more powerful solution than either could provide on its own”. Zhu [2]
goes as far as giving a name to this business and IT encompassing approach: Business
Oriented Architecture or BOA.
The conclusions of our own surveys are similar. In an attempt to find how SOA
differs from other architectural approaches, we conducted three surveys according to
the following scenario:
1. Make two lists, where one captures all key words that appear (anywhere
on the Internet, in literature, in provider definitions or in user experience)
in relation to SOA, and another list that captures key words related to
other main-line architectures like Layered Architectures (LA), Product
Line Architectures (PLA), as well as architectures implied by component
based development (that we term Component Based Architectures or
CBA)4 and architectures implied by object oriented development (OOA)3.
2. Then delete from the SOA list any key word that also occurs in the lists of
any one of the other architectures.
3 This may sound a bit upside down, as if practice is preceding theory. That is exactly what is
happening and it is definitely not the first time (nor probably the last time) theory and formal
definitions are built upon practice, the best example being Number Theory. This actually
makes sense especially in cases like SOA, where arriving at a common formalism proves to
be too difficult initially, forcing one to seek “operational interpretations” instead of a formal
definitions. 4 Strictly speaking, there is no well defined Component Based Architecture (CBA) or Object
Oriented Architecture (OOA), but the component-based & object-oriented paradigms do im-
ply their architectural counterparts that we refer to here.
The terms then left in the SOA list do not necessarily define SOA fully, but they
indicate what is unique in SOA with respect to other architectural approaches.
Following is what comes out of this simple survey:
”Service Oriented Architecture (SOA) is an architectural style that
advocates business aligned, governed, orchestrated, secure & reliable
services, where services are coarse granularity, loosely coupled reusable
and composable components reflecting business functionality exposed
through standard and discoverable interfaces.”
Note that the term business aligned is one of the key terms that SOA focuses upon
according to our surveys, again supporting the earlier observations and the conver-
gence towards business-centric SOA. This signals – amongst other things – the need
for lossless or near-lossless communication (i.e., integration) between business and IT,
which we will look into later.
Business alignment is not the only term that renders SOA unique according to the
survey. The terms governed, orchestrated, composable, and – to a certain degree –
reusable & standards compliant contribute as well. We shall not be looking into all
these concepts in this paper, since it will take more than a workshop paper to do them
justice, but the reason why re-use is in the list of terms that are unique to SOA needs
an explanation, since re-use exists in all other architectural approaches we have men-
tioned as well.
The reason is simple: re-use refers to code or component level re-use in architec-
tures other than SOA, whereas it refers to business service (or process) level re-use in
business-centric SOA. In other words, the semantics of re-use differ in the alternative
architectural approaches even though the term is the same. More specifically, re-use is
at a higher level of abstraction in SOA than in other architectures.
2 Interpreting SOA as a Method Framework
SOA is Service Oriented Architecture. Being architecture, it is a way of thinking, a
way of putting things together, a design approach or a paradigm. Manes [3] puts it as
follows: “SOA is something an organization does, not something it buys or builds.
SOA is a new way to design systems, and it is more about culture than it is about
technology”. Schmelzer of ZapThink [4] repeats the fact that “SOA is something you
do, not something you buy”. And there are many others who have come to similar
conclusions.
So SOA is something we do. But how do we do SOA exactly? Answering the ques-
tion is the same as sketching a method framework for SOA. But before we can do that,
we need to understand what SOA imposes as requirements upon a method framework,
i.e., the principles/goals of SOA that a SOA-compliant method framework must ad-
here to. We summarize these under the concept of Enterprise Development (ED).
2.1 Enterprise Development
SOA’s business alignment principle implies that not only the Software/Systems Devel-
opment Cycle (SDC) but also the Business Development Cycle (BDC) needs to be
studied in developing a SOA-compliant method framework. The same principle also
indicates that the two development cycles need to be aligned somehow.
Figure 1 shows how we picture the two development cycles as well as their align-
ment: a third cycle, called the Orchestration and Planning Development Cycle (OPC)
is introduced in between them for providing the alignment. Orchestration in the new
mediating cycle refers to the orchestration of the two neighboring development cycles.
Fig. 1. Enterprise Development (ED) in terms of its three constituent development cycles.
This model is experience based and is not unique. Another experience-based model is
from a Norwegian advisory/consultancy company called Integrate5 that offers services
to align IT and business. A simplified version of Integrate’s model is in figure 2:
Fig. 2. Enterprise Development (ED) in terms of its three constituent development domains
according to Integrate and Arctic.Park.
5 See http://www.integrate.no/corporate_site for more information on Integrate. It is worth
looking at the Arctic.Park pages as well (http://www.arcticpark.com/), since Integrate and
Arctic.Park work very closely, with Arctic.Park providing the orchestration layer services
(architecture services) in business and IT alignment.
The similarities are obvious. There is more to the similarities than what the figures
convey. Though development is categorized into three distinct cycles or domains in
both models, based upon experience, they both claim a continuum of development
covering the whole enterprise, which is what we refer to as Enterprise Development in
this paper.
Looking from IT’s perspective, SOA’s business alignment principle means IT
alignment to business needs, implying that what would be characterized as the analysis
& design phases of IT (or inception and elaboration phases in Unified Process termi-
nology [5, 6]) are no longer just the top (or early) phases of the Software/Systems
Development Cycle in figure 1, but are extended to cover the whole Business Devel-
opment Cycle and the Orchestration and Planning Development Cycle. In other words,
what manifests itself as a specification or design in the Software/Systems Develop-
ment Cycle comes from the Business Development and the Orchestration & Planning
Cycles, which means that the software/systems specification/design activity (or disci-
pline) is only one of the end steps in a long and complex set of interrelated business
development & support planning activities.
The implied existence of two additional development cycles (BDC and OPC in fig-
ure 1) to the enterprise should not come as a surprise. This is not far from what the
Enterprise Unified Process (EUP) [7] has been trying to say all along through its ex-
tended set of Enterprise Disciplines listed here:
o Enterprise Business Modeling
o Portfolio Management
o Enterprise Architecture
o Strategic Reuse
o People Management
o Enterprise Administration
o Software Process Improvement
Though the EUP list is a single list, it obviously indicates the need to cover both BDC
disciplines (like Enterprise Business Modeling) and OPC disciplines (like Enterprise
Architecture).
Note that Strategic Reuse is emphasized in that it has its own discipline in EUP, as
our comparative definition in section 1.2 indicated. Note also that these disciplines are
at the same level with People Management, which we have always known as an enter-
prise-level activity, and a (distinct) Enterprise Administration discipline, which opens
up to yield the following set of activities:
o Managing Enterprise Physical Assets
o Managing Enterprise Information Assets
o Managing Enterprise Security
o Support Project Teams
There is a message in ED (and in EUP) that is crucial to the definition of a proper
SOA method framework. The same message is also crucial to the success of realizing
SOA in an enterprise, and in running successful development projects. The message
can be summarized in terms of the two following presentation quotes:
”Service Oriented Architecture (SOA) is an architectural style that has enterprise
focus and needs enterprise attention. The job to realize SOA in a company or an
institution can not be given to a SW/systems development project that has a business-
deliverable as its focus. The project has no enterprise level acccess or control, and will
fail in realizing SOA. It will also fail in delivering its business-deliverable because of
loss, dilution or deviation of focus while trying to deliver SOA in addition.”
”A software/systems development project that is not anchored in business design
formalisms (including business processes) cannot be said to ’serve’ the business in a
formal, traceable or controllable manner. Thus, such development projects cannot be
considered service-oriented”.
These two quotes (especially the last one) gives us the clues we need to set up a
SOA-compliant method framework.
2.2 SOA Method Framework
Based upon the preceding section, we are now in a position to offer a four-step Enter-
prise Development cycle shown in figure 3, which is the basis of our SOA method
framework.
Fig. 3. Four steps of the Enterprise Development (ED) cycle as the basis for a SOA-compliant
method framework (mapped onto components from Oracle’s SOA Stack)
A step-by-step scenario of the SOA method framework is as follows:
LLoosssslleessss
11
22
33
44
Step 1. Since SOA implies business alignment, designing the business itself
is the first step in our enterprise-level SOA method framework. This
step includes modeling (designing) business processes, but it re-
quires modeling a good deal more as listed below and in figure 3:
o Business drivers,
o Business goals,
o Key performance indicators (KPIs),
o Business constraints,
o Business rules,
o Organization & roles,
o Common terms,
o Work-processes including workflows (not the same as
business processes),
o Service providers & required services
o …
Step 2. Once the business design is in place, the next step is to make sure
that the design is sound by simulating & analyzing the business de-
sign. Steps 1 and 2 may need to be iterated through several times,
analyzing/simulating to find design glitches and re-designing on
each iteration, until a satisfactory business design is reached.
Step 3. When a satisfactory business design is in place, and once one knows
exactly where (for which processes) technology support is desired,
the design – with all its design parameters as listed above – needs to
be transformed losslessly and seamlessly to a formal implementation
specification. In step 3, this specification is then realized through
doing whatever is necessary of further developing, integrating, or-
chestrating, securing and deploying the solution. Sprecht et al. [8]
also address this kind of transformation.
Step 4. If the solution (and not only its development) is going to be SOA-
compliant, then the solution needs to be monitored with respect to
design parameters (business processes, work-flows, goals, KPIs etc)
for ensuring correct design and business achievement.
The Enterprise Development cycle completes when monitoring and/or other contex-
tual business requirements demand adjustments, leading back to step 1 for a re-design
of the business.
Note that the method framework includes another step that is continuous and con-
current with all four steps: Governance. It should be noted that governance is by no
means secondary to any step in the method framework. It is just that governance re-
quires attention on its own, and that is not the focus of this paper. For those who are
interested, Manes [3] offers a good introduction to the need for governance, and some
insight to governance issues and tools.
Note also that this method framework is a framework and not a method. It needs to
be detailed and adapted to users’ context in order to become a method.
One last note that is relevant for the next section: In such an approach, the business
needs to get its own business development tool distinct from IT’s tools, but well inte-
grated with them.
2.3 Required SOA Tool-Set
Now that we have the main steps of the SOA method framework established, we need
to look at what such a framework imposes upon the tool-set that will be supporting it,
and what kind of modeling hierarchy and development process it implies.
One common belief is that transforming business process models – typically in
Business Process Modeling notation (BPMN) [9] or Event Process Chain (EPC) dia-
grams [8, 10] – to executable flows, as for example Business Process Execution Lan-
guage (BPEL) flows, is sufficient for achieving business-to-IT alignment. Though
such a business-flow to executable-flow transformation is necessary, it is not suffi-
cient. As we noted earlier, a business design is more than just a business process
model. Thus, lossless transformation of a business design will require that all relevant
design-time artifacts & parameters that we listed up in the previous section are trans-
formed to a development or production (run) time tool. Figure 4 sketches the trans-
formational relationships between design and development/production environments
in Oracle Corporation’s SOA (i.e., Fusion Middleware®) tool-set, often referred to as
a “SOA stack”.
Fig. 4. Mapping the SOA method framework into a SOA tool-set (courtesy of Oracle).
Note that practically all design-time artifacts have a receiver on the development &
production time environment.
But, as we have learned dearly during the Computer Aided Software Environment
(CASE) period [11], simply transforming designs to implementables is not sufficient.
The so-called round-trip engineering issue, which flags the issue of implementation-
documentation mismatch once development starts making changes to the design, is
one major issue that has been difficult to resolve until recently. If the SOA method
framework – which needs to cover the whole enterprise, requiring bi-directional
method and tool-level communication between all organizational units, including IT
and other business units – is going to be realizable with proper tool support, this issue
needs to be solved. There are three major approaches to solving this issue:
1. Transform the business notation to implementation notation and export it
on the business tool side, so as to import it on the development side.
Round-trip engineering is achieved by being able to do the opposite as
well: export from the implementation side (after changes) and import it
back into the business design environment. Most available suites or tool-
sets fall under this category.
2. Use a single repository shared by business and IT, where the repository
contains a single shared model (based upon a shared meta-model that is
capable of expressing both sets of notations), which turns the business
model and the IT model into views of this shared model. Oracle’s Busi-
ness Process Analysis (BPA) Suite [12], built upon IDS Scheers’ ARIS
Platform [13], and Oracle’s SOA Suite [14] function in this manner.
3. Make the (business) design notation executable. Intalio [15], an open
source executable BPMN tool, is such a tool.
The first approach may require that the changed version from implementation and the
original business design be merged when re-imported. If not, IT and business cannot
be allowed to work on the same model sets concurrently. In addition, this approach
will most likely yield at least temporary mismatch between design and implementa-
tion, since the export-import cycles are by large manual.
The third approach is very alluring, but it also has a catch. Two languages that are
richly expressive and understandable in their own domains cannot translate losslessly
to each other, unless one reduces either expressiveness or understandability (or both)
drastically. In plain terms, this means that a business “language” that can execute, i.e.,
act as a computationally complete programming language, is not understandable or
usable by business people unless they are re-trained as programmers (and vice versa).
The second approach seems to be the best, but it has been unattainable until re-
cently. In addition to solving the round-trip engineering problem, it has advantages
like allowing for fully expressive (native) languages for all involved in Enterprise
Development. As mentioned before, the only tool set that falls in under this category is
Oracle’s BPA Suite [12], which implements the architecture shown in figure 5.
Fig. 5. Logical model for Oracle’s BPA Suite and SOA Suite integration.
2.4 Implied Model Hierarchy
The SOA method framework with proper business design parameterization and proper
tool support still needs a last detail before the framework becomes understandable and
usable: an enterprise level traceable “design-to-development-and-back” design tech-
nique that complies with the four steps of the framework.
Figure 6 shows the Five Level Model, abbreviated FiLM, which offers a modeling
(design) hierarchy that is SOA compliant, enterprise level and traceable.
Fig. 6. Five Level Model (FiLM): A SOA-compliant model hierarchy for ED.
The first two levels of FiLM map onto the Business Development Cycle in Enterprise
Development. The third level maps onto the Orchestration & Planning Cycle. The last
two levels (i.e., 4th & 5
th levels) map onto the Software/Systems Development Cycle
of Enterprise Development. Since the whole approach is model-driven in essence, the
last two levels actually map onto what is suggested in Model Driven Architecture [16]
of OMG, i.e., onto Platform Independent Models (PIMs) at 4th level and Platform
Specific Models (PSMs) at 5th level, where actual code (the implementation) is con-
sidered to be a PSM in FiLM.
FiLM has several additional advantages that are not immediately visible in the dia-
gram and description above:
o It offers a technique for identifying & designing service operations, ser-
vices, service orchestrations and service categories (same as process do-
mains in FiLM)
o It offers a strict terminology constraining seemingly obvious terms like
“Business Process”, “Work Flow”, “Domain”, “Value Chain” etc.
o It offers a two-way traceable break-down and build-up modeling hierar-
chy, where business models (levels 4 & 5) and orchestrations (level 3) are
all expressed in flow-languages that are easier to transform to each other
4 Concluding Remarks
A version of the SOA Method Framework including a variation of FiLM are included
in Oracle’s SOA Methodology (which in turn is part of Oracle’s Unified Method or
OUM), and put to test by quite a number of Oracle users and some non-Oracle users.
One common feedback from the user community is that the method framework is too
top-down, whereas the reality is sometimes that they need to discover services and re-
fit them into processes that were not designed to accommodate them.
The framework can also be used for bottom up approaches like Service Oriented
Integration (SOI) and Enterprise Application Integration (EAI).
Fig. 7. The relationship between Service Oriented Architecture (SAO), Service Oriented Inte-
gration (SOI) and Enterprise Application Architecture (EAI).
The relationship between SOA, SOI and EAI (depicted in figure 7) is relatively
straightforward. SOA is business-centric. EAI is integration (technology) centric. Still
an application’s desired functionality can be exposed as a service that then can be
integrated using orchestration/integration techniques native to Service-Orientation
(which gives us SOI). The service can also be augmented (for example wrapped) to
deliver a process step in a process-centric SOA design, which gives us SOA – but
bottom up.
Looking at FiLM level 5, we see the following litany that preaches a combination
of both bottom-up and top-down approaches:
o Find in registry
o Find in legacy (and if necessary adapt)
o Buy (and if necessary adapt)
o Develop (if all else fails).
With this level 5 litany and its two-ways traceability, FiLM also supports middle-out
approaches.
As a closing statement, I would like to note that the method-wise interpretation of
SOA described in this workshop paper is under continuous development both through
acquiring experience from actual projects, and through a number of research projects,
including a couple of PhD studies in preparation. Thus, the materials presented in this
paper are not meant to be final and absolute truths, but steps towards better mastery of
SOA, and hopefully a good basis for discussions in a workshop and in SOA literature.
References
1. Vollmer, K., Business Process Management Suites and SOA: Enabling
Flexible Process Improvements. Forrester Trends, 2006. March 10, 2006.
2. Zhu, J. and L.Z. Zhang. A Sandwich Model for Business Integration in BOA
(Business Oriented Architecture). in 2006 IEEE Asia-Pacific Conference on
Services Computing (APSCC'06). 2006.
3. Manes, A.T., Service-Oriented Architecture: Developing the Enterprise
Roadmap. Burton Group Application Platform Strategies In-Depth Research
Overview, 2006. Version 2, July 13, 2006.
4. Schmelzer, R., SOA for Independent Software Vendors (ISVs). 2006. URL:
http://www.zapthink.com/report.html?id=ZAPFLASH-2006419, ZapThink.
5. Scott, K., The Unified Process Explained. 2002: Addison-Wesley Profes-
sional, 1st edition. 160 pages.
6. Ambler, S.W., A Manager's Introduction to the Rational Unified Process
(RUP). 2005. URL:
http://www.ambysoft.com/unifiedprocess/rupIntroduction.html, Ambysoft.
7. Ambler, S.W., Enterprise Unified Process (EUP). 2006. URL:
http://www.enterpriseunifiedprocess.com/, Ambysoft.
8. Specht, T., et al. Modeling Cooperative Business Processes and Transforma-
tion to a Service Oriented Architecture. in Seventh IEEE International Con-
ference on E-Commerce Technology (CEC’05). 2005.
9. OMG, Business Process Modeling Notation (BPMN) Information. 2007.
URL: http://www.bpmn.org/, Object Management Group.
10. IDS Scheer, Event-driven Process Chain. 2007. URL: http://www.ids-
scheer.com/en/Software/Event-
driven_Process_Chain_Modeling_Standards/79740.html.
11. Oman, P.W., CASE: Analysis and Design Tools. IEEE Software, 1990. 7(3):
p. 37-43.
12. Oracle Corporation, Oracle Business Process Analysis (BPA) Suite. 2007.
URL: http://www.oracle.com/technologies/soa/bpa-suite.html.
13. IDS Scheer, ARIS Platform: Business Process Excellence. 2007. URL:
http://www.ids-scheer.com/en/index.html.
14. Oracle Corporation, Oracle Service Oriented Architecture (SOA) Suite.
2007. URL: http://www.oracle.com/technologies/soa/soa-suite.html.
15. Intalio, Intalio BPMS. 2007. URL: http://www.intalio.com/.
16. OMG, Model Driven Architecture (MDA) Home Site. 2003:
http://www.uml.org/.