The role of SOA Governance in Legacy Modernization - Part 1

Submitted by John Fitzgerald. System Architects.

Legacy modernization, through service-enablement of legacy systems, is a key driver in helping organizations implement a Service-oriented Architecture (SOA). However, legacy modernization should always go hand-in-hand with SOA governance. Presuming that a decision has been made to pursue service-enablement, the good news is that developers and even business users now have a number of tools at their disposal to open up legacy systems. This is also the bad news.

With various tools (in skilled or unskilled hands) producing services in different ways and based upon different legacy system layers, the potential is strong for a disorderly mish-mash of services popping up throughout the organization. Below are five problem areas that could appear when an unmanaged herd of new services works its way into the company's SOA projects:

Granularity problems

One of the main debates in the SOA world is determining the proper "granularity" of a service. Granularity is the creation of services at the level that is most appropriate for reuse. Typically, legacy application functions, especially batch programs or CICS transactions, are extremely fine-grained. Service-enabling such business logic may make sense for reuse. But at the end of the day, integration projects may not become any easier if service consumers are forced to understand and glue together a number of fine-grained services to solve a business problem. Conversely, if services are too coarsely grained they may never be reused at all.

Control problems

In theory, service-enabling a legacy asset allows any developer or even user the ability to work with that system. The goal is to know the identity of service consumers have the proper security and controls in place to ensure that the right consumers have access to the right services. And while asset reuse is generally a good thing, it is also very important that a given service is being used in the intended manner. For example, a legacy asset that returns information about a single transaction certainly was not intended to be called hundreds of times in succession to return a large set of data! Therefore it is vitally important that consumers of legacy services have clear expectations about the services provided and aren't placing undue stress on back-office systems.

Duplication problems

Asset management is a problem that is not going to disappear with SOA. Without a complete understanding of what services are available throughout the organization, there is an obvious risk having developers duplicate services. One of the main issues at many companies today is the duplication of data and business logic in various systems across the enterprise. The unmanaged proliferation of services will only prolong and exacerbate this problem. Ultimately, an SOA initiative will only be successful if an organization can define - for every given set of information or data - a single service of record that somehow invalidates any other services that attempt to represent that same set of information or data. It is critical to ensure that the proper infrastructure and policies are in place to ensure that duplication does not occur.

Change problems

One of the primary advantages of SOA is that organizations gain the flexibility to more quickly respond and react to business challenges. By loosely coupling the integration between business processes and critical business systems, it becomes much easier to change those processes and their underlying support infrastructure. However, this capability assumes that organizations understand the dependencies between automated processes, composite applications, service orchestrations and the underlying services themselves.

If an organization fails to track dependencies, it will not be able to predict the impact of legacy service alterations to front-office processes and applications or to back-office services. If a change did occur to a legacy service without the proper controls in place, imagine the ultimate impact: service orchestrations would break, critical business processes could fail and composite applications may no longer function correctly. In the end, an organization will lose the opportunity to gain flexibility and agility if it doesn't have visibility into its infrastructure.

Compliance problems

With the rise of new regulatory measures such as Sarbanes-Oxley, HIPAA, and BASEL II, organizations are under increasing pressure to follow documented, well-defined procedures and processes. In the current regulatory climate, the inability to clearly document or audit the relationships between a business process and underlying services and systems can put an organization at significant financial risk. However, in the paradigm of service orientation, there is no longer a "hard wired" connection between systems and processes. Therefore, connections that were previously documented in architectural diagrams are now freewheeling and potentially untraceable unless some specific set of controls is implemented. With SOA, compliance becomes more challenging - not less.

Time for SOA Governance

What is the best way to mitigate these five potentially serious hazards when service enabling legacy systems? Any organization serious about SOA-based modernization must put in place an SOA governance plan. Such a plan will ensure that best practices are implemented around the development and deployment of services.

SOA governance is how SOA efforts are managed and controlled. It is how the different groups, participants and services operate within the larger SOA framework. The concept of governance in IT is not new. Management policies have existed for years for legacy environments. But SOA implementations typically are developed and deployed in distributed environments, and the complexity of managing this distributed technology is much greater than in the past. Accordingly, the need for strong governance is also greater than ever before.

Part 2 of this article series will discuss the two focus areas of SOA governance: runtime and design-time. It will describe a necessary human component of SOA governance: the SOA Competency Center. And it will also discuss a necessary technology component of SOA governance: the SOA Registry/Repository.