Waiting for Application Integration Standards to Mature Could Be a Terrible Mistake We've all seen the press: "Web services will change the way we integrate applications." "Web services will revolutionize distributed computing." Can the industry afford to wait for this magical group of standards that hold the promise of revolutionizing the way we integrate and build applications? Can you afford to wait, when the waiting itself could prove harmful to the overall health of your company? To answer those questions, you must weigh the value of a standard with the downside of the delays due to arcane internal politics within the standards organizations. We've been here before. If you're as old as me (I'll be 40 this year), you remember the component programming "revolution" that promised to eliminate the need for custom development, as applications would be built out of prebuilt software components. You may also remember the two competing component standards, OpenDoc and ActiveX, that were to take us down the road to component nirvana. Many application development projects stalled as developers and architects waited to see how the standards would evolve and who would win; in the end, neither standard really made much of a difference in the way we do development today. In fact, most of those who waited for ActiveX or OpenDoc have moved on to Java-based standards. Other examples include the evolution of the distributed object standards of the early 1990s, something that never really caught on for the majority, but did delay projects as those looking to leverage the CORBA or COM standards waited for the standards to mature...and they are still waiting today. Those are just a few of many examples where we stopped work to wait for standards that never evolved, or evolved too late in the game. Factoring in Standards Clearly, the industry is waiting for standards in the world of application integration, and for good reason. The solutions today are largely proprietary. The vendors responded with standards around XML, Java, and Web services. They are in the process of defining the second generation of these standards to fill in the missing pieces. For example, the Web Service Interoperability Organization (WS-I) as well as the Web Services Security standards (WS-Security) promise to normalize the competing Web services standards in use today. Current issues surrounding the leveraging of proprietary standards are being replaced with the frustration of having to wait for and deal with the emerging Web services standards. Indeed, there is clear evidence that the sloth of the Web services standards organizations is holding up application integration projects. Confused end users wait for the standards to emerge and mature, fearing that implementing now could mean selecting the wrong technology and standard. The lack of progress in Web services standards development results in a slow-up of the adoption of Web services in both intra- and intercompany integration markets. Of course, the slow movement of end users causes vendors to suffer in the short term. The long-term effects are even more worrisome. In some cases, developers spend more time dealing with standards committees than dealing directly with the IT issues of their employer. In short, we begin to think robotically, allowing standards committees to replace traditional innovation. This phenomenon has negative outcomes: First, because the larger players typically drive standards, their proprietary religious beliefs usually take precedence. The genesis of the standards you adopt could actually be created in the halls of Microsoft, IBM, or Sun, and not by a group of end users. This has been my experience in the past. Second, if you wait for some standard to emerge and do not actively engage in work on your organization's IT issues, then you run the risk of falling behind your competition in creating your application integration infrastructure. Application integration is becoming largely strategic to organizations as they learn to deal with business events, such as selling a product, in real time. The value of application integration in the world of B2B is also becoming well known. Finally, standards are not solutions, and they are not designed for your particular business domain. What's more, they are only implemented within products, and are of no value unless they are bound to an enabling technology. Thus you run the risk that, when the standards finally emerge, they won't provide the anticipated value you seek, or the vendor won't implement a standard in such a way to solve your ultimate problem.
Happy Medium It's not the purpose of this chapter to knock standards; they continue to be a very important part of IT. There are many that work, including ODBC, JDBC, J2EE, XML, and XA. However, there are many that are on the scrap heap, including AD/Cycle, Open Unix, and OpenDoc. We can't let standards define our strategic technology as we move forward. Instead, we must leverage mature standards, when and where they make sense, to solve today's problems. To this end, it's important to understand your own needs, and then look for viable options. If standards meet those needs as part of an enabling technology, all the better. The key is that you solve your problem, and not leverage a particular standard to do it. That's "management by magazine" at its worst. What's more, we can't let standards hold us up. If you always wait for the next magic bullet, you may not be serving the needs of your end users. We have to understand that the focus of IT is to solve the business problems of the company using whatever technology is available to do so. Today. |
