Joe McKendrick, ebizQ's SOA in Action Blogger, is a nationally published author and consultant
with deep knowledge and insights regarding trends and developments in
the technology industry. He is a contributing editor to a number of
national and international publications and Websites including
Database Trends & Applications, ZDNet, and Webservices.Org. He also
serves as analyst for Evans Data Corp., and is lead analyst for Evans'
Web services and enterprise development management issues surveys.
SOA in Action Blog
|
« Technology Won't Clear SOA Bottlenecks; Here's What Will | Main | A New Term I Like: 'Service-Averse Architecture' » May 14, 2007Tough Questions for a Tough SOA Machine Which comes first, the service or the machine? The service should be designed first, of course. But in the world of legacy systems, there may be limits on what services can be extracted or exposed. The mainframe is a great SOA engine -- probably the best -- but it can also be limiting. IBM is really, really, pushing the mainframe hard as an SOA enabler. Among many other things, last month, Big Blue announced that it has expanded its CICS software to better leverage the System z platform as the computing hub for SOAs. The vendor also said it is currently working with over 1,000 enterprise customers that are implementing SOA with the mainframe as a hub. "Mainframes are finding second careers as the hub for SOA," said James Stallings, general manager for IBM System z. Sounds good. Where's the downside, then? In a new article, Mike Oara, co-founder and Chief Technology Officer of Relativity Technologies, discusses the issues that arise when a company seeks to expose mainframe applications to the SOA cloud. Namely, that while the mainframe is a great, solid, scalable machine for supporting SOA, identifying exactly which services should and can be exposed to the outside world is not a trivial task. Mike says three questions tend to arise during this process: Should one begin by deriving services from the legacy application, or rather start with all potential services and decide which would fit actual business requirements? If certain services are required, what is the best way to find them within a typical legacy application? What is the most suitable degree of granularity at which they should be defined? There are three ways to identify such services, Mike explains: The top-down approach: This approach "advocates the up-front definition of services by architects and analysts. This group defines the best set of services that could possibly satisfy all business requirements." However, the mainframe may be incapable of offering such services. "An architect may determine, for example, that a service should allow an application to retrieve the top three most expensive items ordered by a customer. Although the information is in the database, the mainframe program may be incapable of retrieving order data in this way or with this criterion." In other words, someone may be trying to design a sportscar with parts from a minivan. The bottom-up approach: Here, Mike states, "the definition of services originates in the knowledge of the legacy application. The services are discovered, rather then defined as requirements." However, he cautions, "this form of service definition is known to produce sets of services that are awkwardly defined, superfluous, and out of alignment with real business and architectural requirements." In other words, the SOA is bent, shaped, and twisted into unrecognizable forms to try to make it fit with the existing apps. The meet-in-the-middle approach: "In this approach the service modeling team and the mainframe application experts work together to identify potential services that are both useful and feasible, given the existing legacy constraints. Before solidifying a particular design, the architect would ask: 'Can such a service be provided?'" This falls in line with what SOA should be all about -- opening up communication and collaboration across business unit boundaries. The mainframe folks have tended to be isolated from the distributed application teams. Posted by joemckendrick in SOA | Digg This | Add to del.icio.us Trackback Pings TrackBack URL for this entry:
|
