Technical Forces Driving the Adoption of Web Services
There are two aspects to Web services. One aspect is the vocabulary of the message being sent. The other is the communications protocol that is used to send the message. This chapter will analyze the forces driving both aspects by looking at two representational examples of what was used before the advent of Web services. The examples in this part show that advances in technology and standards have diminished the number of restraining forces, making change more likely to occur.
This chapter introduces force field analysis and applies it to the adoption of Web services. Force field analysis will also be used in the next two chapters on service-oriented architecture and cloud computing.
Force Field Analysis Overview
Force field analysis is a tool that provides a perspective on the forces at work when trying to make changes in organizations. This approach to analyzing change was developed by Kurt Lewin.1 Figure 5.1 illustrates the concepts of this technique. For any particular activity, there is a goal or vision, which is shown by the large arrow at the top of the figure pointing to the right. There are driving and restraining forces that will impact whether this goal or vision can be achieved.
Driving forces, which help achieve the goal or vision, are shown as arrows pointing to the right in the same direction as the large arrow at the top.
Restraining forces, which hinder goal achievement, are the arrows pointing to the left in the opposite direction from the large arrow at the top.
Figure 5.1 Force field analysis.
At some point, driving and restraining forces are in equilibrium. This is illustrated in Figure 5.1 by the wide vertical line labeled “Status Quo.” Driving forces move an organization from the status quo in the direction of the organization’s goal or vision.
Restraining forces hold back this change from the status quo. These forces can be external or internal to an organization, or external or internal to the individuals in the organization. The relative strength of the driving or restraining forces determines whether change occurs.
Assume, for example, that you want to change a part of a system in an organization. Two organizational driving forces could be a reduction in operating costs and the opportunity to electronically exchange purchase orders and invoices with a particular customer or supplier. An organizational restraining force could be the development cost for making the change. Figure 5.2 illustrates this concept.
Figure 5.2 Force field analysis for making a system change.
Of course, there could be many other forces at work than those shown in Figure 5.2. The nature of the driving and restraining forces could also vary by organization even if the organizations were attempting to carry out exactly the same tasks. In fact, they can vary among departments in the same organization.
Essentially, the purpose of this model is to make all the driving and restraining forces visible so that decisions concerning change can be made with the best available information. There are various ways to use this model. If you want to make change more likely, you need to either strengthen the driving forces or weaken the restraining forces. Weakening the restraining forces is sometimes the best approach. Strengthening the driving forces can make the restraining forces stronger. In Figure 5.2, developing the electronic exchange capabilities of this change is restrained by the costs of development, effectively resisting change from the status quo. So, perhaps it is possible to adopt an industry standard for electronic exchanges, thus weakening this restraining force. In the figures that follow, weakened restraining forces are shown as gray arrows to indicate that the restraining force is fading away. Figure 5.2, for example, shows the costs of development as weakened and less of a concern.
Adopting Standard Data Element Definitions
In the early 1980s, many large organizations were running custom software and there was very little use of packaged software. At the time, it was believed that there would be opportunities to internally exchange data more easily, reduce development time, and possibly reduce maintenance costs if all the custom software were to use the same data element definitions. These opportunities are shown as driving forces in Figure 5.3. Restraining forces related to cost offset these driving forces. Figure 5.3 shows the restraining forces of costs to developing the standard definitions and the costs related to changing existing systems.
Figure 5.3 Force field analysis for adopting standard data element definitions.
There are additional restraining forces in this figure. In some cases, there were valid reasons that two different systems used different definitions for the same data element. At the time, there had been little progress in developing a standard set of data element definitions that could be shared by various organizations. Therefore, the cost of developing a standard set for a single organization was quite high because it involved starting with a clean sheet of paper. Even if efforts to use standard data element definitions had been successful, the first merger or acquisition would likely cause a problem. The systems used by every other organization would likely have different data element definitions. Finally, as the use of packaged software increased, the definitions used in those products would most likely be incompatible. With enough mergers or acquisitions and use of packaged software, you would be back at the starting point with incompatible data element definitions.
Times have changed since the early 1980s and so have attitudes toward standard data element definitions. Some industries can see advantages in having standard definitions so that data can easily be interchanged among organizations. Another advantage to standard data element definitions is that they lessen the integration efforts involved in mergers and acquisitions. The term data element definition has more or less been replaced by semantic vocabulary. Chapter 3 discussed the opportunity and importance of standardized semantic vocabularies. A sampling of such vocabularies by industry can be found on page 179.
Adopting a Standard Communications Protocol
There has always been interest in connecting two or more software systems together. This is achieved using a communications protocol. Prior to the introduction of TCP/IP in the 1980s, adopting a communications protocol was a major undertaking.
The intent was that adopting an organizational standard communications protocol should reduce development time and maintenance costs. These are shown as driving forces in Figure 5.4. Before TCP/IP, there was no standard protocol and different protocols could be found among software products offered by various vendors. There was limited training and tools for the protocols since they were often only available from the software vendor or a few third parties. There were most likely differing semantics in data sources requiring semantic translation. The message transmitted was more often than not in a fixed-record format. See page 27 for possible issues related fixed record exchanges. Finally, mergers and acquisitions could easily bring in different communications protocols since there was no standard. Figure 5.4 shows these restraining forces.
Figure 5.4 Force field analysis for adopting a standard communications protocol.
Adopting Web Services
Compared to standard data element definitions developed separately for each organization and differing “standard” communications protocols, the use of Web services makes creating interoperable systems much easier. Web services use both XML or name/value pairs for message formats and HTTP with TCP/IP on the Internet for a communications protocol. This greatly reduces restraining forces that had existed prior to Web services. Figure 5.5 shows the driving and restraining forces for adopting Web services.
Figure 5.5 Force field analysis for adopting Web services.
Figure 5.5 retains all of the driving forces from the prior techniques: easier exchange of data, interoperable networked applications, reduced development time, and reduced maintenance cost. There are also additional driving forces. Many industries are working on industry-wide semantic vocabularies for tagged languages such as XML or other languages that use name/value pairs. This relates to the reduced brittleness driving force. The widespread adoption of Web services has pushed many vendors to incorporate the use of Web services into their products and services. The growing use of Web services also results in a significant growth of external services that can be used by organizations of any size. Similarly, there is an abundance of training and tools on Web services.
The restraining forces affecting the adoption of Web service are fewer and weaker than the preceding techniques. Among the remaining restraining forces are lingering different semantics in data sources and semantic translation. There are, however, efforts in various standards organizations to simplify the semantics and standardize the semantic translation.2 Those standards are still evolving, which is why they are seen as a restraining force. Nevertheless, as time goes on these restraining forces will weaken. These weakening forces are shown in gray in Figure 5.5.
Finally, mergers and acquisitions are shown in Figure 5.5 as a weakening restraining force for the adoption of Web services. The broad adoption of Web services by product vendors over time increases the likelihood that an acquired organization will use Web services. Mergers and acquisitions also appear as a driving force. This is for those industries where mergers and acquisitions are commonplace. Easing technical aspects of mergers and acquisitions could, for example, be a driving force for current efforts to develop industry-wide vocabularies for Web services. The reason for the dashed line in Figure 5.5 is because this driving force is not likely to apply to all industries.
Summary
This chapter analyzed the forces driving the adoption of standard vocabularies and communication protocols. It started out by looking at two representational examples of what was used before the advent of Web services. The examples showed that advances in standardized semantic vocabularies and Web services communication protocols have diminished the number of restraining forces, making change more likely to occur.
1Kurt Lewin, Field Theory in Social Science (New York: Harper and Row, 1951).
2See http://www.service-architecture.com/web-services/articles/organizations.html.