Standards Now Or (Lots Of) Cash Later

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

The whole area of standards is fraught with emotion. Nearly everyone in your organization will have an opinion about what the company should do about operating systems, applications, hardware, software acquisition, services and even system development life cycles. Everyone. Even the people who have nothing to do with maintaining your computing and communications environment will have strong opinions about when everyone should move to the next version of Microsoft Office. In fact, discussions about standards often take on epic proportions with otherwise sane professionals threatening to fall on their swords if the organization doesn’t move to the newest version of Windows (or Notes, or Exchange — or whatever).

It’s likely you’ve heard references to return on investment (ROI) and the total cost of ownership (TCO) every time the subject of standards comes up. Let there be no misunderstanding here: Environments with less rather than more variation will save money. Or put another way, you have some choices. You can aspire to be sane or insane.

What does business management really want here? Standards are a second-order business driver. Most companies don’t associate standards-setting with business models, processes, profits or losses. Whether the environment has one, five or 20 word processing systems has probably seldom been associated with business performance: It’s hard to link homogeneity with sales! But the fact remains that expenses are clearly related to sales, and standards are closely related to expenses. Herein lies the subtlety of standards and alignment.

What else does business management want? They want flexibility — and that is the real argument against standards. If your environment doesn’t support the business computing or communications processes the business feels it needs to compete, there will be loud complaints. Business managers want to compute and communicate competitively. Standards are often perceived as obstacles, not enablers.

Try out these standards questions:

How varied is your current environment? How do you know?
Do you know what it’s costing you to support a highly varied environment?
What is your organization’s tolerance for governance of any kind? For standards governance?
Who’s in charge of standards in your organization? Who’s not?
Is there business buy-in to the concept of standards and to the cost-effectiveness of standards?
Has your organization been audited for its compliance to standards? The result?
Do you have standard desktops, laptops and PDAs?
Do you have a standard communications architecture?
Do you have a standard applications architecture?
Do you have standard hardware and software acquisition practices?
Do you have standard design, development & project management standards?

The answers you give to these kinds of questions will reveal a lot about your attitudes about standards, standards responsibility, authority and accountability — and whether your chances of standardization are high, low or miserable.

If we’ve learned anything over the past few decades, it’s that standards are as much about organizational structures, processes and cultures as they are about technology. The ability to actually control computing and communications environments through thoughtful governance policies and procedures will determine to a great extent how standardized organizations become. We’ve also learned that the more you succeed the less you’ll pay.

Elements of Standards Alignment

The elements of a standards alignment strategy appear in Figure 1.

Standards Alignment

Figure 1: The Elements of Standards Alignment

As always, everything needs to sync with your business strategy — assuming one exists. If none exists, then make sure that you cover your political you-know-what. The real key here is governance and the processes that make standards management effective. Without serious support for a standardized environment, you’re toast. Clearly, less variation in your platforms, applications, architectures, acquisition and disposition practices, and life cycles will reduce your costs. And as always, you need to focus on what the environment should look like in the next two to three years.

The following figure will help you implement your standards strategy. It offers cells in a matrix that you can use to identify, define and prioritize requirements.

Note the distinction between the enterprise and the business division or units. This is a killer distinction since it determines ultimately whether you succeed in your quest to reduce variation in your environment. If you’re in a strong centralized organization then your chances for success are much, much higher than they are if you’re in a decentralized organization with a weak enterprise group responsible for infrastructure. Put another way, it you’re in an organization that has a central CIO whose job is really a “Chief Infrastructure Officer” and whose charter is full of authority holes then you’re not likely to reduce variation in your environment. In fact, you’re likely to find yourself suiting up for one standards crusade after another.

The organizational structures that have the greatest chance of success are either a strong centralized IT organization or a decentralized one that has unambiguous separation of duties, with the infrastructure usually belonging to the central group. This later model only works when there is buy-in to standardization and when buy-in begins to weaken the central management is willing to step in to re-establish standards authority.

The figure can help with a current baseline assessment and with the prioritization of standards requirements. This assessment should be focused on today and tomorrow. An assessment of current variation in each of the areas should be made followed by a strategy for reducing variation over some reasonable period of time.

Standards Framework

Figure 2: A Standards Requirements & Planning Matrix

The figure requires you to look at your governance and processes, your platforms, your primary software applications, your architectures, your acquisition and disposition standards, as well as your life cycles. The objective of these assessments is to reduce variation as a means to save money and preserve flexibility. The figure also requires you to realistically determine your organizational structure’s relationship to standards-setting. If you’re decentralized then you have some serious governance work to do; if you’re centralized then you’ll have fewer religious wars over standards. The figure asks you to think about the enterprise versus the divisions or business units and proceed accordingly.

Here are some standards recommendations:

You need to standardize on your desktop, laptop and personal digital assistant (PDA) devices. Get a couple of vendors to bid, but select one and stay with it until there are too many good reasons to switch! Without a truckload of reasons, stay with the single vendor avoiding best of breed approaches (that complicate your integration and interoperability requirements).
You need to standardize on browsers and on an applications architecture that uses the browser as the common applications interface, that is, the primary way users (employees, suppliers and customers) access applications and data bases. One way to do this is to designate a standard portal application.
While perfect standardization seldom works, the goal should be to standardize on as few word processors, messaging systems, spreadsheets, data bases, and the like that make your company work.
Standardization can be vendor-specific or best of breed. Increasingly, large enterprises are moving away from best of breed and toward a more vendor-specific standardization strategy.
Architectures often fall through the cracks. You need to identify at least the communications, applications and security architectures and standardize as much of them as you can. Move to a single messaging system if at all possible and standardize on groupware, workflow, imaging and related applications.
The way you build applications — if you’re still building applications — and the way you configure your off-the-shelf applications will save you or cost you lots of money. Standardize your applications architecture so you can support your environment as it grows without bankrupting the whole company. Make sure you standardize on a single security architecture as well.
Standardize on the processes by which you acquire hardware and software: one individual or organization in your company should have the necessary responsibility and authority to purchase hardware, software and services for your entire organization. Don’t let vendors divide and conquer you.
Life cycles come in many shapes and sizes. Focus on three: requirements management, development/integration capabilities, and end-to-end systems design, development, deployment and support.
Make someone accountable for developing standards scenarios that calculate the quantitative costs and benefits of standardization. Check out what the competition is doing to gain insight into these numbers. Project what might happen over time if your organization refuses to standardize.

Since standardization does not generate direct impact to the bottom line, you’ll have to communicate why it makes sense to standardize. Use industry benchmarks to communicate why you should standardize and how the process might work.

If you’re lucky you’ll avoid a few religious wars over standardization. Good luck.

Steve Andriole is the founder and chief technology officer (CTO) of TechVestCo, a new-economy consortium that focuses on optimizing investments in information technology. He is formerly the senior vice president and CTO of Safeguard Scientifics and CTO and senior vice president for Technology Strategy at CIGNA Corp. His career began at the Defense Advanced Research Projects Agency where he was the director of Cybernetics Technology. He can be reached at steve@techvestco.com.