Much of the dramatic growth of the Internet can be credited to a single organization: the World Wide Web Consortium (W3C). By serving as the clearinghouse for the submission and approval of the standards that define how companies and their products interface with the Internet, the W3C has shepherded the growth of the largest computer network in history. Although we all inherently understand the value of standards and have seen institutions like the Internet prove their worth, it’s still difficult to get standards defined, maintained, and adhered to in our own organizations.

Part of the problem with implementing internal standards is that we have all that “legacy stuff” that never quite fits the body of standards we create. Most companies also don’t have a well-defined process for the submission, approval, and enforcement of the standards they need to make their business systems run efficiently. But with the example of the Internet to follow and the move toward Web services requiring companies to rethink their systems strategy, this is an ideal time to consider how to implement your own company’s W3C equivalent. To get started, you must determine what your process will be for developing standards and for which major areas you will form working groups to oversee the process.

The standards process
Just like the W3C has to deal with constituents from multiple companies with varying needs and desires, companies developing their own standards teams need to accommodate the needs and desires of constituents from many different business units. In the good old mainframe days, standards were simple: The customer was the accounting department, and the standards were defined by what was installed.

We’ve come a long way since then, and we need to take a few steps backward. With all of the choices of systems, software, and development platforms available, and with the needs of many departments being met with technology, it’s incumbent upon the leader of technology implementation (typically the CIO or CTO) to find a way for all of these participants to have a voice.

The W3C organization and process is a simple but effective metaphor for how to successfully manage standards for any company. Individuals or companies submit draft specifications for new standards. W3C members who have an interest in seeing those draft specifications become recommendations agree to participate in working groups that make recommendations. The working groups then create the recommendation for approval by the members of the W3C. Although the actual process is much more detailed, this basic process is a great starting point for companies that want to develop their own internal standards.

Creating your own standards group requires soliciting participation from all of the departments who use technology extensively. You should make it clear that the participants will be expected to spend significant time in working groups. These groups can follow the W3C methodology of defining the standards, but you should also get agreement from the departments that they will abide by the standards once they reach the recommendation stage.

If a group starts an implementation based on a draft specification, the managers must understand that the department will move their implementation to the recommendation once adopted. Proper standards implementation will not only ensure that systems implemented by different departments will interoperate, but will also make it easier for future generations of developers to enhance and extend the departmental systems.

Documenting systems and forming new working groups
Once you have a set of standards in place, it’s easy for standards committee members to find opportunities to enhance company standards. The hard part is determining what initial standards need to be developed.

The first major task is to document the currently installed systems and applications. These need to be divided into core systems and transient systems. Core systems are those upon which you will build future systems (and around which you will define your standards). Transient systems are those you have to continue running for legacy reasons but are prime candidates for replacement once new system standards are in place.

Once the core systems have been identified, then core working groups should be defined around the operating systems, operating procedures, development tools, and development methodology used to develop and maintain these systems.

Now you can focus on issues that you will face not only within your organization, but, more importantly, between your company and your customers and partners. As you move from a company run primarily on internally developed and managed systems to a company that relies on external Web services and also delivers its systems externally as Web services, it’s critical that standards are in place to allow you to not only consume others’ systems, but also to make yours easy to consume without sacrificing security.

Here are some major areas that new working groups should consider:

  • External authentication
    How will your systems be able to authenticate external users, whether those users are people or systems? Will you use external authentication mechanisms like Microsoft Passport, or will you have to create your own internal systems for maintaining IDs, passwords, access rights, and permissions?
  • System interfaces
    Even though Web services are based on standards like Extensible Markup Language (XML) and Simple Object Access Protocol (SOAP), there is still lots of work to do for companies to develop a standard method-calling syntax, determine which security and transport protocols they’ll use, and solve other key system-to-system issues.
  • User interface
    We’re still years away from making all of our important internal systems accessible via Web services. In the interim, we can make it easier for customers and business partners to communicate with us by developing company standard user interfaces to which all new systems will adhere.
  • Training
    Once standards have been decided, it will be critical to both build programs to keep developers and business process owners trained on the technology and business skill sets initially and to develop continuing-education programs to support those needed skill sets.

Just do it
There are obviously many more potential working groups that you may want to form based on your immediate business needs. The point here is to get started now, because the sooner you have these standards in place, the better. And if you have your own doubts about the project, or if your staff members are less than enthusiastic, you’ve got a proven standards model to follow in the W3C.

What working groups would benefit your company most?

If you were to select three areas for which to develop standards, what would they be? Security, e-mail, development methods, network design? Send us your opinion on what standards are most important.