{"id":25589,"date":"2021-03-03T16:31:37","date_gmt":"2021-03-03T15:31:37","guid":{"rendered":"https:\/\/cesam.community\/?p=25589"},"modified":"2023-01-20T11:46:50","modified_gmt":"2023-01-20T10:46:50","slug":"7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution","status":"publish","type":"post","link":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/","title":{"rendered":"7.1 Systems Architecting does usually not Lead to a Unique Solution"},"content":{"rendered":"

7.1 Systems Architecting does usually not Lead to a Unique Solution<\/h2>

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.
\nNote 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\u2019s architecture.
\nTrade-offs \u2013 that is to say the specific engineering activities that result in making a choice between various architectural options \u2013 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.
\nTrade-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)1<\/a><\/sup>This paragraph was highly inspired of the Wikipedia article on \u201cTrade-off\u201d (see [97]).<\/span>.
\nNote finally that \u201chuman engineering\u201d 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.<\/p>\n<\/div>

Prioritizing a System Budget: the Data Warehouse Case<\/strong><\/p>\n

TELBYTE is a leading communication company in Europe. In order to make offers \u2013 as well as possible \u2013 adapted to their customer needs, the general direction of TELBYTE decided to develop a data warehouse2<\/a><\/sup>A data warehouse is a huge data basis, constructing with specific technology to guarantee transactional performance.<\/span> where all existing customer information shall be stored in order to provide suitable data for a number of customer-oriented internal services.
\nA 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 \u2013 named APERO \u2013 was then launched on this basis in order to construct the corporate data warehouse for a budget of around 40 million euros.
\nUnfortunately 9 months after having started, APERO faced a severe budget restriction \u2013 due to bad market figures \u2013 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.
\nCESAMES 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 process3<\/a><\/sup>One 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]). <\/span>.
\nAs 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 \u2013 both of the data clusters to interface with the data warehouse and on the precise service scope to offer \u2013 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<\/a><\/sup> 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 \u2013 in some sense (this case indeed required a lot of work) \u2013 so easy to achieve.<\/span>, which made everybody happy since renouncements were quite light at the very end.<\/p>\n<\/div>

Case study 9 \u2013 The Data Warehouse Case\u00a0<\/span><\/strong><\/p>\n<\/div>NEXT PAGE<\/i><\/a><\/div><\/div><\/div>

TABLE OF CONTENTS<\/h2>[vc_wp_custommenu nav_menu=\u00a0\u00bb132″]

REFERENCES<\/h2>

[87] Wikipedia, Nash equilibrium, https:\/\/en.wikipedia.org\/wiki\/Nash_equilibrium <\/span><\/p>\n

[97] Wikipedia, Trade-off, https:\/\/en.wikipedia.org\/wiki\/Trade-off<\/span><\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>\n<\/div>","protected":false},"excerpt":{"rendered":"

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…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[158],"tags":[157],"yoast_head":"\n7.1 Systems Architecting does usually not Lead to a Unique Solution - Cesam Community<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"7.1 Systems Architecting does usually not Lead to a Unique Solution - Cesam Community\" \/>\n<meta property=\"og:description\" content=\"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...\" \/>\n<meta property=\"og:url\" content=\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/\" \/>\n<meta property=\"og:site_name\" content=\"Cesam Community\" \/>\n<meta property=\"article:published_time\" content=\"2021-03-03T15:31:37+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-01-20T10:46:50+00:00\" \/>\n<meta name=\"author\" content=\"admin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@cesamcommunity\" \/>\n<meta name=\"twitter:site\" content=\"@cesamcommunity\" \/>\n<meta name=\"twitter:label1\" content=\"\u00c9crit par\" \/>\n\t<meta name=\"twitter:data1\" content=\"admin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data2\" content=\"6 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/\"},\"author\":{\"name\":\"admin\",\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505\"},\"headline\":\"7.1 Systems Architecting does usually not Lead to a Unique Solution\",\"datePublished\":\"2021-03-03T15:31:37+00:00\",\"dateModified\":\"2023-01-20T10:46:50+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/\"},\"wordCount\":1454,\"publisher\":{\"@id\":\"https:\/\/cesam.community\/fr\/#organization\"},\"keywords\":[\"Article\"],\"articleSection\":[\"CESAM Systems Architecting Method\"],\"inLanguage\":\"fr-FR\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/\",\"url\":\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/\",\"name\":\"7.1 Systems Architecting does usually not Lead to a Unique Solution - Cesam Community\",\"isPartOf\":{\"@id\":\"https:\/\/cesam.community\/fr\/#website\"},\"datePublished\":\"2021-03-03T15:31:37+00:00\",\"dateModified\":\"2023-01-20T10:46:50+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/cesam.community\/fr\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"CESAM Systems Architecting Method\",\"item\":\"https:\/\/cesam.community\/fr\/category\/cesam-systems-architecting-method-en\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"7.1 Systems Architecting does usually not Lead to a Unique Solution\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/cesam.community\/fr\/#website\",\"url\":\"https:\/\/cesam.community\/fr\/\",\"name\":\"Cesam Community\",\"description\":\"La communaut\u00e9 CESAM\",\"publisher\":{\"@id\":\"https:\/\/cesam.community\/fr\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/cesam.community\/fr\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/cesam.community\/fr\/#organization\",\"name\":\"CESAM Community\",\"url\":\"https:\/\/cesam.community\/fr\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png\",\"contentUrl\":\"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png\",\"width\":7310,\"height\":1018,\"caption\":\"CESAM Community\"},\"image\":{\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/x.com\/cesamcommunity\",\"https:\/\/www.linkedin.com\/company\/community-cesam\/about\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505\",\"name\":\"admin\",\"sameAs\":[\"https:\/\/cesam.community\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"7.1 Systems Architecting does usually not Lead to a Unique Solution - Cesam Community","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/","og_locale":"fr_FR","og_type":"article","og_title":"7.1 Systems Architecting does usually not Lead to a Unique Solution - Cesam Community","og_description":"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...","og_url":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/","og_site_name":"Cesam Community","article_published_time":"2021-03-03T15:31:37+00:00","article_modified_time":"2023-01-20T10:46:50+00:00","author":"admin","twitter_card":"summary_large_image","twitter_creator":"@cesamcommunity","twitter_site":"@cesamcommunity","twitter_misc":{"\u00c9crit par":"admin","Dur\u00e9e de lecture estim\u00e9e":"6 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/#article","isPartOf":{"@id":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/"},"author":{"name":"admin","@id":"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505"},"headline":"7.1 Systems Architecting does usually not Lead to a Unique Solution","datePublished":"2021-03-03T15:31:37+00:00","dateModified":"2023-01-20T10:46:50+00:00","mainEntityOfPage":{"@id":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/"},"wordCount":1454,"publisher":{"@id":"https:\/\/cesam.community\/fr\/#organization"},"keywords":["Article"],"articleSection":["CESAM Systems Architecting Method"],"inLanguage":"fr-FR"},{"@type":"WebPage","@id":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/","url":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/","name":"7.1 Systems Architecting does usually not Lead to a Unique Solution - Cesam Community","isPartOf":{"@id":"https:\/\/cesam.community\/fr\/#website"},"datePublished":"2021-03-03T15:31:37+00:00","dateModified":"2023-01-20T10:46:50+00:00","breadcrumb":{"@id":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/cesam.community\/fr\/2021\/03\/03\/7-1-systems-architecting-does-usually-not-lead-to-a-unique-solution\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/cesam.community\/fr\/"},{"@type":"ListItem","position":2,"name":"CESAM Systems Architecting Method","item":"https:\/\/cesam.community\/fr\/category\/cesam-systems-architecting-method-en\/"},{"@type":"ListItem","position":3,"name":"7.1 Systems Architecting does usually not Lead to a Unique Solution"}]},{"@type":"WebSite","@id":"https:\/\/cesam.community\/fr\/#website","url":"https:\/\/cesam.community\/fr\/","name":"Cesam Community","description":"La communaut\u00e9 CESAM","publisher":{"@id":"https:\/\/cesam.community\/fr\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/cesam.community\/fr\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Organization","@id":"https:\/\/cesam.community\/fr\/#organization","name":"CESAM Community","url":"https:\/\/cesam.community\/fr\/","logo":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/","url":"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png","contentUrl":"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png","width":7310,"height":1018,"caption":"CESAM Community"},"image":{"@id":"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/x.com\/cesamcommunity","https:\/\/www.linkedin.com\/company\/community-cesam\/about\/"]},{"@type":"Person","@id":"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505","name":"admin","sameAs":["https:\/\/cesam.community"]}]}},"_links":{"self":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts\/25589"}],"collection":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/comments?post=25589"}],"version-history":[{"count":9,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts\/25589\/revisions"}],"predecessor-version":[{"id":33375,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts\/25589\/revisions\/33375"}],"wp:attachment":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/media?parent=25589"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/categories?post=25589"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/tags?post=25589"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}