Managing the Transition to a Future Operational Architecture

Last month I wrote a blog post about capturing and managing operational architectures. In this article, I will explore how to plan for and manage the transition from the current (or “As-Is Architecture”) to a future (or “To-Be Architecture”) configuration. While this can seem like a daunting proposition, don’t be intimidated. It’s really fairly straightforward.

In GENESYS, the starting point for understanding these concepts is shown in the following diagram.

Figure 1. Managing development of a To-Be Architecture

The To-Be Architecture has to be developed by a set of programs and/or projects to develop the new/improved systems that form the future architecture. As discussed in last month’s article, capability, component, and performer are basic elements defining an architecture. Execution of a program and/or project is the mechanism that delivers the new/improved system and a revised set of capabilities for the operational nodes (or performers) of the To-Be Architecture.

For the purposes of this discussion, I will define a program element as the totality of effort required to accomplish a specifically defined work objective. In other words, the program element defines the resources (time, labor cost, and non-recurring cost) required to provide a new/revised component associated with a capability and performer.

Extending this concept further, we can use program elements of a detailed, phased approach in providing the to-be architecture. Let’s assume for a moment that a To-Be Architecture requires three new systems in a systems architecture. In order to design and develop these three new systems, I will have three independent projects, each with a specific time line and funding amount to deliver the systems.

The To-Be Architecture is composed of the new system architecture as shown in the following diagram.

Figure 2. To-Be Architecture System Entities

The development of these three systems may all be funded and start at the same time, but each development program may take a different amount of time and require different times. First, we can show the overall development configuration wherein we have a New System Architecture Development Program consisting of three separate projects.

Figure 3. New System Architecture Program

We can expand this to show that each project supplies one of the systems needed in the To-Be Architecture.

Figure 4. Program/Project and the systems developed

Finally, we can further plan for development of the Revised System Architecture by defining Start Dates, End Dates, and Cost for each of the System Development Projects. The table below provides an example set of information for the example New System Architecture Development Program.

While this example is very simple in nature, you can easily extend this to show any variety of intermediate projects with schedule dates and costs for development of a future (or To-Be) architecture. See—not so hard after all, was it?