Answers to key SOA questions

Service-Oriented Architecture (SOA), enterprise users have a variety of fuzzy understandings, these fuzzy understandings are likely to introduce Enterprise SOA projects into misunderstanding, under such circumstances, deploying SOA may lead the enterprise's business astray and understand the key issues of SOA, which may help CIOs avoid the trap in SOA deployment.

　　1. Why do different people have different interpretations of SOA?

The definition of SOA depends on your role in the Organization's business.

For business executors, SOA creates a set of services that the enterprise wants to expose to its customers, partners, or other parts of the organization. For it architects, SOA is an architectural style that requires at least service providers, requestors, and service descriptions. For programmers, SOA is a programming model supplemented by standards, tools, web services, and other technologies.

Of course, the reason why enterprise information technology systems and process management personnel have a seemingly non-SOA concept may also be that software vendors have not explained the meaning of SOA to enterprise users. For example, a service in SOA is not a traditional enterprise service that we understand, but a professional term in software development. It refers to functional modules at the technical level and with fine granularity, it is far from reaching the degree of direct correspondence with the Business Process of the enterprise. Software vendors have not explained this point while emphasizing that SOA brings great commercial value to enterprises.

　　2. What is the relationship between business process management (BPM) and SOA?

BPM and SOA can be deployed separately or in combination.

If the enterprise's IT system is relatively simple and the enterprise scale is relatively small, the same group of IT staff can control all IT systems, then deploy a BPM suite that does not use SOA, you can quickly create, execute, and monitor/manage business processes without deploying SOA. However, if the BPM suite is deployed by one IT team and uses system services from the other IT team at the same time, SOA can help.

If the enterprise's IT system is complex enough, you can consider combining BPM and SOA. Generally, implementing BPM solutions on SOA gives you greater business flexibility. If the BPM project reaches a certain scope and scale, it is best to develop BPM first, and leave the SOA component for future consideration.

It is best to keep the business process team and the IT architecture team in good communication at the beginning and make feasible plans for the future. For example, the BPM suite itself should be able to provide a wide range of connectivity, so that you do not need to fully apply a complete SOA to make BPM run, and do not make BPM and SOA a separate system.

　　3. "Waterfall" Development and iterative development which is suitable for SOA?

It is best for enterprises to deploy SOA through iterative models.

The iteration model identifies a group of functions that are critical to the business and have high value for service support. This model can be subsequently used by subsequent service support projects and activities. If you deploy SOA using the "waterfall" development method used for traditional application development, you may create a service that can only be deployed once, but cannot reuse it later.

With iterative development and deployment of SOA, organizations can be gradually incorporated into the system to reduce the risk of service faults. At the same time, the ability of any organization to accept and accommodate changes is limited. iterative development ensures that new processes and system changes are introduced to adapt to the enterprise's capacity, it will not cause major confusion in the enterprise.

At the same time, in SOA, new features are not always restricted by a single line of business (LOB), and many cross-organizational dependencies need to be considered, iterative development also helps resolve cross-organization coordination.

4. Is web services the same as SOA?

Web services are currently the most popular SOA implementation technology, but they are not the only technology that can be used to develop SOA.

SOA is independent of the number of web services. For SOA, what is truly valuable is the reuse of web services rather than the web services themselves. Even if all the information technology systems are implemented using Web Services, SOA is deployed. Some enterprises use too many web services for the same IT service, and the result of deploying SOA is very poor. Equivalent to SOA, Web services can easily occur in enterprises that want to quickly implement SOA but do not really understand SOA.

Many SOA projects involve integration of legacy data, which is included in systems using "old" technologies such as MQSeries and Common Object Request Broker Architecture. Many of these technologies have been adjusted for SOA and can be used regardless of Web Services. In fact, enterprises can implement SOA only by using MQSeries, CORBA, or even Remote Procedure Call (RPC) technology.

　　5. Is SOA suitable for all applications or environments?

Not all application environments are suitable for deploying SOA. In many cases, the effect of deploying SOA may be counterproductive.

SOA allows you to deploy, combine, and use various application components in a distributed manner based on your needs, to meet your requirements for unified service interfaces and rapid deployment of new services. However, if the enterprise's IT system is not complex and the system is basically built on the same architecture, it is not difficult to integrate the system. Therefore, the implementation of SOA does not bring too many benefits to the enterprise, but may have a negative impact.

Experts believe that SOA may not be recommended for certain applications or IT environments. For example, independent and non-distributed applications that do not require components or application integration; applications with narrow application scope or short life cycle; application environments built on the same architecture. For some enterprises, if they adopt the technology and products of a single manufacturer and have an IT environment with the same architecture, they do not need to implement SOA as urgently as they are, or the implementation effect is not very obvious.

Some enterprises have formed their business support systems many years ago. Although they have undergone many repairs and supplements, they have been operating normally. Professionals believe that this kind of system with old structures, many patches, and heavy responsibilities is not as powerful as the SOA-based major operation, so it is better to wait for such a system to end and re-develop a new system that conforms to the SOA architecture, it is better to conduct natural elimination.

　　6. How should enterprises start to deploy SOA?

To deploy SOA, a clear roadmap should be developed gradually.

When deploying SOA, it is best for enterprises to first develop a clear road map, and then build an SOA architecture from a single application, starting with a relatively simple application. In this way, enterprises can balance the ROI before fully deploying SOA, and accumulate sufficient experience before there are major problems.

When an enterprise plans to deploy an SOA project, CIOs should pay attention to various details, such as whether the software provided by the supplier supports Web Services and SOA, and when developing some applications, whether the application needs to support other business needs, and which applications need to be embedded to Support Web Services. If an enterprise deploys SOA on a large scale, it also needs to establish an enterprise service bus (ESB) to provide service requests through ESB. Of course, the establishment of ESB also requires a process. CIOs must pay attention to the deployment pace.

Although you can find a lot of knowledge about SOA, it is still very difficult to deploy SOA. The most direct reason is that SOA requires high communication between enterprise departments and requires the entire enterprise to be ready for change. After the problems caused by changes are solved, technical problems may occur. Therefore, enterprises need to prepare a variety of SOA deployment in advance and have long-term detailed plans.