Chapter 2.

Case Studies

2.1 How case studies are used

2.2 Case #1 background: RailCo Ltd.

2.3 Case #2 background: Transit Line Systems Inc.

Due to the distinctive nature of modern-day service-oriented architectures, using case studies is
an effective way of conveying the topics covered by this book. Though purely fictional, the
examples derived from these case studies raise common issues and problems faced by typical IT
departments.

This chapter provides background information for two separate organizations. The first is RailCo
Ltd., a mid-size company with a modest IT staff. The second, Transit Line Systems Inc. (TLS), is
a larger corporation with multiple IT departments managing enterprise-level solutions. Though
treated as separate case studies, these companies also have a business relationship.
2.1. HOW CASE STUDIES ARE USED

This book weaves approximately 125 examples relating to these case studies throughout all
subsequent chapters. This essentially establishes these two organizations as constant real-world
reference points. Appendix A concludes this book by ending the storylines of both case studies
and exploring the results of the organizations’ respective transitions to SOA.
2.1.1. Style characteristics

To more easily identify these examples, we’ve incorporated a special style element. Any portion
of the book (beyond Chapter 2) that discusses our case studies will contain a light gray
background. Below is an example.

...Initially, there was no concern around this approach, as each application delivered its promised
set of features and solved its corresponding business problems. However, because no strategy
was used to ensure that XML and Web services were being applied in a standardized manner in
support of SOA, there was nothing in place to prevent the resulting design disparity...
2.1.2. Relationship to abstract content

For those of you not interested in learning with case studies, you can consider these parts of the
book as voluntary reading. None of the abstract descriptions reference or rely on the examples.
They are provided only to further assist in communicating the purpose and meaning behind the
concepts, technologies, and processes covered. Feel free to bypass shaded areas or perhaps only
reference them when you need further elaboration on a given subject.
2.1.3. Code samples
The chapters that comprise Part V: Building SOA (Technology and Design) contain numerous
case study examples with markup code. These code samples are used to demonstrate many of the
technologies discussed.

This book has been designed so that the supplementary technology tutorials include descriptions
of all of the language elements used in the case study code samples. (Note that there are three
samples in Chapter 17 that introduce elements from languages that are not explained to
demonstrate an aspect of a container element that is explained.)

Now, let’s introduce RailCo and TLS.

2.2. CASE #1 BACKGROUND: RAILCO LTD.

RailCo Ltd. is an established parts supplier for railways, specializing in air brakes and related
installation tools. RailCo ships air brake parts internationally, but 90% of its sales are in North
America. Though its primary line of business is product resale, RailCo also has a small group of
specialized technicians that are hired out locally for installations and repairs.
2.2.1. History

Established in the early 90s, this company has gradually grown from a staff of 12 to 40. It started
out as a brokerage for various railway wholesalers, but then came to specialize in air brakes. The
narrowed business focus resulted in increased opportunities, as RailCo was able to become a
wholesaler in its own right by dealing directly with air brake parts manufacturers.
2.2.2. Technical infrastructure

Five employees and one manager are dedicated to full-time IT duties, responsible primarily for
maintaining client workstations and back-end servers. Custom development tasks have typically
been outsourced to local consulting firms, whereas periodic upgrades and maintenance fixes
have been the responsibility of in-house staff.
2.2.3. Automation solutions

RailCo’s automated environment consists of the following applications:

• A two-tier client-server system governing all accounting and inventory control transactions.
Two administrative clerks manually feed this solution with standard transaction document data
(primarily incoming and outgoing purchase orders and invoices). Receipt and submission of
these documents typically initiates corresponding inventory receiving and order shipping
processes.
• A contact management system in which customer and business partner profile information is
stored and maintained. This simple application consists of a database fronted by Web-based data
entry and reporting user-interfaces. Users range from managers to administrative assistants and
accounting personnel.
2.2.4. Business goals and obstacles
Profit margins have been noticeably declining over the past year. A recent review revealed that
the overhead associated with RailCo’s current business processes is becoming less acceptable.
Clients have been switching to a competitor providing the same products in a more efficient
manner and at a lower cost.

Further investigation led to the discovery that this competitor has implemented an extension to
their existing accounting system, allowing them to perform various transactions online via B2B
solutions provided by some of the larger clients. They have subsequently been able to reduce the
staff required for processing orders, while increasing response time and lowering their overall
price point. A further unpleasant revelation was that RailCo’s primary client, Transit Line
Systems, has started an online relationship with this competitor as well.

RailCo is a company with outdated technology automating inefficient business processes. It is

looking to overhaul its technical environment to better respond to new business trends and
automation requirements.

To remain competitive and minimize losses, RailCo must upgrade its automation environment as
soon as possible. Its top priority is to participate in online transactions with TLS. Before our
storyline begins, RailCo has already hurried to build a pair of Web services (Figure 2.1) that
enable it to connect with the existing TLS B2B solution. These services are explained and
referenced as we progress through chapters discussing Web services technology.

Figure 2.1. RailCo’s initial set of Web services, designed only to allow RailCo to connect to
TLS’s B2B solution.
The design of this solution, though, is revisited and expanded in Part V. By that point RailCo
runs into some limitations and decides to re-evaluate its environment in consideration of
establishing an SOA. Further, RailCo realizes that it must also seek new clients to make up for
the lost sales to TLS. This new requirement ends up also affecting the design of its SOA.

Note that though technically a Web service with its own WSDL, the Invoice Submission Service
frequently acts as a service requestor, issuing invoice documents to a TLS Web service. It is
important not to view this service as just a Web service client program. It begins to perform more
of a provider role in later chapters where it evolves along with RailCo’s SOA. Chapter 5 explains
how services play both requestor and provider roles.
2.3. CASE #2 BACKGROUND: TRANSIT LINE SYSTEMS INC.

Transit Line Systems Inc. (TLS) is a prominent corporation in the private transit sector. It
employs over 1,800 people and has offices in four cities. Though its primary line of business is
providing private transit, it has a number of secondary business areas, including the following:
• A maintenance and repair branch that outsources TLS service technicians to public transit
sectors.
• Parts manufacturing for other industries.
• A tourism branch that partners with airlines and hotels.
2.3.1. History

TLS existed as a mid-sized corporation centered around a single private railway for several
years. However, the end of a long-term battle with a rival railway (which resulted in the
bankruptcy of its competitor) sparked an era of growth. TLS enjoyed a successful period of
expansion during which it established two further private railways in separate cities. Over the
course of approximately ten years, TLS made a series of corporate acquisitions, including:
• G&R Tracks Ltd., a privately owned railway company (its original competitor) that provided
TLS with enough rail assets to launch a new railway in a neighboring city. G&R had over 180
employees, but TLS kept only ten technical specialists.
• Sampson Steel Corp., a large manufacturing plant that produced various metal parts for clients
in the automobile and airline industries. An economic downturn sent this company to the brink of
liquidation until TLS stepped in. TLS formed a partnership with Sampson Steel, making TLS
majority owners, but allowing the original Sampson management group to continue operational
control of the factory. While Sampson Steel continues to service its existing clientele, its primary
focus became the production and assembly of parts for TLS’s railways. Though only generic
parts can be produced by the factory, this arrangement allows TLS to acquire these parts at a
fraction of the original supplier’s prices.
2.3.2. Technical infrastructure

The TLS head office contains a sizable IT department. Of the 200 IT professionals that support
TLS’s automation solutions, approximately 50% are contractors, hired on a per-project basis.
The overall technical infrastructure is mixed. More contemporary eBusiness solutions are hosted
in a clustered server environment, capable of high transaction volumes and with robust backup
and disaster recovery mechanisms in place. Individual legacy systems are typically isolated in
separate environments, depending on the nature of the system. Mainframes have their own space,
and a series of Windows servers individually house older, specialized client-server applications
and associated databases.
2.3.3. Automation solutions

Following is the subset of TLS’s inventory of legacy systems that we will be referencing in case
study examples:
• A distributed enterprise accounting solution, accommodating some 400 users. It replaced TLS’s
original accounting package during its expansion period, when accounting requirements grew
along with the size of the company. This solution is partially custom developed but relies mostly
on out-of-the-box accounting features. It provides sophisticated Web front-ends for intranet and
remote access but also offers some desktop tools for analysis and reporting. The product vendor
is relatively progressive and has offered a set of Web service adapters that plug into different
modules of the overall system.
• A third-party time tracking system used by some employees that are outsourced by TLS to
record the time they spend at client sites. The information collected by this program is later
manually entered into the accounts receivable module of the accounting system.
2.3.4. Business goals and obstacles

TLS is a corporation that has undergone a great deal of change over the past decade. The identity
and structure of the company has been altered numerous times, mostly because of corporate
acquisitions and the subsequent integration processes. Its IT department has had to deal with a
volatile business model and regular additions to its supported set of technologies and automation
solutions. TLS’s technical environment therefore is riddled with custom developed applications
and third-party products that were never intended to work together.

The cost of business automation has skyrocketed, as the effort required to integrate these many
systems is increasingly complex and onerous. Not only has the maintenance of automation
solutions become unreasonably expensive, their complexity and lack of flexibility have
significantly slowed IT response time to business process changes.

Tired of having to continually invest in a non-functional technical environment, IT directors

decided to adopt SOA as the standard architecture to be used for new applications and as the
founding principle to unite existing legacy systems. The primary motivation behind this decision
is a desperate need to introduce enterprise-wide standardization and increase organizational
agility.

As the storyline begins, TLS has built its first service-oriented solution already (Figure 2.2). This
is the B2B system to which RailCo and many other vendors connect to conduct transactions
online. The services that comprise this solution are introduced in Chapter 5, and are then
referenced throughout the chapters that discuss Web services technology. However in Part V,
TLS embarks on a new SOA project. This shifts our focus to a new set of services, as well as the
related adjustments TLS makes to its technology platform.

Figure 2.2. The Web services that comprise the TLS B2B solution.