Traditionally, Application 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. This is illustrated in Table 6.2.
Application Development
Application Management
Primary focus
Building functionality for their customer. What the application does is more important to them than how it is operated
Focus on what the functionality is as well as how to deliver it.
Manageability aspects of the application, i.e. how to ensure stability and performance of the application
Management mode
Most development work is done in projects where the focus is on delivering specific units of work to specification, on time and within budget.
This means that it is often difficult for developers to understand and build for ongoing operations, especially since they are not available for support of the application once they have moved on to the next project
Most work is done as part of repeatable, ongoing processes. A relatively small number of people work in projects.
This means that it is very difficult for operational staff to get involved in development projects, as that takes them away from their ‘real jobs’
Measurement
Staff are rewarded for creativity and for completing one project so that they can move on to the next project
Staff are rewarded for consistency and for preventing unexpected events and unauthorized functionality (e.g. ‘bells and whistles’ added by developers)
Cost
Development projects are relatively easy to quantify since the resources are known and it is easy to link their expenses to a specific application or IT service
Ongoing management costs are often mixed in with the costs of other IT services since resources are often shared across multiple IT services and applications
Lifecycles
Development staff focus on Software Development Lifecycles, which highlight the dependencies for successful operation, but do not assign accountability for these
Staff involved in ongoing management typically only control one or two phases of these lifecycles – Operation and Improvement
Table 6.2 Organizational roles
Over the last several years, these two worlds are being brought together by recent moves to Object 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 a 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 contribution 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 (see Service Transition publication).
A clear mapping of Development 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 organization, although some generic guidelines are given in each of the ITIL publications.
Greater focus on integrating functionality and manageability requirements early in the project.
Figure 6.6 Role of teams in the Application Management Lifecycle
Figure 6.6 shows a common Application ManagementLifecycle with involvement from both groups. In this diagram it is clear that 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 organization and their efforts are coordinated through Service Transition mechanisms and processes.
