EDF Luminus - Solution Architecture Study

October 2015 till Januari 2016
Content:  
     


Management Summary

As part of a roadmap to update the way of working of the architecture team at EDF Luminus, an exercise of defining the approach to solution architecture is an apt description of this study. It occurs in parallel with a similar exercise to define the approach to enterprise architecture. Deliverables for the study are the articulation of all concepts and concerns that should govern any good solution architecture, as well as the templates to be used for formalizing the project efforts to its end.

We define the solution architecture scope as the glue between the capabilities and standards governed at the enterprise level, and the technical designs of individual components. As shown in the illustration below, solution architecture is positioned at the project scope, unifying the guidelines set out by the enterprise scope with the capabilities and standards part of shadow IT, and thus not yet part of those governed by the IT department. More on the mechanisms between enterprise capabilities and their relationship with shadow IT can be read here.

Team Composition

This study was done in cooperation with three other architects of the EDF Luminus Architecture Team, being Svend Jacobsen, Leo Vincent, and Lode Rammelaere.

Lessons Learned

In every solution architecture approach, there comes a point where several possible solutions will cover the requirements stipulated by the project stakeholders. In order to determine which solution has the preference of all involved, a rationale should be constructed. In the past, at least for my projects, this was largely done based on the combined experience of the architects (both solution, domain and application). Although this approach seldom steered me wrong in the past, for this study, the more structured approach offered by Carnegie Mellon, was used. This is the Architecture Tradeoff Analysis Method (ATAM).

My main interest in this method lies with the identification and formalization of the business drivers for the architecture, which is done in the requirements view of the solution architecture document, and in the description of the architectural decisions made, based on these driving requirements. We elaborate each of these decisions with a listing of the risk/non-risks involved, the sensitivities accompanying them (which means those properties of one of more components that are critical to achieving a particular driving requirement), and the tradeoff points (for example cost versus performance level).

Assessment EA Utilities Sector