Future-Proof Software-Systems: Summary Condensed Summary of Previous Lectures Lecture Summary of:...

Future-Proof Software-Systems: Summary Condensed Summary of Previous Lectures Lecture Summary of: 22.10.2013 ( 9 slides)

Copyright Frank J. Furrer 20132 I prefer dialog - rather than monolog: Please feel free to ask questions at any time Future-Proof Software-Systems: Preferred Interaction Style I am available for additional questions or discussions after each lecture My Preferred Interaction Style Summary 22.10.2013 Lecture Website: http://st.inf.tu-dresden.de/teaching/fps13

Copyright Frank J. Furrer 20133 Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013 Software is one of the most important key success factors for todays and tomorrows products and services http://myauto24.blogspot.ch/2013/ etc Therefore we need agile, affordable, dependable software what we call future-proof software-systems We as software engineers have a high responsibility to produce good software Software production has mutated from an art to an industrial activity guided by well-founded architecture principles

Copyright Frank J. Furrer 20134 Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013 It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change. Charles Darwin: The Origin of Species (1859) Software must not only be affordable and dependable it must also play its role as a key competitive factor Future-proof software must allow to implement new requirements in a short time, with reasonable cost and with adequate quality Key SW-property: Agility

Copyright Frank J. Furrer 20135 Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013 The three devils of systems engineering are: Complexity, Change, Uncertainty Anonymous

Copyright Frank J. Furrer 20136 Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013 Definition: A future-proof software-system is a structure that enables the management of complexity, change and uncertainty with the least effort, with acceptable risk and with specified quality properties Parts of the system and their relationsships Activity: Steering the development & evolution Providing the best value for the resources money and time-to-market Having an adequate probability for undesired effects and consequences Assuring the desired properties (Fit for Purpose)

Copyright Frank J. Furrer 20137 Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013 Business Value Agility Future-Proof Software-Systems Coordinates System State at time t n System State at time t n+T Project P n Project P n+1 System State at time t n+kT Loss of agility

Copyright Frank J. Furrer 20138 Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013 Future-Proof Software System (FPSS) ) Structure Architecture Manifesto of Future-Proof Software-Systems: 1.Fit-for-Future of an IT-system depends on its structure and is determined by its architecture 2.The agility must continuously be improved 3.Future-proof software-systems need strong architects and a farsighted management

Copyright Frank J. Furrer 20139 Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013 Safety Security Agility Availability etc. Safety Security Agility Availability etc. Functionality of a system or an extension F1F1 F2F2 F5F5 F4F4 FmFm F3F3 A1A1 System & software architecture AnAn A4A4 A5A5 A3A3 A2A2 A9A9 Functionality and architecture are (nearly) orthogonal Architectures differ by their quality properties Architecture assessment & evaluation optimum

Architecture Principles enforce Copyright Frank J. Furrer 2013 10 Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013 Future-Proof Software-System Structure enables Architecture forms http://berxblog.blogspot.ch Future-Proof Software-Systems Engineer Architecture Principle Architecture Principle Architecture Principle Part 1, Slide 90

Future-Proof Software-Systems: Summary 5.11.2013 Condensed Summary of Previous Lectures Lecture Summary of: 5.11.2013 ( 11 slides)

Copyright Frank J. Furrer 201312 Future-Proof Software-Systems: Summary 5.11.2013 Architecture Erosion http://thoreau.colonial.net/Students/EricksonHoyt/erosion Quality Properties : Business Value Agility Security Availability etc. Time Continuously improve the architecture Summary 5.11.2013 Sources of Architecture Erosion: technological change progress in software-engineering new laws & regulations accumulation of mistakes + shortcuts sloppy system extensions and some more

Copyright Frank J. Furrer 201313 Future-Proof Software-Systems: Summary 5.11.2013 Architecture Views Stakeholders www.123rf.com Sys Mgmt Security Safety etc. Architecture documentation: Documentation Framework Views: Overarching documentation Summary 5.11.2013

Copyright Frank J. Furrer 201314 Future-Proof Software-Systems: Summary 5.11.2013 How much Architecture is enough? Architecture work (% total ) Project effort () 10 % 100 % http://www.skyscrapernews.org http://www.dimensionsinfo.com/dimensions-of-a-dog-house Summary 5.11.2013 G. Fairbanks / ISBN 978-0-9846181-0-1

Copyright Frank J. Furrer 201315 Future-Proof Software-Systems: Summary 5.11.2013 Legacy Software http://www.nzz.ch/aktuell/startseite/hintertuerchen-der-banken-bei-den-gold-etf-1.5956390 http://www.123rf.com/photo_4985178_old-rusting-scrapped-cars-in-a-junk-yard.html LiabilityAsset good : invaluable implicit knowledge of the domain and the business processes stable operation (mature) good solutions/algorithms often: suprisingly good code bad : eroded architecture badly or not documented obsolete technology (HW & SW) lost knowledge (people left) difficult integration context Summary 5.11.2013

Copyright Frank J. Furrer 201316 Future-Proof Software-Systems: Summary 5.11.2013 Architecture Principle A1: Architecture Layer Isolation Isolate the architecture layers via standardized, technology- independent and product-independent mechanisms. Never implement technical functionality in the applications. Architecture Principle A1: Architecture Layer Isolation Isolate the architecture layers via standardized, technology- independent and product-independent mechanisms. Never implement technical functionality in the applications. A1 Justification : Any reliance on specific technologies or products generates dependencies which (massively) reduce agility. Architecture layers should be able to evolve in their own pace without impacting the other layers by force Summary 5.11.2013

Industry Standards Technology & Product Independence Copyright Frank J. Furrer 201317 Future-Proof Software-Systems: Summary 5.11.2013 Technical Architecture (Technical Infrastructure) Integration Architecture (Cooperation Mechanisms) Applications Architecture (Functionality) Business Architecture (Business Processes) Information Architecture (Information & Data) Business Process Orchestration Technology Services

Copyright Frank J. Furrer 201318 Future-Proof Software-Systems: Summary 5.11.2013 Architecture Principle A2: Partitioning, Encapsulation & Coupling 1.Partition the functionality and data into encapsulation units according to their coherence and cohesion (thus minimizing dependencies) 2.Isolate the encapsulation units by strictly hiding any internal details. Allow access to functionality and data only through stable, well specified interfaces governed by contracts 3.Minimize the impact of dependencies between the encapsulation units by using adequate coupling mechanisms Architecture Principle A2: Partitioning, Encapsulation & Coupling 1.Partition the functionality and data into encapsulation units according to their coherence and cohesion (thus minimizing dependencies) 2.Isolate the encapsulation units by strictly hiding any internal details. Allow access to functionality and data only through stable, well specified interfaces governed by contracts 3.Minimize the impact of dependencies between the encapsulation units by using adequate coupling mechanisms A2 Justification : These 3 principles minimize the number and the impact of dependencies. The resulting system therefore offers the least resistance to change, because any change affects the smallest possible number of system elements. A low resistance to change corresponds to high agility. Summary 5.11.2013

Copyright Frank J. Furrer 201319 Future-Proof Software-Systems: Summary 5.11.2013 F F F F F F F F FF F F F F F F F F F F F F F IF Partition, encapsulate, and couple as loosely as possbile Summary 5.11.2013

Copyright Frank J. Furrer 201320 Future-Proof Software-Systems: Summary 5.11.2013 Summary 5.11.2013 Q1 : Boundary between Architecture and Design? Q2 : Granularity of the Encapsulation Units?

Copyright Frank J. Furrer 201321 Future-Proof Software-Systems: Summary 5.11.2013 Summary 5.11.2013 Q : Boundary between Architecture and Design? Module Component Application System -of- Systems Technology Dependence Design Architecture Part : Container for functionality & data Relationsship : Contract Part : EJB, Java Class Relationsship : Web-Service

Copyright Frank J. Furrer 201322 Future-Proof Software-Systems: Summary 5.11.2013 Summary 5.11.2013 Q : Granularity of the Encapsulation Units? System-of- Systems System Application Component Module Encapsulation Coupling tight loose

Copyright Frank J. Furrer 201323 Future-Proof Software-Systems: Summary 5.11.2013 Summary 5.11.2013 Part 2, Slide 41 Continuation: Architecture Principle A2: Partitioning, Encapsulation & Coupling Architecture Principle A2: Partitioning, Encapsulation & Coupling A2 How do we: partition encapsulate couple a system?

Copyright Frank J. Furrer 201325 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 The three devils of systems engineering are: Complexity, Change, Uncertainty Anonymous Therefore, good engineering is: 1. Reduce complexity as much as possible (Simplify) 2. Limit the effects of change 3. Contain the risks of uncertainty The most powerful concepts to do so are: 1. Partitioning of the system ( smaller subsystems) 2. Encapsulation ( hide the inner workings) 3. Coupling ( stable interfaces and as loose as possible) 3 main rules: Functional coherence Data coherence Cohesion Partitioning, Encapsulation and Coupling

Copyright Frank J. Furrer 2013/1426 5: Communications & Collaboration Business Partner Applications (BPA) Financial Instruments, Research & Market Data (FIN) Enterprise Content Management (ECM) Client Communication (CHA) Street Side Interfaces (SSI) 1: Partners & Persons 2: Finance, Investment & Sales 3: Trading and Markets 4: Cash and Asset Operations Customer & Partner (CUS) Wealth Management & Advisory (WMA) Credits and Syndication (CRS) 6: Accounting, Controlling and Reporting Financial Accounting (FAC) Regulatory, Risk and Liquidity (RRL) Accounting Control (AOC) Logistics (LOG) Basic Facilities (BAS) Trading (TRA) Product Control (PRC) Payments (PAY) Settlement and Clearing (SCL) Single Accounts (SAC) Custody (CDY) Corporate Actions (COA) 7: Enterprise Common Services Future-Proof Software-Systems: Partitioning, Encapsulation & Coupling Example: Domain Model for a Financial Institution A domain is a container for all the functionality and data related to a specific business activity in this case the trading activities

Copyright Frank J. Furrer 201327 Future-Proof Software-Systems: Partitioning, Encapsulation & Coupling Domain-Driven Architecture and Design Business People: Finance Automotive Aerospace Medical Requirements Software People: Architects Designer Programmer Tester Specifications Requirements Engineering Business Domain Concepts & Terminology Software Engineering Concepts & Terminology http://www.directortom.com

Copyright Frank J. Furrer 201328 Future-Proof Software-Systems: Summary 19.11.2013 Redundancy in an IT-system is in most cases poison for agility and for many of the systems quality properties Functional redundancy: The same or similar function is implemented several times in the IT-system Data redundancy: Same elements of data are stored in different places Interface redundancy: Interface functionality is implemented in more than one interface or overlaps interfaces Code redundancy: The same code-sequence is used in several programs Specification redundancy: The same or similar requirement is stated in different specifications etc. Summary 19.11.2013 http://www.hdwpapers.com Redundancy sneaks into the system via: Requirements Specification Implementation (Coding) Maintenance

Copyright Frank J. Furrer 201329 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 Manage redundancy ! Managed redundancy There is exactly one source for the functionality and for the data (both during development time and during run-time) All redundant copies must be materially and time-wise synchronized NO WAY ! Avoid and eliminate NO WAY ! Avoid and eliminate Identify (search) and eliminate

Copyright Frank J. Furrer 201330 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 System Part A System Part B Interoperability is the capability to exchange and make use of information and control Technical Interoperability Interaction infrastructure Syntactic Interoperability Structure of the data Semantic Interoperability Meaning of the data Applications Interoperability Collaborating applications must share a common conceptual model Instruments: Conceptual Models Domain Models Ontologies Instruments: Controlled Vocabularies Taxonomies Instruments: Syntax specification languages Instruments: Network standards Internet standards

Copyright Frank J. Furrer 201331 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 Q1 : Are there other partitioning rules? Q2 : What is needed for full semantics? Q3 : How do I teach partitioning to my little ones?

Copyright Frank J. Furrer 201332 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 Q1 : Are there other partitioning rules? 1)Functional Coherence 2)Data/Information Coherence 3) Functional and Data & Information Cohesion High performance (HPC) standard performance Low rate of change high rate of change Weak technology dependency strong technology dependency Low criticality high criticality YES ! under special circumstances

Copyright Frank J. Furrer 201333 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 Q1 : Are there other partitioning rules? Hierarchical Partitioning (Dominant Quality Property) Level 1 Very High Performance Safety Level 2 HPC (High Performance Computing) Standard (Standard Performance Computing) Safety-critical Non safety- critical Reduced Architecture Principles Full Architecture Principles Full Architecture Principles Full Architecture Principles http://www.brickbybrickinvesting.comm

Copyright Frank J. Furrer 201334 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 Q2 : What is needed for full semantics? Technical Interoperability Syntactic Interoperability Semantic Interoperability Definition of the concepts and their relationships Applications Interoperability Ontology Applications Interoperability Collaborating applications must share a common conceptual model

Copyright Frank J. Furrer 201335 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 Q2 : What is needed for full semantics? Technical Interoperability Syntactic Interoperability Semantic Interoperability Definition of the concepts and their relationships Applications Interoperability Ontology Applications Interoperability Collaborating applications must share a common conceptual model Savings Account

Copyright Frank J. Furrer 201336 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 Q3 : How do I teach partitioning to my little ones? http://www.hdwallpapers.in Partitioning Rule = Colour

Copyright Frank J. Furrer 201337 Future-Proof Software-Systems: Summary 19.11.2013 Summary 19.11.2013 Part 2A, Slide 122 (A5: Common Functions) Continuation: Architecture Principle A5: Common Functions Architecture Principle A5: Common Functions A5

Copyright Frank J. Furrer 201339 Future-Proof Software-Systems: Summary 3.12.2013 Common Functions & Software Infrastructure Enterprise-wide common software infrastructure managed copy managed copy managed copy Access (Service) access (Service) access (Service) Common Tables Common Data Common Functions Application synchronized in time and content Summary 3.12.2013

highly valuable software/system architecture knowledge in proven & easily accessible form Copyright Frank J. Furrer 201340 Future-Proof Software-Systems: Summary 3.12.2013 Reference Architecture: A reference architecture provides a template solution for an architecture for a particular application domain - such as financial systems, automotive, aerospace etc. Architecture Framework: An architecture framework establishes a common practice for creating, interpreting, analyzing and using architecture descriptions within a particular application domain [ISO/IEC/IEEE 42010] Architecture Pattern: An architectural pattern is a concept that solves and delineates some essential cohesive elements of a software architecture http://en.wikipedia.org/wiki/ Architectural_pattern Reference Architectures, Architecture Frameworks, Architecture Patterns Summary 3.12.2013

Copyright Frank J. Furrer 201341 Future-Proof Software-Systems: Summary 3.12.2013 Reference Architectures Architecture Frameworks Architecture Patterns Future-Proof Software- Systems Engineer Learn & understand Apply & enforce http://biscicol.blogspot.ch/2011/06/biscicol-core-software-architecture.html Summary 3.12.2013

Copyright Frank J. Furrer 201342 Future-Proof Software-Systems: Summary 3.12.2013 Types of Reuse Black Box Reuse Unmodified (1:1) reuse Grey Box Reuse Limited modified reuse (Specific changes 25 %) White Box Reuse Significantly modified (Specific changes 25 %) Parametrization Business Rules True, value-generating Reuse Not reuse unmanaged redundancy Summary 3.12.2013

Copyright Frank J. Furrer 201343 Future-Proof Software-Systems: Summary 3.12.2013 Reuse & Parametrization Black Box Parametrization Business Rules Parametrization Business Rules Parametrization Business Rules Change Distributed/Updated by Configuration Management System Loaded/Initialized at Run-Time Summary 3.12.2013

Copyright Frank J. Furrer 201344 Future-Proof Software-Systems: Summary 3.12.2013 A STANDARD is: a formal, established norm for (technical) systems a document which establishes uniform (engineering or technical) criteria, principles, methods, processes and practices www.ietf.orgwww.omg.org www.iso.org International Standards Organizations CS Business Object Model V1.1/2009 Company Standards Summary 3.12.2013

Copyright Frank J. Furrer 201345 Future-Proof Software-Systems: Summary 3.12.2013 Summary 3.12.2013 1715-1789 Napoleonic Empire (ca. 1810) The power of standards

Copyright Frank J. Furrer 201346 Future-Proof Software-Systems: Summary 3.12.2013 Summary 3.12.2013 Q1 : How many versions in production?

Copyright Frank J. Furrer 201347 Future-Proof Software-Systems: Summary 3.12.2013 Grey Box Modification Divergence (= Unmanaged Redundancy) Grey Box Modification A Grey Box Modifi- cation B Grey Box Modifi- cation C Grey Box Modifi- cation D Change time Black Box Change V5 Black Box Change V6 Black Box Change V7 unmodified reuse 3 versions in production

Copyright Frank J. Furrer 201348 Future-Proof Software-Systems: Summary 3.12.2013 Summary 3.12.2013 Part 2, Slide 40 A9: Information Architecture A10: Formal Modeling A11: Systems-of-Systems (SoS) A12: Complexity and Simplification Additional Topics: Software Product Lines Resilient Software Systems Cloud Computing Architecture Legacy System Migration/Modernization

Copyright Frank J. Furrer 201350 Future-Proof Software-Systems: Summary 17.12.2013 Classification of data/information Structure of data/information Modeling of information Quality assurance of data/information Protection of data/information Modeling of data Deployment of data/information Disaster recovery of data/information Data/Information Architecture Information Architecture Data Architecture conceptual Implementation Summary 17.12.2013

Copyright Frank J. Furrer 201351 Future-Proof Software-Systems: Summary 17.12.2013 Data/Information Architecture The principles for building applications are the same in all application domains [sometimes with some tradeoffs] Q: Is this also true for information/data architecture ? http://www.ormutual.com Enterprise data/information architecture http://www.ove.uk.com Vehicle data/information Architecture [Embedded Systems] unfortunately NO! Summary 17.12.2013

Copyright Frank J. Furrer 201352 Future-Proof Software-Systems: Summary 17.12.2013 Basic Rules for Partitioning : 1)Functional Coherence : Assign functions to encapsulation units based on their coherence (Dogs to Dogs, Cats to Cats) 2)Data/Information Coherence : Assign data and information to encapsulation units based on their similarity (coherence) (Apples to Apples, Pears to Pears) Summary 17.12.2013

Copyright Frank J. Furrer 201353 Future-Proof Software-Systems: Summary 17.12.2013 What is different in embedded systems data & information? http://thorntoncenter.net Time ! Data items have timing relationships between them sometimes very demanding and stringent! Summary 17.12.2013

Copyright Frank J. Furrer 201354 Future-Proof Software-Systems: Summary 17.12.2013 Data Timing & Validation Data in embedded systems must often be validated before use Validation : Assure consistency in value and in time Time ms] Acquisition Interval Sensor FR Sensor FL Sensor BR Sensor BL Brake Control Impact Interval Computing Intervall Validation/Correction http://www.cdxetextbook.com/brakes Wheel rotation speed sensor Validation step : Processing of data items before using them in the computing of actions Methods : cleaning & plausibility algorithms (simplest: -check) Summary 17.12.2013

Copyright Frank J. Furrer 201355 Future-Proof Software-Systems: Summary 17.12.2013 All models are wrong but some are useful http://museumvictoria.com.au/treasures Models simplify the real world Models abstract the real world Models focus the real world Why wrong? Why useful? Summary 17.12.2013

Copyright Frank J. Furrer 201356 Future-Proof Software-Systems: Summary 17.12.2013 Modeling of IT-Systems : State of the Art http://www.ubizoo.de Business Object Model Domain Model Simulink Models Frameworks model@runtime Timed Automata Contracts Directed Hypergraph Taxonomy State Machines Petri Net Ontology OWL SysML UML Summary 17.12.2013

Copyright Frank J. Furrer 201357 Future-Proof Software-Systems: Summary 17.12.2013 Modeling of IT-Systems : Engineering Solutions Business Object Model Domain Model BO Structural Model Behaviour Model Database Model Domain Ontology UML + Profile Model Application Taxonomy UML + Profile Model [Interface Contract Model] Data Dictionary ERD-Model Summary 17.12.2013

Copyright Frank J. Furrer 2013 58 Future-Proof Software-Systems: Summary 17.12.2013 Modeling of IT-Systems : Modeling Instruments UML Diagram Structure Diagram Behaviour Diagram Class Diagram Object Diagram Component Diagram Composite Structure Diagram Profile Diagram Deployment Diagram Package Diagram State Machine Diagram Interaction Diagram Activity Diagram Use Case Diagram Sequence Diagram Communi- cation Diagram Timing Diagram Interaction Overview Diagram http://www.ubizoo.de Summary 17.12.2013

Copyright Frank J. Furrer 201359 Future-Proof Software-Systems: Summary 17.12.2013 Modeling of IT-Systems : Engineering Solutions The Future: Contract-Based Systems Engineering Component, Application Interface Service Contract Component, Application Interface Service Contract Component, Application Interface Service Contract Component, Application Interface Service Contract Composition Summary 17.12.2013

Copyright Frank J. Furrer 201360 Future-Proof Software-Systems: Summary 3.12.2013 Correction : SoS UML Class Diagram Question : When will we see job advertisements for modeling engineers? Summary 17.12.2013

Future-Proof Software-Systems: Summary 17.12.2013 Function [F] utilizes 1..* Function Owner [FO] 1..*1 manages Capability [C] 1..* builds 1..* System-of-Systems [SoS] Mission [M] 11 is defined by Mission Owner [MO] 11 implements 1..* Coordinator [CE] 1 governs Cooperation Standards [CS] 1..* 1 enforces Environment 11..* interacts Users 11..* benefit State of the Art Example : SoS Conceptual Model: Structure (High Level) 1 Constituent System Domain [CSD] Cooperation Domain [CD] 1..* interconnects 1..* 1 Cooperation Mechanism [CE] Cooperation Contract [CC] Constituent System [CS] Process [Proc] 1..* 1 Global (synchronized) Time delivers 1 Governance [Gov] 1 is delineated by 1..* Change Management Ownership Budget Authority 1 11 Summary 17.12.2013

Copyright Frank J. Furrer 201362 Future-Proof Software-Systems: Summary 3.12.2013 Summary 17.12.2013 Question : When will we see job advertisements for SW modelling engineers? http://luciano63.hubpages.com/hub/Sculptural-car-design Answer: UML-Skills: today ! Simulink, Modelica, : today ! Ontological engineering: tomorrow Advanced modelling mechanisms: 3 5 years

Copyright Frank J. Furrer 201363 Future-Proof Software-Systems: Summary 3.12.2013 Summary 17.12.2013 Part 2, Slide 126 A11: Systems-of-Systems (SoS) A12: Complexity and Simplification Additional Topics: Legacy System Migration/Modernization Resilient Software Systems Software Product Lines Cloud Computing Architecture

Future-Proof Software-Systems: Summary 21.01.2014 Condensed Summary of Previous Lectures Lecture Summary of: 21.01.2014 [13 slides]

Copyright Frank J. Furrer 201365 Future-Proof Software-Systems: Summary 21.01.2014 What is a system-of-systems ? ( SoS ) # of stakeholders (users, providers, ) size (SLOCs) 10 8 10 6 10 4 10 2 10 12 10 9 10 6 10 3 System- of- Systems Mega- System Monolithic System Monolithic systems Systems-of-systems: 1.Operational Independence of the Elements 2.Managerial Independence of the Elements 3.Evolutionary Development 4.Emergent Behavior 5.Geographic Distribution [5 Maier criteria, 1998] Managerial Independence of the Elements Emergent Behaviour Governance Total = more than the sum of its parts Summary 21.01.2014

Copyright Frank J. Furrer 201366 Future-Proof Software-Systems: Summary 21.01.2014 SoS (Systems-of-systems) Classification http://www.acq.osd.mil/se/initiatives/init_sos-se.html Summary 21.01.2014

Copyright Frank J. Furrer 201367 Future-Proof Software-Systems: Summary 21.01.2014 Systems-of-Systems Engineering ( SoSE ) CS I CS H CS F CS L SoS http://www.yellowjacketdisposal.com 1)Transparent architecture 2) Explicit dependencies 3) Complete contracts 4) Risk mitigation 5) Monitoring and early response CS A CS E CS D CS G CS B CS N Mission Reqs Constraints CS R SoS Summary 21.01.2014

Copyright Frank J. Furrer 201368 Future-Proof Software-Systems: Summary 21.01.2014 Complexity is that property of an IT-system which makes it difficult to formulate its overall behaviour, even when given complete information about its parts and their relationships Complexity = (IT-) Risk Summary 21.01.2014 good Complexity makes large, useful systems possible It forces us to develop science for dealing with complexity it is a highly interesting and fruitful area of research bad It is the single most important reason for disasters in IT It makes understanding, explaining and evolving IT-systems very hard It may lead to unpredictable (= emergent) behaviour Complexity must be managed ! Identify it Understand it Avoid and reduce it as much as possible

Architecture Topic Map Copyright Frank J. Furrer 201369 Future-Proof Software-Systems: Summary 21.01.2014 Architecture-Greatness: Simplicity Elegance Functionality Architecture-Quality: Agility Availability Security Safety Performance Requirements Req A Req B Req Y Future-Proof Software-System Engineer Summary 21.01.2014 http://de.123rf.com Beautiful Architecture

Copyright Frank J. Furrer 201370 Future-Proof Software-Systems: Summary 21.01.2014 Legacy system modernization strategies: Summary 21.01.2014

Copyright Frank J. Furrer 2013 71 Future-Proof Software-Systems: Summary 21.01.2014 Environment Software System Attack Resilience: Environment Change Fault Human Error Emergent Behaviour https://soundcloud.com Crash t Degraded operation t t Malfunction http://kanto.stripes.com Summary 21.01.2014

Copyright Frank J. Furrer 201372 Future-Proof Software-Systems: Summary 21.01.2014 How can we build resilient systems ? Information Architecture Technical Architecture Integration Architecture Applications Architecture Business Architecture Horizontal architecture layers A1 Layer Isolation A2 Partitioning A3 Redundancy A4 Interoperability A5 Com F A6 Ref Architectures A7 Reuse A8 Industry Standards A9 Inf Arch A10 Formal Modelling A11 SoS A12 Simplification Vertical architecture layers etc. Safety Security Availability Performance Integrity Availability PrinciplesSecurity PrinciplesSafety PrinciplesIntegrity Principles Performance Principles Summary 21.01.2014

http://www.auto-motor-und-sport.de/ Example : Product line in automotive development Copyright Frank J. Furrer 201373 Future-Proof Software-Systems: Summary 21.01.2014 Product Line Definition: A software product line is a set of software-intensive systems sharing a common, managed set of features, that satisfy the specific needs of a particular market or mission and that are developed from a common set of core assets [Clements02] Summary 21.01.2014

Copyright Frank J. Furrer 201374 Future-Proof Software-Systems: Summary 21.01.2014 Economics of Product Line Development: 1 2 3 4 5 6 # of different systems built Total effort [, t] Single systems approach Product line approach Initial effort: Prod line def Variability Quality Great advantage in cost, time-to-market and quality Summary 21.01.2014

Copyright Frank J. Furrer 201375 Future-Proof Software-Systems: Summary 21.01.2014 Cloud = Execution and Delivery Infrastructure Cloud Computing: SaaS S oftware as a S ervice PaaS P latform as a S ervice IaaS I nfrastructure as a S ervice Application End-User Developper System Manager Cloud service consumer Cloud service provider pay as you go Summary 21.01.2014

Copyright Frank J. Furrer 201376 Future-Proof Software-Systems: Summary 21.01.2014 Cloud Computing Risks : SaaS PaaS IaaS Contract SLA: Service Level Agreement functional operational commercial legal compensate by: Cloud Service Level Agreements (Cloud-SLA) http://pssiusa.wordpress.com Security, Dependability, Resilience, Attacks Loss of direct control ??? Summary 21.01.2014

Copyright Frank J. Furrer 201377 Future-Proof Software-Systems: Summary 21.01.2014 Summary 21.01.2014 Part 3, Slide 1 Future-Proof Software-Systems Future-Proof Software-Systems Architecture Principle A11: A1 1 Architecture Principle A11: A1 1 Architecture Principle A11: A1 1 Scientific & Technical Focus Human Focus

Future-Proof Software-Systems: Summary Condensed Summary of Previous Lectures Lecture Summary of:...

Documents

Transcript of Future-Proof Software-Systems: Summary Condensed Summary of Previous Lectures Lecture Summary of:...