Services Oriented Architecture:

My fellow members at the Toronto IT Society would be horrified to learn that I, some years ago – in a moment that I can only describe as temporary insanity – uttered the words: “COBOL is dying.”

COBOL, short for Common Business Oriented Language, is a language that found its beginnings in the ’50s. It was designed as a standard mechanism for resolving business problems. Today, statistics will tell you that the language – which was architected to run on virtually any platform – currently consists of 150 to 200 billion (or more) lines of robust COBOL code. The statistics also tell us the code still executes an excess of 80% of all business transactions. Each and every day, hundreds of thousands of lines of code are still being developed.

These systems have served their owners well over the years, perfectly designed for the requirements of the time. The current issue, however, is their inability to provide the nimbleness that companies now demand. Given issues such as competitive business pressures as well as the desire to reduce IT budgets and meet market demands, a number of companies are finding their systems are unable to compete. Adding to the dilemma, particularly for older systems, resources have introduced their own individualism into the system, meaning that the system may be less flexible than when initially implemented; resulting in increased maintenance costs and a inability to react efficiently to new initiatives.

To address these business issues, companies are looking to a concept known as Services Oriented Architecture (SOA) to provide more flexible solutions.

WHAT IS SOA?

SOA is a design approach. The underlying architecture of the system is designed so that each of the functional areas has no dependency on any other functional areas. This concept is known as “loosely coupled.” For example, if an insurance company with several legacy systems wanted to re-write their rating system, it would not be efficient to re-write the same logic in each system. The system should be developed in such a way that each system called the new common rating function.

Web Services is another technical phenomenon that has received a lot of attention. Essentially SOA and Web Services go hand in hand, although they can exist in their own right. Web Services is a communications protocol that maps out the set standards to allow services to be accessed over the Internet. You may decide, for instance, that your new rating function will be called by your existing legacy systems via the Web Service protocol. Broker management systems could also call your new rating service to determine premiums within the Broker Management System, without requiring the policy data to be written to the insurances companies’ database.

INTER-OPERABILITY

Allowing your rating function to be called by a number of different external – or even internal – systems enforces another attribute of SOA known as “inter-operability.” For example, your rating system should be able to be called by any other system that knows the format of the message required by the originating system, given those systems have the appropriate authority to do so.

A non-programmatic example of SOA is your DVD player. In order to view the contents of your DVD, the service you wish to invoke is ultimately your television. Essentially, two services and two acts of communicating data are involved. The first is the DVD itself which contains data that will be provided to the DVD player, thus invoking the first service. The DVD player processes the information and then it calls the second service with the converted data, the second service being the television. If your DVD player is integrated with your television, I’m afraid you’re not SOA-enabled. If your television breaks, you have to forgo the whole unit until it’s fixed. Also the repairman will have to test not only if the DVD player within the television is still working, but also whether the television itself still works. Similarly, some of today’s tightly-integrated insurance systems demand higher maintenance.

An SOA Architecture brings with it the following benefits:

Reusability.

* Your rating function can be used by other internal or external systems.

* Your DVD system could be plugged into many other systems, including your stereo and computer.

Maintainability.

* You only maintain one function, as opposed to maintaining rating functions in all your legacy systems.

* If your DVD player breaks, the repairman only has to take apart, fix and test the DVD Player.

Scalability.

* The rating function can be deployed to more powerful/larger platforms without affecting the system that is using the rating function.

* You could bundle a number of DVD players together for recording purposes, although that is potentially illegal.

All of these will result in a greater return on the investment of the cost of one rating function – and a very flexible DVD player.

Some insurance companies have already implemented SOA systems, or are committed to implementing them. Fireman’s Fund engaged IBM on a significant project to SOA-enable their existing legacy systems. California State Automobile Association (CSAA) implemented The Innovation Groups COBOL Services Based system with one line of business early last year; Auto will roll out the project this year.

Insurance companies may be tempted at this juncture to look beyond COBOL, to Java-based systems, to pursue SOA. However, the COBOL option should not be overlooked. Companies such as The Innovation Group have taken a sensible evolutionary step in building upon an already-proven, globally-implemented, COBOL-based Policy Management System to create a system that is services-based.

BUYERS BEWARE!

When insurance companies started looking at Web Front ends for their systems, a number of vendors professed solutions to “plug into your legacy systems.” Similarly, vendors are marketing solutions that profess to allow you to produce services from your existing mainframe system without major change to the underlying system. Although this gives the appearance of an SOA system, your underlying property and casualty application hasn’t altered significantly. Obviously this is okay if you are after a tactical solution, but it won’t fully realize the benefits an SOA solution can provide. Under this scenario, the maintenance cost will not be reduced compared to that of an SOA-enabled system; if anything, this option may increase your IT costs, since an additional layer must also be considered.

Tools are available that purport to convert your legacy code into services. But when I attended one vendor’s seminar on converting legacy code into Web Services, I was disappointed to find that their scope of the term “legacy” included anything that was currently in production – even if it was implemented within the last 24 hours. Using this definition, they successfully converted one Java program that was not a service into one that was. When questioned, the vendor was not able to answer how their solution would convert a “real legacy” application – for example, one that was older than 10 to 15 years.

SOA REDESIGN

Companies are also investigating the option of redesigning their existing COBOL-based system into Services Oriented systems. There are definitely a number of advantages to this; one of the major ones is that it represents a much lower risk than wholesale replacement.

Current systems contain the lifeblood of the company’s business rules. A project that is focused on a redesign with SOA in mind will be able to capitalize on the existing code, extracting various pieces to develop new services. Depending on the existing architecture, it may be possible to introduce Service Oriented functionally to your existing system on a gradual basis so the current production processing will no
t be upset but instead made transparent to the end user. A number of side benefits can also be realized. For example, the code can be audited while it is being analyzed, resulting in the identification of redundant code and performance bottlenecks.

If approached in the right way, and the system is fully SOA-enabled, the system should be quite agile. If the company decides COBOL is not for them at that point, the proposition for converting the existing services from COBOL to another language or another platform is much easier to swallow and less of a risk.

A comforting thought is that newer versions of COBOL are being released that can support Web Services and XML. Standards are obviously very important to the whole scheme of interoperability; according to a recent Celent report, around 80% of U.S. companies have adopted the ACORD XML standards. If one good thing came of the CSIO Portal, it was the introduction and adoption of the XML standards into the Canadian marketplace.

Redesigning the current legacy system will allow a continual return on investment on the existing system; the various industries that invested billions of dollars to ensure their systems survived the stroke of midnight on Dec. 31, 1999, did not throw their money away.

Regardless of whether the approach is to replace or enhance an existing system, the move to Services Oriented Architecture presents a number of appealing benefits:

* Products can be developed, tested and implemented a lot quicker, resulting in a quicker time to market.

* Code reusability and easier maintenance helps to control and reduce IT costs.

* The company can create growth by capitalizing on new distribution channels and meeting both market demands and compliance.

The statement “COBOL is dead” was uttered with the best of intentions. The context was not intended to relate to the demise of the language, but rather to the concept of undertaking a SOA redesign project – the result of which would produce a much more flexible system.

The benefits of flexibility include the possibility that, if a company should decide at some point down the road, migration to another language would be a lot easier. I will be looking for forgiveness from my colleagues at the Toronto IT society.