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.
|Recent Datamation Columns|
|Security Guard: Siding with Judges on Privacy -- Paul Desmond E-Comment: Popular Sentiment, E-Business Reality -- Chris Pickering Enterprise Advisor: Here Comes Microsoft (Again) -- Joshua Greenbaum Quality Quest: Quick Wins Almost Always Lose -- Linda Hayes|
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:
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.
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.