Eran Lasser and Ziv MendelThe most popular word in the adds of the various software vendors (Oracle, IBM, Microsoft, Sun, BEA, SAP, Magic) is SOA, a term that appears to be endowed with magical powers when it comes to customers’ buy decisions. Nearly all the announcements and advertisements of software vendors boast SOA, and Oracle even placed the technological term on outdoor billboards in one of its last campaigns. 2007 was no doubt the year of the SOA, not only as far as billboards go but also because of the organizational need to cope with the challenge of speed and the ability of the software to change on one hand, and to integrate the old with the new on the other. Below is an attempt to explain what is needed successfully define an SOA strategy for the organization and to succeed in implementing the organization’s SOA vision.
What is SOASOA (Service Oriented Architecture) is a service-driven technology management approach to system architecture. The basis of SOA and its business rationale are rooted in the need to build the organization’s software development and maintenance setup in such a way that it is easy to make changes and to respond to new needs for functionality in the fastest possible manner. What are the obstacles to making changes and developing new functionality quickly? The main problem is one of integration and the ability to activate one software component from within another. The ability to activate a software component quickly, flexibly, and safely (in other words, without the need to invest a great deal of time in testing the integration) enables us to create a rapid development capability by using existing software components from within and without the organization. The reuse of old software components that created within the organization in the past and that work well, saves new and unnecessary development. Instead of having to write again this code (say, in COBOL), it is possible to wrap and reuse the old code.
Use of external software components, purchased from software vendors or obtained from sites for open code components enables us to achieve additional savings by not having to write code that has already been written by others. SOA enables us to also combine and integrate various systems relatively easily, so that we need not duplicate functionality in two systems. If, for example, the ERP system needs a customer care component that resides in the CRM system, we simply connect through SOA the functionality required by the ERP system from portions of code that reside in the CRM.
The SOA approach provides us with the ability to connect activities and processes at the business level of the organization by combining the various code components. With the aid of the SOA tool, we disassemble the organizational software into its constituent components, wrap them in an envelope of network services, and reconnect them through that new envelope. SOA technology enables us to wrap software components present in legacy systems, external software components, and new software components, and to build an information system integrating the old with the new. Implementing SOA requires an advanced tool that fully implements the standard and allows interconnecting all the universes. The system solution within the organization is built as a process into which the various services are mapped, for example, as a modular assembly line of IT machines. The use of standards (standard connectors between systems) makes it possible to integrate services created elsewhere, by various vendors, together with existing services that had been disassembled and wrapped as services. In the implementation of SOA, we use a set of standards commonly accepted today in industry: XML (a standard method of data representation), SOAP (a flexible structure for message definition), WSDL (a simple method for describing the service to other applications), and UDDI (the ability to publish/locate the application).
Selecting the appropriate productToday all software houses have SOA solutions. The question is: what are the criteria for selecting the appropriate product? We identify four main criteria: (1) ease of integration; (2) ability to connect with all environments; (3) speed of implementation; and (4) low cost, both of the software, of the learning curve, and of the ability to carry out the integration. Based on these criteria, we seek an SOA tool that contains a single development environment with a central data dictionary, and which covers all the technologies and environments without preferences and with full adaptation capability. It is important that SOA development tools have graphic interfaces (eliminating the need for coding) and the ability to work collectively. The tools must be within easy grasp of the systems analyst, the business user, and the programmer. Naturally, the SOA tool must be based on accepted standards in the area of Web services.
We recommend defining the SOA vision of the organization this year (if it hasn’t been done already), selecting the technology, and beginning implementing the SOA approach at the level of the whole organization. As in every heterogeneous environment, it is possible that in some organizations the SOA approach will be implemented on the basis of several SOA solutions, with the central tool in the middle, and various SOA tools are connected to the various technologies operating within the organization. In a perfect world, it is naturally preferable to go with one solution, but in our complex reality this is not likely to happen. It is important to begin implementing the SOA vision in 2007 by selecting the existing applications that are slated for disassembly and wrapping in the SOA envelope, and it is important to begin developing the new applications ahead of time on an SOA basis.
Note that in the first stage the transition to SOA requires investment in creating the SOA infrastructure, a requirement for being able to benefit from SOA. In the areas of flexibility and speed of development we must first build an infrastructure of software components that resides on top of the SOA. This stage does not produce immediate benefits in the area of ROI and requires the correct selection of the locations where we wish to implement it. After the software components have been transferred to the SOA infrastructure, it is important to address the issues of documentation, publishing, and training with regard to the components residing in the data dictionary, so that new projects and the routine maintenance activity can reuse these components through the SOA for easy integration.
If you have any comments or questions, or if you wish to tell us anything about this topic, please write to us at
ziv@johnbryce.co.il.