Although all Application Management departments, groups or teams perform similar activities, each application or set of applications has a different set of management and operational requirements. Examples of these differences include:
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.
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:
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.
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:
Applications analyst/architect Applications Analyst and Architects are responsible for matching requirements to application specifications.
An appropriate number of Application Analysts will be needed for each of the Application Management teams or department to perform the generic activities.