SOA Issues

Implementing an SOA environment will cost time and money. Some organizations have no budgetary process to finance infrastructure development. In such organizations, all information technology development projects are developed for and managed by a specific customer. This customer assumes all the costs associated with the development of the application. If it were decided, under this model, to develop an application for a customer using an SOA environment, the customer would have to assume the entire cost of developing the environment, as well as the cost of using it to build the application. This system of financing for IT projects punishes infrastructure development.

A better financial model is the one used by car manufacturers, such as Canaxia. Every four years, all of Canaxia's car models undergo a major rework. This rework requires an investment of several billion dollars. In spite of the size of the outlay required, it is accepted because it is known that expensive retooling is the cost of doing business. Therefore, the initial retooling outlay is amortized over the four years of the product run by adding a small amount to the cost of each car. Organizations that adopt a similar approach to financing IT infrastructure will have a competitive advantage in today's marketplace.

Applications built using an SOA will not only be cheaper to develop and have a faster time to market but will be significantly less expensive to maintain. Unfortunately, it is a common financial procedure in most enterprises to separate the cost of developing an application from the cost of maintaining it. It is well known to software engineers that the cost of maintaining an application is several times more than the cost of developing it. An effective method of financing application development is to have the customer pay for both development and maintenance costs. Using that financial model, what maintenance is really costing will become painfully evident to the business side of the enterprise. When cradle-to-grave financing is used, the lower maintenance costs of SOA applications will become quickly evident. Building an SOA and using it to develop applications will demonstrate a positive ROI that will more than justify the initial outlay required.

Architecture is a result of the organization's funding model (Stevens 2002).

You should be aware that as you build an SOA implementation and the system becomes more complex, maintenance or enhancements of the infrastructure components could carry considerable risk. We strongly recommend that you couple all development, maintenance, and enhancements with the generation of automated test scripts so that a thorough regression test can be quickly run. SLAs are a complex area. Certain architectures and applications make satisfying SLAs much easier.

It is relatively easy to write an SLA for a stovepipe application. Tightly self-contained, they are like watches. You know pretty well how they will perform. They are relatively immune to network issues. Database changes are one of the few things that can slow down or speed up a stovepipe application.

See Chapter 1, Systems Architecture, and Chapter 11, Data Architecture, for a discussion of issues related to stovepipe applications.

Distributed architectures such as SOA are at the other end of the spectrum when it comes to specifying and satisfying SLAs. The plus side is as follows:

• The modular, layered nature of an SOA naturally lends itself to setting up parallel, redundant pathways of communication between the various components that are required for the functioning of the service. This can help make a server resistant to network problems.

• The simple, modular nature of the components in the service layer lends itself to achieving stated reliability levels through clustering of servers.

• Asynchronous communication can be much more tolerant of network disruption than synchronous communications.

• Since services are located and connected to at run-time, it is possible for system architects to easily change the location of components in response to systems architecture changes. Distributed architectures also provide the possibility of having applications recover from the unavailability of a component by binding to an alternative component, perhaps at an alternative location.

Following is the negative side:

• The distributed nature of SOAs makes them very vulnerable to network issues. Not just gross network failures that are easy to spot, but also slow, easy-to-overlook network slowdowns and intermittent congestion.

• SOAs are hosted on many machines. A seemingly innocuous change in the availability any one of a number of computers has the potential to disrupt a service.

• The complex nature of some systems built on an SOA makes it very difficult to mathematically derive SLA parameters. Unless you have an extremely thorough system to monitor the elements of your execution platform, initially any SLA numbers will be speculative.

• Yes, there are numerous ways to tune and tweak SOA systems. However, that tuning and tweaking will cost time and money.

In summary, SOAs live in a complex environment. The layered, modular nature of the systems, plus the fault-tolerant ability of the find-and-bind service location system, help SOAs satisfy SLAs.