7.1 Systems Architecting does usually not Lead to a Unique Solution
Systems architecting is not like mathematics since systems architecting issues have commonly never only true or false answers, which may be disorientating for the beginner. A systems architecture process does indeed classically lead to many different possible and valuable solutions. So the core questions in systems architecting are always choice and decision among these various options. The key point is of course to be able to make these choices and decisions in the most rational possible way, which is the main purpose of systems architecting and of this pocket guide.
Note first that systems architecture options can occur in each architectural vision: there are usually lots of choices to do in terms both of needs or requirements prioritization and of missions, functions or components selection. One must in particular always arbitrate between performance and cost in any systems development context, under quality and delay constraints. These key indicators lead to make regularly arbitrations relatively either to the level of coverage both of stakeholder needs and of systems requirements, or on the scope covered by a system’s architecture.
Trade-offs – that is to say the specific engineering activities that result in making a choice between various architectural options – are thus permanent within any systems architecting process where decision plays a key role. As a consequence, if one wants these decisions to be as rational as possible, one needs both to organize the trade-off processes in the most efficient way and to have rigorous methods for taking such decisions on the basis of explicit and shared decision criteria. The trade-off techniques presented in this current chapter try to propose a valuable answer to this reasonable and strategic objective of any system development process. Trade-offs are however never easy. A trade-off is indeed a situation that involves losing one feature of a system in return for gaining another quality or aspect. More colloquially, if one thing increases, some other thing must decrease.
Trade-offs can occur for many reasons, including simple geometry (into a given amount of space, one can fit either many small objects or fewer large objects). As already mentioned above, the idea of a trade-off always in a system development context implies a decision that has to be made with full understanding of both the upside and downside of a particular choice, such as when somebody decides whether to invest in stocks (more risky but with a greater potential return) versus bonds (generally safer, but lower potential returns)1This paragraph was highly inspired of the Wikipedia article on “Trade-off” (see [97])..
Note finally that “human engineering” is a key point when managing trade-offs. As noticed above, making a trade-off in any systems architecting context means eliminating an architectural option for choosing another one, which means privileging some part of the organization against another one, due to the fact that one shall never forget that there are always people behind systems (see the last paragraph of section 2.3). As can be imagined, these human and/or political issues are at the heart of the difficulties when managing trade-offs in practice.
Prioritizing a System Budget: the Data Warehouse Case
TELBYTE is a leading communication company in Europe. In order to make offers – as well as possible – adapted to their customer needs, the general direction of TELBYTE decided to develop a data warehouse2A data warehouse is a huge data basis, constructing with specific technology to guarantee transactional performance. where all existing customer information shall be stored in order to provide suitable data for a number of customer-oriented internal services.
A scoping study showed that around 1,500 data sources were to be connected with the data warehouse in order to be able delivering all the 300 internal services that were requested by around 10 marketing-focused teams within TELBYTE. A dedicated project – named APERO – was then launched on this basis in order to construct the corporate data warehouse for a budget of around 40 million euros.
Unfortunately 9 months after having started, APERO faced a severe budget restriction – due to bad market figures – of 20 %. The project team did not have any idea on how to deliver the expected services to the marketing department within a reduced budget of 32 million euros. A trade-off was clearly required and APERO asked CESAMES to manage it.
CESAMES analyzed the situation and understood quickly that the complexity of the project was too high and value was totally absent of the way the APERO project was working, which explained why the project was not able to manage alone the trade-off it was facing. Several actions were then managed in parallel by CESAMES, during around a month, for creating the conditions of a successful trade-off through a collaborative prioritization workshop. The first one was to reduce the data source complexity: by clustering the initial 1,500 data sources according to their origins, it was possible to only handle 250 data clusters. The second one was to give 100 tokens to each marketing team and to ask them distributing their tokens on the services they were requesting: as an immediate side-effect of putting value at the heart of the problem, their number diminishes from 85 % to arrive at only 50 services. Each team indeed understood that it was necessary to concentrate their tokens on the services with highest value if these services wanted to have a chance to be selected during a collective prioritization process3One can easily understand that any team which would not have concentrated their token on a limited number of choices could not win in a collective prioritization as soon as another team decided to have such a strategy. Hence the best strategy for everybody is concentrating the tokens, which is a classical Nash equilibrium in the meaning of game theory (see [87]). .
As a consequence, the complexity of the trade-off problem to solve passed from 1,500 x 300 = 450,000 possible source / service to 250 x 50 = 12,500 possible cluster / service choices to arbitrate, that is to say a 97 % reduction of complexity which allowed to make successfully a collective arbitration – both of the data clusters to interface with the data warehouse and on the precise service scope to offer – during a one-day collective prioritization workshop involving all concerned business actors. The result achieved during that workshop allowed covering 95 % of the marketing demands within the new 80 % restricted budget4 This illustrates another point that one shall in mind when doing trade-offs. Costs are often distributed with respect to value according to Pareto laws: 20 % of the costs allow offering 80 % of the value when 80 % of the costs does only deliver 20 % of the value. This type of law does explain why the arbitration could work in the data warehouse case and why it was – in some sense (this case indeed required a lot of work) – so easy to achieve., which made everybody happy since renouncements were quite light at the very end.
Case study 9 – The Data Warehouse Case
TABLE OF CONTENTS
REFERENCES
[87] Wikipedia, Nash equilibrium, https://en.wikipedia.org/wiki/Nash_equilibrium
[97] Wikipedia, Trade-off, https://en.wikipedia.org/wiki/Trade-off