Interpreting SOA as a Method Framework

Dr. M. Naci Akkøk

Oracle Nordic, Vollsveien 2, 1366 Lysaker, Norway naci.akkok@oracle.com

or

Department of Informatics, University of Oslo, Gaustadalléen 23, Norway nacia@ifi.uio.no

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/.