Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mini-course at VFU - Architecting modern digital systems - 1

66 views

Published on

A small source for IT students at the VFU, Varna.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Mini-course at VFU - Architecting modern digital systems - 1

  1. 1. Architecting digital systems Module 1 System, digital and architecture Alexander Samarin
  2. 2. • system set of interacting discrete elements organised as a whole which exhibits (as the result of interaction between the elements) some emergent characteristics indispensable to achieve one or more stated purposes – Etymology: from the Latin systēma, which in turn is derived from the Greek σύστημα meaning “together” • “Discrete" means "individually separate and distinct" • Systems are different from structural assemblies • A system is more than a sum of its discrete elements © A. Samarin 2018 Architecting digital systems - Module 1 2 Definition of system
  3. 3. – A system is encapsulated, has a boundary – A system can be nested inside another system – A system can overlap with another system – A system is bounded in time; it has its own life cycle – A system is bounded in space, though the elements are not necessarily co-located – A system receives input from, and sends output into, the wider environment – A system consists of processes majority of them transform inputs into outputs – A system for somebody is an element for another – Different stakeholders see the same system differently © A. Samarin 2018 Architecting digital systems - Module 1 3 System’s characteristics
  4. 4. • structure <of a system> internal arrangement of, and relationship between, elements – Etymology: from the Latin structūra meaning “a fitting together” • behaviour <of a system> what a system will do in response to its external environment without referring to details on implementation – Note: In some cases, the behaviour of a system cannot be explained in terms of the behaviour of its elements – Note: Some emergent characteristics are the result of a system’s behaviour © A. Samarin 2018 Architecting digital systems - Module 1 4 Related concepts
  5. 5. • Chaotic vs. organised • Accidental vs. intentional • Static vs. dynamic © A. Samarin 2018 Architecting digital systems - Module 1 5 Any system has a structure
  6. 6. • Unlimited life-cycle (unpredictable and incremental evolution) • Socio-technical • Collaborative • Industrialised • Ability for rapid innovation is important • Variety of services • High level of security for data • Customer experience • Self-referential © A. Samarin 2018 Architecting digital systems - Module 1 6 Systems are complex
  7. 7. • architecture <of a system> fundamental orderliness (embodied in its components, their relationships to each other and the environment), and the principles governing the design, implementation and evolution • architecting is about: – making essential decisions about the system-in-focus to enable the achievement of its desired emergent characteristics – understanding the relationship between structure and behaviour, between design and outcomes • An architect is a person who a) translates a customer’s requirements into a viable plan and b) guides others in its execution Systems architecting © A. Samarin 2018 Architecting digital systems - Module 1 7
  8. 8. • Enterprise architecture is sometimes translated into French as “urbanisation” © A. Samarin 2018 Architecting digital systems - Module 1 8 Architecture used to construct Garthage
  9. 9. © A. Samarin 2018 Architecting digital systems - Module 1 9 Importance of architecture  No architectural blueprint  38 years of construction  160 rooms, 497 doorways, 950 doors  Over 20 tonnes of paint required  No disruption of river traffic activities  The committee evaluated 50 projects  Three architectural techniques  8 years of construction  Modernised for new technology
  10. 10. • Digital triumphs physical • Fast triumphs slow • Group triumphs single • Big triumphs small • With this new speed and scale, there is no time for human intervention and errors in routine operations and at interfaces Digital age © A. Samarin 2018 Architecting digital systems - Module 1 10
  11. 11. • Digital system – a system which building its life cycles of its primary artefacts on the primacy of explicit, formal, computer-readable and computer- executable description of those artefacts • Example – an ideal digital description of a house is designed – this digital description is used to create a physical copy of the house, e.g. with the use of 3D industrial printers – various implanted IoT devices permanently monitor the real situation with the house and create a real digital description – the real digital description of the house is used for its maintenance – the real digital description of the house is used to improve its ideal digital description © A. Samarin 2018 Architecting digital systems - Module 1 11 About Digital Systems
  12. 12. • Employ the concept of “digital twins” – Digital twins refer to computerized companions of physical assets that can be used for various purposes. Digital twins use data from sensors installed on physical objects to represent their near real-time status, working condition or position. • For a man-made object, a digital twin comes first • For a nature-made object, a digital twin comes second • Versioning and configuration management are fundamental • Versioning of atomic objects • Versioning of compound objects © A. Samarin 2018 Architecting digital systems - Module 1 12 Some recommendations related digital systems
  13. 13. • Healthcare, Smart Cities, Smart Homes, Smart Energy, IoT and Smart Manufacturing are uber-complex real- time systems of cyber-physical, socio-technical and classic IT systems with the following characteristics: – digital data and information in huge volumes – software-intensive – distributed and decentralized – great influence on our society – ability to interact with the physical world – security, safety, privacy and resilience are required by design • To build right, good and successful Digital Systems it is mandatory to think about their architectures © A. Samarin 2018 Architecting digital systems - Module 1 13 We deal with Digital Systems
  14. 14. • Why do we need methodology? – the goal: different people in similar situations find similar solutions/services/components or bring innovations • systems approach holistic approach to understanding a system and its discrete elements in the context of their behaviour and their relationships to one another and to their environment – Note: Use of the systems approach makes explicit the structure of a system and the rules governing the behaviour and evolution of the system © A. Samarin 2018 Architecting digital systems - Module 1 15 Systems architecting methodology
  15. 15. Eight areas of six systems traditions © A. Samarin 2018 Architecting digital systems - Module 1 16
  16. 16. © A. Samarin 2018 Architecting digital systems - Module 1 17 System-of-interest and its environment
  17. 17. • Formalise your artefacts – syntax and semantic • Define their life cycles • All artefacts must be versionable throughout their lifecycle • All artefacts must evolve to become externalised, virtual and cloudable • Assemble some artefacts into other artefacts • All relationships between artefacts must be modelled explicitly – thus the system’s structure is explicit • All models must be made to be machine-executable – thus the system’s behaviors can be simulated in advance • Adjust the artefacts and models to achieve the optimal behaviors for emergent characteristics © A. Samarin 2018 Architecting digital systems - Module 1 18 Ideal (happy) path
  18. 18. • Strategy – top manager • Business – manager – process owner – super-user – user • Project – manager – business analyst • IT – manager – enterprise IT architect – solution architect – developer – operator © A. Samarin 2018 Architecting digital systems - Module 1 19 Different stakeholders have different views and concerns
  19. 19. © A. Samarin 2018 Architecting digital systems - Module 1 20 4 levels of systems architecting 2.Reference architecture 1.Reference model 4. Implementation A2 3. Solution architecture B 3.Solution architecture A 4. Implementation A1 4a. Reference Implementation 3a. Reference solution architecture build and test build and testdesign and engineer field feedback feasibility feedback design and engineer architect extract essentials constraints and opportunities refinement constraints and opportunities design and engineer Problem space Solution space Various needs architect extract See some definitions at the end of this slide deck
  20. 20. • Explain to any stakeholder how future implementations (which are based on the reference architecture) can address his/her concerns and change his/her personal, professional and social life for the better – explicitly link needs (or high-level requirements) with the principles of reference architecture • Provide a common approach for architecting systems in the particular system domain – different people in similar situations find similar solutions or propose innovations • Help stakeholders, programmes and projects to collaborate and coordinate their efforts – common agreements (i.e. standards) on various system elements (e.g. services, interfaces, data, etc.), common vision, etc. © A. Samarin 2018 Architecting digital systems - Module 1 22 Purpose of reference architecture
  21. 21. Geometrical views of buildings are viewed side by side — as a composition Architecture description: Viewpoints, models kind, views and models View (system-in-focus dependent) vs viewpoint (system-in-focus independent) Multiple viewpoints are mandatory Architectural views are often originated by different people — thus they must be aligned to be used together © A. Samarin 2018 Architecting digital systems - Module 1 23 Each model kind consists of artefacts (e.g. applications, servers, etc.) and relationships between them (those applications are deployed on this servers). In accordance with ISO/IEC/IEEE 42010
  22. 22. • One of three International Standard Development Organisations – ISO – ITU – IEC • www.iec.ch 2018-03-12 Syc Smart Cities for Varna 24 International Electrotechnical Commission
  23. 23. • About 10 years ago IEC found that some problems are bigger than a few Technical Committees • System Committee (SyC) has to analyse a domain and propose missing standards to be developed – SyC Smart Energy – SyC Active Assisted Living (AAL) – SyC Smart Cities – SyC Low Voltage Direct Current (LVDC) – SEG 7 Smart Manufacturing – SEG 8 Communication Technologies and Architectures – SEG 9 Smart Home/Office Building Systems – SRG Systems Resource Group 2018-03-12 Syc Smart Cities for Varna 25 System Committee concept
  24. 24. 2018-03-12 Syc Smart Cities for Varna 26 Relations between systems domains IoT Smart manufacturing Smart Homes AAL Smart Cities Smart Energy
  25. 25. • Many common goals (sustainable development, better efficiency, resilience, safety and wider support for citizen’s engagement and participation) • Many common technologies (big data, mobile, IoT, etc.) • Smart Cities are unique and common at the same time • But current implementation practices are rather disjoint – programmes and projects are, primarily, local initiatives – programmes and projects are considered as technology projects – many independent Smart Cities interest groups – efforts for development of a common vision are insufficient – typical financing patterns do not promote a common vision • There is a systemic problem which has to be addressed with the IEC SRG Systems Approach © A. Samarin 2018 Architecting digital systems - Module 1 27 Smart City as a System is important
  26. 26. Achieve synergy between diversity and uniformity © A. Samarin 2018 Architecting digital systems - Module 1 28 A unique A common B unique B common T unique T common Let us 1) Build common understanding 2) Isolate common parts 3) Find how to integrate unique and common parts 4) Develop common parts once and with high quality as a platform 5) Have an individual version of the common platform at each Smart City 6) Cooperate and coordinate among Smart Cities Together Smart Cities will gain a lot in quality, time and money
  27. 27. Reference architecture helps to isolate unique & common parts of Smart Cities © A. Samarin 2018 Architecting digital systems - Module 1 29 A unique A common B unique B common T unique T common Reference architecture
  28. 28. Reference architecture Reference modelReference CUBE platform S2 …S1 S3 CUBE platform in City B S2 … B2B1 CUBE platform in City A A2 …S1 CUBE platform in City T S2 …T1 T3 Cooperation and coordination Telecommunication providers Industries Academic and research institutes Financial organisations Standards Development Organizations Specialized consulting firms City Unified Business Execution (CUBE) © A. Samarin 2018 Architecting digital systems - Module 1 30 Common parts Unique parts
  29. 29. • N is the total cost of a Smart City implementation (construction and operating) • 70 % - common, 30 % - unique • Total cost for 100 Smart Cities WITHOUT standardization – N * 100 • Total cost for 100 Smart Cities WITH standardization – N * 100 * 0.3 (unique parts) + N * 1 * 0.7 (common parts) * 3 (complexity factor) = N * (30 + 2.1) = N * 32.1 • Cost difference is (N*100) / (N*32.1) ≈ 3 times! • Thus good, right and successful architecture for Smart Cities is very important © A. Samarin 2018 Architecting digital systems - Module 1 31 Simple calculations
  30. 30. • Value viewpoint – stakeholders, high-level requirements, mission, vision • Big Picture viewpoint – illustrative, essential characteristics, architecture principles • Capability Map viewpoint – level 1 modularisation, level 2 modularisation • System Target Operating Model (STOM) engineering viewpoint – function map, service map, process map, data flows, organigramme • Operating viewpoint • Performance viewpoint • Implementation viewpoint • Security, Safety, Risk, Privacy and Resilience viewpoint • Standards viewpoint © A. Samarin 2018 Architecting digital systems - Module 1 32 Smart Cities Reference Architecture Methodology: essential viewpoints
  31. 31. • Stakeholders, their roles and their concerns © A. Samarin 2018 Architecting digital systems - Module 1 33 Value view: stakeholders’ needs analysis
  32. 32. • The guiding principles for defining the Smart Cities architectures are – interoperability – safety – security (including confidentiality, integrity and availability) – privacy – resilience – simplicity – low cost of operation – short time to market – combining diversity and uniformity – self-referential © A. Samarin 2018 Architecting digital systems - Module 1 34 Value view: guiding principles
  33. 33. • List of high-level requirements – Adequate water supply – Assured electricity supply – Sanitation, including solid waste management – Efficient urban mobility and public transport – Affordable housing, especially for the poor – Robust IT connectivity and digitalisation – Good governance and citizen participation – Sustainable environment – Safety and security of citizens, particularly women, children and the elderly – Affordable healthcare for everyone – Modern education for children and adults – Attractive for business © A. Samarin 2018 Architecting digital systems - Module 1 35 Value view: high-level requirements (example)
  34. 34. © A. Samarin 2018 Architecting digital systems - Module 1 36 Big picture view: illustrative (from Descriptive framework)
  35. 35. • Flows handling: Cities are self-referential systems of flows ( see http://www.academia.edu/15717758/Conceptualising_the_Urban_System_as_a_System_of_Flows ) and, those flows are flows of entities of various types: digital, physical, living, social, political, legal, etc. If no flows then a city is dead. • Multidimensionality: Those flows co-exist and interrelate in the several dimensions: spatial, temporal, cybernetical, technological, etc. • Unpredictability of growth: Smart Cities are organically-grown and must be scalable. (What do you see in 70 million people moving to cities every year?) • Technology absorption: Because of the technology progress, many various (and unknown right now) intellectual devices (or “Things” from the IoT) and digital technologies will progressively automate, improve and drastically change various aspects of Smart Cities functioning including planning, execution, monitoring, prediction, optimisation of flows. • Synergy: Intellectual devices, digital applications and digital services must work synergistically in several dimensions. • Holistic overview: Various aspects of the Smart Cities functioning (e.g. level of security, environmental impact, etc.) must be integrally (i.e. including all the available data, information and knowledge) anticipated, monitored, analysed, controlled, alerted and acted on. • Trustworthiness: High level of trustworthiness (includes security, privacy, safety, reliability, and resilience) is mandatory. © A. Samarin 2018 Architecting digital systems - Module 1 37 Big picture view: essential characteristics (example)
  36. 36. © A. Samarin 2018 Architecting digital systems - Module 1 38 Big picture view: high-level requirements vs. essential characteristics High-level requirements Essential characteristics
  37. 37. • Explicit systems architecting and engineering is only a way to achieve essential characteristics of Smart City implementations • Smart City as a System of Digital Interrelated Flows (SCaaSoDIF) which implies total digitalisation and intensive use of intellectual devices from the IoT • Separation of concerns is very critical to reduce the complexity of Smart City implementations • SCaaSoDIF is an assembly to be very adaptive and flexible • SCaaSoDIF as an assembly is constructed and operating on the basis of explicit and machine-executable digital contracts between people, services, applications, devices and organisations • Time and place must be integrated to handle flows properly • Ontology is a must because this system-domain covers many, historically, disjoint subject fields © A. Samarin 2018 Architecting digital systems - Module 1 39 Big picture view: architecture principles (example)
  38. 38. © A. Samarin 2018 Architecting digital systems - Module 1 40 Big picture view: essential characteristics vs. principles Architecture principles Essential characteristics
  39. 39. • Leading capabilities – Overall city governance, management and operations • Core capabilities – water, energy, waste, etc. • Enabling capabilities (shared among CORE capabilities) – geomatics, census, registries, etc. • Supporting capabilities – finance, legal, PMO, ICT, media, procurement, etc. © A. Samarin 2018 Architecting digital systems - Module 1 41 Capability map view: level 1 modularization Structural decomposition of the city mission into groups or domains or value streams All Smart Cities have the same capability map (and different levels of maturity). Each Smart City will implement (at a particular moment) only some capabilities from this map
  40. 40. © A. Samarin 2018 Architecting digital systems - Module 1 42 Capability map view: level 1 visualisation (example) Leading capabilities ProcurementFinance Legal Media PMO ICT … Supporting capabilities Facilities&buildingsmanagement Energymanagement Watermanagement Wastemanagement Publicsafetyandsecuritymanagement Environment(nature)management Transportationmanagement Healthcaremanagement Educationmanagement Socialsidemanagement Economicdevelopmentmanagement Culture&entertainmentmanagement Geomatics Census Registries Urban info Enabling capabilities Core capabilities Management Operations Governance Security Safety Privacy Resilience Interoperability Low cost for operations Short time to market Emergent characteristics by design Business continuity Tourismmanagement
  41. 41. § © A. Samarin 2018 Architecting digital systems - Module 1 43 STOM engineering view: operational patterns (example) Data analysis Data enrichment Decision selection Action activation Continuous monitoring Observe, Orient, Decide, Act (OODA) pattern Coordination, Event Streams, Analytics, Rules (CESAR) pattern Sensor A Sensor B Sensor C Situation prediction Case (e.g. incident) coordination Rules application Actions execution Case (e.g. incident) data flow-of-control flow-of-data flow-of-events
  42. 42. • In general, no problems with the GDPR compliance: – Use of explicit and machine-executable business processes – Request GDPR compliance from all partners (including IoT devices providers) • Use digital contracts ( see http://improving-bpm- systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html ) © A. Samarin 2018 Architecting digital systems - Module 1 44 Security, safety, risk, privacy and resilience view: example
  43. 43. Solution 1 … CUBE platform Security management Business process management Operational and analytical data Decision management Master and reference data Reporting management Analytics management Drivers for IoT … Solution 2 Smart Cities specific layer Service management Event management Implementation view: platform-based approach (example) © A. Samarin 2018 Architecting digital systems - Module 1 45 City Unified Business Execution (CUBE) platform Digital flow management
  44. 44. © A. Samarin 2018 Architecting digital systems - Module 1 46 Questions?
  45. 45. • Explain to each group of stakeholders – Artefacts under their control – Relationships under their control – How to address their concerns (i.e. carry out a particular potential change) • Example – architectural framework for improving BPM systems – A comprehensive set of recommendations, models, patterns and examples of how to transform existing disparate IT systems into a coherent, agile and flexible BPM/SOA solution Architecting digital systems - Module 1 47 Communication to stakeholders © A. Samarin 2018
  46. 46. • The architectural framework is not about how to make your products better, different and more attractive for the market place – this is for you to decide • What it offers is to help you reduce the overheads in doing so – your flexible BPM system will become an enabler for your business innovations © A. Samarin 2018 Architecting digital systems - Module 1 48 Strategy: top managers
  47. 47. Maturity level Technology architecture Data architecture Application architecture Business architecture Enterprise architecture Optimising Managed Defined Under development Initial None Architecting digital systems - Module 1 49 Business: enterprise architects • Help in the definition of the different types of architecture © A. Samarin 2018
  48. 48. • The architectural framework goal is to help you to streamline your critical business processes by – automating their management – eliminating work which does not add value – integrating existing applications around the business needs – evolving information systems in a coordinated manner • Should make use of the synergy that exists between business needs and IT potentials Architecting digital systems - Module 1 50 Business: managers © A. Samarin 2018
  49. 49. • The architectural framework classifies all human activities as intellectual (evaluation, decision-making, etc.), verification or administrative • The goal is that the humans should perform only intellectual activities, and other activities should be automated (which may also improve quality) © A. Samarin 2018 Architecting digital systems - Module 1 51 Business: process owners
  50. 50. • Proactive control over execution of business processes • Delegation of complex tasks to less-qualified staff members • Some maintenance without systematic involvement of the IT © A. Samarin 2018 Architecting digital systems - Module 1 52 Business: super-users
  51. 51. • Common dashboard (over different applications) with tasklist, worklist, notifications • Common approach for the implementation of different solutions © A. Samarin 2018 Architecting digital systems - Module 1 53 Business: users
  52. 52. • Achievement of common understanding within a project through clarification of the different views of artefacts • Better visibility of artefacts • Shorten the gap between modelling and implementation Architecting digital systems - Module 1 54 Project: managers Today Tomorrow © A. Samarin 2018
  53. 53. • The architectural framework offers a modelling procedure to guide you to produce executable models • Such a model acts as a skeleton or foundation to which the IT attaches services to obtain the implementation © A. Samarin 2018 Architecting digital systems - Module 1 55 Project: business analysts
  54. 54. • A modelling procedure – four-phase guidance to produce executable models – diagramming style – naming conventions – several practical patterns • Promoting joint work between the business and IT • Quick iterations for building an operational prototype Architecting digital systems - Module 1 56 Project: business analysts KPIs Processes Services Events Roles Data structures Documents Rules Human “workflow” Audit trails © A. Samarin 2018
  55. 55. • Considerable reduction of TCO © A. Samarin 2018 Architecting digital systems - Module 1 57 IT: managers v.1 v.2 v.3 v.4 v.5 Life-cycle TCO First BPM/SOA project Further BPM/SOA projects Each subsequent solution is cheaper because it reuses the same tools, the same services, the same architecture Maintenance approx. 80 % Initial development approx. 20 % Typical IT projects
  56. 56. • Architected flexibility – your BPM system is easily adaptable to practically all aspects of the organisation – policies and priorities – constantly changing business processes – business innovations – computer knowledge and culture of the users – IT systems – size and complexity – data – SLA © A. Samarin 2018 Architecting digital systems - Module 1 58 IT: enterprise IT architects
  57. 57. • Implementation layers of artefacts © A. Samarin 2018 Architecting digital systems - Module 1 59 IT: architects
  58. 58. • Relationship of BPM/SOA with other technologies © A. Samarin 2018 Architecting digital systems - Module 1 60 IT: architects (cont.)
  59. 59. • Transformation from typical inter-application data flows to end-to-end coordination of services © A. Samarin 2018 Architecting digital systems - Module 1 61 IT: developers
  60. 60. • The architectural framework helps to manage the complexity of a mixture of interconnected and interdependent services by making explicit all relationships between services • It thus allows a correct evaluation of the availability of business-facing services from the known availability of technology-related services © A. Samarin 2018 Architecting digital systems - Module 1 62 IT: operators
  61. 61. • The simplest • Zachman framework • The Open Group Architecture Framework (TOGAF) • Federal Enterprise Architecture Freamework (FEAF) • Model of C. Longépé © A. Samarin 2018 Architecting digital systems - Module 1 63 Some EA frameworks
  62. 62. • Nomenclature / taxonomy of artefacts • Building blocks • Layers • Improvement cycle – As-is architecture – Transitional architecture(s) – To-be architecture • Governance processes • Top-down vs bottom-up • Views and viewpoints © A. Samarin 2018 Architecting digital systems - Module 1 64 Some EA concepts
  63. 63. © A. Samarin 2018 Architecting digital systems - Module 1 65 Views of information system
  64. 64. • Pros: – Simple and easy to understand for everyone – Historically well known • Cons: – Too simple – Do not show the constraints and links between layers – Requires to be described twice for the as-is and for the to-be © A. Samarin 2018 Architecting digital systems - Module 1 66 The simplest Strategy and Planning IT Architecture Infrastructure
  65. 65. © A. Samarin 2018 Architecting digital systems - Module 1 67 Zachman framework (1)
  66. 66. • WHAT – assets (physical and electronic ones) • WHO – roles (e.g. people, organizations) • WHERE – places (physical and virtual ones) • HOW – functions (actions of making some assets from other assets, adding value, etc.) • WHEN – events (temporal, systematic, spontaneous, external, internal) • WHY – reasons (e.g. motivation, rules, internal and external constrains including desired performance, principles) © A. Samarin 2018 Architecting digital systems - Module 1 68 Zachman framework (2)
  67. 67. • www.theopengroup.org © A. Samarin 2018 Architecting digital systems - Module 1 69 TOGAF (1)
  68. 68. © A. Samarin 2018 Architecting digital systems - Module 1 70 TOGAF (2)
  69. 69. © A. Samarin 2018 Architecting digital systems - Module 1 71 TOGAF – Architecture development method (ADM)
  70. 70. © A. Samarin 2018 Architecting digital systems - Module 1 72 FEAF (1)
  71. 71. • Four reference models for the US governmental agencies © A. Samarin 2018 Architecting digital systems - Module 1 73 FEAF (2)
  72. 72. © A. Samarin 2018 Architecting digital systems - Module 1 74 Model of C. Longépé Description du métier compréhensible par les acteurs du métier Description et structuration fonctionnelle du système d’information (Services) Description et structuration du système informatique en composants logiciels (Implémentation des Services) Infrastructure de fonctionnement du système d'information et des composants logiciels et applicatifs Métier Applicative Technique Fonctionnelle : : : : : : Systèmeinformatique Systèmed’Information
  73. 73. © A. Samarin 2018 Architecting digital systems - Module 1 75 Comparison
  74. 74. © A. Samarin 2018 Architecting digital systems - Module 1 76 Collection and alignment of EA Operation units & security Tool reviews Feasibility studies Competence centers Architecture Enterprise Livre Blanc : • Vue 6 • Vue 7 • NOCA • Fiches signalitiques • Configurateur Projects CollectionofEArules UseofEA Capitalization PMO Macro-planning Tools: • PM methodology tailoring • “Dossier architecture” • “Fiche chiffrage” • “Fiche qualité”
  75. 75. © A. Samarin 2018 Architecting digital systems - Module 1 77 Vue 6 – conceptual architecture
  76. 76. © A. Samarin 2018 Architecting digital systems - Module 1 78 Vue 7 – technical architecture
  77. 77. • Three different sources of complexity: – natural complexity (problem space) – cultural complexity (social space) – undesired complexity (solution space) • The purpose of Enterprise Architecture (EA) – promote the use explicit and executable techniques to reduce the natural complexity – guide solution architecture to follow the natural complexity to avoid adding undesired complexity – liberate resources to handle the natural complexity Managing complexity © A. Samarin 2018 Architecting digital systems - Module 1 79
  78. 78. • capability, <systems approach> – ability of a system or a system element to do something at a required level of performance • Capability is independent from “how” we do it, “where” we do it, “who” does it, “which tools” are used • Capabilities are grouped by levels (see example below) © A. Samarin 2018 Architecting digital systems - Module 1 80 Reminder the concept “capability” Level 1 Level 2

×