SOA s 11 myths

1. SOA is a technology

This myth is the most frequent. SOA is a concept, a paradigm, a new approach to the enterprise software development and automation of enterprise business-processes, but not a technology at all. SOA is only a next stage of the development of software architecture.

Figure 1 shows the development of programming paradigm in time and the place that SOA takes as an approach to the software development:


Figure 1. The evolution of programming paradigm

And here is the place that SOA will take being considered as a stage of enterprise systems development:


Figure 2. The evolution of enterprise systems


So SOA is an approach to creation of an information system in the enterprise or to software development and can be realized by various tools and technologies.

2. SOA is a new and a revolutionary concept

Not much. First of all, return to the figures from the first point, and you will understand, that SOA "has absorbed" all experience and functionality, put by the previous architecture. As well as client-server architecture, SOA works on the principle of demand-reply and functions in the network environment. For today it is safe to say that comparing to the N-level architecture SOA creation with Web-services only is impossible without middleware. If two services cooperate and the format of messages differs, it is necessary for you to use middleware software for messages conversion. Secondly one should not forget about technologies like DCOM (Distributed Component Object Model) or CORBA (Common Object Request Broker Architecture), which were the base for first attempts of SOA creation as far as in the ninetieth.

3. SOA requires creation of Web-services

Not necessarily. Technologies for SOA development vary. The choice is based on physical interoperability of different system components.

Thus SOA realization would be quite expensive in terms of operating speed and volume of networked data for a company working with one LAN. In this case it is possible to create SOA using desktop applications interacting by COM+ technology (Component Object Model with advanced facilities).

4. Any programming solution using web-services could be considered as SOA

A great delusion about SOA is the fact that most people associate SOA with Web-services (see point 3). Use of Web-services is only a part of programming. And besides programming SOA has specific principles of creation, components and standards that every developer of this architecture relies on.

5. EAI, BMP and SOA – different words for the same thing

One can say that these abbreviations hide the cards from the same pack, but nevertheless they are of different suits. Let’s take a closer look at each abbreviation in the light of SOA. EAI (Enterprises Application Integration) is an integration of enterprise applications. Technologies and applications that integrate several applications (developed using different technologies perhaps) used in the same organization in united process and convert data formats between them are related to EAI.

SOA and EAI have several distinctions. At first SOA components of the system interact on the service level (XML messages exchange), not by means of API (Application Programmer Interface) like in EAI. Secondly the “weak” connection of the SOA elements provides the flexibility of the architecture while EAI applications are rigidly bound and can not be transformed. Thirdly EAI is just an integration of enterprise applications, not a concept of information system creation. A lot of people are inclined to consider EAI as a part of SOA, but at the same time we can say that SOA has become a stage of EAI development:


Figure 3. The evolution of SOA as an approach to flexible application interacting.

In a case of SOA and BPM we must talk about their tight interaction. BPM (Business Process Management) can be named a management methodology allowing reorganizing and optimizing of business-processes that is very important for SOA implementation (see point 6). Therefore BPM and SOA should be considered as two sides of the same coin using BPM from the service-oriented point of view and SOA from the business-process point of view. BPM is a side of SOA that unites SOA and business-processes through constant improvement of the latter by means of modeling and simulation done with specific software - BPMS (Business Process Management System).

6. SOA guarantees the adaptation of IT to the business

On single cases of SOA implementation in the organizations one can conclude that first of all business should be adapted to IT and not the reverse. For successful SOA functioning and getting an effect from its implementation all business-processes in the organization should be revised but not at once (see point 8). This is required by the fact that any web-service you are going to create must have well-defined applicable business value. It must be independent, full-function and responding for a specific business-process (e.g. service “Contracts creation”). SOA should not be considered as an implementation methodology or as adaptation of IT solutions to your enterprise. In the wide sense SOA can be treated as a conception of business development: «SOA is about the business, not about IT».

7. Risks of the enterprise automation are less if you choose SOA

Quite a diffused opinion: “We heard that SOA is the most flexible optimum solution. And our business develops and grows. Let’s implement SOA!” At first lots of vendors lack sufficient experience of successful implementation. Secondly SOA can not be replicated for different organizations as SOA is intended for business-processes of specific organization. And what is good for one company can be dead for yours. It’s impossible to buy SOA as packaged software, to customize it a bit, and get your enterprise automated according to the latest IT fashions. SOA is designed, then developed and implemented for a specific organization.

It can be called an “exclusive IT solution”. SOA can change your view to the business management as this architecture optimizes business-processes and makes business flexible, mobile and agile through the quicker IT respond for the business demands. The possibility of implementation of such a solution should be evaluated soberly as the result can fall short of expectation.
 

8. All business-processes should be reorganized and all technologies should be used for SOA implementation

Since SOA implementation is money and resources consuming step by step implementation would be the best way. Create several services for uncritical business tasks and watch the reaction of employees and the benefits of new solution. To rush into using only one technology (.NET, Java) for SOA implementation is a bad idea. Implementing SOA by stages without vast sums of money and trying different approaches you would probably discover a better solution. Pass from small to greater.

9. SOA implementation requires an army of consultants

Not necessarily. You would probably succeed in finding an excellent manager who will be able to organize the implementation process and to explain the importance of this process for the organization to other employees. Besides some human resources benefits he will require some management tool – software that helps to track and evaluate the results of SOA implementation.

10. SOA is applicable only to specific business areas

Many people believe that SOA is used successfully in service, e-commerce and dot com organizations as they provide services to customers. It is to be recalled that SOA is architecture and an approach and it can be applied successfully for any kind of business. Successful SOA implementation projects in manufacturing, finance companies and banks can be the evidence to this statement.

11. SOA is easy

One can agree that the concept of this architecture is transparent and has a clear structure with standards and components that provides fast understanding. But the main complexity of SOA is in services definition, business-process reorganization, optimization of their interaction and their realization according to the principles of the architecture. Realization well-designed theoretically can be irrelevant in practice. Just add to this unskilled employees, security and data consistency problems and you will get all these issues that a SOA project manager has to deal with (see point 8).

In conclusion it is to be recalled that SOA implementation is a serious and important step. You should take into account all the forces – economic and human and have the complete information about all the aspects of the enterprise architecture. Note that successful implementation of such a system not only provides the organization with the opportunity to manage the business effectively but also to respond quickly to all changes implementing new IT solutions on the SOA platform easily.
 

©Borzov Sergey

© Издание 12NEWS (ИП Маринин А.Л.), 2007