AN OVERVIEW OF THE OSTRA FRAMEWORK FOR THE

TRANSITION TO SOA

Fabiano K. T. Tiba, Shuying Wang and Miriam A. M. Capretz

Department of Electrical and Computer Engineering, University of Western Ontario

London, Ontario, N6A 5B, Canada

Keywords: Service-Oriented Architecture (SOA), SOA transition.

Abstract: Service-Oriented Architecture is an emerging paradigm to build applications as a collection of services that

can be coordinated to provide flexible applications. At its full potential, the development of services is

considered from the perspective of the enterprise to deliver services that can be reused across applications

and provide flexible solutions. However, the achievement of an enterprise-wide SOA is challenging, as it

remains unclear how organizations should evolve towards the SOA paradigm. This paper discusses issues

related to transition to SOA and provides an overview of OSTRA - a framework which provides a realistic

approach for the transition to SOA, by considering short-term and long-term goals and balancing planning

and management with practical experimentation.

1 INTRODUCTION

Organizations have always been under constant

pressure to adjust quickly to the changing demands

of their businesses. Service-Oriented Architecture

(SOA) technology promises unmatched flexibility

and seamless integration at relatively low costs.

SOA is comprised of a set of design principles that

promotes the development of applications as a

composition of loosely coupled Web services (Erl,

2005). The emphasis of web services on industry-

wide standards has enabled the vision of the agile

enterprise that flexibly adapts its technology to its

business needs.

In general, the transition to an SOA requires

changes to company’s existing applications, and

there is a lot of uncertainty surrounding the

challenges involved in the implementation of an

SOA. Although many researchers have worked on

the individual difficulties of the transition, there is

still a lack of frameworks to guide the entire

transition to SOA. Academic literature is focused on

providing solutions for technical challenges rather

than in the overall transition itself, and while the

industry has provided a fair amount of research on

management issues, a complete solution for the

transition to SOA has not been yet published as it

probably composes their portfolio of consulting

services. The main reason for the shortage of

frameworks though, is that the concepts and

technology that have enabled the SOA vision are

recent and still evolving, and therefore, the need for

a framework describing the transition to SOA has

only recently become a priority issue.

In this paper, we discuss the transition

approaches to SOA and their adoption challenges.

Moreover, it presents an overview of the OSTRA

(Opportunity-driven Service-oriented TRAnsition)

framework to guide enterprises in the evolution to

SOA, followed by a discussion of the initial

implementation of OSTRA in a real organization.

The paper is organized as follows: Section 2

presents the OSTRA framework. Section 3

overviews the implementation of OSTRA in a real

company while Section 4 discusses the lessons

learned from the real case and presents its

conclusions.

2 OSTRA: AN SOA TRANSITION

FRAMEWORK

In contrast to other transition approaches

(Bieberstein, 2005) (Sprott, 2003), which

recommends the development of a precise long-term

plan, OSTRA aims to provide a more adaptive

approach to managing the iterative and incremental

195

K. T. Tiba F., Wang S. and A. M. Capretz M. (2008).

AN OVERVIEW OF THE OSTRA FRAMEWORK FOR THE TRANSITION TO SOA.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 195-198

DOI: 10.5220/0001678101950198

 SciTePress

transition to SOA. OSTRA achieves this by

balancing a continuous analysis of the transition

process with the development of opportunities into

projects, which enable organizations to obtain and

evaluate short-term goals while still laying the

foundation for the achievement of its long-term

vision.

2.1 OSTRA Streams

OSTRA defines three streams as its key foundations

for the successful transition to the enterprise SOA:

SOA Roadmap, SOA Development and SOA

Governance, which are represented in Figure 1.

Figure 1: OSTRA streams.

• SOA Roadmap defines topic areas focused on the

planning of the transition. It organizes the planning

in four topic areas: the identification of goals

(Actional, 2005); the assessment of the current state

of the organization; the identification of

opportunities; and the subsequent elaboration of a

plan to achieve that vision.

• SOA Development contains topics for effectively

constructing the conceptual SOA (Krafzig, 2004).

These topics are categorized as service development,

service composition, service management and

infrastructure development.

• SOA Governance is composed of four topic areas

that are concerned with controlling the transition and

enforcing consistence of the resultant SOA:

communication and education; policies and

procedures; governance model; and SOA group and

concepts. (Windley, 2006)

2.2 OSTRA Phases

These three streams of OSTRA are gradually

investigated in the course of three phases, and can be

executed simultaneously: Inception, Elaboration and

Implementation as depicted in Figure 2.

Inception is the initial phase, where the

enterprise establishes the foundations for the

transition, defining goals and identifying the group

that will be responsible for the transition process.

Elaboration is an ongoing phase where the transition

is planned by continually identifying opportunities,

managing the transition, and governing the SOA.

The identification of opportunities triggers the onset

of the Implementation phase, where identified

opportunities are developed as projects, with the

evaluation of the benefits and practical challenges.

The results are consolidated into processes, services

and infrastructure, which are continuously improved

until the goals are achieved. These results also

provide feedback for the Elaboration phase to adjust

and investigate other issues regarding the

governance of the SOA and the transition.

Figure 2: Overview of OSTRA phases.

OSTRA enables a dual positioning strategy with

respect to goals, focusing not only on short-term

results in the Implementation phase, but also

ensuring that they are part of longer-term goals,

which are continuously evaluated during the

Elaboration phase. By utilizing a dual positioning

strategy focused on opportunities, OSTRA aims to

continuously align the business goals of the

organization with its underlying technology while

still supporting its immediate needs through the

investigation of opportunities. This approach is

evolutionary as it aims to gradually incorporate SOA

values into the existing assets of the enterprise

through the successive exploration of opportunities

while minimizing risks and disruption.

ICEIS 2008 - International Conference on Enterprise Information Systems

196

3 CASE STUDY

We have been working with a large corporation to

employ OSTRA to develop their SOA initiative.

This industrial partner is interested in using SOA

technology to improve their business flexibility and

to enable better integration between its divisions and

products (Bloomberg, 2003). However, the company

size is a challenge for the implementation of

enterprise-wide initiatives, as there are many

conflicting interests and a myriad of existing

applications and competing technologies. Therefore

we have started the work in one of their division

Plant-Wide Systems (PWS) and have been preparing

to deliver it at other divisions.

3.1 Inception

The first step in the application of the OSTRA

framework involves the definition of the SOA group

and SOA concepts. The SOA Group contains a

business leader, the manager, to provide a view of

the customer needs and enterprise directions; a

technical leader, the systems architect, to provide an

overall perspective of the applications; product

architects, to contribute with their detailed

knowledge on each application; and external

consultants, to provide an understanding of SOA

technology. Moreover, in order to discuss

information pertaining to SOA concepts, regular

meetings were organized with core members of the

SOA group. The results of these discussions were

consolidated into a presentation to the entire SOA

group and were compiled in a document that served

as the basis for a conceptual whitepaper.

3.2 Elaboration

Although several opportunities were identified, it

was decided that the initial focus would be on

improving application integration, since this can

produce more visible and immediate results than

decomposing existing applications into services. A

new application named InfoLite has been selected as

the pilot project to illustrate the benefits of an SOA-

approach in practice and to establish initial standards

for SOA development. Furthermore, an overall plan

for the transition has been established, which is

depicted in Figure 3. The plan involved using the

results of the development of the opportunities to

demonstrate the value of an SOA to their

applications and to obtain approval at the current

business division, securing a budget and eventually

triggering the SOA adoption for the entire system.

In the current organization of the enterprise, each

division has a certain degree of autonomy to take

their own decisions, and therefore it provides a

natural structure for the Governance Model.

Furthermore, initial investigation has started on

policies and procedures, especially in terms of

naming conventions and optimal services

granularity; this investigation is being assisted

through collaboration with the other information

team. In order to facilitate reuse by different teams,

specific industry standards have been adapted to

build a vocabulary of valid verbs to use as service

operation names, and to provide recommendations

on the names and scope of the services.

Figure 3: High-level plan for the transition.

3.3 Implementation

In the implementation phase, the pilot project

InfoLite was developed. Figure 4 displays an overall

view of the initial situation. Three applications from

a plant control division are represented: Limit

Control, Incident Intelligence, and Operator

Assistance. Also depicted is the Plant Information

application, which is used by managers to control

the production of the plant at the next higher level.

PWS platform and PWS database provide

information models such as equipment structures for

the Limit Control and Plant Information applications

at enterprise level. The Limit Control (LC) database

is depicted separately to assist in conceptualizing the

models at domain level. Incident Intelligence

retrieves their equipment structure, as well as other

data, from the Limit Control database. However,

these applications retrieve data directly from the

Limit Control database and need to deal with

problems such as synchronization and dependency

on the Limit Control data structure. If designed

AN OVERVIEW OF THE OSTRA FRAMEWORK FOR THE TRANSITION TO SOA

197

Figure 4: Initial situation. Figure 5: Improving integration between applications.

properly, the services developed for InfoLite could

provide a more loosely-coupled solution for

integrating applications that depend on Limit

Control data. In fact, this potential solution was the

main motivation for InfoLite’s SOA, since retrieving

data from Limit Control has been a recurring

problem. After analysing the requirements of

InfoLite and other PWS business units needs, the

Infolite service was divided into four granular

services. As depicted in Figure 5, instead of

providing a specific service, this architecture

provides four generic services that are useful for

other applications. The Tag service will provide tag

data to other applications, such as Plant Information

Application and Incident Intelligence, making them

independent of Limit Control data structure. The

Equipment Structure services will provide the

Equipment Structure that is required by other

applications.

Two versions of the Equipment

Structure service are planned, one for Limit Control

data and one for PWS Platform. Moreover, by

defining the standard Equipment Structure service, it

will be possible to switch from one version to

another seamlessly.

4 CONCLUSIONS

The implementation of the SOA initiative in an

actual company has provided invaluable feedback

for certain areas in the transition process. These

lessons have influenced the refinement of OSTRA

and have provided insights on future improvements.

The pragmatic approach of OSTRA has been

considered successful since the development of the

identified opportunity has indeed provided the basis

for the achievement of the vision and has clarified

the challenges and issues of an SOA. Additionally,

the development of the pilot project has provided

valuable feedback from industry, as the practical

results further illustrated the challenges, the

importance of the SOA governance and the

investigation of standards and recommendations.

During the implementation we have observed that

technology vendors have a major influence on the

practical implementation of the SOA, as the

existence of tools and platforms to support the

solution, as well as the alignment with industry

trends, is crucial issue for enterprises. In the case of

our industrial partner, the existence of supporting

and reliable tools, as well as being aligned with their

emerging industry SOA standards were important

arguments for supporting the transition to SOA.

Finally, OSTRA is an open-ended framework that

enables the transition to SOA become harmonized

with other initiatives like CMM or 6-Sigma.

REFERENCES

Actional Corporation, 2005. Implementing a Successful

Service-Oriented Architecture (SOA) Pilot Program,

Retrieved Oct. 2006 at http://www.actional.com.

Bieberstein, N., Bose,S., Fiammante, M., Jones, K., Shah,

R., 2005. Service-Oriented Architecture Compass:

Business Value, Planning, and Enterprise Roadmap,

IBM Press.

Bloomberg, J., 2003. Growing an Agile Service-Oriented

Architecture White Paper - Achieving Reuse & Loose

Coupling through Web Services Delivery Contracts,

ZapThink.

Erl, T., 2005. Service-Oriented Architecture (SOA):

Concepts, Technology, and Design, Prentice Hall

PTR.

Krafzig, D., Banke, K., Slama, D., 2004. Enterprise SOA:

Service-Oriented Architecture Best Practices, Prentice

Hall PTR.

Sprott, D., 2003. Web Services Roadmap Planning

Framework, CBDI Forum Ltd.

Windley, P. J., 2006. Governing SOA, InfoWorld.

ICEIS 2008 - International Conference on Enterprise Information Systems

198