Fakultät für Informatik Technische Universität München A Quantitative Perspective on Systems of Systems Formerly: Upscaling for Systems of Systems Astrid, Iman, Jens, Judith, Steffen, Florian , 12: Dagstuhlintern

Glossary of Terms  Systems = Organizational Systems (social & economic) + IT Systems  Key Performance Indicators (KPIs) are (arbitrary) useful measures for business performance Different from technical throughput, response time, resource consumption intern Dagstuhl2

Geschäfts-Service-Schicht Infrastruktur-Service-Schicht Localizing the Problem: Aligning Business & IT  You can’t manage what you can’t measure  Precision of metrics vs. understandability & commitment & control  Tension between players in the business layer (department egoism)  Gap: Linking and integrating multiple models from the contributing domains intern Dagstuhl3 Business Layer Application & Information Layer Infrastructure Layer Strategies & Objectives KPI Business Service Layer Infrastructure Service Layer Quality Metrics ?!

Problem Statement Simply combining existing metrics of multiple systems is not sufficient to arrive at useful recommendations for key performance indicators (KPIs) in organizations. Reasons  Missing common terminology  Complexity in nature of the socio-technical systems we are measuring Example  Scalability as an aggregated metrics might be more attractive/useful than individual fine-grained metrics  Cost, skills & time are “universal measures” that are neglected today Possible solutions  Interaction between KPI view & systems quantity attributes Business to IT mapping of requirements IT to Business mapping of measurements intern Dagstuhl4

Illustration by a specific example intern Dagstuhl5 Enterprise Architecture Management IT Architecture Management Synchronization Management Project Portfolio Management Strategy & Goal Management IT Project Lifecycle Define Measure Plan Measure Prioritize & Commit Implement Measure Deploy & Migrate Requirements Management Identify Measure SCENARIO: Internet Book shop Stakeholder: Sales Mgr. for the US KPI: # of Customers in the US Goal: Increase in 2010 by 50% Current Value: 1 Mio Customers

Illustration by a specific example  Inspect / update capability map  Collect proposals from marketing  New kind of products mp3 sales through immediate delivery leads to 40% new customers of in 2010  # of MP3 downloads per customer characteristics of work Cost: 1M € in 2010 (setup & operations) Earnings: 100K €in 2010 Time: Shop opening in January 2010: “Immediate”  buy not make  Competing project proposals (modify existing processes) Availability of performance data through monitoring in the past  Are there limiting factors in the existing systems? Missing functionality: Search Engine with Engl. Thesaurus Lack of capacity (# of Engl. Books)  Allocate Budget intern Dagstuhl6

Lessons learned  Business information can to some degree provide useful information for performance management  Can we refine the high-level indicators, e.g. to provide statistical distributions over time and deviations, e.g. Christmas sales, marketing campaign on opening?  How do we estimate value / risk?  How do we handle risk? Oversizing, flexible architecture, simple architecture?  Currently: Low quality, usage, storage, and analysis of logged data  Main motivation for logging today is bug tracking, rarely other goal-directed logging  It is not always clear, which data is relevant for which goal. This can depend on the business context the system is used in.  Need for service management interfaces in addition to service interfaces to perform monitoring & adaptation.  Hypothesis: Fuzzy quantitative models might be more helpful than classical process description languages tuned for automated process execution. intern Dagstuhl7

What can Software Engineering bring to the table?  possible research topics  Quantitative annotation of visual process models (instead of Excel / Visio separately) Similar to tool to describe software processes & analysis of graph, now also applied to medical processes (Lee Osterweil & Lori Clarke, UMass) Dependency Structure Matrixes (DSM) could also applied to business architecture (describe or constrain dependencies between business units / business processes)  Bring together experts with knowledge about marketing models and experts with knowledge about performance models. Is it possible to formalize the marketing models, e.g. to use them in model transformations?  At which level of abstraction could simulation based on behavioral specifications take place? intern Dagstuhl8