11.1 Phase E artifacts

The aim of phase E is to define the realization strategy for the envisaged transformations. In particular, it develops the framework for projects deriving from the results of earlier phases. The result of earlier phases can be seen in terms of gaps, between the as-is and the to-be states, in order to achieve the desired result. Projects then formalize the resources, time horizons, schedules, budgets, and so on, to carry out the work required to close these gaps. Closing a gap has a cost, risk, time to value, benefit, alignment with business and technical objectives, and so on. The gap assessment would generally be to close the lowest cost, lowest risk, highest value gaps to maximize results from available resources/revenue. Phase E prepares project planning, finalizes decisions, and defines the architectural building blocks needed to build the evolutions of the IS.

Phase E reuses models from the development phases and consolidates them. Phase E introduces no new modeling concepts (Table 11.1).

11.2 The “Benefits diagram” artifact

•  External actor

•  Interaction component

•  Entity component

•  Intermediary component: Implements quite complex business logic.

Benefits diagrams present opportunities identified during architecture definition. These opportunities are classified in terms of their relative size, their benefits, and their complexity. This type of diagram is used by decision-makers to select or assign priorities, or to make decisions regarding the order in which actions should be carried out with regard to opportunities.

Figure 11.1 presents the possibility of creating two new application components and making two others evolve in order to better address visitors who come back to the site, for example, to propose promotions related to previously expressed interests. Thought can be given to this model derived from application communication diagrams in order to answer questions that contribute to the decision-making process:

• What work has been planned for this kind of change?

• What is the associated complexity?

• What are the risks, and in particular, do any migration operations have to be foreseen? Are there risks concerning the continued functioning of the IS?

• What is the expected benefit?

This sophisticated evolution was not taken into account in the first iteration of IS change. It was more prudent to first put in place a web infrastructure, which constitutes a major change for the enterprise. Later, once the first step has been successfully completed and changes appear to be managed, then more sophisticated improvements can be envisaged. This evolution can be proposed as an opportunity for change during the next ADM cycle.

Projects can be defined here as a means of organizing the potential changes (opportunities) into units that can be assessed. The projects can also be linked to the goals and assessments of impact.

11.3 Project context diagrams

•  External actor

•  Internal actor

•  Requirement

•  Business process

•  Use case

•  “Database” component

•  Interaction component

•  Application component

•  System federation component

•  Information flow: Indicates a flow of information of any sort (business entity, event, etc.) circulating between active entities of the system.

•  An application component realizes the designated element (for example, a business process).

•  Link between a participant (for example, an actor) and an element of the system being studied; expresses that the participant consumes the element of the IS.

•  Indicates that an element of the IS satisfies a requirement.

A project context diagram presents the scope of a work package, which is realized as part of a change roadmap. The project context diagram links a work package to organizations, functions, services, processes, applications, business or data entities, and technologies that will be added, withdrawn, or modified by the project. The project context diagram is also a useful tool in the management of application portfolios and for initiating a project.

In this type of diagram, the essential application components of the project are presented, along with the main requirements and the linked business elements (business processes, businesses services, business functions). We will express which requirements are satisfied by the project, which business processes are implemented, which business functions are concerned, and which actors or roles will use the targeted application components.

Other links to parts of the information system can also be expressed. Figure 11.2 focuses on the trip reservation site. It highlights its connection to the portfolio repository and the accounting ERP (both of which exist in the current system) and recalls the use cases and processes implemented by the site. It indicates that this site accesses partner systems. The client and the account manager are the two actors who use the site. The main requirement satisfied by this site is the request for IS connection to the Internet.