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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Management of Complexity in System Design for Large IT-Solutions
Dr. Michael HeissGlobal Vice President for Knowledge, Innovation & Technology
Dipl.-Ing. Stefan HuberSenior Architekt
Siemens IT Solutions and Services
Management of Complexity in System Design for Large IT-Solutions
Dr. Michael HeissGlobal Vice President for Knowledge, Innovation & Technology
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)
Requirements Engineering – a cycle of detecting and reducing complexity
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
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
Acting with responsibilities instead of detailed process descriptions
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)
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”)
Assoc. Prof. Dr. Michael Heiss Global Vice President for Knowledge, Innovation and TechnologyStefan Huber, Senior ArchitectDr. Benedikt Lutz, Head of Learning Network Martin Arnhof, Student
Siemens AG ÖsterreichSiemens IT Solutions and ServicesGudrunstraße 11