TOWARDS TECHNOLOGY INDEPENDENT STRATEGIES FOR
SOA IMPLEMENTATIONS
Zheng Li
School of Computer Science, ANU and NICTA, Canberra, Australia
He Zhang
School of Computer Science and Engineering, UNSW and NICTA, Sydney, Australia
Liam O’Brien
School of Computer Science, ANU and CSIRO, Canberra, Australia
Keywords: Service-Oriented Architecture (SOA), SOA implementation, Organization theory, Organization design,
Strategy.
Abstract: Benefiting from the technology based strategies, Service-Oriented Architecture (SOA) has been able to
achieve the general goals such as agility, flexibility, reusability and efficiency. Nevertheless, technical
conditions alone cannot guarantee successful SOA implementations. As a valuable and necessary
supplement, the space of technology independent strategies should also be explored. Through treating SOA
system as an instance of organization and identifying the common ground on the similar process of SOA
implementation and organization design, this paper uses existing work in organization theory area to inspire
the research into technology independent strategies of SOA implementation. As a result, four preliminary
strategies that can be applied to organizational area we identify to support SOA implementations.
Furthermore, the novel methodology of investigating technology independent strategies for implementing
SOA is revealed, which encourages interdisciplinary research across service-oriented computing and
organization theory.
1 INTRODUCTION
Service-Oriented Architecture (SOA) emerges with
the requirements of quick response to the rapid and
often unpredictable changes in business environment
for modern enterprises. Motivated by the
expectations of the people who are engaged in SOA
activities, SOA has goals such as reusability of
software assets across multiple platforms and
applications, agility of support to business processes,
efficiency in terms of development time and cost,
and flexible integration of existing and legacy
information systems. Considering goals define
where we want to go while strategies define how we
will get there (Daft, 2009), SOA implementation
strategies should be investigated to facilitate
achieving SOA’s goals. In fact, numerous strategies
have been proposed and developed over the past
decade. For example, Newcomer and Lomow (2004)
use Web services to concrete the conceptual SOA;
Krafzig, Banke and Slama (2004) focus on the
practical application of SOA in enterprises with
discussion of the roadmap of relevant technologies;
Erl (2007; 2009) summarizes a full scope of
implementation strategies through eight principles of
service design and 17 SOA design patterns. To the
best of our knowledge, however, most of existing
strategies for SOA implementation only pay
attention on the technology aspect, particularly
relying on the current state of the art of Web
technology. As we know, technology is a necessary
but not a sufficient condition for successful SOA
implementations (Rosen, Lublinsky, Smith and
Balcer, 2008). In other words, technology cannot
guarantee the success of an SOA system. Therefore,
the technology independent strategies for
143
Li Z., Zhang H. and O’Brien L..
TOWARDS TECHNOLOGY INDEPENDENT STRATEGIES FOR SOA IMPLEMENTATIONS.
DOI: 10.5220/0003467801430154
In Proceedings of the 6th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2011), pages 143-154
ISBN: 978-989-8425-57-7
Copyright
c
2011 SCITEPRESS (Science and Technology Publications, Lda.)
implementing SOA should also be identified and
examined.
To achieve technology independent strategies of
SOA implementation, it would be necessary to
investigate every aspect of SOA system. In general,
“SOA is a concept for large distributed systems”
(Josuttis, 2007), which supposes services are
decentralized and may be under the control of
different owners. When unfolding research into
distributed systems, we can generally adopt two
different approaches (Fox, 1981): one is learning by
doing (building real distributed systems), while the
other is learning by analogy (drawing upon ideas
from other research areas). Considering the
limitations to empirically implementing various
SOA projects by ourselves, we have employed
learning by analogy with organization theory as an
efficient way to inspire the research into SOA
domain. In fact, the use of organizational theory to
guide technology research has proven significantly
beneficial particularly in the multi-agent system
community. For example:
Well-known human organizational structures
are used for the deployment of multi-agent
systems (Argente, Julian and Botti, 2006);
Social laws are chosen to simplify multi-agent
systems (Fitoussi and Tennenholtz, 2000);
Dependency theory of social interaction is used
to explain how to achieve social goals of
multi-agent systems (Sichman and Demazeau,
2001).
Therefore, this paper also presents an
organization-based view to comprehend SOA, and
treats SOA implementations as organizational
activities. Based on the traditional consensus of the
organization concept, thinking of SOA
organizationally could be reasonable. Moreover, the
parallels are identified between organization design
and SOA implementation in general, which follows
a pentagonal process with five steps focusing on the
Goal and Strategy, Environment and Scope,
Structure, Process and Coordination and Control.
Note that the “SOA implementation” we discuss
here refers to common SOA implementation
practices rather than any particular case. Enlightened
by existing work of organization design in the
organization theory domain, we have initially
identified four strategies as a demonstration to meet
four predetermined research topics of service-
oriented software engineering (Kontogiannis, Lewis
and Smith, 2008): (1) to use Total Quality
Management (TQM) to accommodate the Quality
Assurance challenge in the Engineering topic, (2) to
keep the structure as flat as possible meet the
Adoption challenge in the Operations topic, (3) to
take measurements at interim steps in process to
satisfy the Governance challenge in the Cross-
Cutting topic, and (4) to build business process
teams to facilitate mapping between business
structure and service-oriented environment in the
Business topic. These four strategies are independent
and each can improve SOA implementations
depending on real circumstances. In other words, the
strategies can be employed both individually and all
together for an SOA implementation instance.
Overall, this paper makes three contributions.
Firstly, new interdisciplinary research opportunities
are suggested between service-oriented computing
and organization theory. Secondly, the methodology
of investigating technology independent strategies
for SOA implementation is outlined. Thirdly, four
preliminary strategies enlightened by organization
design are identified within four predetermined
research topics of SOA.
The remainder of the paper is organized as
follows. Section 2 justifies thinking of SOA from an
organizational perspective. Section 3 analogizes the
procedure of SOA implementation with that of
organization design. Section 4 introduces four
technology independent strategies enlightened by
organization design for SOA implementation.
Section 5 uses an example to demonstrate how these
four strategies are applied to improve SOA
implementation. Conclusions are drawn and some
future work is proposed in Section 6.
2 SOA: AN ORGANIZATIONAL
PERSPECTIVE
Organizations emerged as early as ancient
civilizations appeared. Today, organizations have
become indispensable and pervasive components of
human beings’ society, for example, from schools to
hospitals and from armies to governments. When it
comes to the SOA area, we can similarly regard
service-oriented systems as virtual organizations that
are composed of services. There are two ways of
thinking of SOA from the organizational
perspective. One is to view an SOA system as an
organization; the other is to treat SOA system as a
mirror of its corresponding organization.
2.1 Viewing an SOA System as an
Organization
Viewing SOA systems as organizations is to use the
ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering
144
organization concept to cover SOA systems, as
shown in Figure 1. Under the same umbrella of
organization concept, both traditional organizations
and SOA systems consist of organizational units.
Organizational units in an SOA system are services,
while that in a traditional organization are
individuals. Furthermore, different organizational
units have different skills and play different roles in
an organization. For example, composite services
play integrative roles in an SOA system, which
parallels the responsibilities of managers in a
traditional organization. Unfortunately, there is no
single agreement on definition of an organization.
Fierce debates about the organization concept are
still underway, though theorists have traditionally
consented that organizations are collectivities of
people who are socially arranged to pursue specific
purposes and achieve explicit goals (McAuley,
Duberley and Johnson, 2007). This classical
consensus makes it possible to think of SOA from
the organizational perspective due to two reasons.
First, it is suitable to think of SOA representing
organization architecture. The Organization for the
Advancement of Structured Information Standards
(OASIS) (2006) defines SOA as “a paradigm for
organizing and utilizing distributed capabilities that
may be under the control of different ownership
domains. It provides a uniform means to offer,
discover, interact with and use capabilities to
produce desired effects consistent with measurable
preconditions and expectations.” When it comes to
implementation, SOA is used to build up a collection
of independent services that can be quickly and
easily integrated into different, high-level business
services and business processes to create business
value and achieve business strategies (Rosen et al.,
2008). To summarize, SOA both in theory and in
practice is proposed for organizing services to attain
some particular goals. Therefore, SOA can be set
under the umbrella of organization theory in terms
of the suggestion of traditional organization concept:
if the organizing process is about goal attainment,
the organization theory could be followed to
conceptualize, explain and ultimately guide
individuals’ activities that should be united together
to achieve desirable, common organizational goals
(McAuley et al., 2007).
On the other hand, it is reassuring to think of
SOA from the organizational perspective. In fact,
conceptual challenge might appear when talking of
organizations based on having a goal, because the
agreement about an organization’s purpose amongst
members may not exist. In the SOA area, however,
this disagreement issue can be ignored. Within SOA
systems, a service is a well-defined unit of
functionality realized by a service interface and a
service implementation (Papazoglou and Heuvel,
2007). A service interface identifies a service and
exposes the semantic description of the service’s
invocation. A service implementation realizes the
work that the service is designed to perform. Unlike
people in social organizations, services in SOA do
not have mental or psychological attributes.
Consequently, services will always obey the control
from the “senior management” of the whole SOA
system, and may even not be aware of the
“organizational goal”. When thinking about SOA
organizationally, the blind obedience characteristic
of services can naturally avoid the challenge of
defining organizations in terms of having a goal
while not all members freely agree to that goal
(Bakan, 2005).
Figure 1: View SOA system as an instance of
organization.
Moreover, according to a set of general
characteristics of the organizations identified by
Campbell and Craig (2005), we can find more
similar features between SOA system and
organization. For example:
Both human organization and SOA system
contain organizational units (people/services);
These organizational units perform different
roles/functionalities and their employment
depends on such performance;
Any human organization or SOA system has a
collective goal to which all units subscribe;
All of the roles/functionalities, taken together,
help the human organization / SOA system
achieve its collective goal;
Difference tasks are distributed to different
individual units according to their expertise,
Organization
SOA
System
Hospital
Government
Company
University
Other human
organizations
TOWARDS TECHNOLOGY INDEPENDENT STRATEGIES FOR SOA IMPLEMENTATIONS
145
interest or specialism (human) /
functional
capability and non-functional performance
(service)
;
There is a clearly defined hierarchy of authority
so that each member of the organization is
aware of where he or she ‘fits in’. / This
scenario depends on Orchestration or
Choreography when composing services in
SOA system;
The limits or borders of a human organization /
SOA system are usually clearly defined.
2.2 Treating an SOA System as a
Mirror of Real Organization
Unlike Conway’s Law (Conway, 1968), treating
SOA systems as copies of real organizations herein
implies that an SOA system reflects the features of
an organization for which the system is
implemented. Conway’s Law emphasizes the
organization who designs a system, which states that
“any organization that designs a system will
inevitably produce a design whose structure is a
copy of the organization's communication structure”
(Conway, 1968). However, here we emphasize the
organization for which a system is designed and
implemented. Figure 2 illustrates such a sample that
a departmentalized company and its SOA based
information infrastructure have the same functional
structures.
In fact, current information infrastructures for
organizations are normally realized by third-party
software companies, but the organizations
themselves are also closely involved in the activities
Figure 2: A Company and its infrastructural SOA system.
from requirements analyses to system
implementations. Considering the information
technology (IT) must be aligned with business when
establishing information infrastructure for an
organization, any SOA based information system
will inevitably copy the features of the organization
for which the SOA system is designed and built. For
example, services will be grouped functionally to
support different departments in a functional
structure based organization, while services should
be grouped separately according to different product
lines in an organization that employs product-based
structure; businesses with narrow span of control
will result in tall-hierarchy control flows among
services, while businesses adopting broad span of
control will bring flat-hierarchy control flows among
services.
Benefitting from thinking of SOA from the
organizational perspective, no matter treating SOA
system as a mirror of real organization or viewing
SOA system as an organization, we can use
organization concept to comprehend SOA systems,
and further use organization theory to inspire SOA
implementations.
3 ANALOGIES BETWEEN SOA
IMPLEMENTATION AND
ORGANIZATION DESIGN
The similarity between SOA systems and
organizations is not a coincidence. We can find
common ground on a pentagonal process of SOA
implementation (Josuttis, 2007; Krafzig, 2004;
Lawler and Howell-Barber, 2007; Rosen et al.,
2008) and organization design (Burton, DeSanctis
and Obel, 2006; Daft, 2009; Davis and Weckler
1996; Kates and Galbraith, 2007), which is
identified through refining the waterfall process of
organization design (Burton et al., 2006). In the
pentagonal process, five steps focusing on the Goal
and Strategy, Environment and Scope, Structure,
Process and Coordination and Control are executed
generally along the clockwise sequence arrowed in
Figure 3. Meanwhile, each step has influence on as
well as is under influence of the other four steps. For
example, the goal and strategy together determine
the whole process of organization design or SOA
implementation, while they will be refined gradually
as the process is unfolded.
CEO Office
Decision Making
Su
pp
ort Process
Financial Office
Financial
Mana
g
ement
Product Department
Product Line
Mana
g
ement
HR Department
HR
Mana
g
ement
Market Department
Market Analysis
Process
Other Departments
Other
Processes
ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering
146
Figure 3: The pentagonal process of SOA implementation
/ organization design.
3.1 Goal and Strategy
As mentioned previously, an organization must have
a collective goal according to the traditional
consensus of organization concept. Although
different parts of the organization may have their
own objectives, an overall collective goal can be
established by aggregating all the separated
objectives together. The overall goal is a desired
direction that the organization will head. In practice,
an organization’s overall goal embodies a set of
specified goals, each of which focuses on different
aspect of the organization. Daft (2009) distinguishes
organization’s goals into official goals and operative
goals. The official goals formally define the
business, values and outcomes that the organization
attempts to achieve, while the operative goals are
more explicit and scattered in different facets such
as performance, efficiency, innovation and profit.
Goals of an organization introduce the target that
the organization wants to pursue, while strategies
define how the organization can pursue its target.
Therefore, strategies can be treated as the
operationalization of organization’s goals (Burton et
al., 2006). Following the analysis of organization’s
goals, we can also distinguish organization’s
strategies into official strategies and operative
strategies. The official strategies are essential plans
of actions that can realize the corresponding official
goals, for example the cost-leadership strategy or
differentiation strategy. On the other hand, the
operative strategies will aim at different detailed
tasks like how to improve working efficiency or
increase product profits. As different tasks may have
resource conflict with each other, the strategy set
should be carefully balanced.
Goals and strategies are in the first phase of
organization design and essentially influence how an
organization should be designed. Similarly, the first
step of SOA implementation is to identify the
business strategies and goals, and we can adopt the
technique, namely business value chain, to help
identify the specific goals and strategies for certain
SOA projects (Rosen et al. 2008). Since service-
oriented computing emerged from the requirement
of addressing the rapid and usually unpredictable
changes that modern enterprises are confronting,
SOA systems contribute more promises than the
traditional software infrastructures. Therefore,
common goals and strategies can be extracted
among the general SOA implementations, which are
emphasized in Section 4.
3.2 Environment and Scope
The environment is the surroundings of a system,
and the system influences and is influenced by its
environment. Meanwhile, the environment is not
static but can be changing continuously and
dynamically. Generally, there are five environment
patterns interacting with any system, including
asymptotic variation, interfering variation, periodic
variation, phase-transition variation, and random
variation (Peng, Liu and Tao, 2009).
Both SOA systems and organizations cannot be
isolated from their external environments. The
environment surrounding an SOA system or
organization has a set of factors relating to resources
or vulnerabilities. For example, the suppliers,
customers, competitors, culture and government are
organizations’ environmental factors, while the
developers, users, legacy system, existing service
pool and state of current technology are SOA
systems’. Building organization and implementing
SOA are highly dependent on the environmental
factors. In practice, the number of factors that
constitute environment might be considerable. All
these factors together reflect the boundary that an
organization or SOA system, and then outline a
scope, which determines the capability,
applicability, competitive advantages and business
range for the organization or SOA system.
For organization design, environment restricts
organizations within certain scopes, and further
influences their processes, structures and controls.
For SOA implementation, analyzing the external
environment and determining the applicable scope
are particularly significant. SOA-based software
Coordin-
ation and
Control
Goal
and
Strategy
Environ-
ment and
Sco
p
e
Structure Process
TOWARDS TECHNOLOGY INDEPENDENT STRATEGIES FOR SOA IMPLEMENTATIONS
147
infrastructure is supposed to be adaptive within an
increasingly changing and complex environment.
However, the loosely coupled asynchronous SOA
systems are inherently more complex than the
traditional architecture based systems. Josuttis
(2007) has pointed out that distributed processing
would be inevitably more complicated than non-
distributed processing, and any form of loose
coupling increases complexity. In practice, building
a true heterogeneous SOA for a wide range of
operating environments may take years of
development time if the company does not have
sufficient SOA experience and expertise (Jamil,
2009). Since the more complexity involved in a
system, the more difficulty the designers or
engineers have to understand the implementation
process and thus the system itself (Cardoso, 2005),
SOA should be adopted only in the suitable
environment and only when its benefits outweigh
any extra costs due to the increased complexity.
3.3 Structure
Structures of both organizations and SOA systems
are established to divide up the work into
manageable and measureable units with clear
responsibility boundaries. Organization’s structure is
normally a hierarchy that allocates roles, power,
authorities and responsibilities, and determines
working relationships and communication channels.
Generally, organizational units are arranged around
functions, products/services, customers/geographies,
or business processes. Therefore, the organization
structures can be typically divided in five basic
styles: functional, product- or service-based,
customer- or geographical area based, business
process based, and matrix structure (Davis and
Weckler, 1996). Each kind of structure has specific
advantages and disadvantages. Unsuitable
organization structure will result in formidable
obstacle to align the other design elements with the
organization’s strategy (Kates and Galbraith, 2007).
Consequently, large organizations always build
hybrid structures to achieve the combination of the
advantages.
SOA systems normally adopt matrix structure,
which simultaneously groups services in two
directions: functional direction and business process
based direction, as shown in Figure 4. The
functional direction is to classify services according
to the type of logic they encapsulate. Although there
are quite a few service classifications we can
identify from literature, most of the existing
classifications can be unified and layered as Basic
Services, Business Entity Services, Process-centric
Services, and Enterprise Services. The Basic
Services, settled at the bottom layer of SOA
systems, provide reusable, technical, and
foundational functionalities. The Business Entity
Services represent the entities in business activities,
such as employee, customer, contract, and product.
Through composing relevant Business Entity
Services, a Process-centric Service encapsulates a
sequence of activities to complete a specific business
task. The Enterprise Services provide endpoints to
access the corresponding SOA systems, which could
have less reuse potential but enable cross-enterprise
integrations.
Figure 4: The matrix structure of SOA systems.
On the other hand, to obtain the reuse of services
in multiple business processes, the landscape of
different services within different business process
contexts should be described to show how the
services work together (Rosen et al., 2008). The
business process based direction of SOA systems’
structure can then be outlined. Along the business
process based direction, the overall services are
grouped according to different roles and
responsibilities within the real business. Each group
may contain single service or multiple services.
Moreover, the relationships to each other among the
groups and the places of these groups in the business
processes are also described.
3.4 Process
The organization design has been viewed from an
information processing perspective (Galbraith,
1974). The term process herein means not only
business processes that produce products or services
for customers, but also non-profit routines that
constitute organizational actions. Generally, a
… … …
… … …
Business
process
context n
Business
process
context 2
Business
process
context 1
Enterprise Services layer
Process-centric Services layer
Business Entity Services layer
Basic Services layer
ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering
148
process in an organization is a series of connected
activities that transfer and transform information and
resources through the organization (Kates and
Galbraith, 2007), for example approving an
application, submitting a report, and managing work
progress. From the mid-1990s, many modern
enterprises began to evolve into process-focused
organizations in order to achieve higher performance
and survive the market competition (Seltsikas,
2001). Currently, process-focused organization has
become the new organizational form with business
process as the core concern. As a result, the design
of processes significantly impacts on how well the
organizational goals can be achieved.
Moreover, processes in an organization have
close relationships with the organization’s structure
and coordination. All kinds of organization’s
structures inevitably create barriers to collaboration,
because boundaries will appear as soon as
organizational units are grouped under the structure.
To fulfil the effective collaboration targets in
organization, however, processes are required to
flow cross the boundaries. Therefore, processes can
glue the related organizational units to work
together.
Like process-focused organizations, SOA
systems can also be regarded as process-focused
systems comprising such as management process,
coordination process, and traditional work process.
Among all kinds of processes, SOA inherently
concentrates on business process. Essentially, SOA
is aligned with business process management (BPM)
in business firms in which the criticality of business
processes is concerned (Lawler and Howell-Barber,
2007). The emphasis of SOA is the functional
infrastructure and the business services instead of
the technical infrastructure and technical services. A
business service encapsulates a piece or an entity of
a business process. When implementing SOA, it is
crucial to analyze business processes before
identifying and developing services (Rosen et al.,
2008). Following the analysis of business process,
those potentially and even partially suitable services
should be identified first. These existing services
provide constraints that frame the future SOA
system. The business processes are then broken
down into business pieces that can be implemented
by developing new services.
3.5 Coordination and Control
The coordination problem is one of the central topics
in organizational studies (Heath and Staudenmayer,
2000). As mentioned previously, individual actions
of large numbers of interdependent roles and
specialists must be coordinated to constitute
processes to fulfill global tasks in an organization.
On the other hand, the coordination will increase
organizations’ information processing capabilities
when encountering increasing amount of uncertainty
(Galbraith, 1974). In practice, the activity of
coordinating overlaps the activity of controlling,
because the appearance of coordination usually
implies the occurrence of some control (Davis and
Weckler, 1996). To coordinate and control
organizational work, organizations should adopt
suitable techniques and mechanisms. Unfortunately,
there is not a fixed prescription of methods for
coordinating and controlling work. The coordination
and control, for example, can be simply related to
the structures (Kates and Galbraith, 2007), be
utilized by goal setting, hierarchy, and rules
(Galbraith, 1974), or be executed by using four basic
techniques: Supervision, Standardization, Building
employee commitment, and Teams (Davis and
Weckler, 1996). However, the principle of these
techniques and mechanisms is uniform: to make sure
organizational units work appropriately and find out
to what extent they are reaching the goals and
targets.
When implementing SOA, services must be
composed to fully realize the benefits of SOA
(Sarang, Jennings, Juric and Loganathan, 2007),
which also relies on the coordinating and controlling
activities. According to the cooperation fashions
among component services, the mechanism of
coordination and control can be distinguished
between Orchestration and Choreography.
Orchestration describes and executes a centralized
process flow that normally acts as an intermediary to
the involved services. Choreography describes
multi-party collaboration and focuses on the peer-to-
peer message exchange.
If comparing Orchestration and Choreography
with the two classical organization types –
Mechanical and Organic organizations, we can find
that the fundamental ideas and notions behind these
different concepts in two disciplines are nearly the
same. In particular, we can even explain
Orchestration and Choreography by using the
descriptions of those two types of organizations
4 TECHNOLOGY INDEPENDENT
STRATEGIES FOR SOA
IMPLEMENTATION
When it comes to information system architecture,
TOWARDS TECHNOLOGY INDEPENDENT STRATEGIES FOR SOA IMPLEMENTATIONS
149
service-orientation establishes a universal model in
which functionalities and business logics are cleanly
partitioned and consistently represented. Therefore,
in addition to the various targets that satisfy the
business requirements of respective SOA projects,
SOA implementation possesses general promises
and goals. The motivations and expectations of the
people who are engaged in SOA activities can be
used to empirically and efficiently assess the
universal goals of SOA. With reference to the survey
in 2006 conducted by the Cutter Consortium (Rosen
et al., 2008), we can identify the most common and
general goals of SOA are agility, flexibility, reuse,
data rationalization, integration, and reduced costs.
In fact, plenty of technical strategies have been
developed to help realize SOA’s goals. Examples of
technology based strategies are standard service
contract that facilitates integration, loosely coupling
that supports flexibility, and service autonomy that
provides reliable and predictable performance. As
supplementary, here we focus on the technology
independent strategies of SOA implementation that
are inspired by existing research into organization
design. Following four research topics of service-
oriented software engineering (Kontogiannis et al.,
2008), we have initially identified four strategies
respectively (S1~S4).
4.1 S1: Applying TQM to SOA
Implementation
Under the Engineering research topic of service-
oriented computing, we propose to use Total Quality
Management (TQM) to accommodate to the quality
assurance of SOA implementation. Just as the name
implies, TQM is a holistic level management for
quality, because it can be achieved only if the total
quality concept is utilized from the acquisition of
resources to the customer satisfaction (Kaynak,
2003). When it comes to SOA, the quality
management has been emphasized to satisfy the
unique characteristics of service-oriented computing.
Nevertheless, to the best of our knowledge, existing
research into quality management in SOA area is
mainly at the service level, which is limited around
the Quality of Service (QoS). The overall QoS of an
SOA system is determined by all the QoS of
component services who compose the SOA system
(Yau, Ye, Sarjoughian and Huang, 2008). Based on
the QoS management, SOA systems generally
replace component services with higher quality
services to realize adaptations. Hence, the focus of
QoS management is on individual services in an
SOA environment.
When applying TQM to SOA domain, Deming’s
14 points (Walton, 1988) can be used as a
framework to guide SOA implementations. For
example, service suppliers and SOA system users
should be taken into account when measuring the
total quality of an SOA implementation. Here we
focus on the quality of interaction and cooperation
process among services. With reference to the
explanation of TQM by Deming, in any
circumstance, processes should be constantly
analyzed to determine what changes can be made to
bring improvement. Therefore, TQM introduces a
new angle of view to SOA systems when adapting
environment. However, employing TQM does not
indicate abandoning QoS management. There is no
conflict between TQM and QoS management. On
the contrary, they are two complementary
approaches for SOA to accommodate the changing
environment: (1) TQM can be used to adjust the
process of interaction and cooperation among
services. (2) QoS management can be used to switch
services based on the latest quality requirement.
4.2 S2: Flattening the Structure of
SOA Systems
Under the Operations research topic of service-
oriented computing, we propose to flatten the
structure of SOA systems when considering service
composition. In human organizations, every level in
a hierarchy will inevitably involve more operating
costs (George and Jones, 2007). An organization
with a higher hierarchy may come with longer
decision making chains and slower responsiveness
to customers. Therefore, organizations can increase
efficiency by keeping their structures as flat as
possible. Furthermore, flat structure can decentralize
responsibility and control to lower-level employees
to take greater advantage of the skills and experience
of organization members.
In an SOA system’s hierarchy, the number of
levels can increase along with the growing cascade
of service composition. In general, a composite
service is recursively defined as an aggregation of
elementary and composite services. When thinking
of SOA from the organizational perspective,
composite services play integrative roles in an SOA
system. In organizations, an integrative role is a full-
time manager who is in charge of orchestrating work
across units (Kates and Galbraith, 2007). These
managers have accountability for results but are not
directly responsible for the resource achieving and
specific work that should be accomplished by staff.
A flat organizational structure can help reduce the
ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering
150
number of integrative roles. The similar scenario of
SOA implementation can be simply illustrated in
Figure 5.
(a) Tall structure with composite service playing integrative role.
(b) Flattened structure
Figure 5: Tall structure vs. flat structure for implementing
the same business process.
Figure 5(a) shows a tall structure example of
some business process implementation by inserting
two composite services that respectively compose
two of the elementary services. Suppose only the
three elementary services are available at the
bottom, we can flatten the structure and move the
additional functionality of original composite
services upward, as shown in Figure 5(b), to reduce
the composition cost and lower the complexity of
the business process implementation. However, we
should keep the tall structure if the composite
service already exists or its reusability is to be
achieved. Therefore, when applying this strategy, the
value and cost should be well balanced to determine
the extent of flattening structure.
4.3 S3: Taking Measurements at
Interim Steps in Process
Under the Cross-Cutting research topic of service-
oriented computing, we propose to take
measurements at interim steps in process to govern
SOA implementation. When generating products
following certain working processes or designing the
working processes in an organization, it has been
proven valuable to take measurements at interim
steps in processes. The research and practice in
organizations during the past decades reveal that it is
increasingly important to ensure the work finishes
properly the first time instead of having to be redone
(Davis and Weckler, 1996). The inspections and
measurements can be applied to different steps in
processes to save the cost of rework and avoid flaws
in the end product.
When applying this strategy to SOA
implementation, the inspiration is to confirm the
individual work of each service in processes. The
idea behind this strategy is to clearly define
connected subtasks in a process, and specify and
measure the result of each subtask. It should be
noted that measuring interim task mainly concerns
the result rather than how the task is performed.
Considering a service is such an entity that performs
some task while hiding technical details, we can use
the interim task measurement to help identify the
most suitable services. Once all the services are
determined, the relevant business process can then
be correctly implemented.
4.4 S4: Building Virtual Business
Process Teams
Under the Business research topic of service-
oriented computing, we propose to build business
process teams to facilitate mapping between
business structure and service-oriented environment.
In human organizations, teams are cross-functional
structures that bring people outside the scope of
traditional departments to work together and share
collective responsibility for special and complex
assignments. A business process team is established
around one business process and includes people
who can collectively perform all the major activities
to carry out the business process from beginning to
end. Business process teams exist as a characteristic
of “horizontal organizations” (Davis and Weckler,
1996). Horizontal organizations instinctively tend to
flatten their structures by focusing on all the units
involved in completing certain work, rather than the
coordinate activities relying on a vertical hierarchy.
As analyzed in Section 4.1, horizontally established
business process teams then have advantages of
reduced management costs and less need for
coordination.
Building business process teams in an SOA
system should be a virtual division without many
real actions. All the services involved in a business
process logically constitute a team without changing
the existing structure of the SOA system. Through
virtual business process teams, the focus of
coordination and control can be balanced between
Service 1
Service
2
Service
3
Comp-
osite
Service
Business Process
Comp-
osite
Service
Service
1
Service
2
Service
3
Business Process
TOWARDS TECHNOLOGY INDEPENDENT STRATEGIES FOR SOA IMPLEMENTATIONS
151
inward IT and outward business during SOA
implementations. Furthermore, considering one
service can be involved in different business process
teams like the same scenario of organizational
teams, we can identify and scale services’
dependency of business processes in an SOA
system. The more dependency a service has, the
more carefully it should be controlled especially
when planning to modify or adapt this service.
5 AN EXAMPLE CASE
Here we use a simplified case to demonstrate how
the technology independent strategies can be applied
to improve an SOA implementation. The example
case is an SOA-based application in a travel agency,
as illustrated in Figure 6.
Figure 6: An SOA-based application of hotel booking in a
travel agency.
The travel agency books hotel through BPay on
behalf of a group of tourists, and will rent a car by
money transfer if the number of the tourists is more
than ten. Suppose there are three online banking
services, two hotel booking services and one car
rental service. Each service can fulfill its
corresponding business function, while Online
Banking Service B1 and Hotel Booking Service H1
are selected according to their reliability and
response time. Moreover, the business rule “rent a
car by money transfer if the number of the tourists is
more than ten” is encapsulated in a composite
service composed by Hotel Booking Service H1 and
Car Renting Service. The composite service is
implemented as a Reinforced Hotel Booking Service
following the technology based strategy of using
service composition to “fulfill a large extent of
future business automation requirements” (Erl,
2007). After applying the four proposed strategies,
this travel agency application will evolve as shown
in Figure 7.
5.1 Applying TQM (S1)
After a period of operation, the travel agency
receives many complaints from small groups of
tourists about inconvenience without cars. Hence,
the travel agency decides to change the business rule
into “rent a car by money transfer if the number of
the tourists is more than five”. When applying TQM
to the SOA system to check the cooperation among
services, we can find that the invocation of Car
Rental Service is inflexible because old business rule
is hardcoded in the Reinforced Hotel Booking
Service. Therefore, the number of tourists should be
set as a variable and exposed as an input parameter
of the composite service. The operation of this
composite service is then adjusted by accepting one
threshold parameter to improve the flexibility of the
SOA system.
5.2 Flattening the Structure (S2)
When analyzing the structure of the travel agency’s
SOA system, we find that the Reinforced Hotel
Booking Service does not have any reuse
opportunity. Furthermore, the encapsulated business
rule can be easily transformed into control flow
logic of invoking two component services, and
moving the control flow logic into upper business
logic will have little increase complexity for the
latter. Therefore, we can flatten the structure as
Figure 5(b) by removing the Reinforced Hotel
Booking Service to reduce the service maintenance
effort.
5.3 Measuring Interim Steps in Process
(S3)
Suppose both BPay and money transfer will result in
commission charges, and the charges vary
depending on different bank and transaction time.
We can then use the criterion “choose bank with the
lowest commission charges” to constantly and
simultaneously measure the three candidate online
banking services. The service of the bank that
charges the lowest fee will be dynamically employed
by the SOA system to help the travel agency save
money.
Reinforced
Hotel
Booking
Service
Travel Agency Application
Hotel
Booking
Service H1
Car Rental
Service
Online
Banking
Service B1
ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering
152
5.4 Building Virtual Teams (S4)
Based on the business logic behind the travel agency
application, we can identify there are two atomic
business processes: one is hotel booking through
BPay, and another is car rental through money
transfer. Consequently, the selected Online Banking
Service, Hotel Booking Service and Car Rental
Service can be logically grouped into two business
process teams. The coordination and control among
services in the hotel booking business process team
follows the BPay rules, while in the car rental
business process team obeys the money transfer
rules. Through the team building, we can naturally
arrange different cooperation for services in
different teams, and in this case we may further
identify the Online Banking Service is the key
service when implementing the SOA system.
Figure 7: The travel agency application after applying four
proposed strategies.
6 CONCLUSIONS
The emergence of SOA has been considered a
feasible opportunity for modern enterprises to
leverage the capabilities of quickly adapting to
competitive and changing environment. Compared
with systems based on traditional architecture,
however, SOA systems are inherently more
complicated. Since the more complexity involved in
a system, the more difficulty the designers or
engineers have to understand the implementation
process and thus the system itself (Cardoso, 2005), it
is vital to find a set of implementation strategies to
help achieve the promises of SOA. Based on the
review of the relevant literature, we can identify a
suite of technical strategies based on the current
state of the art of Web technology. For example, to
hide the technical details to abstract services, to
standardize the contract of communication between
services, to decouple the logic as well as the
implementation of services, and to use service bus to
facilitate service integration. Whereas, technology
based strategies cannot guarantee the success of
SOA implementations (Rosen et al., 2008). We
therefore notice that the technology independent
strategies should also be emphasized as the
supplements in implementing SOA.
By presenting an organization-based view to
comprehend SOA, and treating SOA
implementations as organizational activities, this
paper delivers three main contributions. First,
interdisciplinary research opportunities are
suggested across SOA area and organization theory
area. Second, the methodology of investigating
strategies for implementing SOA is proposed by
analogizing organization design with SOA
implementation. Last, benefiting from existing work
of organization design in the organization theory
domain, four preliminary strategies conforming to
the general goals of SOA are identified and
suggested at this stage.
The four technology independent strategies
highlighted in this paper can be applied to different
steps in the process of organizational design. When
applying them in an SOA environment, one
simplified example case is elaborated to show their
applicability for SOA implementations. However,
their value and effectiveness still need to be further
investigated and evaluated in practice. Therefore, the
future work of this research is to explore other
technology independent strategies for SOA
implementation, as well as to apply these strategies
in real scenarios and report the empirical results.
REFERENCES
Moore, R., Lopes, J., (1999. Paper templates. In
TEMPLATE’06, 1st International Conference on
Template Production. SciTePress.
Smith, J., 1998. The book, The publishing company.
London, 2
nd
edition.
Argente, E., Julian, V. and Botti, V. (2006). Multi-agent
system development based on organizations.
Electronic Notes in Theoretical Computer Science,
150(3), 55-71.
Bakan, J. (2005). The Corporation: The Pathological
Pursuit of Profit and Power. New York: Free Press.
Burton, R. M., DeSanctis, G. and Obel, B. (2006).
Organizational Design: A Step-by-Step Approach.
Cambridge, UK: Cambridge University Press.
Selected
Online
Banking
Service
Travel Agency Application
Hotel
Booking
Service H1
Car Rental
Service
Online
Banking
Service B2
Online
Banking
Service B1
Online
Banking
Service B3
Hotel Booking
Tea
m
Ca
r
Rental
Measure and Replace
TOWARDS TECHNOLOGY INDEPENDENT STRATEGIES FOR SOA IMPLEMENTATIONS
153
Campbell, D. and Craig, T. (2005). Organisations and the
Business Environment (2nd ed.). Burlington, MA:
Butter-worth-Heinemann.
Cardoso, J. (2005). How to measure the control-flow
complexity of Web processes and work-flows.
Workflow Handbook 2005 (pp. 199-212). Layna
Fischer.
Conway, M. E. (1968). How do committees invent?
Datamation, 14(4), 28-31.
Daft, R. L. (2009). Organization Theory and Design (10th
ed.). Mason, OH: South-Western College Pub.
Davis, M. R. and Weckler, D. A. (1996). A Practical
Guide to Organization Design. Menlo Park,
California: Crisp Publications, Inc..
Erl, T. (2007). SOA Principles of Service Design. Boston,
MA: Prentice Hall PTR.
Erl, T. (2009). SOA Design Patterns. Boston, MA:
Prentice Hall PTR.
Fitoussi, D. and Tennenholtz, M. (2000). Choosing social
laws for multi-agent systems: Minimality and
simplicity. Artificial Intelligence, 119(1-2), 61-101.
Fox, M. S. (1981). An organizational view of distributed
systems. IEEE Transactions on Systems, Man, and
Cybernetics, SMC-11(1), 70–80.
Galbraith, J. R. (1974). Organization design: An
information processing view. Interfaces, 4(3), 28-36.
George, J. and Jones, G. (2007). Understanding and
Managing Organizational Behavior (5th ed.). Boston,
MA: Prentice Hall.
Heath, C. and Staudenmayer, N. (2000). Coordination
neglect: How lay theories of organizing complicate
coordination in organizations. Research in
Organizational Behaviour, 22, 153-191.
Jamil, E. (2009). SOA in asynchronous many-to-one
heterogeneous bi-directional data synchronization for
mission critical applications. WeDoWebSphere.
Retrieved January 14, 2011 from
http://wedowebsphere.de/node/30604
Josuttis, N. M. (2007). SOA in Practice: The Art of
Distributed System Design. Sebastopol: O'Reilly
Media, Inc..
Kates, A. and Galbraith, J. R. (2007). Designing Your
Organization: Using the STAR Model to Solve 5
Critical Design Challenges. San Francisco, CA:
Jossey-Bass.
Kaynak, H. (2003). The relationship between total quality
management practices and their effects on firm
performance. Journal of Operations Management,
21(4), 405-435.
Kontogiannis, K., Lewis, G. A. and Smith, D. B. (2008). A
research agenda for service-oriented architecture. In
SDSOA’08, 2nd International Workshop on Systems
Development in SOA Environments (pp. 1-6). ACM
Press.
Krafzig, D., Banke, K. and Slama, D. (2004). Enterprise
SOA: Service-Oriented Architecture Best Practices.
Upper Saddle River, NJ: Prentice Hall.
Lawler, J. P. and Howell-Barber, H. (2007). Service-
Oriented Architecture: SOA Strategy, Methodology,
and Technology. Boca Raton, FL: Auerbach
Publications.
McAuley, J., Duberley, J. and Johnson, P. (2007).
Organization Theory: Challenges and Perspectives
(1st ed.). England: Prentice Hall.
Newcomer, E. and Lomow, G. (2004). Understanding
SOA with Web Services. Upper Saddle River, NJ:
Addison-Wesley Professional.
OASIS. (2006). A reference model for service-oriented
architecture. White Paper. Billerica, MA.
Papazoglou, M. P. and Heuvel, W. -J. (2007). Service
oriented architectures: Approaches, technologies and
research issues. The VLDB Journal, 16(3), 389-415.
Peng, Y., Liu, H. and Tao, H. (2009). Analyzing the
pathway of organizational change based on the
environmental complexity. In ECBI ’09, 2009
International Conference on Electronic Commerce
and Business Intelligence (pp. 463-466). IEEE
Computer Society.
Rosen, M., Lublinsky, B., Smith, K. T. and Balcer, M. J.
(2008). Applied SOA: Service-Oriented Architecture
and Design Strategies. Indianapolis, Indiana: Wiley.
Sarang, P., Jennings, F., Juric, M. and Loganathan, R.
(2007). SOA Approach to Integration: XML, Web
Services, ESB, and BPEL in Real-World SOA
Projects. Birmingham: Packt Publishing.
Seltsikas, P. (2001). Organizing the information
management process in process-based organizations.
In HICSS 34, 34th Hawaii International Conference
on System Sciences (pp. 8066), IEEE Computer
Society.
Sichman, J. and Demazeau, Y. (2001). On social
reasoning in multi-agent systems. Revista Ibero-
Americana de Inteligncia Artificial, 13, 68-84.
Walton, M. (1988). The Deming Management Method.
New York, NY: Perigee Books.
Yau, S. S., Ye, N., Sarjoughian, H. and Huang, D. (2008).
Developing service-based software systems with QoS
monitoring and adaptation. In FTDCS 2008, 12th
IEEE International Workshop on Future Trends of
Distributed Computing Systems (pp. 74-80), IEEE
Computer Society.
ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering
154