Do You Have a Standards Policy?
"What's your formal policy towards the use of standards?" is a question we're increasingly asking to our customers. Often the answer is "We have no such policy" or the vague "Our policy is to follow open standards."
As I will explain in this column, I believe every project needs a well-defined policy on this increasingly important topic.
The True Benefits of Standards
The politically correct view is that standards are a Good Thing, with capital G and T. Yet strict adherence to standards comes at a cost: Standards are notoriously slow to develop, which might delay your project (witness the three years it took W3C to release XML Schemas). Also standards are often too broad for your needs, which force you to support features you will never use.
It's no surprise, therefore, that faced with the challenges of delivering a project on time, we're only too happy to take a shortcut and turn to proprietary solutions. Is that a good idea? There's no universal answer: It depends on the specifics of the project, the standard in use, and where it is being applied. My advice, to avoid losing focus, is to formalize your needs in a standards policy.
Internal and External Reasons
Let me take one example of a standards policy. Suppose you work for a film processor and you are tasked with building the e-commerce interface, e.g., to take advantage of the growing popularity of digital photography.
|The benefits you derive from those standards vary, depending on where you deploy them.|
You will need to consider standards in the internal and external interfaces. The internal interface is where your project will interact with your back-office. The two most likely candidates in that space are J2EE and .NET.
The external interface is between your new e-commerce solution and your customers. This includes HTML, XML, JPEG, TIFF, but it may also include Flash or ActiveX.
More specifically, the benefits you can derive from standards used internally and externally are different.
Costs and Benefits
The benefits you derive from those standards vary, depending on where you deploy them. For the internal interface, the primary benefit of adopting a standard is that it increases competition amongst the vendors.
Increased competition translates in lower costs; but, and this is key, you derive those benefits not from strict compliance with the standard but from the fact that your chosen vendors had to compete against other vendors. The benefits of adopting a standard have already been realized by the time you adopt the product. Therefore, the pragmatic attitude is to use the standard but not be "religious" about it. If you can save time and effort by using vendor-specific extensions, do so.
On the other hand, you use external standards primarily to lower support costs. Consider: The alternative to an HTML-based interface is a desktop application that collects the images, uploads them to your server, and prepare the order. However you would need to port the application to different platforms: Windows, Macintosh, and Linux most likely. You would also need to support users actively, manage the updates, network connections, and the like.
Adopting standards in that space lowers your cost by shifting some of the effort onto the customer. As long as you support standards, it's his or her job to update his or her system.
Therefore, you have to be more religious in your support of standards in the external interface. The benefits are only realized if you stick to the standards. Vendor extensions may appear as if they save you time and effort, but those extensions may come back to haunt you when incompatibilities occur at your customer site. Ultimately, that increases support costs that nullify the benefits of adopting standards in the first place.
Standards used to be a non-issue in project management, but as organizations tighten their links with their customers and business partners, compliance with standards may help control costs and increase benefits. My advice is to identify clearly what standards you want to use and where. More importantly, document the benefits you hope to derive from those standards (which may be identical or differ from the example I introduced here) in a formal policy.
Without a clear policy, the project may fail to realize the benefits of your investment in standards.
About the Author
Benoît Marchal is a Belgian developer and writer. He is the author of XML by Example (two editions) and Applied XML Solutions, as well as a columnist for developerWorks. There's more on this topic at marchal.com.