Michael Rowley writes: New technology for simplifying development is always good, right? New APIs and servers just make it easier to develop SOA applications, right? And, of course, developers have all the time they need to adjust to the big changes that SOA development imposes on them.

Of course, this isn’t true. With any technological change as important—and beneficial—as the shift to SOA, it takes time for developers and businesses to absorb the important standards, to implement them in real applications and to get comfortable with the impact of SOA on the overall development environment. In short, it is important for vendors to release technology on a schedule that makes it possible for users to consume the technology, and to support it in ways that allow developers and businesses to recoup their investments in those products.

Recent announcements from Microsoft got me thinking about the tension between a vendor's desire to create new development technology and the developer's desire for predictability in the pace of change for the technologies they use to accomplish their work.

Microsoft will soon be releasing Workflow Foundation (WF) 4.0, which will have some big changes from previous versions, primarily for the purpose of simplifying development. There will now be a flowchart workflow style, which will join the sequential and state machine workflow styles that already exist.

WF will be integrated with the Windows Communication Framework, and developers will be able to deploy the resulting Web-service enabled workflows to the “Dublin” application server. So the first question that comes to mind is, if you can develop Web-service-enabled flowcharts using WF and deploy them to Dublin, how many people will still be interested in buying BizTalk Server? Actually, that is just a question for Microsoft product management to worry about. I’ve got bigger questions.

How many technologies do we need to accomplish the same thing? How many times can Microsoft add a new technology for simplifying development before the number of simplifying technologies becomes just too complex to follow? Once we have learned the latest-and-greatest way of developing apps, how long should we be able to expect that knowledge and those skills to be relevant? And what about the code and other artifacts? Even if there is an attempt to continue to execute code from older versions, it is hard for any vendor to provide comprehensive forward-compatibility for abandoned products.

Standards are typically looked to for interoperability or portability. But standards have another important value: stability. The standards development process is inherently tortoise paced, especially in comparison to the hare that is any group of fired-up software engineers inside a vendor, attempting to create the next development-technology breakthrough. In contrast, standards-setting work requires that a diverse group of individuals and companies all think that some technological advance is worth the disruption. It certainly happens, but it happens slowly. And that’s a good thing for the developers and companies that adopt the standard. It delivers reliability and predictability when developing new applications.

If you were to develop an application using Oslo to create a flowchart where the activities are calls to Web Services, you would be creating a service orchestration. The standards that are important for service orchestration are WS-BPEL and BPMN. WS-BPEL was partly designed by Microsoft, but support for it in Microsoft products has been half-hearted at best.

There is a community technology preview of an activity library that supports the OASIS standard (which is WS-BPEL 2.0), but the supported product release has yet to see the light of day. Microsoft just seems to be too anxious to release the next great thing to be slowed down by the more stately pace of standards, or to deliver full support for standards it did, in fact, help promulgate.

And BPEL is continuing to progress. There is an OASIS committee now standardizing support for human activities with BPEL via the BPEL4People and WS-HumanTask specifications. An OMG workgroup is also developing BPMN 2.0, which will be more closely aligned with BPEL than the current 1.1 version of the standard is.

Development technologies should be evolved with exceptional care. A large body of software will be developed that depends on the technology and that software will be expected to live and evolve for many years. In this respect, development technology is akin to laws: They shouldn’t be made or changed lightly. In any democratic government, it isn’t good enough for one person or even a small group of people to think that a law would be a good idea in order for it to be enacted. It has to pass the muster of one or sometimes two legislative bodies, plus get by an executive. This slows things down, and many times stability in the law is as important as having the right laws.

In this small respect (and not many others), the analogy with development technology holds. In many cases, having a fairly stable set of development technologies is better than having a fast-changing set of technologies, even if an argument could be made that the changes are for the better. They should be a lot better, and if they are that much better, it shouldn’t be too hard to get a group of companies to sponsor an effort to standardize the advancement.

If the standards body follows an open process, as OASIS does, it is possible for the user community and the vendor community to follow the technology as it develops. By the time it is done, it is a surprise to no one, and vendors and users will understand it and be able to use it.

Microsoft’s interest in creating conforming implementations of standards waxes and wanes at regular intervals. They are continually fighting their own desire to invent nifty new technologies with their developer community’s desires for them to follow standards. It is up to the development community to keep the pressure on Microsoft to do the right thing.

Michael Rowley is director of strategy and technology for Active Endpoints, which offers open-source SOA business orchestration software.