net.work

The Way Business Is Moving

net.work published by
Issue Date: July 2008

Bridging the IT/SOA gap

July 2008
Joe Gentry, Software AG

How does an organisation reap the ­benefits of a service-oriented architecture while retaining the performance and value of its custom-built core systems?

Although service-oriented architecture (SOA) is a complicated subject, the basic premise is fairly simple. The idea is to avoid building new applications from scratch each time, and also to avoid duplicating applications, data and business rules in one part of the organisation that already exist in another part of the organisation. Instead, applications are built quickly out of existing building blocks (called services), and draw information from different places throughout the organisation without actually changing where the information lives. Among the results of a properly implemented SOA are greater agility, better responsiveness to customer and market demands, and significant cost reduction.
The journey from a traditional IT model to SOA can be represented as a modern concrete and steel traffic bridge that spans a body of water such as a causeway. In our example, there are five basic bridge elements:
The piles - long columns of concrete driven deep into the sea bed. The piles represent service enablement, which extends valuable core applications to SOA environments without extensive programming effort.
The footing - the enlarged concrete foundation of the bridge that holds the pier and rests directly on the piles below the water line. The footing represents high-value business services, which enable Web services to be strung together or orchestrated to create new high-value business services that provide greater alignment of the business with IT.
The pier - the vertical concrete part of the bridge that rests on the footing and rises out of the water, supporting the beams and deck. The pier represents SOA governance, which facilitates maximum re-use of Web services within and across organisations.
The beams - horizontal concrete or steel members that rest on the pier and support the deck. The beams represent SOA policy management and enforcement, which serves to define, manage and enforce service policies that span the entire SOA lifecycle
The deck - the top surface of the bridge that rests on the beams and carries the traffic load. The deck represents application composition, which enables the organisation to assemble new applications from multiple business services with little or no coding required.
Joe Gentry, Software AG
Joe Gentry, Software AG
The piles: service enablement
In order to re-use core mainframe assets in future applications, they must be exposed as services at various levels of granularity. A coarse-grained service performs a complex function. A fine-grained service performs a simple function. The process of exposing core applications as re-usable services with differing levels of granularity is called service enablement.
There are three basic ways to do service enablement: session integration, transaction integration and data integration. Session integration intercepts the information passed back and forth between the mainframe and the terminal, and is able to convert that information into services that can be re-used by other applications. Transaction integration puts a wrapper around a single database interaction, including the business rules, so that it takes on the modular characteristics of a service - similar to the way packets are sent back and forth between devices in a communications network. Data integration bypasses the presentation and business rules layers and creates a data access service that can be called from another application.
All three methods of service enablement put core enterprise assets into a form that can be recognised and used within an SOA.
The footing: high-value business service orchestration
Sometimes the services exposed from core systems are too fine-grained to meet the needs of the final business applications or processes. In such cases, it is often necessary to execute multiple fine-grained Web services in sequential steps, with additional business logic inserted between the steps. In this process, called service orchestration, a new coarse-grained service is created that is much more useful to a variety of business applications.
The composite service created from such a process is called an orchestrated service or high value business service. Typically, the piece of technology used to perform service orchestration is an enterprise service bus (ESB).
The pier: SOA governance
With many fine-grained and coarse-grained services being created and re-used, the organisation must be able to efficiently track information about the services. Just a few examples include service identity, version, access rights, security settings, where used, and the systems impacted by any change made to the service. These details and others will have a direct impact on the re-usability of existing services, and on the success of the entire architecture.
For this reason, it is now universally recommended by industry analysts that organisations adopt a method of SOA Governance as a central element of any SOA initiative, and that governance be implemented right from the beginning. Analysts also agree that a full-featured SOA registry/repository can provide excellent support for a program of SOA Governance. A registry/repository provides many important capabilities to both producers and consumers of services. These include publishing and searching tools, the ability to attach an up-to-date service contract to each service, and service usage tracking.
The beams: SOA policy management and enforcement
Once services are exposed and made available for consumption by various applications, they are only at the beginning of the SOA lifecycle. Each service will take on a life of its own as it is consumed in various applications, and as changes are made (or not made) to the system(s) from which the service calls data and business rules. All of the changing variables throughout the life of the service have the potential to wreak havoc within the enterprise infrastructure unless various SOA policies are created, managed and enforced. These policies serve to regulate each service throughout its lifespan.
Governing the SOA lifecycle requires specific technology - a scalable SOA policy management platform that can span design, run-time and change-time governance requirements. This platform sometimes also includes the registry/repository, combining all aspects of SOA governance under a single umbrella. An SOA policy management platform can accelerate SOA adoption by making it easy to synchronise policy enforcement across the SOA lifecycle. It can also enable organisations to consistently meet their service level agreements (SLAs) and key performance indicators (KPIs), as well as automate the SOA processes that support their business objectives.
The deck: application composition
The end-game of SOA is the creation of new applications to solve a variety of business problems.
These new applications are the result of a process called application composition, and are known as composite applications. They are not developed in the traditional manner, by writing line after line of code in a language such as Java or .NET or COBOL. Instead, composite applications are created in a modular way by combining Web services available both inside and outside the enterprise. Yet composite applications also have the enterprise-level speed, performance and graphical interaction capabilities associated with sophisticated desktop applications.
The specific tie-in between composite applications and SOA is that the user of composite applications will actually be employing Web services to call vital information out of the organisation's core systems. Gone are the days of requesting a report from IT or sitting in front of a special green-screen terminal. Thanks to SOA, business users can use codeless, drag-and-drop tools to build their own browser-based applications. This is truly revolutionary.
Three bridge building tips
Using the five elements above, organisations can cross over from developing hard-wired, slow-changing, inflexible systems into a more responsive and efficient way to solve business problems. As a final extension of the analogy, here are three bridge building tips.
#1. Be fully aware of all environmental factors that could stress the components.
Be sure there is full buy-in on any SOA project by all stakeholders, including IT management, enterprise architects, business line managers and key executives.
#2. Anticipate the traffic load that the deck must carry in the years ahead, not just the current traffic load.
Do not scrimp on SOA governance. Perhaps the current number of services can be tracked on a simple spreadsheet, but the infrastructure should accommodate a wildly successful process that is adopted throughout the organisation.
#3. Do not try to save initial cost by building the bridge with inferior materials.
A project that will impact the future of the business should be entrusted to partners proven to offer world-class experience and mission-critical software solutions.


Others who read this also read these articles

Others who read this also read these regulars

Search Site





Subscribe

Previous Issues