Around Your Infrastructure in 8 Ways

In order to make cost-effective infrastructure investments, several things should be true:

• You have to know every piece of your infrastructure: laptops, desktops, servers, personal digital assistants, minicomputers, mainframes, communications networks, routers, switches, business applications, messaging applications — all of it. (And if you don’t have an asset management system, now is a good time to think about getting one.)
• You have to know who has the skills in your organization to support and transform your infrastructure.
• You have to know your organization’s plans for e-business and enterprise applications, since most businesses suffer from an “infrastructure gap.”
• You have to know what it costs to run your infrastructure, including both the total cost of ownership of the gear and the return on your investments.
• You have to know what processes define your infrastructure support — that is, how you acquire hardware and software, how you administer passwords, when you upgrade software, who works the help desk, and how applications are tested prior to deployment.
• Finally, you have to know who pays the bills, what you have centrally funded, and what you expect your end-users to pay.

This is a partial list, but you get the idea: in order to improve your infrastructure, you have to know the baseline of your existing assets and their performance.

But you also have to know what your infrastructure is expected to do. Are you primarily a back-office, legacy applications shop maintaining aging applications in centralized data centers? Or are you distributing your applications and making them accessible to remote customers, suppliers, and employees?

Depending on the answer, you’ll need two very different infrastructures. Most likely, you’ll need both: the former while you continue to support your legacy applications, and the latter as you migrate to your future.

It’s also likely that you have an infrastructure gap on your hands. Part of the reason is, of course, cost. No one wants to keep buying new stuff all the time, and, if you’re like most businesses, it’s been easier to invest in new applications linked directly to business processes than infrastructure, which everyone finds hard to define or appreciate.

You can support the databases and applications in-house or via outsourcing, but one way or another the trains must run on time. Interestingly, many IT organizations have already separated infrastructure requirements from application development requirements. In “decentralized” environments, infrastructure usually stays with the enterprise while the applications development professionals move directly into the business units. In these organizations, the CIO is actually the “chief infrastructure officer,” since his or her responsibilities begin and end with the company’s computing and communications hardware — the plumbing.

Companies can influence the effectiveness of their infrastructures through their organizational decisions. Companies that separate infrastructure from applications often do so because they want the focus that segmentation creates. Unfortunately, in weakly governed organizations they also often set up conflict between those who build applications and those who support them. The reality? Make sure that applications and infrastructures integrate and interoperate – and that planning for both are synchronized.

Let’s look at eight elements of a sound infrastructure alignment strategy:

1. Business Strategy
All decisions must be passed through the filter of a business model. If none exists, and you can’t get the organization to invest in business modeling necessary to optimize infrastructure investments, then make minimally acceptable investments until the business strategy clarifies.

2. Governance Policy

Who owns what? You need to determine where the lines of responsibility and governance are between infrastructure and applications, as well as how decisions are made on both sides of the line. For example, is there a common applications architecture, so you can be sure that applications that are developed will efficiently run on the existing infrastructure? Fights here will paralyze your business.

3. Layers Specification

Many IT professionals think about infrastructure as computing and communications layers.
Here are three to focus on:

• The access layer includes the desktops, laptops, browsers, PDAs, and other devices that permit access to your data, applications, communications, messaging, workflow, and groupware capabilities. You need to use an asset management tool to profile your current access “assets,” including any device used to access your applications and databases. You need to determine how skinny or fat these devices need to be. You need to standardize a browser, as well as an architecture that uses the browser as the common applications interface — that is, the primary way users (employees, suppliers, and customers) access applications and databases through your communications networks. And you need to plan for an environment that will support an increasing number of skinnier clients and uses all computing devices as remote access devices.
• The coordination layer includes the query, messaging, directory, security, and privacy services that comprise your infrastructure. It also includes the transactions, application, and Web servers that permit you to support your applications portfolio. You may also invest in the tools and processes necessary to coordinate access and management. The most obvious tools are the network and systems management solutions and frameworks. And make sure you track developments in Web services.

  Lots of vendors will be offering comprehensive e-business applications support in the coming months. While standardization is seldom perfect, the goal should be to standardize on a minimal number of directory services, messaging systems, applications servers, and the like. 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 strategy.

  You’ll need a network and systems management strategy that can be based on individual point solutions or an integrated framework. Point solutions work best in smaller environments where network and systems management processes are hard to define and govern; frameworks work best in large organizations where governance is strong enough to define and sustain processes. The implementation of network and systems management frameworks is complex and expensive. Be careful — and make sure you develop effectiveness metrics for your network and systems management.

• The resource layer includes the applications themselves, as well as the management services necessary to keep transactions humming. It also includes the data, knowledge, content, and metadata resources necessary to support transactions and applications. Your data centers reside in the resource layer of your infrastructure. But data centers will evolve to distributed data centers that (virtually) house distributed applications and data, knowledge, or content, as well as legacy applications and databases — all of which must co-exist in the same infrastructure.

4. Architecture Design

Applications and communications architectures need to be designed and supported. Make sure these designs are done holistically and with reference to the layers described above. Here’s where business strategy requirements get converted into technology designs that support business transactions. Integrated design is complex; make sure that you ask enough smart people to help design your communications and applications architectures.

5. Architecture Implementation

Planning is tough, but too often execution is nearly impossible. Architecture involves hardware, software, and processes, and the discipline to faithfully convert strategic architecture requirements into robust, reliable, secure, and scalable infrastructures. Take the long view here. Build an infrastructure that can adapt to evolving strategic requirements.

6. Infrastructure Management

It’s difficult to find professionals who can support heterogeneous environments. Make sure that your in-house personnel are up to the task. If they’re not, consider outsourcing to a company with the right mix of skills and experience. While you may be reluctant to outsource your data centers, for example, remember that legacy data centers have been outsourced for years. As the number of deployed e-business and enterprise applications rises, it’s likely that legacy data center management will have to be modified substantially to integrate and support newer applications. All of this may make outsourcing the smart move. If you can manage your infrastructure cost-effectively with in-house people, and infrastructure support is on your core competencies list, then go for it. But if you’re in over your head, look for outside help.

7. Effectiveness Metrics

What works, and what doesn’t? Just as it’s essential to track your infrastructure assets, it’s also important to track their effectiveness. Without obsessing over return-on-investment modeling, you should develop quantitative and qualitative effectiveness metrics that will permit objective performance assessments. Business cases should be developed prior to any significant infrastructure investments — and be prepared to pull the plug if the data look bad.

8. Future Modeling

Make someone accountable for developing scenarios that recognize the likelihood of more e-business and enterprise applications working alongside legacy applications. Access, coordination, and resource infrastructure support requirements will rise in number and complexity as your applications environment becomes more heterogeneous. Track your competition, and inject their strategies into your business modeling and infrastructure analyses. And develop a “tiger team” to look continuously for infrastructure gaps.

Steve Andriole is the founder and CTO of TechVestCo, a consortium that focuses on optimizing IT investments. He is a former chief technology officer of both Safeguard Scientifics and CIGNA Corp., and his career began at the Defense Advanced Research Projects Agency, where he directed cybernetics technology.