Merging the complementary technologies of mainframe applications and Service-Oriented Architecture (SOA) presents organizational as well as technical challenges. In this, the second in the series, we examine the organizational issues related to managing multiple skill sets needed to support the use of mainframe applications in SOA development efforts, including:
Developers and designers from mainframe and SOA backgrounds will need their domain specific skills, but they will also need an understanding of their colleagues' different principles and practices. Project managers will similarly need to understand how to coordinate and combine the efforts of the technical staff.
Presumably the goal of integrating mainframe services and SOA applications is to bring the functionality and scalability of mainframe applications to a diverse service-oriented development environment. It would be easy to make the mistaken assumption that the differences between mainframe and SOA development are analogous to difference in coding in COBOL and PL/I— there are different ways to define what the program should do but a developer would do roughly the same thing using either language. This is not the case. Mainframe and SOA development are specialized domains within information technology (IT) with their own models, terminology, and tools. The first article in this series examined, in detail, differences in the models; here, we will briefly discuss the different terminology and tools found in mainframe and SOA development efforts and examine the implications of those differences on project management and systems maintenance.
In spite of the fact that fundamental programming and design principles are the same across the IT spectrum, there are significant difference in how these are applied within the different objectives of and constraints on mainframe and SOA development. Consider two examples.
Although developers may share similar terminology, such as services and transaction, there are subtle but important distinctions between these terms in mainframe and SOA environments. A service to an SOA developer may be a relatively small application that provides a simple unit of work, such as calculating the state tax for an online order. To a mainframe developer, a service might be the entire order processing sequence of events that includes a rich set of application logic to check inventory levels, determine shipping method, update stocking information, and other operations required to maintain the integrity of business operations.
Also, mainframe developers are accustomed to working in high-volume, transaction-processing environments that take advantage of specialized services, such as Customer Information Control System (CICS), which has been widely adopted since its introduction decades ago. CICS is used in screen-oriented applications and typically depends on batch programs that run in the background. Unlike mainframes, where there may be a relatively limited number of distinct types of CICS transactions, SOA developers may think of a transaction as any sequence of service calls that are treated as single logical unit. The exact steps may vary depending on the particulars of the data being processed. The steps are treated as a transaction by virtue of being part of a single unit of work as defined by a programming framework, such as Enterprise Java Beans 3.0.
IT is fundamentally based on the principles of computer science and information management, but these broadly applicable disciplines leave a great deal of room for specialization. Both mainframe and SOA models are examples of specialized instances of IT. As the previous examples show, similar terminology can mean different things to different kinds of developers. In addition, developers have different tool sets.
Mainframe developers work with tools for application development, data management, and security that are distinct to their IT environments:
SOA developers use different kinds of tools and data management systems that, although there are fundamental similarities, are distinct enough that they are used and managed differently:
Neither skill set is inherently more important or better than the other; projects that encompass mainframe and SOA models will need skills from both areas.
If it were just a matter of separating mainframe from SOA components so that they each did their respective operations without interfering with the other, then mainframe/SOA projects would be much easier to design and manage. Unfortunately, there is no hard and fast boundary that allows the two approaches to coexist without the need to adapt to some elements of the other. To realize the benefits of mainframe services in an SOA environment, we must understand differences in the way services are provided and consumed in each application type.
Mainframe applications provide and consume their own services. The term "monolithic" is often used to aptly describe these systems. They do not usually make calls to services provided by other applications but perform the operations themselves. For example, if an interactive COBOL program running on a z/OS operating system needs to update a customer's address in a database, it will use code within itself to perform the operation. That is not the case in a typical SOA application.
A customer self service Web application may have an "update address" feature that is composed of several components including: code to generate the interface using HTML and XML, serverside code to verify the structural integrity of the data sent from the client device to prevent SQL injection and related attacks, and finally, a call to a Java or .NET service that executes a SQL statement to update the relational database. In addition, not only are the components written in different languages and use different protocols but also they may all run on different client devices and servers. These separate services function together, though, because providers and consumers use implicit contracts about what each service expects as input and what it provides as output. This separation of functions impacts the way applications are written.
In the case of mainframe applications in which all relevant events occur within the same logical piece of code, procedural side effects are acceptable. A loan payment processing application on a mainframe might deduct a principal payment from an amount-due field in an IMS database and then increment another field that stores the number of payments made to date. A more finely grained set of services, like those found in SOA applications, typically perform smaller units of work, such as deducting the principal payment from an amount due. They do not make assumptions about sequences of events or try to maintain information about the global state of an application. For example, rather than look to a database field for the number of payments made, an SOA application may find querying the database for the number of payment records to be a more consistently reliable method of retrieving the information. The underlying assumption is that the information in the database may be entered and updated in several ways under a variety of circumstances. The contrary mainframe assumption is that changes to the database are made through the same program that does the querying and therefore all possible ways of making changes are available to developers. These differing assumptions are neither categorically correct nor categorically wrong; they both have uses.
Business operations supported by mainframes often do not easily decompose into fine-grained services. These applications carry out complex operations with multiple steps; as a result, they contain a great deal of business logic. Should these business operations be re-implemented in a more modular, SOA approach to ease their integration? Although this approach is appealing in theory, the practical considerations of actually restructuring and redesigning make this option cost prohibitive. Consider some of the challenges:
The software maintenance life cycle is replete with management challenges in the best of circumstances. Trying to force a mainframe service into a set of finer-grained SOA services is like trying to force the proverbial square peg into the round hole—with enough force, it can be done, but the results will probably not meet expectations.
Ultimately, the effectiveness of using both mainframe and SOA services is largely influenced by management decisions about staff, development skills, and software maintenance. Fortunately, the practice of combining mainframe and SOA services has matured to the point where several management best practices have emerged.
Both mainframe services and conventional SOA-designed services can contribute to the success of an SOA project if several principles are followed. First, clearly assign responsibility and ownership for services based on skills. Project management should assign ownership of controlling the business context of a service to those that have the skill sets appropriate to the applications from which the services are derived.
As noted earlier, mainframe programmers and SOA developers have complementary skills sets. They use different sets of tools and design applications in different ways. Both have created practices that reflect the design goals and the constraints of the systems they develop. Mainframe programmers may have detailed knowledge about business process as well as an in-depth understanding of how mainframe code implements that business process. SOA developers probably do not have the same level of experience with macro-level business processes. These programmers are more likely to be familiar with protocols and design patterns used in distributed systems. Services that require complex business logic and high-volume transaction processing are best assigned to mainframe developers. Specialized, fine-grained services that require familiarity with Web protocols, distributed security, and commonly used application stacks are best assigned to SOA programmers.
Second, weigh the need for granularity of services with the need to leverage business logic embedded in mainframe programs. If a mainframe application can provide a service that encompasses two or more fine-grained services, one may be tempted to re-implement the service. Before taking on the responsibility of maintaining additional software, consider how the mainframe service can be used to provide multiple services. For example, rather than call the three separate mainframe services, one after each of three fine-grained SOA services, call the mainframe service once after all three fine-grained services have executed. The sequence of events in an SOA process is not fixed. (In fact, the dance inspired term "choreography" is often used to describe the art of sequencing events in SOA).
Third, manage mainframe and mid-tier development teams in ways that support coordinated development. IT is not monolithic and IT professionals are not homogenous. Bringing mainframe services into an SOA application is more like managing a relay race team made of peers rather than a hierarchical organization in which some answer to the demands of others. Some parts of the overall design will be dictated by the best practices in SOA and in other cases it will be dominated by the practical constraints of existing mainframe applications.
Managing a mainframe/SOA development initiative is a challenge. There are multiple skill sets and different ways of designing and maintaining software that must be brought together, but when properly organized, they will complement, not compete with, each other.