DM Review would like to welcome Robert Morris as a new online columnist. Rob brings an extensive background in application development and integration environments. He is a frequent conference speaker and will share his insight on service-oriented architectures in the coming months.
When it comes to integrating mainframe assets into today's service-oriented architectures (SOA) applications, many organizations have proceeded with very low expectations and, as a result, have achieved minimal results. For example, they assume that there are no tools to effectively bridge the gap between mainframe applications, data and knowledge, and the service-oriented demands of today's customer-centric enterprises; they have been satisfied with a rudimentary Web services-only approach.
Typically, this consists of wrapping discrete chunks of mainframe functionality as Web services, and publishing them for non-mainframe service developers to do with what they can. This provides a fast implementation; however, this approach involves far more back- and-forth processes which can lead to more complications, including breakdowns that require more extensive repair and downtime.
In many other areas of the corporate information infrastructure this would be unacceptable, but intimidated by its seeming intractability, SOA architects have settled for less when it comes to integrating the mainframe.
To remediate this limited vision, one must look no farther than the concept of automated Web service orchestration, the cornerstone of success for mainframe-based service development. This concept goes hand-in-hand with top-down design, where the goal is determined and agreed upon before the effort begins.
Defining and building the proper business services that make up an existing SOA is more complex than simply Web service-enabling functions in a standard way. In addition to being readily recognizable and understandable by the business user, they typically contain orchestrated multistep, multioperation functionality, 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 that is 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.
This basically distinguishes between top-down and bottom-up design approaches.
Top-down service design, where business processes drive the development of the Web service, has been shown to be a best practice for mainframe SOA. Even so, bottom-up design seemingly allows faster delivery of some basic services. Each can have its place in an enterprise that is implementing or converting to applications based on SOA.
With the top-down approach, the mainframe developer works in advance with the user who needs the service, identifying the consumer's functional and data requirements, then mapping the mainframe components to the service requirements.
How do you identify and scope a business service that will be the right kind of building block to take advantage of your SOA?
Start your service definition at the endpoint - the employment of the completed service by the user: for example, the customer service representative (CSR) performing 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 is a discrete job function within the process that the CSR will recognize and know how to use.
While the user sees a recognizable business task, under the hood, "Get Customer Information" is a multifunction, multioperation service, which is a further indication that you are approaching the right level of granularity. It comprises information such as financial transactions, address information, credit rating, purchase history, etc. Retrieving this information may invoke multiple applications or systems with different interfaces and even external Web services such as an outside credit bureau. It might even perform specific operations on the data returned in order to fulfill the requirements of the service interface.
At the same time, all of this must be transparent to the user of the service; the alternative is a bunch of standalone services, each of which must be invoked, in turn, by the user.
Further, at the right level of granularity, the use of the service itself must be 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 is invoked by the CSR's customer upgrade application. This combination of granularity and transparency ensures the highest level of service understanding, acceptance and reuse - the ultimate goal of the SOA. If designed with the top-down approach, such a business process change will be much easier; if not intuitive, at least more straightforward to accomplish.
As just described, with the top-down approach the mainframe developer works in advance with the user who needs the service, identifying the consumer's functional and data requirements, then mapping the mainframe components to the service requirements. From this design map, the developer builds an integrated business service that automates all the steps and operations required to fulfill those requirements, which ensures that the components of the architecture are optimally designed and sized to promote maximum reuse and efficiency.
It is this service optimization that leads to the fastest returns on your SOA investments, in terms of cost savings, operational efficiencies, reduced overhead and strategic advantage. And it is service orchestration that enables mainframe developers to achieve this level of optimization without coding.
It is becoming a very common approach to development using flow modeling or "wiring" diagrams that allow the user to drag, drop and wire together various building blocks - the steps of a process - to compose a service. The benefits of this approach are obvious in terms of who can participate in the development process, what they are able to accomplish, and the types of design patterns they can employ.
Be the first to comment on this post using the section below.