Benefits of an SOA

SOA can be of enormous benefit to the modern enterprise. It provides an important new avenue for integration of applications. Creating new applications under an SOA offers a significant increase in the qualities of availability, interoperability, maintainability, and reliability for those applications. For the enterprise as a whole, the SOA translates into lower operating costs, lower development costs, higher quality, and greater corporate agility.

SOA benefits flow primarily from breaking applications into modules with a well-defined interface contract that leads to very loose coupling between services and applications. Loose coupling between consumer and provider benefits the consumer because consumer applications are effectively protected from changes in service provider implementations and the consumer has a greater choice of providers. It benefits the provider because from an implementation of loosely coupled systems come applications that map much more closely to the business processes that represent a company's value proposition. In addition, these applications increase the enterprises' competitiveness because they are easier to modify to satisfy changing business conditions. In addition, applications and work processes assembled using an SOA are cheaper to maintain. Organizations that adopt a service-oriented philosophy of development will be able to handle change more quickly and cheaply. SOA can provide a major increase in the value of the data and application resources of a company by enabling a major new mode of integration of these assets.

The benefits a Service-Oriented Architecture lie in the following areas:

  • Decreased application development costs

  • Decreased maintenance costs

  • Increased corporate agility

  • Increasing overall reliability by producing systems that are more resistant to application and equipment failure and disruption.

  • Providing an application upgrade path that is considerably cheaper and less disruptive than the total application replacement that is the norm using monolithic applications.

Let's examine these areas in detail. Application development costs are reduced for the following reasons:

  • Code reuse is extensive.

  • Most of the code has been thoroughly tested.

  • The presentation layer is the only layer requiring customization for different clients.

  • RAD development via automated code generation becomes a possibility.

Once the infrastructure of an SOA has been built, and the application development staff has been educated in its use, you'll see extensive reuse of the SOA infrastructure's code. Building new applications becomes close to a plug-and-play operation. This plug-and-play ability derives from the manner in which application functionality has been factored into components and from the loose coupling between these components.

Reuse will also substantially reduce the time and expense involved in testing new applications and certifying them ready for production. Since the bulk of the code and logic lies in components that have already been extensively tested, the testing effort will probably only be regression testing. Even more important than reducing the quantity of code that must be tested is the fact that the really difficult stuff the transport, resource access, and business logic has not been changed and hence needs little attention from your quality assurance (QA) team.

A solid, well-tested SOA implementation also substantially reduces the risks involved in developing new applications. That reduction in risk stems from the fact that the application will be largely assembled from a palette of well-tested components. The parts that are new will be isolated from the rest of the application by loose couplings. This will have the effect of limiting and controlling dependencies between what is new and what is well tested. This will allow application development to proceed with a significantly higher level of confidence.

In practical terms, when the business side of Canaxia asked for access to a set of information that resides partially in CRM and partially in the financial systems, the application development team was able to quickly respond. It could state that the GUI layer was going to take 3 person weeks for development and QA; the service to access the information in the financials would take 4 person weeks; and the component to access the CRM would take only 1 week because an existing module could be modified easily. Integration would take another week. The business customers were very pleased with the speed that the design generated and the quick development that was provided. They were even more pleased when it was discovered that the functionality of the application could be greatly enhanced by accessing a different section of data from the financials and that the application development team was able to satisfy that new requirement by developing and plugging in another data-gathering module.

Development of user interfaces, particularly browser-based GUIs, is only minimally enhanced by an SOA. An SOA does insulate the GUI code from all the back-end details, and that makes GUI development much faster and maintenance much easier. The GUI needs only to capture the data in some form and pass it to the transport component. If the application is browser-based, the transport will be HTTP/S, SMTP, or FTP/S. If it is a Java Swing or Microsoft Foundation Classes GUI, the transport layer could be any of the transports mentioned, plus Java RMI, DCOM, or CORBA IIOP. It has been our experience that separation of the transport functionality into its own layer means that it takes only a few lines of code to select the proper transport and pass the data to the correct service.

SOA designs are amenable to the development of RAD tools to speed the development of new services. Since the service contract is published in a directory and easily accessible it can be used by a modern integrated development environment (IDE) to generate code that will connect to the service at run-time. Many service frameworks can also configure a dynamic proxy using the contract to connect to the service at run-time over various transports. RAD development is made possible by the modular, layered architecture of the SOA and the lack of dependencies among the various layers.

A good SOA implementation reduces maintenance costs due to the tested nature of the code and the fact that the production support staff is more familiar with the back-end code. Due to the modular nature of the components in the various layers, once they have been tested and debugged, they can be plugged in with confidence where needed. The lack of dependencies among the various components in the different layers is also very important in reducing the cost of maintenance of applications developed under an SOA framework. The fact that the dependencies are so few and are well known makes it easy to state with confidence that a given change will have no unexpected side effects. New application development carries a maintenance risk as well as a development risk. Building applications using an SOA will reduce the maintenance risk as well as the development risk. Production support staff will soon become familiar with and confident in the SOA code. Since this code is well tested and debugged, the production support people must comb through much less when a defect appears in a new application.

Instituting an SOA framework is an important step in the direction of building a product line development system. See Chapter 4, Software Product Lines, for further details.


We're talking about a measurable and significant reduction in recurring IT costs. This is not a one-time reduction in costs but savings that will persist.

For most enterprises, a major value added for an SOA is that it greatly increases the agility of the corporation. This increase in agility is due to the way in which SOA makes it easier to respond to new conditions and opportunities. It is possible to build an adapter layer that allows easy access to the services from all clients who are known now, which makes it easy to open the service layer to client access modalities that haven't yet been imagined. The fact that the services themselves are loosely coupled to the service consumer makes it easy to change the implementation of the service without affecting the client. This provides a relatively simple and painless evolutionary pathway for the applications that satisfy the business needs of the organization. In addition to allowing evolutionary growth and change, the SOA makes the possibility of revolutionary change much simpler.

SOAs can be used as a method to integrate legacy applications by exposing sets of their functionality as services. Once legacy application functionality has been externalized as a service, modifying, replacing, or outsourcing that function becomes a much more manageable proposition. The reduction in IT costs brought about by the cheaper application development and maintenance that come from an SOA also helps to make a corporation more agile.

SOA is one of the most effective tools to use for incremental integration of legacy application functionality. Once an interface (contract) has been defined for some part of a legacy application's services, plugging that interface into an SOA is relatively straightforward.




Practical Guide to Enterprise Architecture, A
A Practical Guide to Enterprise Architecture
ISBN: 0131412752
EAN: 2147483647
Year: 2005
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net