Service-Oriented Architecture (SOA) is gaining acceptance as many companies begin to create services and Service-Oriented Business Applications (SOBAs). Over the past decade, businesses have mandated the creation of business reporting systems that span multiple IT systems to provide consolidated views of their operations and performance. Now, businesses are taking the next step, mandating flexible workflows across those same disparate IT systems that help them do business. SOA represents the logical next step in IT evolution. 

The appeal of SOA stems from the ability to integrate disparate systems into cohesive business processes and the greater responsiveness that SOA provides to the IT department and the business. SOA also brings the promise of solving the problems associated with the long, risky project lifecycles normally seen when building traditional monolithic disparate applications. 

SOBA offers the ability to quickly assemble reusable business services created from existing IT assets. SOBAs can be deployed in weeks, not months, and incrementally enhanced to meet the changing business needs. SOA provides a vision of an IT landscape populated with well-documented, reusable services that are easily assembled into a SOBA to meet evolving business needs. It’s a great vision, but getting there can be a difficult journey.

 Mainframe to SOA: Challenges and Opportunities

 The mainframe remains the foundation of many corporate data centers. Indeed, more than 70 percent of all corporate data resides on mainframes. Legacy systems represent trillions of dollars in assets and hundreds of millions of lines of code still run on mainframes. So any enterprise-wide SOA implementation strategy certainly must include mainframes and should start with a plan for how to move these most critical systems into an SOA. 

Unfortunately, mainframes represent one of the most challenging systems to move to SOA. The challenges fall into three categories: 

  1. Comprehending what reusable business services can and should be exposed from the mainframe
  2. Configuring services appropriately so they’re accessible from the SOA platform
  3. Ensuring that the mainframe access point doesn’t create a security risk. 

SOA is about creating reusable services that mirror business processes. The ideal size of a service is an atomic business action, so any conceivable process can be created by assembling the appropriate atomic business actions. The first step is to identify the atomic business actions and encapsulate the services. However, mainframe systems tend to be monolithic and provide no immediate or easy way of identifying appropriate services. The applications often house millions of lines of COBOL code that have evolved over years—perhaps including decades’ worth of incremental change and enhancement. Finding a skilled resource to discover potential services in this mountain of code doesn’t just mean finding someone who knows COBOL; it’s finding anyone who has any idea of what the program actually does. The people who originally deployed, wrote, or enhanced it often have moved on. That leaves the options of training someone by walking through the programs or buying a code-analyzing tool to create reports to assist in the process. Of course, this provides only a feel for what the business could be using the mainframe for, not what parts of the code are actually used or how users may be using or abusing the system. 

The real answer to what business processes are encapsulated and used in the mainframe lies with the user community. However, most IT staffs don’t even know who’s using the mainframe, much less how they’re using it. Usually, uncovering these processes from the user community is achieved either anecdotally (by the business owner who is screaming the loudest) or systematically (through a long, expensive engagement with a consulting group to do a comprehensive set of as-is and to-be sessions to provide a set of process maps). 

The anecdotal method is common and proven. The business screams, a project is initiated, and business requirements are dutifully collected from a small, hopefully representative set of users. Several steps through the Software Development Lifecycle (SDLC) later, a service is born. Of course, the service was conceived in a near vacuum of true requirements from an SOA perspective. The requirement was limited in scope to what was needed for the immediate project, and the user group limited to a few representative users, which invariably don’t represent all the capability required or used, or how it’s used by users in other locations. The result is an incomplete service that’s doomed to either a life of slow, expensive incremental re-work, or orphaned while another, better service is designed with the benefit of hindsight. Usually, after the third or fourth duplicate service is created, enough knowledge is accumulated to provide a proper reusable service. 

In contrast to the incremental method of service creation and re-definition, the process of performing a comprehensive business process analysis will provide the requirements and knowledge to construct a proper service the first time around. The challenge is to ensure a comprehensive examination of the current processes and systems used. As the scope of the analysis grows to include business process exceptions, end of month, end of quarter, end of year processes, and all territories and classes of users, the costs of the study rise. In sharp contrast to the anecdotal method of service creation and re-definition where the costs accumulate over time, the decision for the analysis scope must occur upfront, and the trade-off between completeness and cost must be made. 

2 Pages