InformationWeek

ost organizations building large, enterprisewide systems try to reduc e the risk of failure by concentrating their efforts on three major areas-refining application development methodologies, beefing up hardware and network infrastructures, and aligning IT strategy with corporate business strategy. l But with all the attention to system and software architectures, one important piece of the solution is often overlooked-the IT support architecture. This support structure could be the tool that helps enterprisewide information systems reach their potential. l Just what is a support architecture, and why is it important? As the name implies, it is a structure composed of an integrated set of technologies, processes, and strategies designed to support and sustain corporate IT investments. Like the other strategic components of a system project, the support architecture forms the foundation from which strategic objectives can be met. From the perspective of most IT support organizations, those objectives are centered on providing reliable and effective information services at reason able costs. Judging by the skyrocketing costs of supporting modern IT infrastructures, these simply stated objectives are often very difficult to achieve over the long term. l Support architecture provides a mechanism for the support organization to establish its operational and management strategies in concert with end users and developers. Without this integrated approach, there is an increased possibility that

information systems will not reach their post-development reliability, availability, or value objectives. In addition, the synergy provided by the inclusion of the support architecture in systems design can offer end users and support organizations the opportunity to establish realistic and achievable service-level objectives.

Sourcing Strategy
One of the key areas overlooked during system planning is the source of post-deployment support for the system. Typically, during the justification phase of new systems, the identification of business users and sponsors is key. However, t here is rarely a representative from the IT support organization or a clear definition of their expected role in the project. By addressing the support sourcing issue as a component of the support architecture, the design team can make sure that the proper skill sets to maintain the new system are in place.

The question of outsourcing usually comes up when assessing the IT organization. Outsourcing is often viewed as a sure bet to quickly establish support for a new system. But outsourcing alone may not solve the total support problem.

The inclusion of a sourcing component of the support architecture will define the linkages between the internal IT support organization and an outsourcing vendor. The sourcing component will guarantee that outsourcing is not viewed as a separate, discrete solution, but as an integrated component of the strategic support strategy. The support architecture will define the inputs and outputs into the outsourcing function, thus ensuring complete support coverage for the s ystem.

One of the driving concepts of the support architecture is that the operations staff should have a major role in a system design. We've established that members of the operations group are usually the only ones who can assess the true impact a new system will have on the current infrastructure and operational processes. But what about the concept of having developers involved in operations?

We've found that the development of a dedicated support group, or SWAT team, is the best method for making the project successful for some clients. The SWAT team concept is based on the notion that the best people to support a new application are the people who developed it. This concept provides several benefits to the organization.

First, the application will, theoretically, be better supported because of the high level of knowledge the SWAT team provides. The second potential benefit is that by having development team representation involved with support, there is a more concentrated knowledge transf er to the day-to-day support staff.

The third benefit is that by having that representation available very close to the application, the developers are able to get a firsthand understanding of the volume and composition of the problems that are being reported to primary support staff. This link will facilitate faster bug fixes and patches, and potential additional functionality.

The SWAT team should not be a static organization. It should be a dynamic virtual group that has development roles. However, SWAT team members should be part of the formal problem-management escalation process. The SWAT team can also provide the knowledge transfer to the support organization that will enable a smoother transition path from development to production.

System Piloting Strategy
Another often-overlooked component of system architectures is the potential value that the system pilot or prototype can provide to the support organization. One of the key principles of a support architecture is that the development and pilot environments should be a microcosm of the total system-including the system support.

The major benefit of this approach is that it gives the processes, strategies, and technologies of the support architecture the opportunity to mature along with the applications and systems that they are to manage. Early definition of a support structure in the overall system architecture can give IT organizations the opportunity to truly understand their new environment and refine their operational procedures.

The physical deployment of new information systems and applications is always daunting. The sheer number of network devices and hardware and software components used in distributed systems can seriously challenge conventional rollout strategies. When coupled with organizational and geographical barriers, system and application deployment can become a technical and managerial nightmare.

To meet these challenges and increase your chances for success, include the deployment strategy as a component of the support architecture. When deploying software components across a widely distributed enterprise, it's critical that a structured methodology be used. The manual "sneaker-net" method of deploying software to distributed nodes has been tagged as a principal culprit in rising deployment costs.

One emerging methodology is to integrate software change-management and release control with a software-distribution mechanism. Implementing this technique will help to ensure that all of the software components and their corresponding dependencies are controlled from a formal change- management process.

Also, the software-distribution methodology, which often includes an inventory scan of the current state of the software environment, can provide a clear picture of application version and release numbers. These can be directly tied back to the change-management tool.

This solution also provides another key benefit: consistency. Often in distributed environments, each new application requires a customized distribution strategy. This constant re-creation of deployment strategies can add time and expense to a development project. Implementing the integrated change-management and software-distribution approach can help IT organizations develop a consistent launching pad for their applications, which can increase the reliability and speed of getting new applications into the hands of business users.

Financial Management Strategy
The support architecture can also provide an opportunity for the IT organization to establish sound financial management practices. Because of the constant flow of new software and hardware components in most IT environments, financial management is a foreign term. Even IT departments with multimillion-dollar budgets often can't provide a complete accounting of their assets.

By including an asset-management strategy in the support architecture, support groups can get a handle on the financial aspects of technology before they get out of hand. Financially aware organizations can design asset management into their solutions by implementing an asset-tagging system for hardware, and by establishing a software licensing and metering strategy.

Two other financial components of the support architecture are the definition of a structured maintenance program and technology-refreshment strategy. The maintenance program establishes a scheduled preventative maintenance strategy for technology components, with the intent of identifying potential problems before they occur. Most hardware vendors have prescribed a maintenance program for their components. Relatively simple tasks such as cleaning fans and tightening network connections on a regular basis can prevent unnecessary downtime.

The technology-refreshment component of the support architecture defines a structured methodology for replacing outdated software and hardware. Typically, software and hardware in an enterprise are refreshed in a random manner. A technology-refreshment strategy is key to providing st ructure to the upgrade of hardware and software components. Although clearly not as glamorous as the other areas of systems architecture, applying sound financial awareness and accountability is essential to the viability of the IT department.

An emerging financial component of the support architecture is the value-management strategy. This strategy defines the value that the system should provide to the users-and the processes used to constantly measure that value. This principle is rarely applied in the IT domain-which may lead to the constant questioning of the return on investment that a new system or application provides. Establishment of these strategies and metrics on the front end of a project can help quantify the value that IT provides to the business.

Systems Management Strategy
A major component of the support architecture is the enterprise systems management strategy. The ESM strategy and supporting architecture define the processes and technologies used to operate and mainta in your information systems. By integrating into the overall support architecture, the ESM architecture can serve as a critical point of integration between the development and operations groups.

During the design phase of projects, the IT operations group should be heavily involved in the design of applications and infrastructure. In conventional development models, the operations group usually has very little to do with system architecture. But in the support architecture concept, the operations group is involved in the actual design of a system, not from a functionality perspective, but from a manageability perspective. The support architecture provides a vehicle for system architects and IT operations staff to develop a shared understanding and vision for the functionality and manageability of systems.

One of the strategic ESM trends we're seeing in this area is the concept of embedding management information and functions directly inside application code. This approach goes beyond the convention al application-management approach, which usually monitors the application by capturing external application variables. Through the support architecture, application architects work with support architects to identify the critical components that need to be managed within an application.

It's critical that the design team identify the managed objects within an application as soon as possible in the development cycle. This early awareness will ensure that applications are able to generate the management information desired by developers, and also that the operations group is able to capture and interpret the captured information.

Integrating management code within applications will also provide the application developers the opportunity to build performance-management profiles of applications before they are deployed. These profiles will help them identify any potential performance problems while the application is still in development.

To build performance profiles, it is important that the suppo rt architecture define the performance-management environment so that any measurements taken in development will have a direct correlation with measurements taken in production. System and support architects who have the foresight to embed management data into applications can be rewarded with an abundance of invaluable information about their systems and applications.

The ESM component of the support architecture should also define a common approach to configuring management agents. Management agents such as asset management, fault management, and performance management should be accounted for in the initial system design. The purpose of this strategy is to make sure that networks, servers, and PCs are sized to accommodate both the application components and the system overhead required by the agents.

Typically, management agents are configured on a node-by-node basis. By applying common configuration specifications that are outlined in the support architecture, IT support organizations can avoid po tential flurries of random events.

Conclusion
The introduction of support architecture into a system design process requires a shift in the conventional project structure and design focus. Typically, the support mechanism for a new system is not in place until it is time for the system to be deployed.

This separation between development and operations could be an underlying cause for shaky applications and infrastructure and soaring operational costs. To provide a more stable foundation for systems design, greater focus should be placed on items that have traditionally taken a backseat to system development. The support architecture addresses many of these issues, and makes enterprise support strategically equal in systems architecture.

Wayne Simmons is a senior consultant at Ernst & Young's Center for Technology Enablement. He can be reached at wayne.simmons@ey.com .

  Back to Labs

  Send Us Your Feedback

  Top of the Page