Mainframe systems have been the backbone of most enterprises for decades. Companies are now looking to Service-Oriented Architecture (SOA) to enable consistent reuse of applications and data without requiring the consumers of those resources to understand the mainframe. Unfortunately, the focus has been primarily on the mechanics of Web Services (e.g., SOAP, WSDL, XML, HTTP), and not on identifying and meeting the real requirements to deliver SOA benefits.
There’s no shortage of vendors willing to further confuse the issue by offering simplistic solutions to delivering mainframe Web Services, and claiming this is synonymous with delivering SOA. This approach should come with a warning label: “Web Service enclosed. All assembly required.” It’s like delivering a load of lumber to a prospective home-builder. Oh, sure, everything you need to frame the house is there—except a blueprint and a basic plan for how all the pieces fit together. Once you move past the high-level marketing messages—“ Instant house—just add nails!”, you start to realize that delivering mainframe SOA is much more than just delivering mainframe components dressed up as Web Services.
- An in-depth understanding of how the components work together to comprise a recognizable business task
- Automating the interaction of the underlying functionality and data sources necessary for the task
- The whole thing be packaged in an easily recognizable and accessible form for effective use and reuse.
The assembly of such right-sized services into a standardized, enterprisewide framework for the effective use of an entire company’s information and systems ensures the realization of a true SOA—all of which is why an exclusive focus on Web Services is shortsighted. So, how can organizations cut through the hype and get to a clear, deliverable SOA vision? The following three guidelines may be helpful.
1. Think “business services”: There’s a common misconception today that Web Services are necessarily required for—or even synonymous with—implementing an SOA. But talking “Web Services” instead of “business services” really misses the point. Web Services are likely to be a part of an SOA, but only as one of several technology options for standardizing access to services across the enterprise. The business services that comprise an SOA perform a more complex role than simply enabling the invocation of a function in a standard way. Besides being functions that are readily recognizable and understandable, they typically contain multi-step, multi-operation functionality, orchestrated within the service, with transparent communications and data transformation. Critical to successful SOA is the ability to understand and deliver such business services at the optimal level of granularity to facilitate reuse and to insulate the user from downstream maintenance. Otherwise, everything developed in support of the SOA simply becomes an elementary building block that will have to be assembled into a usable structure elsewhere, with all the attendant development, testing, and maintenance ramifications that implies.
So, how do you identify and scope a business service that will be the right kind of building block for your SOA? Start with the requirement that it be a recognizable business function. There’s a tendency here to start at too low a level—the level, not coincidentally, where the developers of the service are likely most comfortable. Instead, start your service definition at the endpoint— the employment of the completed service by the user. Consider, for example, the Customer Service Representative (CSR) who performs the job function “Get Customer Information.” This is just one step in the process of signing up a customer for a new service or product, but it’s a discrete job function within the process that the CSR will recognize and know how to use.
While the user sees a discrete, recognizable business task, under the hood, “Get Customer Information” is a multi-function, multi-operation service that’s a further indication you’re approaching the right level of granularity. It’s comprised of functions such as “Get Customer History,” “Get Customer Credit Rating,” “Identify Customer Pricing Level,” etc. Each function may invoke multiple operations, such as interacting with an outside credit bureau, then performing specific operations on the data returned in combination with the customer’s internal purchasing and payment history, in order to assign an appropriate pricing level.
Meanwhile, all this is transparent to the user. Further, use of the service itself is insulated from downstream changes to its underlying components. For example, if the company switches credit bureaus, the necessary changes can be made within the service without affecting the way it’s invoked by the CSR’s customer upgrade application. This combination of granularity and transparency ensures the highest level of service reuse, fulfilling the ultimate goal of the SOA.
The Web-Services-as-SOA approach would serve up each of the functions underlying the business service as a building block, which would then have to be assembled and managed by the service consumer. This do-it-yourself approach would include orchestrating the interactions between the various Web Services and the necessary data transformations, as well as the application inputs and outputs.
Further, when any of the underlying components change, the Web Services consumers would have to be alerted as to how and what to change in relation to their specific uses of the services. With a backto- the-drawing board reaction every time there’s a component change, the benefit—and therefore the likelihood— of reuse is lost, as is much of the advantage of implementing SOA.