Proceedings of the 39th Hawaii International Conference on System Sciences - 2006

A Case Study in SOA and Re-Architecture at Company ABC

Wong-Bushby, I.
NJIT
iw2@njit.edu

Egan, R.
NJIT
egan@njit.edu

Abstract
Following September 11 2001, company ABC
zeroed in on a home-grown fat client system, System
E, as the enterprise
data warehouse for risk
management. It became mission critical for System E to
remove key person dependencies and migrate from
C++, a niche technology, to a more accessible
platform. Under the leadership of a new hire, System E
adopted an Service Oriented Architecture (SOA)
approach to re-architecture. As company ABCs IT
unit is under a flat headcount constraint, an
incremental SOA approach was the only way to get
upper management approval. A pilot is well underway
and scheduled to complete in December 2005. This
paper presents the current/target architectures of
System E, a theoretical framework for SOA, the
Unified Modeling Language class diagram for SOA
Model at ABC, and concludes with lessons learned
from the pilot to date. Key contributions of the paper
include SOA Model at ABC, and lessons learned
regarding enterprise architecture initiatives.

1. Introduction
Following the aftermath of September 11 2001,
company ABC zeroed in on a home-grown C++ fat
client system, System E, as the enterprise data
warehouse for risk management. Following Categories
of Strategic Relevance and Impact (Applegate,
McFarlan and McKenny, 2002), System E was
identified by upper management as strategic1, critical
to the survival of the organization. As such, it became
mission critical for System E to migrate from C++, a
niche technology within the company, to a more

Isaacson, C.
Rogue Wave
cory.isaacson@
Quovadx.com

accessible platform such as Java. This will remove key

person dependencies which is no longer acceptable in
System E. Consequently, led by a new hire, System E
embarked on a re-architecture (and technology refresh)
project.
At a high level, the re-architecture strategy is to decouple business logic from the fat client and move the
business logic into (Java) services (see section 3.1 for
definition of services), with the services designed to
Service Oriented Architecture (SOA) principles. After
de-coupling, the C++ fat client would essentially be a
thin client and can quickly be replaced by a Browser
front end. As each fat client screen is de-coupled, the
new service(s) will be integrated into and accessible
under an umbrella service, System Es Enterprise
Service, which is capable of supporting business
processes.
An SOA approach to re-architecture is the linchpin
that gained upper IT management approval. As SOA
can be developed incrementally (i.e., one service at a
time), the fat client can be converted one screen at a
time. As company ABCs IT unit is under a flat
headcount constraint, an SOA approach, being
incremental and low-risk, was the only way to get
upper management approval.
As of this writing, a pilot is well underway,
scheduled to complete in December 2005. This paper
begins with the current and target architectures for
System E (section 2); followed by a theoretical
framework for SOA (section 4) which lays the
foundation for SOA Model at ABC (section 5). The
paper concludes with benchmark results (section 6) and
lessons learned (section 7) from the pilot to date.

2. Current and target architectures

2.1. Current architecture

The Categories of Strategic Relevance and Impact consists

of four quadrants: factory, strategic, support and turnaround.
The two dimensions are strategic impact of existing IT
systems and strategic impact of IT applications under
development. Firms with strategic IT applications rely on
IT development to maintain competitive advantage.

Figure 1 illustrates System Es current architecture

using a Unified Modeling Language (UML)
Deployment Diagram (Fowler and Scott, 2003). The
online system is deployed in a three-tier model: the
C++ fat client runs on a Windows workstation; the C

0-7695-2507-5/06/$20.00 (C) 2006 IEEE

Proceedings of the 39th Hawaii International Conference on System Sciences - 2006

message-driven component runs on a Unix application

server; and the database system runs on a Unix server.
Currently, the client accesses the database via both MQ
connections as well as SQL connections. The messagedriven component evolved out of ad-hoc business
needs to provide customer reference information,
stored in System Es database, to downstream
transaction processing systems (TPS). The reference
information is retrieved one piece at a time, reflecting
the evolutionary nature of the message-driven
component.

application server; and the database system remains as

is. (The Browser thin client and web application
replace the C++ fat client; while the SOA compliant
component replaces the C message-driven component.)
In the target, the client is fully de-coupled from the
database. Accesses to the database is via the SOA
component only. Compliant with SOA principles (see
section 3), the SOA component is modeled after
business processes.

Figure 3 Target architecture

Figure 1 Current architecture
Figure 2 illustrates a UML Use Case (Fowler et al.)
for new customer rating. Currently, to rate a new
customer, a TPS needs to make multiple calls to
System Es message-driven component. The first call
retrieves a System E key which is used to retrieve
(customer) reference information A and B. Each piece
of information requires one call. In sum, three calls are
made to rate a new customer under the current
architecture.

Figure 4 illustrates a use case for new customer

rating in the target architecture. To rate a new
customer, a TPS makes one call to System Es
Enterprise Service, which provides a single API for its
message-driven component. Behind the scenes, System
Es Enterprise Service translates the external key to an
internal key, uses it on behalf of the TPS to retrieve
reference information A and B, combines the results,
and returns the information in one response. In sum,
only one call is made (versus three) to rate a new
customer under the target architecture.

Figure 4 Rate new customer (target)

Figure 2 Rate new customer (current)

2.2. Target architecture

Figure 3 illustrates System Es target architecture.
While System E remains three-tiered, the system now
has: a Browser thin client running on a Windows
workstation; a web application and an SOA compliant
component, both in Java, which run on a Unix

3. Theoretical framework
3.1.

Service oriented architecture (SOA)

A Service Oriented Architecture (SOA) is a

distributed system architecture consisting of a

Proceedings of the 39th Hawaii International Conference on System Sciences - 2006

collection of services. A service encapsulates a

reusable business function, loosely-coupled to other
services, and is invoked through connection
technologies (Keen, Acharya, Bishop, Hopkins,
Milinski, Nott, Robinson, Adams and Verschueren,
2004). While Web services represent the most likely
connection technology for services, earlier SOAs used
technologies such as Distributed Component Object
Model (DCOM) or Common Object Request Broker
Architecture (CORBA).
According to the W3C (2004), an SOA-compliant
architecture has properties described in Table 1.

Logical View

Message
Orientation

Description
Orientation
Granularity

Platform
Neutrality

3.2.

Table 1 SOA properties

Each service represents a logical view
defined in terms of a business-level
operation (e.g. new customer rating).
Each service can be described in
terms of messages exchanged between
provider and requester agents. In other
words, a service is initiated on a
requester message and, if there is a
response, terminated with a reply
message.
Each service is documented by
machine-readable meta data (e.g. Web
Service Definition Language WSDL).
Services should be relatively large or
coarse-grained, in support of a
business process.
Messages are sent in a platformneutral format (e.g. Extended Markup
Language XML).

Web services

While SOA and Web services appear synonymous

today, historically SOA has been implemented using
any connection technologies such as DCOM, CORBA
or Web services. There is no requirement that SOA
must be implemented using Web services. In fact, a
Web service does not necessarily mean that it is SOA,
particularly if it is not designed to support a businessoriented logical view. According to the W3C (2004), a
Web service is a software system designed to support
interoperable machine-to-machine interaction over a
network (p. 7). Additionally, a Web service should
have the properties described in Table 2 (Cerami,
2002).

3.3.

SOA and Web services

While Web services (over HTTP) seem to be taking

the world by storm, the W3C (2004) cautions its

implementation as still immature (p. 62). Isaacson

(2004) echoed the same concern at one of his sessions
during a recent Advisor Live Conference. At the core
of Web services (over HTTP) is a technology stack
that includes SOAP/XML and HTTP. Consider an
enterprise system consisting of legacy mainframe
systems behind a firewall: SOAP and XML adds a
layer of string parsing that is processing-intensive; and
HTTP adds a transport layer which may be already
well-served by IBM MQ Series. Within this context,
Web services (over HTTP) may not be the best choice
for implementing SOA since there is no requirement
for multiple platforms to justify the costs in
performance associated with SOAP/XML and HTTP.
Rather, a fixed record format with delimiter characters
may be used to simulate an XML functionality where
optional data are omitted. Using fixed record formats
(with delimiters) and IBM MQ Series, an enterprise
system of legacy applications can still be SOAcompliant without incurring unnecessary performance
overhead. Hence, as long as the architecture of a
distributed system satisfies the properties of logical
view, message orientation, description orientation,
granularity, and platform neutrality (in the sense of
record interfaces), it is SOA-compliant. This is the
perspective of the SOA model presented in section 5.
Table 2 Web services properties
Message
The WSDL format (versus text files,
description
for example) is used to describe its
message formats, datatypes, transport
protocols and transport serialization
formats, etc.
Message
SOAP (Simple Object Access
format
Protocol
or
Service
Oriented
Architecture Protocol) is used as the
message format (versus fixed record
structures, for example).
Transport
HTTP (versus FTP, for example) is
layer
used as the transport layer.
Serialization
XML (versus other serialization
format
schema) is used as the transport
serialization format.
Discovery
Web services are discovered using a
method
Registry (versus private, unpublished
URIs, for example).
Security
Web services have sophisticated
security
mechanisms
including
confidentiality,
authentication,
authorization, non-repudiation, audit
trails, etc.

4. SOA Model at ABC

Proceedings of the 39th Hawaii International Conference on System Sciences - 2006

4.1.

Architecture models

According to Somerville (2002), architectural

design is the process of establishing a basic component
framework and the communications between these
components. There are various types of architecture
models. One type of architecture model encapsulates
best practices from real world systems. The main
benefit of defining any architecture model is that it can
be reused, generating savings by shortening the design
phase of similar application development.
The SOA model (i.e., SOA Model at ABC) in the
rest of the paper is an architecture model abstracted
from a real world system. It is applicable to rating
engines in Property and Casualty applications. These
applications typically rely on purchased reference data
for rating/renewing insured entities. Specifically at
company ABC, an ad-hoc collection of services has
evolved over time to make available purchased data to
downstream transaction processing booking systems.
As each purchased data set is acquired, it is stored in
one reference database table. There is a correspondence
of one service to one database table.
The rest of this section is in four parts. Section 4.2
describes the current architecture of the C services
which evolved out of ad-hoc business needs (i.e., Adhoc Services Model). Section 4.3 illustrates how an
SOA generic architecture model (i.e., SOA Model at
ABC) can be applied over Ad-hoc Services Model
creating an Enterprise Service. The section concludes
with a discussion of the functionality (section 4.4),
reliability (section 4.5) and performance (section 4.6)
of the SOA Model at ABC.

4.2.

Ad-hoc Services Model

Figure 5 illustrates a UML Collaboration Diagram

(Fowler and Scott, 2003) for one of the ad-hoc
services, say Service A. Service A follows System Es
Ad-hoc Services Model, an inheritance2 application
framework (Fayad and Schmidt, 1997), of four classes:
a listener class (ListenerA) which implements an MQ
interface for receiving and sending messages, a request
class (RequestA) which encapsulates methods3 and
attributes4 for the request, a transformation class
2

Inheritance is an Object-Oriented terminology that

refers to a type of relationship between two classes (i.e.
programs). A child class that inherits from a parent
class receives the parents methods and attributes by
default.
3
Method is an Object-Oriented terminology that is
similar to a program procedure/function.
4
Attribute is an Object-Oriented terminology that is
similar to a program variable.

(TransformA) which services the request by retrieving

information from the database, and a reply class
(ReplyA) which encapsulates methods and attributes
for the reply. Using GetCustRefA from Figure 2 as an
example, Figure 5 illustrates that upon receipt of
GetCustRefA
message
from a
TPS
(i.e.,
1GetCustRefA), ListenerA stores the request in
RequestA by invoking its method setBytes (i.e., 2
setBytes). It then passes RequestA and a new copy of
ReplyA to TransformA by invoking its method
process (i.e., 3 process). When TransformA finishes,
ListenerA returns the result which is stored in ReplyA
by invoking its method getBytes (i.e., 4 getBytes).
The same inheritance application framework in
Figure 5 is repeated for each ad-hoc service. Using
GetCustRefB from Figure 2 as another example,
GetCustRefB will be received by ListenerB, which in
turn stores the request in RequestB, services the request
by using TransformB, and captures the result in
ReplyB.
Within this current architecture, company ABC has
approximately two dozen ad-hoc services, supported by
approximately two dozen MQ queues.

4.3.

SOA Model at ABC

One of the main limitations of Ad-hoc Services

Model is the requirement for multiple MQ calls to
complete a business process (e.g. Rate New Customer
takes 3 calls). With multiple MQ calls, reliability and
performance are impacted in the event an (MQ) ad-hoc
service fails or takes longer to run. The more (MQ) adhoc services there are, the higher the probability of
poor response or failure to the consumer. Driven by
System Es re-architecture initiative (see section 1),
addressing these non-functional issues became a matter
of priority because a reliable and high-performance
SOA component is critical to accomplishing the
migration of the C++ fat client to a thin client platform.
To address the limitations of Ad-hoc Services
Model, SOA Model at ABC (see Figure 6) was
developed. SOA Model at ABC results in an Enterprise
Service that satisfies three requirements: a) improved
functionality providing a single Enterprise Service
Application Programming Interface (API) in support of
business processes, b) improved reliability providing
99% availability 24 X 7, and c) improved performance
providing consistent peak-hour throughput.
Figure 6 illustrates SOA Model at ABC. It follows
the same inheritance application framework of four
classes as Ad-hoc Services Model: a listener class
(ListenerES), a request class (RequestES), a
transformation class (TransformES), and a reply class
(ReplyES). Figure 6 shows that upon receipt of a
business process such as Rate New Customer (i.e., 1

Proceedings of the 39th Hawaii International Conference on System Sciences - 2006

RateNewCustomer), ListenerES stores the request in

RequestES (i.e., 2 setBytes). It then passes RequestES
and a new copy of ReplyES to TransformES (i.e., 3
process). When TransformES is finished, ListenerES
returns the result which is stored in ReplyES to the
transaction processing system (i.e., 4 getBytes).
The major difference between SOA Model at ABC
(Figure 6) and Ad-hoc Services Model (Figure 5) is the
SOA Interface (versus the MQ Interface). The SOA
interface is capable of receiving System Es canonical
(i.e., basic) request message which is defined as the
union of ad-hoc service requests. In addition, the SOA
Interface is capable of translating a business process
request (e.g. Rate New Customer) into a service
request list which can be used by a business process5.
Finally, the SOA interface returns System Es
canonical reply message which is defined as the union
of ad-hoc service replies. (Note: Canonical data
modeling is underway at company ABC and is outside
the scope of this paper. Ultimately, the canonical
request and reply messages will be modeled into a
canonical data structure representing an enterprise view
of System Es data structure in Extended Markup
Language format.)
Specifically, SOA Model at ABC is a middleware
integration framework6 (Fayad and Schmidt, 1997)
built on top of the Ad-hoc Services Model. Figure 7
illustrates the UML Class Diagram (Fowler et al.,
2003) for SOA Model at ABC. A major contribution
of SOA Model at ABC is software reuse. According to
Fayad et al., software reuse has the important benefit of
eliminating re-creation and re-testing of common
software. Conceptually, RequestES cobbles together
RequestA, RequestB, etc.using the Adaptor pattern7
(Gamma, Helm, Johnson and Vlissdes, 1994);
TransformES
cobbles
together
TransformA,
TransformB, etc.using the Mediator pattern8 (Gamma
et al), and ReplyES cobbles together ReplyA, ReplyB,
etc. using the Composite pattern9 (Gamma et al). The
Mediator pattern in TransformES encapsulates the
5

The translation from business process to a service list has

not been implemented. Current implementation requires the
caller to include the list of services to accomplish a business
process. As usage patterns become established, a business
process to service list translation table can be implmented
very easily.

Fayad and Scmidt refers to three types of application

frameworks: system infrastructure framework,
middleware integration framework and enterprise
application framework.
7
Adapter enables classes to work together that couldnt
because of incompatible input/output interfaces.
8
Mediator enables classes to interact differently in a
loosely coupled manner.
9
Composite implements whole-part relationships.

behavior of the ad-hoc services through parallel service

chaining (see section 4.6 for details).
Because of software reuse, SOA Model at ABC
was implemented and placed in production within three
months. To date, it has been in production successfully
for one year. It has met its objectives of improved
functionality, improved reliability and improved
performance. Each of these is discussed in detail
below.

4.4.

Functionality

The SOA Model at ABC results in an Enterprise

Service which supports business processes (e.g., Rate
New Customer). This is a major improvement as
transaction processing systems are loosely coupled
from the internals of System E (i.e., the correspondence
of ad-hoc service to reference database table). Under
the SOA Model at ABC, transaction processing
systems will make one call to System E versus three
calls. Consequently, SOA Model at ABC results in a
coarse-grained Enterprise Service (i.e., single API)
with improved functionality defined on business
processes, compliant with W3C SOA requirements of
Logical View and Granularity (see pg. 5).

4.5.

Reliability

At the heart of SOA Model is TransformES, a

Mediator pattern providing parallel service chaining to
ad-hoc services. Ultimately, since all ad-hoc services
are in a single Java Virtual Machine, TransformES will
provide service chaining through direct program-toprogram calls to the ad-hoc services transformation
class (e.g. TransformA). The net effect is the
elimination of MQ calls which dominate in Ad-Hoc
Services Model. In the SOA Model at ABC, instead of
approximately two dozen MQ queues, one MQ queue
suffices for the Enterprise Service. Elimination of MQ
calls translate to improved reliability because of
removal of interdependencies that can be affected by
MQ errors or time-outs.

4.6.

Performance

The coup de grce of SOA Model at ABC is

performance. Whereas ad-hoc services are invoked one
after the other under Ad-hoc Services Model, they are
invoked in parallel (i.e., threaded processing) under
SOA Model at ABC. The pseudocode for TransformES
is:
//Begin TransformES
Create a fork for
transformation

each

ad-hoc

service

Proceedings of the 39th Hawaii International Conference on System Sciences - 2006

Wait for all ad-hoc service transformations to

complete
Combine ad-hoc service transformation results
//End TransformES
Results of a benchmark (section 5) comparing Adhoc Services Model to SOA Model at ABC show
significant and substantial performance gains because
of parallel processing in TransformES.

5. Benchmark Results
Performance testing in lab over a four day period is
captured in Table 1. The data are obtained using two
test drivers that simulate 1000 customers for the
business
process
Management
Report.
The
ManagementReport business process is a list of eight
ad-hoc services. This business process was selected for
performance testing because the TPS was experiencing
performance problems using ad-hoc services. To justify
converting the TPS to using System Es Enterprise
Service, performance results were obtained.

Test 1
Test 2
Test 3
Test 4
Test 5
Test 6
Test 7
Test 8
Average

Table 1 Benchmark results

Ad-hoc Services SOA Model
Model (sec.)
ABC (sec.)
1234.27
625.93
866.828
594.262
857.188
593.984
855.385
563.441
1107.393
642.834
864.568
643.761
868.532
772.725
861.109
647.325
939.409
635.533

over four consecutive evenings using a LoadRunner

script. The LoadRunner script kicks off the testers at
midnight; and the script iterates once each evening.
Over four evenings, eight sets of data were gathered.
On average, results show that Ad-hoc Services
Model took 939.41 secs. to produce management
reports for 1000 customers; while SOA Model at ABC
took 635.53 sec. This represents an improvement of
33%. Using Students t-test (one-tailed, df= 7), the
difference is statistically significant with a level of
error at .0005.

6. Lessons Learned
While the pilot is still underway, it is expected that
it will be successful given the benchmark results to
date. More importantly, System Es pilot has created a
lasting effect on the organization as other projects have
been spawned using an incremental approach to
rewrite, much like System Es approach. This paper
now concludes with lessons learned in two major
areas- technical and organizational.

6.1.

Technical Lessons

at

The first column in Table 1 (corresponds to upper

series in chart) shows results from retrieving customer
rating information using Ad-hoc Services Model. The
second column (corresponds to bottom series in chart)
shows results from retrieving customer rating
information using SOA Model at ABC. The benchmark
was executed on an isolated server and database system

The SOA Model at ABC stands out most for its

performance improvement. The key factors for its
performance are: a) use of parallel processing for adhoc service chaining; b) use of record structure (versus
XML) as the message format; and c) use of MQ over
HTTP as the connection technology.
While some of these factors are not compliant with
Web services standards (especially use of non-XML
message formats and non-HTTP connection
technology), this paper agrees with W3C (2004) that
Web services are still immature and nascent in best
practices. Within the context of pre-dominantly legacy
mainframe applications behind a firewall, it makes
sense to implement SOA over MQ and record
interfaces versus SOA over Web services where
there is no requirement for platform neutrality.
In the future, it is envisioned that System Es
Enterprise Service will be a Web service to entities
outside the organization. At that time, a mediating
service is envisioned that will encapsulate System Es
Enterprise Service within a SOAP/XML envelope and
transport the message outside the firewall using HTTP.

6.2.

Organizational Lessons

Although the SOA Model at ABC is ultimately

successful, the new hire who developed and
implemented the model met with much organizational
resistance in the process. The resistance came from

Proceedings of the 39th Hawaii International Conference on System Sciences - 2006

System Es current project team members who are

mired in fat client technologies and lacked
comprehension for web-based technologies. As the
SOA project gained momentum and visibility, there
was a shift in the status quo causing resentment from
senior team members. Company ABCs management
was faced with personnel issues as a result of a normal
process of change from the re-architecture project. The
resistance that occurred at company ABC has been
well-documented in published literature. Keen (1981)
prescribes organizational change as a necessary
condition to successful systems implementation. What
is needed in an organization prior to a re-architecture
initiative is a management team that understands and is
adept at managing a process of change. While much
has been published on managing organizational change
(Kotter, 1995; Jick, 1991; Garvin, 2000; Egan and
Fjermestad 2005), most corporate cultures, which are
compliance-based and rank-conscious, will have a
difficult time embracing change and, in particular, be
effective at implementing enterprise architectures
(which represent a fundamental change in IT processes
and products).

7. Contributions
Key contributions of the paper include:
a) SOA as a re-architecture strategy for upper
management- Service oriented architecture enables
incremental development (i.e., one service at a time).
In todays budget conscious environment, this is a
positive perspective for upper management.
b) SOA Model at ABC as a middleware architecture
model- SOA Model at ABC is SOA-compliant which
means it provides a logical view of the business
processes, is coarse-grained, etc. Consequently, it
delivers improved functionality (driven by business
processes versus data base design), improved
reliability (invoked via a single coarse-grained MQ
service versus multiple MQ services), and improved
performance (implemented via parallel processing of
existing services within a coarse-grained service).
c) SOA Model at ABC as a software reuse case study
with implications for management- SOA Model at
ABC is an integration framework built over a
collection of existing message-driven services. The
design and implementation was completed in three
months. This presents another powerful win for
software reuse. Furthermore, it highlights the
continuing need for management to reward
performance on the basis of software reuse instead of
NIH (i.e., not invented here.)
d)

Enterprise

architecture

initiatives

organizational impact- Enterprise architecture

initiatives represent a fundamental change in IT
implementation (i.e., processes and products). Keen
(1981) prescribes organizational change as a prerequisite condition for successful IT implementation.

8. References
[1]

Applegate, L.M., FcFarlan, F. W., and McKenney, J.

L., Corporate Information Systems Management Text and
Cases, Sixth Edition, Irwin McGraw-Hill, Boston, MA,
2002.
[2] Cerami, E., Web Services Essentials, OReilly, CA,
2002.
[3] Egan, R.W., Fjermestad, J. Change and Resistance.
Help for the Practitioner of Change, in Proceedings for
Hawaii International Conference of System Sciences, Big
Island, 2005.
[4] Fayad, M. and Schmidt, D.C., Object-Oriented
Application Frameworks, Communications of the ACM,
40:10, 1997.
[5] Fowler, M. and Scott, K., UML Distilled Third Edition,
Addison Wesley Longman, New York, 2003.
[6] Gamma, E., Helm, R., Johnson, R., and Vlissides, J.
Design Patterns. Elements of Reusable Object-Oriented
Software, Addison-Wesley Pearson Education, New York,
1994.
[7] Garvin, D., Learning in Action: A Guide to Putting the
Learning Organization to Work, Business School Press,
Boston, 2000.
[8] Isaacson, C. Advisor Live, Baltimore, November, 2004.
Available at: http://www.AdvisorLive.com
[9] Jick, T., Implementing Change, Harvard Business
School Press, Boston, 1991.
[10] Keen, G.W. (1981). Information Systems and
Organizational Change. Communications of the ACM,
24(1), 24-33.
[11] Keen, M., Acharya, A., Bishop, S., Hopkins, A.,
Milinski, S., Nott, C., Robinson, R., Adams, J.,
Verschueren, P. Patterns: Implementing an SOA Using an
Enterprise Service Bus, IBM Redbooks, July, 2004.
Available at: http://publibb.boulder.ibm.com/Redbooks.nsf/0/2b0de69b65f8a8128525
6e620078c4c9?OpenDocument
[12] Kotter, J.P., Leading Change: Why
Transformation Efforts Fail, Harvard Business Review,
March-April, 1995.
[13] Somerville, I., Software Engineering (Sixth
Edition), Pearson, England, 2002.
[14] W3C, Web Services Architecture, 2004. Available
at: http://www.w3.org/TR/2004/NOTE-ws-arch-20040211.

and

Proceedings of the 39th Hawaii International Conference on System Sciences - 2006

Figure 5 Ad-hoc services model collaboration diagram (service A)

Figure 6 SOA Model at ABC collaboration diagram (enterprise service)

Figure 7 SOA Model at ABC class diagram