Application ManagementOrganisation

The purpose of the application. Each application was developed to meet a specific set of objectives, usually business objectives. For effective support and improvement, the group that manages that application needs to have a comprehensive understanding of the business context and how the application is used to meet its objectives. This is often achieved by Business Analyst who is close to the business and responsible for ensuring that business requirements are effectively translated into application specifications. Business Analysts should recognize that business requirements must be translated into both functional and manageability specifications.

The functionality of the application. Each application is designed to work in a different way and to perform different functions at different times.

The platform on which the application runs. Although the platform is usually managed by a Technical Management team or department, each of them affects the way in which an application needs to be managed and operated.

The type or brand of technology used. Even applications that have similar functionality operate differently on different databases or platforms. These differences must be understood in order to manage the application effectively. Even though the activities to manage the applications are generic, the specific schedule of activities and the way they are performed will be different. For this reason, Application Management teams and departments tend to be organized according to the categories of applications that they support. Typical examples of application Management organizations include.

• Financial applications. In larger organizations where a number of different applications are used for different aspects of Financial Management, there may be several department, groups or teams managing these applications, e.g. Debtors and Creditors, Age Analysis General Ledger, etc.
• Messaging and collaboration applications
• HR applications
• Manufacturing support applications
• Salesforce automation
• Sales order processing applications
• Call Centre and marketing applications
• Business-specific applications (e.g. healthcare, insurance, banking, etc)
• IT applications, such as Service Desk, Enterprise System Management etc.
• Web Portals
• Online Shopping

Traditionally, applications Development and Management teams and departments have been autonomous units. Each one manages its own environment in its own way and each has a separate interface to the business. Over the last several years, these two words are being brought together by recent moves to objects oriented and SOA approaches, together with growing pressure from the Business to be more responsive and easy to work with. This means that Application Development will have greater accountability for the successful operation of applications they design, while Application Management will have greater involvement in the development of applications. This does not change the fundamental role of each group but it does require a more integrated approach to the SLC. It will also mean that the output of Application Development will be more commoditized and that Application Management will be more involved in Development projects.

This will require the following changes:

• A single interface to the business for all stages of the lifecycle and common requirements and specification-setting process.
• A change in how both Development and Management staff are measured. Development teams should be held partly accountable for design flaws that create operational outages. Management staff should be held partly accountable for contributing to the technical architecture and manageability design of applications.
• A single Change Management process for both groups, with change control in each group being subordinate to the overall authority of Change Management.
• A clear mapping of developments and Management activities in the lifecycle, which is illustrated at a high level in Figure 6.5. The exact activities and how they interact should be defined in each organisation, although some general guidelines are given in each of the ITIL publications.
• Greater focus on integrating functionality and manageability requirements early in the projects.

Figure 1 shows a common Application Management Lifecycle with involvement from both groups. In this diagram, Application Development will be driving some phases with input from Application Management. In other cases, Application Management will be driving the phase with input and support from Application Development. Both groups are subordinated to the IT Service Strategy of the organisation and their efforts are coordinated through Service Transition mechanisms and processes.

Figure 1

Role of teams in the Application Management Lifecycle An applications Manager or Team-leader (Depending upon the size and/or importance of the team or departments and the application they support, and the organisation’s structure and culture) will be needed for each of the applications teams or departments, The role will:

• Take overall responsibility for leadership, control, and decision-making for the applications team or department.
• Provide technical knowledge and leadership in the specific applications support activities covered by the team or department.
• Ensure necessary technical training, awareness and experience levels are maintained within the team or department relevant to the applications being supported and process being used.
• Involve ongoing communications with users and customers regarding application performance and evolving requirements of the business.
• Report to senior management on all issues relevant to the applications being supported.
• Perform line-management for all team or department members

Applications analyst/architect Applications Analyst and Architects are responsible for matching requirements to application specifications.

• Working with users, sponsors, and all other stakeholders to determine their evolving needs.
• Working with Technical Management to determine the highest level of system requirements required to meet the business requirements within budget and technology constraints.
• Performing cost-benefit analyses to determine the most appropriate means to meet the stated requirement.
• Developing Operational Models that will ensure optimal use of resources and the appropriate level of performance.
• Ensuring that applications are designed to be effectively managed given the organizations technology architecture, available skills tools.
• Developing and maintaining standards for applications sizing, performance modeling, etc.
• Generating a set of acceptance test requirements, together with the designers, test engineers and the user, which determine that all of the high-level requirements have been met, both functional and with regard to manageability.
• Input into the design of configuration data required to manage and track the application effectively

An appropriate number of Application Analysts will be needed for each of the Application Management teams or department to perform the generic activities.