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:
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:
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:
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.
Part I: SOA and Web Services Fundamentals
The Evolution of SOA
Web Services and Primitive SOA
Part II: SOA and WS-* Extensions
Web Services and Contemporary SOA (Part I: Activity Management and Composition)
Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)
Part III: SOA and Service-Orientation
Principles of Service-Orientation
Part IV: Building SOA (Planning and Analysis)
SOA Delivery Strategies
Service-Oriented Analysis (Part I: Introduction)
Service-Oriented Analysis (Part II: Service Modeling)
Part V: Building SOA (Technology and Design)
Service-Oriented Design (Part I: Introduction)
Service-Oriented Design (Part II: SOA Composition Guidelines)
Service-Oriented Design (Part III: Service Design)
Service-Oriented Design (Part IV: Business Process Design)
Fundamental WS-* Extensions
Appendix A. Case Studies: Conclusion