XML.com

The Selfish Tag
by Edd Dumbill | Pages: 1, 2

Reasons to be Selfish, Part Two

Thus far we've seen that there are hazards of using standards, and that they shouldn't be used blindly. There are undeniable benefits of using standards, however, but a strong self-interest should be your guide. So let's look at the positive aspects of being selfish. There are many advantages of "rolling your own," despite the stigma of wheel reinvention. Also, there are times when not doing so makes sense, too.

Retain control

Nobody knows your business better than you. It's essential when planning to have control over as many variables as possible. If you want to start delivering information to your customers in XML format you might be faced with the choice of waiting 6 months for a standard to be completed, and associated reworking of your systems, or to define document structures that meet your business needs straight away.

There has to be a convincing case above and beyond altruism to risk your business with standards developed by third parties. The two main reasons to do this are when it's useful for creating new business or when it will cut costs. Needless reinvention is as stupid as blind adoption.

Standard is not the same as well-designed

Economics aside, developers have a strong interest in the good design of a system, which can be jeopardized by external dependencies. It is possible that standard technologies may not have a good design or that their future development is not guaranteed to happen in a sane way.

If you know you can do something better, and it doesn't affect your business adversely, then ignoring the standard makes a lot of sense. On the other hand, if you have to adopt a standard, be sensible about the way you do it.

How much the adoption of a standard affects you depends on how you design your systems in the first place. The inherent instability of most XML standards means that it would be hazardous to the long-term health of a system to build it around the standard itself. Instead, it would seem sensible to always build around models of your own business data and processes.

We must understand that business is the strongest driver of standards, not technology. Consequently, it seems folly to let somebody else's business make decisions that directly affect your own. Reserve the ability to interface with standards, but don't take them into the heart of your own strategy. If you must become strongly involved, then you should also become involved in the development of a standard.

Leave it until later

One of the hazards of systems development is over-specification: that is, anticipating future requirements and overcomplicating a system to fulfill them. In many situations, those future requirements will never actually arise. The Extreme Programming people call this "Big Up-Front Design" (BUFD).

The antidote to BUFD is to build only what is necessary and retain the ability to change a system to respond to varying needs. For instance, a firm manufacturing widgets might be concerned about the ability to conduct business using technologies established as a result of the ebXML project. It might want to take this into account when developing an internal system. By any reckoning, such a scenario is probably two years off. A sensible policy would be for them to use such XML technologies as fit their immediate needs, but to be aware of the broad requirements of electronic order fulfillment, and make such provisions as are necessary not to make this cost prohibitive to implement at a later date.

In the current economic environment, few can guarantee consistent levels of market or funding over the next six months, and even "short" periods like two years seem a long way off. Doing the least necessary work but preserving the ability to change makes more sense than ever.

The effects of BUFD are also felt within standards themselves. The more traditional approach to standards are that they're distilled from long-term agreement on particular aspects of a technology. ANSI C is a good example. However, many of the standards we must now contend with in the XML world are more like inventions-by-committee, lacking the assurance of being tried and tested. By the nature of their creation, they are extremely vulnerable to over-specification.

Several such standards have withered due to not addressing popular requirements or else have entered into a second generation of adjustment in the light of experience. In either case, there are costs inherent for those who adopted early. Developers should feel justified in picking and choosing carefully.

Reasons to be Selfish, Part Three

Also in <taglines/>

XML 2004: After Declaring Victory, What's Next?

An Old New Thing

Moving On, But Not So Far

XML at Five

Whither Web Services?

If everyone adopted the cautious self-centered approach mentioned above, might we never have had XML in the first place? Plainly, this selfish policy that I've outlined isn't directed at visionaries or missionaries. But the large majority of the developer community is not out to change the world. Most developers are out to get paid so they can feed themselves.

In fact, XML's essential qualities allow the selfish policy to succeed. By using XML 1.0 and namespaces, you've already made a large commitment to interoperability with others and assured yourself of future flexibility. In most cases, simple transforms will be enough to enable you to fulfill relationships with external parties. XML's major benefits are to be reaped on the outside, not the inside, of a system.

It is vital to understand that XML is not a platform, however much companies would like to market it as one, and that it's entirely possible and very sensible to use as much or as little as you need. The benefit of XML is that it has provided a way to exchange data in a decentralized way, where individuals can retain control over their destiny. Clearly this runs counter to the dominant inclinations of large corporations, who would like to recover their advantage by tying more and more into XML, and making it into an all-or-nothing platform.

A selfish -- some may prefer pragmatic -- policy is entirely in line with using XML. It may well benefit you to adopt XML, and reap the benefits of interoperability and flexibility, but there was and is nothing about XML 1.0 that mandates the recentering of strategy to blindly follow standards bodies. Standards should be made to compete, and present tangible benefits to their adopters, and not be the insidious mechanism of those seeking control.

I will end by highlighting the major recommendations for pursing a selfish policy of XML development, and I certainly welcome and encourage discussion and feedback in the forum below.