Copyright 2014 by Adaptive Growth Inc. All rights reserved.

Transcription

1 The Abstract Business System Description in the Context of Application Lifecycle Management The approach we take to business requirements management, which we call the method of Abstract Business System Description, is not intended to be an integral part of any particular methodology of Application Lifecycle Management (ALM). It does, however, fit the concept of ALM quite well in two important ways: it provides the ALM process with a much improved facility for managing business requirements, and ALM provides the method of Abstract Business System Description with a ready-made management structure for requirements governance. This brief whitepaper offers a sketch of this integration. As its name suggests, ALM represents an effort to extend the principles of IT governance to the whole lifespans of application systems. It attempts to incorporate or to expand or, in some versions of ALM, to replace the concept of the System Development Life Cycle (SDLC) by superimposing a layer of continuous governance on top of the traditional develop-deploy-maintain system lifecycle model. One common view of ALM is shown in Figure 1. Figure 1 The scope of ALM as it applies to a single system When ALM is depicted, as it is in Figure 1, as applying to a single system, it can be hard to see how its scope and goals differ from SDLC because the purpose and function of the governance layer is unclear. Here is a wider view:

2 Figure 2 The scope of ALM as it applies to successive instances of the same application. Note that the governance activity is continuous, spanning the lifecycles of each version of the application. Figure 2 shows that governance is a continuous process that spans iterations of a single application. That is to say, the same governance process that managed the development and ongoing operations and maintenance of the system shown in gold instituted and managed that system s replacements. The scope of the governance process is actually wider yet: 2

3 Figure 3 The scope of ALM as it applies to multiple applications. The same governance activity continuously controls all three applications shown. Here we finally see the full scope of the governance process. It manages not only the successive lifecycles of systems that support a single application it manages the evolution of all applications. There are two aspects of this cross-application view of ALM that are of great importance to business requirements management: 1. At least in theory, as much attention is being paid to the operational portion of system lifecycles as to development and implementation and the same governing body, however it is constituted, is responsible for all phases of the life of all enterprise systems. 2. Since a single and permanently active governing body is perpetually responsible for the health and accuracy (in terms of fit to the business) of all systems, a management structure that can coordinate business requirements between applications is at least theoretically in place. As we discuss elsewhere, 1 one of the greatest threats to requirements completeness and accuracy is the siloing of requirements gathering and analysis inside development and implementation projects. A brief recap: since the input of one enterprise system (or external process) is often the output of another system, 1 See our whitepaper called Why Some Requirements Exceed the Scope of Any Single Enterprise System. 3

4 there exist dependencies between systems that are often missed when the scope of inquiry is restricted to a single actual system. Our product 2 is aimed at decoupling the gathering of business requirements from individual development and implementation projects, and replacing the requirements gathering phases of those projects with a process of selecting the most appropriate set of requirements from a permanently maintained library, which we call the Abstract Business System Description. Our approach has two implications for the structure of management: there must be a management structure in place that takes ongoing responsibility for the permanent, evolving library of business requirements, and that management structure must effectively distribute those business requirements to each enterprise system project as it comes along. As is shown in Figure 4, the governance function envisaged by ALM addresses both these needs: Figure 4 The ALM governance function extended to manage the evolution of the Abstract Business System Description As we discuss elsewhere, 3 at any one time there is only a single active version of the Abstract Business System Description. As each new enterprise system (or major release) is deployed (the timing is shown by the vertical lines in Figure 4), the previously active version is replaced by a newly-active version that 2 The Unified Approach to Enterprise Software Failure Prevention 3 See our whitepaper called How New Enterprise Projects Use the Abstract Business System Description. 4

5 reflects the changes just made to the post-deployment business landscape changes, that is, that were brought about by the new system s deployment. In practice, the kind of close coordination needed cries out for some degree of common oversight between application development, implementation, and deployment on the one hand and the maintenance, administration, and publishing of the Abstract Business System Description on the other. The ALM governance function provides that common oversight. 5