In the TOGAF (The Open Group Architecture Framework) standard, “Phase E: Opportunities and Solutions” is the fifth phase of the Architecture Development Method (ADM).
In this phase, the architects develop a set of solution architectures that must address the business goals, objectives, and drivers identified in earlier phases of the ADM. A logical architecture design (AD) will be chosen amongst maybe several proposals that all would respond to the logical architecture deign produced in the Architecture Definition Document (ADD). Such a qualitative artefact is a more “visual” representation of how the EA team proposes to fulfil the quantitative, and therefore more measurable, Architecture Requirements Specifications agreed on and so expected by the client.
The primary objectives of Phase E are therefore to identify and evaluate potential solutions that can meet the architecture vision and business requirements translated into the ADD.
During Phase E, the Solution Architects start developing a roadmap for implementing the chosen physical solution architecture from the directives provided by the AD. They aim at defining what the solution will look like in real life and if it will work in the targeted environment. They will also start giving the client an idea on the cost of such solution as well as any pro and contra, compared to other alternatives.
In the “Phase F: Migration Planning”, the Solution Architects develop a detailed migration plan that outlines the steps and activities required to transition from the current architecture state (baseline) to the target architecture state. The primary objective of Phase F is to finalise the comprehensive roadmap for the implementation of the solution architectures defined in earlier phases of the ADM.
During Phase F, the architects analyse the implementation costs, relevant risks, and benefits of each migration step and develop a detailed schedule of projects that identifies the dependencies between the various activities. They also define the governance and management structures needed to oversee the implementation of the migration plan and continue to ensure that it aligns with the enterprise’s overall strategy and goals.
When it comes to designing and building a suitable product (i.e. a service, hardware or software) of some sort, the architects in phase E have the options of buying it from a supplier or manufacturer during that phase E, testing it so that it’s scaled deployment implementation can take place after F. This could be so that they try to minimise the risk going back and forth with a 3rd party, should the solution need a partial or full redesign. One would see this case probably more often in smaller “do-it-all” teams, operating in smaller environments or for smaller-scaled project where the EA team wants, or need to, see more of the completion occur under the EA watch for instance. This allows also for more late requirements to still be taken into consideration, rendering the design a tad more dynamic and responsive, therefore a little more agile…
But the architects could also prefer to leave such creation process to an outsourced capability and in this case such implementor would require a detailed plan of what to do, and how to implement/migrate it in the desired target environment. Of course, in such case, little to no building process would occur in Phase E and such phase would serve only to design specifications and request for tendering etc. so the implementors would have all the responsibility to create the described solution. This is suitable for transition based projects where once a decision is made, we would be ok to stick to it until it is fully deployed. We would also see this in larger-scaled projects, where the scope is simply too wide and complex for the EA team to also manage on top of their very busy workload.
Choosing with way to go, really relies on the necessary capabilities being available to the architecture team, the level of maturity of the solution area for such task, and the express desire of the client. In many cases a highly specialised 3rd party, would prove more competitive and be the right choice to create the actual product but to keep a software piloting closer to the heart of design (aka the domain architecture team), the EA role may prefer to make such creative work happen under his/her watch during Phase E.
In this case the EA would have defined and tested a working product on a smaller scale (i.e. pilot, proof of concept etc.) before handing it over to the implementor for a scaled deployment of the working product.
What’s your preferred approach?
