Management of Complexity in System Design of Large IT Solutions
Upcoming SlideShare
Loading in...5
×
 

Management of Complexity in System Design of Large IT Solutions

on

  • 6,321 views

The capability to manage complexity is one of the key competencies of system engineers for large IT-solutions. We call a technical system "complex" (in contrast to "complicated") if it is impossible ...

The capability to manage complexity is one of the key competencies of system engineers for large IT-solutions. We call a technical system "complex" (in contrast to "complicated") if it is impossible (due to the networked interaction of its components) to predict the behavior of the whole system, even if you know exactly how each of the system components behave. On the other hand, customers expect increasingly high reliability of IT systems as their business is more and more dependent on the proper operation and interoperation of the IT systems. First we show how a network of interactions increases the complexity of the overall-system. Then we analyze the complexity management strategies of our system engineers and present generalized strategies based on examples of large customer projects. The examples demonstrate that a high maturity in managing complexity enables to provide IT solutions of ultra-high reliability even if they are complex solutions in the above defined sense.

Statistics

Views

Total Views
6,321
Views on SlideShare
6,292
Embed Views
29

Actions

Likes
6
Downloads
272
Comments
2

2 Embeds 29

http://www.slideshare.net 22
http://www.linkedin.com 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Management of Complexity in System Design of Large IT Solutions Management of Complexity in System Design of Large IT Solutions Presentation Transcript

  • Management of Complexity in System Design for Large IT-Solutions Dr. Michael Heiss Global Vice President for Knowledge, Innovation & Technology Dipl.-Ing. Stefan Huber Senior Architekt Siemens IT Solutions and Services © Siemens AG Austria 2009. All rights reserved.
    • Definition
    • Example: Networking generates complexity
    • Categories of Complexity
    • Strategies for Management of Complexity
    Agenda
  • A pragmatic definition of complexity
    • We call a technical system complex (in contrast to complicated), if it is impossible to predict the behaviour of the whole system,
    • even if you know exactly how each of the system components behave and interact.
    Page
  • Just a simple example Page x(t=0..4) = 0,8 x(t > 4) = 0,1 Delay one step y = x - x² y = 3,8x
      • 3 very simple elements
      • 3 simple behaviors
      • “ perfectly predictable ”
    x y x y x y
  • Just a simple example Page y = x - x² y = 3,8x
      • Complexity is generated by interaction
    Delay one step y 1 x = y 1 y 3 x = y 3 y 2 x = y 2
  • Just a simple example … ??? Page
      • Complexity is generated by interaction . The result is…
    Even the best supercomputer of the world cannot predict more than 300 steps full precision limited precision Time steps Unpredictable!
  • A real-life software example
    • In a real world software system the number of elements, interactions and dependencies is far bigger than in the simple “toy” examples.
    • Example: Intelligent Networks service platform for telecom systems
    • (more than 100 customers worldwide)
    Page
  • Where do we meet complexity? Page
      • Complexity of the „ problem space “: Real world phenomena to be solved by means of hardware and software
      • Complexity of the „ solution space “: How the problems are solved through hardware and software
  • Where do we meet complexity? Page
      • Organizational complexity Structure of organizations and teams
      • Process complexity How solutions are developed by the means of processes, methods, tools and technologies
    • Definition
    • Example: Networking generates complexity
    • Categories of Complexity
    • Strategies for Management of Complexity
    Agenda
  • Requirements Engineering – a cycle of detecting and reducing complexity Page Detecting complexity (problem space) Info for the requirements engineer from various sources (requirements documents, interviews with stake holders, discussing prototypes, market studies,...)  The world is more complex than it seems to be at first sight Reducing complexity (solution space) Distilling abstractions out of multiple input, finding out which functions are really needed by a customer (and not everything that is stated as requirement)  Make the solution as simple as possible , as complex as needed
  • Usability Engineering – make solutions “user friendly”
    • Find the right balance in the complexity of the solution and avoid cognitive overload of users
      • Usage scenario driven requirements engineering (typical tasks are most important)
      • Prototyping with customer involvement
      • Standardization of user interfaces (“the Apple way...”)
      • Staging concepts of functionality (“one click shopping” vs. step by step)
      • Usability testing with “thinking aloud” technique
    Page Usability testing Paper prototyping Source: SIS PSE Support Center Usability
  • Divide and conquer? Page
      • Old wisdom of statesmen and commanders
      • Classical principle for trying to reduce complexity :
        • Break down a problem into two or more sub-problems of a similar type, until these become simple enough to be solved directly + focussing - per definition not sufficient for complex systems
    The Tower of Hanoi puzzle: A simple algorithm applied recursively Source: Wikipedia
  • Metrics are useful indicators of complexity Page
      • Complexity of requirements : Function Point Analysis
      • Complexity of code :
        • McCabe metrics (cyclomatic complexity)
        • Halstead metrics (static analysis)
      • Can be a hint showing
        • Maintainability
        • Risk of errors
        • Code worth being reworked or checked e.g. by a senior developer
  • Managing Software Complexity by Patterns Page Suboptimal Software Design
    • Monolithic or
    • Ad-hoc design
    • Complexity not manageable
    • Difficult to understand
    • Error-prone
  • Managing Software Complexity by Patterns Page Suboptimal Software Design
    • Monolithic or
    • Ad-hoc design
    • Complexity not manageable
    • Difficult to understand
    • Error-prone
  • Managing Software Complexity by Patterns Page Software Design Patterns
    • Managing complexity by providing higher level abstractions .
    • Reuse of engineering know-how
    • Patterns can be
    • named
    • taught
    • communicated
    Proxy Facade Chain of Responsibility Composite Factory
  • Managing Software Complexity by Patterns Page Software Architecture Patterns Patterns at Software architecture level Design & Architecture Patterns Training in our Software Architect Curriculum * UI...User Interface Business Layer Data Layer Web / UI* Layer
  • Architectural Qualities and Tactics Page Page
      • Architectural Qualities (related to non-functional requirements)
        • E.g. performance, availability, maintainability
      • Architectural Tactics
        • Tactics to achieve certain architectural qualities
        • More than patterns, tactics provide straight-forward approach from non-functional requirements to a design solution
      • Several architectural tactics support managing complexity
    Tactics Patterns guides selection of implements a collection of Qualities are achieved by using
  • Architectural Qualities and Tactics Page Page Tactics Patterns guides selection of implements a collection of Qualities are achieved by using Modifiability Localize modifications Layers Prevent rippling effects Explicit Interface Testability Manage I/O
  • Organizational patterns – experience based practices to act successfully in a specific context Page Source: Siemens IT Solutions and Services SDE Support Center PM
  • Acting with responsibilities instead of detailed process descriptions Page
      • Defining responsibilities as anchor point for software delopment
      • Performing software design via thinking in responsibilities (e.g. in distributed development)...
        • Provides a basis for independent, local decision making
        • Decouples development process
        • Similarity to management theory (away from Taylorism)
      • Techniques in software development:
        • CRC Cards ( Kent Beck / Ward Cunningham )
          • Classes – Responsibilities – Collaborations
          • “ Responsibility Driven Design”
        • Design by Contract
          • Precondition – Invariant - Postcondition
  • Safety nets in development processes Page
      • Reviews and inspections of intermediate results (specifications, plans, test cases, etc.)
      • Quality gates in company internal processes
      • Impact analyses – identifying the consequences of changes
      • Test driven development (specify test cases prior to developing code)
      • Process improvement (root cause analyses, project experience workshops, CMMI-assessments,...)
  • Safety nets in product design Page
      • Software Architectural Tactics exist to provide safety nets in the product: “Be prepared for the unforeseeable” ( self-healing systems , high system availability , etc.)
      • Examples:
        • Process / system monitoring software
        • Restart routines after error detection (“watchdogs”)
        • Load balancers
        • Redundancies, Voting
        • Heartbeat
    Worker 1 Worker 2 Worker 3 Load balancer
  • Agile Software Development - the new paradigm for Software Engineering Page
      • Time boxing (fixed schedule and effort, functionality to be prioritized by customer – only really important functions are developed)
      • Iterative development with short iteration cycles (fast changes possible)
      • Refactoring (continuous improvement of design)
      • Test driven development
      • Pair programming
      • Self-organizing team, Scrum Master in supportive role
    Source: Siemens IT Solutiond and Services SDE System Engineering Method SEM
  • Depending on the angle of view the same complexity might be easier to handle Page view v 1 view v 2 ? !
    • Example from Computational Intelligence : 4 different „languages“ to tell the computer what to do
    • Presenting the computer:
    • Examples (neural networks, case based reasoning)
    • Rules (fuzzy logic, expert systems)
    • Fitness function (optimization algorithms, genetic algorithms)
    • Commands (classical program code based on classical system modeling)
    • „ No free lunch“: non of them is better for all problems
    • Compare to
    • management theories (all 4)
    • Test driven development (first: examples)
    • Definition of non-functional requirements (first 3)
    correlation visible v 1 v 2
    • Systems have increased interconnectivity
    • This leads to an increased complexity
    • Customers need high availability for mission critical IT systems
    • A high maturity in management of complex systems is required to deliver ultra-highly available and complex IT systems
    Conclusion
    • Assoc. Prof. Dr. Michael Heiss Global Vice President for Knowledge, Innovation and Technology Stefan Huber , Senior Architect Dr. Benedikt Lutz , Head of Learning Network Martin Arnhof , Student
    • Siemens AG Österreich Siemens IT Solutions and Services Gudrunstraße 11 1100 Vienna Austria Phone +43-5-1707-46560 Fax     +43-5-1707-56591 Mobile + 43-664-8855 1526 mailto: [email_address]
    Thank you for your attention! Page