Handout 1 Architecture (Concepts) for Digitalization – Old Wine in New Bottles?

Siemens AG 2019 Page 12019 Michael Stal, CT RDA SSI 1

Prof. Dr. Michael Stal

Siemens AG 2019

Handout 2 Objectives of this Talk

Goals Non-Goals

• to provide insights into architectures • to cover each and every aspect (or and architecture concepts for every slide ) Digitalization • to provide a full solution or a • to illustrate some “Anti-Patterns” software/system architecture • to motivate architecture-first instead of technology-first approaches

Siemens AG 2019 Page 32019 Michael Stal, CT RDA SSI 3

Handout 3 Menu

• Architecture matters • Reference Architectures • Architecture Concepts • Systems of Patterns • IoT • Edge Devices • Applications & Infrastructure • AI • Future Outlook • Conclusions and Summary • Q & A

Siemens AG 2019 Page 42019 Michael Stal, CT RDA SSI 4

Handout 4 Architecture matters

Handout 5 Industry is facing a Landscape of Disruptive Innovations

Cloud Native

Siemens AG 2019 Page 62019 Michael Stal, CT RDA SSI 6

Handout 6 Scale Matters

• Decentralization • Inherently conflicting, unknowable, and diverse requirements • Continuous Evolution and Deployment • Heterogenous, inconsistent, and changing elements • Erosion of the system/people boundary • Normal failures • New paradigms for acquisition and policy • Emergent Behavior

Thanks to Linda Northrop, SEI CMU

Siemens AG 2019 Page 72019 Michael Stal, CT RDA SSI 7

Handout 7 Welcome to the Jungle!

Siemens AG 2019 Page 82019 Michael Stal, CT RDA SSI 8

Handout 8 Using „Standard“ Architectures

Handout 9 Challenges

• Digitalization and Industry 4.0 are common challenges in industry and enterprise domains • Re-occurring problem contexts: • Event-Driven Architecture, Reactive Architecture • SPLE, Platforms/Ecoystems, APIs • Communication • Sensing • (Time-series) Data • Persistence (e.g. in-memory databases) • Edge Devices • … One-Size-Fits-All-Reference Architecture for Industry solutions?

Siemens AG 2019 Page 102019 Michael Stal, CT RDA SSI 10

Handout 10 What about Gartner‘s Mesh App and Service Architecture (MASA)?

Increasing Granularity Macroservice Miniservice Microservice

Application Capability Domain Feature E Commerce Order Shopping Shipping service cart options Siemens AG 2019 Page 112019 Michael Stal, CT RDA SSI 11

Handout 11 What about Gartner‘s Mesh App and Service Architecture (MASA)?

Increasing Granularity Macroservice Miniservice Microservice

Application Capability Domain Feature E Commerce Order Shopping Shipping service cart options Siemens AG 2019 Page 122019 Michael Stal, CT RDA SSI 12

Handout 12 IIoT Reference Architecture of the iiconsortium?

Siemens AG 2019 Page 132019 Michael Stal, CT RDA SSI 13

Handout 13 Maybe, the IIoT Reference Architecture of the iiconsortium could be suitable

Siemens AG 2019 Page 142019 Michael Stal, CT RDA SSI 14

Handout 14 Or Reference Architectures proposed by IBM, Oracle, SAP, Amazon, Intel, ARM?

Source: Source: Amazon Microsoft

Siemens AG 2019 Page 152019 Michael Stal, CT RDA SSI 15

Handout 15 Or Reference Architectures proposed by IBM, Oracle, SAP, Amazon, Intel, ARM?

Source: Microsoft

Source: Amazon

Siemens AG 2019 Page 162019 Michael Stal, CT RDA SSI 16

Handout 16 Recommended Approach: Problem Domain First

• Use an Ecosystem • Apply Domain Driven Design to model (Sub)Domains • Bring both together • Mind DevOps in development process

Siemens AG 2019 Page 172019 Michael Stal, CT RDA SSI 17

Handout 17 In theory, practice and theory are the same. In practice, they are not [Albert Einstein]

• Even a Platform Architecture The Gang of Four Design Patterns does not solve all problems • In particular, it doesn‘t cover the concrete problems Structural Behavioral Creational architects & developers face • In practice, proven solutions for recurring problems in specific contexts are needed: Architecture Concepts such as Software Patterns

Siemens AG 2019 Page 182019 Michael Stal, CT RDA SSI 18

Handout 18 In theory, practice and theory are the same. In practice, they are not [Albert Einstein]

Siemens AG 2019 Page 192019 Michael Stal, CT RDA SSI 19

Handout 19 Architecture Concepts

Handout 20 Old Wine in New Bottles?

DSLs MDSD

Patterns & AI Styles

Design Middleware Architecture Tactics

Aspect Modeling Weaving

Components Re-Use & Services Siemens AG 2019 Security Page 212019 Michael Stal, CT RDA SSI 21

Handout 21 Old Wine in New Bottles and some Cool Drinks => Party time

Cloud Robotics DSLs MDSD Computing QueryQL

AI Patterns & Styles Micro- services IIoT

Digitalization Design Middleware Architecture Tactics

Docker + Kubernetes Aspect Modeling Weaving

Components Re-Use Industry Blockchain & Services 4.0 Siemens AG 2019 Security Page 222019 Michael Stal, CT RDA SSI 22

Handout 22 Example: Using Architecture Concepts for Microservice Architectures

• Domain Driven Design to define a Ubiquitous Language and a DSL whenever possible • Service Component Architecture to build Microservices and assemblies of Microservices • MDSD to create implementations/configurations (e.g. based on Docker and Spring Boot) as well as Observation and Control Points for Testing • AOSD to create Cross-Cutting-Concerns and inject them into the implementations • Generative Design to help select the best among multiple architectural alternatives • AI to automatically learn and adapt the system dynamically to the current context, e.g., using Cloud Native as technology platform

Siemens AG 2019 Page 232019 Michael Stal, CT RDA SSI 23

Handout 23 The Four Tenets of Digitalization Architecture

Handout 24 1st Tenet: Scaled Agile (e.g., with SAFe)

Note: All areas and stages contain architecture-relevant information • Agile and lean organizations • Organization • Roles • Management • Product Portfolios • Processes • Principles • Practices • Emphasis on value streams

Siemens AG 2019 Page 252019 Michael Stal, CT RDA SSI 25

Handout 25 2nd Tenet: Automation via DevOps

Note: All areas and stages contain • Acceleration of Development Cycles architecture-relevant information • Solution: Automation via DevOps • Homogeneous stages for Dev, Test, Prod • Empowerment by Inverse Conway Maneuver, and, • Introduction of DevOps Deployment Pipeline If DevOps consists of high number of disparate tools, managing the DevOps infrastructure becomes a nightmare => DevOps as a Service

Siemens AG 2019 Page 262019 Michael Stal, CT RDA SSI 26

Handout 26 3rd Tenet: Evolutionary Architecture Design

(Transformation into) Evolutionary Architecture essential • Evolvability over Predictability • Scaled Agile Twin Peaks Model • Evolutionary Architecture, i.e. incremental, guided development of architecture • Experimentation to avoid technology pitfalls • Hypothesis-based Development such as A/B Testing with Feature Flags • Transformation of Legacy Code starting with • Low Hanging Fruit, Highest Value first, Eroded Subsystems (e.g., lack of test coverage) • Demonstration of Feasibility instead of Powerpoint slides

Siemens AG 2019 Page 272019 Michael Stal, CT RDA SSI 27

Handout 27 Evolutionary Architecture

• Small Architecture Quanta • Reduction of Coupling Points: • Architecture designed around business capabilities • Preference of duplication over re-use • DDD/MBSD for automation of architecture design where Microservice possible and feasible Architecture • Individual selection of technology stack for each Service subdomain Architecture • Goldilocks: definition of technology stack for small, Event Driven medium, large subdomains Architecture • Cross-operational teams to avoid silo-thinking Service Bus Architecture • responsible for products not projects Monolithic • sized according to Amazon Two Pizza Principle Architecture • Deployment Pipeline • Fitness functions (see next slide) Big Ball of Mud

Siemens AG 2019 Page 282019 Michael Stal, CT RDA SSI 28

Handout 28 Fitness Functions

• … measure the architecture: coupling, dependencies, contracts, metrics, -ilities, Fitness function that identifies Dependency Cycles: compliance with guidelines public void testPackageCoupling() { • They can be DependencyConstraint constraint • evaluated and triggered automatically by = new DependencyConstraint(); events in deployment pipeline such as Unit JavaPackage persistence = constraint.addPackage(“com.siemens.....persistence“); Tests, Integration Tests, Acceptance Tests JavaPackage connectivity = • weighted according to their priority constraint.addPackage(“com.siemens.....connectivity“); • atomic such as testing response times JavaPackage helpers = • holistic such as evaluation of tradeoff constraint.addPackage(“com.siemens.....helpers“); persistence.dependsUpon(helpers); between scalability and performance connectivity.dependsUpon(helpers); • continual, e.g., checking functional slices jdepend.analyze(); (transactions) assertEquals(“Dependency Mismatch“, true, jdepend.dependencyMatch(constraint)); • static such as Cyclomatic Complexity } • dynamic: measure performance during high load

Siemens AG 2019 Page 292019 Michael Stal, CT RDA SSI 29

Handout 29 Evolutionary Architecture allows systematically addressing Unknown Unknowns

Principles and Patterns:

• Set-based and Hypothesis-driven Design, Feature- Flags, Canary Releases • Building of Throw-Away-Architectures • Anti-Corruption Layers • Bounded Contexts • Use of the simplest technologies and designs that work • Management of External Dependencies • Preference of libraries over frameworks • Internal version resolution over version numbering

Siemens AG 2019 Page 302019 Michael Stal, CT RDA SSI 30

Handout 30 4th Tenet: Toolset for Architecture Development and Management Aggregate and unify all architecture-relevant information in a navigable and context-sensitive way

Personalized Customizable, Role-specific Dashboards

Configuration TraceabilityTracking and

Proxy …… Workflow Versioning IDEs Service Tool Architecture .. Architecture Monitoring Collaboration Introspection Tools Integrator Repository Approach: Static Analysis Tools • Start small Service Event DevOps Tools Discovery Queue IAM • Eat your Data Layer & Data Transformation Layer own dog Modelling Tools food Software Foundation 3rd Party Sources

Note: All tools and views are not isolated islands, but connected with each other

Siemens AG 2019 Page 312019 Michael Stal, CT RDA SSI 31

Handout 31 Systems of Patterns

Handout 32 Systems of Patterns - Overview

IIoT Foundation

Operations Power Management Sensing Edge Nodes Device Gateway Mains-powered Device Schedule-based Sensing Edge Provisioning Device Shadow Energy-Limited Device Event-based sensing Edge Code Deployment Rules Engine Lifetime Energy-limited Device Hidden Sensors and Actuators Edge Orchestration Device Wakeup Trigger Energy Harvesting device Edge Diameter of Things Delta Update Always-on Device Remote Device Management Normally-sleeping Device Remote Lock & Wipe

Clouds & Services Smart Systems Decentralized Systems

CQRS Separate Knowledge Blackboard Management, Processing & Circuit Breaker P2P Acquisition API Gateway Self-Coordinatiom Encapsulate AI Functionality API Management using Agents Self-Management

Siemens AG 2019 Page 332019 Michael Stal, CT RDA SSI 33

Handout 33 (I)IoT - System of Patterns

Siemens AG 2019 Page 342019 Michael Stal, CT RDA SSI 34

Handout 34 Structural Pattern Pattern: Device Gateway

Uni Stuttgart (L. Reinfurt et al): Mediator, Broker Context: Constrained, Semi- constrained Devices without Internet connectivity Problem: Connecting devices to a network that only support local Gateway communication or low range communication Solution: Introduce a mesh of local devices and an intermediary communication/management gateway

Siemens AG 2019 Page 352019 Michael Stal, CT RDA SSI 35

Handout 35 Structural Pattern Pattern: Device Shadow (aka Digital Twin)

Context: Devices that are often offline Proxy Problem: Other components want to access these components, but do not know their reachability Device Solution: Represent device virtually on + Shadow backend server (i.e., cloud) incl. last state. Communicate with virtual device. Virtual device synchronizes with real device

Siemens AG 2019 Page 362019 Michael Stal, CT RDA SSI 36

Handout 36 Behavioral Pattern Pattern: Rules Engine

Interpreter

> Context: Data received from devices should trigger actions on backend server Problem: How to react when receiving a wide range of messages from devices and other components Solution: Pass messages to a rules engine. Messages are evaluated and <= actions triggered when rule matches. Optional GUI support for defining rules.

Siemens AG 2019 Page 372019 Michael Stal, CT RDA SSI 37

Handout 37 Behavioral Pattern Pattern: Device Wakeup Trigger

Interceptor, Activator Context: devices with constrained power sources Problem: Devices go to sleep mode =>

they are not reachable Device Solution: Implement mechanism that allows server to trigger messages over low power/energy communication. Devices should immediately wake up on such trigger messages

Siemens AG 2019 Page 382019 Michael Stal, CT RDA SSI 38

Handout 38 Behavioral Pattern Pattern: Delta Update

Context: continuous change of data Problem: handling large amounts of data Solution: Keep last message in memory. Calculate Delta of current data plus hash of previous & current data. Hash and delta are sent to Delta Delta receiver. Receiver combines delta and previous information and checks the result for validity using hash

Siemens AG 2019 Page 392019 Michael Stal, CT RDA SSI 39

Handout 39 Structural Pattern Pattern: Remote Device Management

Context: device management Fowarder-Receiver Problem: managing a large amount of devices Solution: Install management server on Manage Device ment backend, and management clients on devices

Siemens AG 2019 Page 402019 Michael Stal, CT RDA SSI 40

Handout 40 Behavioral Pattern Pattern: Remote Lock & Wipe

Context: security of devices Problem: when devices is stolen, Manage Stolen ment device unauthorized persons should not be able to read data or abuse the device Solution: Implement managed devices that retrieve and execute management commands such as wiping all data

Manage ment

Siemens AG 2019 Page 412019 Michael Stal, CT RDA SSI 41

Handout 41 Power Management Pattern Pattern: Mains-powered Device

Context: stationary devices Problem: handling devices with high energy consumption Solution: use main power plug, Device transform high voltage to low voltage, and use a rectifier to convert AC/DC to DC

Siemens AG 2019 Page 422019 Michael Stal, CT RDA SSI 42

Handout 42 Power Management Pattern Energy-limited Device

Context: mobile or autonomous device Problem: device cannot be connected to mains Solution: use exchangeable or Device rechargable power source. Notification service sends alarm when capactity falls under treshold value causing a service technician to change or recharge power source

Siemens AG 2019 Page 432019 Michael Stal, CT RDA SSI 43

Handout 43 Power Management Pattern Lifetime Energy-limited Device

Context: mobile or remote device Problem: keep maintenance efforts and energy consumption low Solution: use power source that keeps Device device running for its whole lifetime

Siemens AG 2019 Page 442019 Michael Stal, CT RDA SSI 44

Handout 44 Power Management Pattern Energy Harvesting Device

Context: mobile or remote device with very low power consumption in a stable, forseeable environment Problem: keep maintenance efforts Device very low Solution: use renewable power sources such as solar cells or wind power. device must only contain low-power components

Siemens AG 2019 Page 452019 Michael Stal, CT RDA SSI 45

Handout 45 Power Management Pattern Always-on Device

Context: mission-critical devices Problem: how should we deal with devices that have infinite power resources, must be always available, Device and implement fast responses Solution: Let the devices always be powered-on and connected

Siemens AG 2019 Page 462019 Michael Stal, CT RDA SSI 46

Handout 46 Power Management Pattern Normally-Sleeping Device

Context: devices with constrained power sources Problem: keeping the power consumption minimal Device Solution: device can shut down main components that are currently not required. Integration of low-power circuit that wakes up components

Siemens AG 2019 Page 472019 Michael Stal, CT RDA SSI 47

Handout 47 Sensing Pattern Schedule-based Sensing

Context: devices that read sensors Problem: device cannot be constrained to specific sensor values, Sensor or is expected to determine trends Device Solution: device follows schedule. Programming ensures that sensors are activated and read according to schedule. Between measurements device is sleeping

Siemens AG 2019 Page 482019 Michael Stal, CT RDA SSI 48

Handout 48 Sensing Pattern Event-based Sensing

Context: devices that read sensors Problem: focus on rare events that cannot be anticipated Sensor Solution: interesting sensor values are Device determined in advance, device contains low-power sensors that are Low always active. Low power circuits read Power sensors. On interesting values device Circuit is being notified

Siemens AG 2019 Page 492019 Michael Stal, CT RDA SSI 49

Handout 49 Hidden Sensors and Actuators

Context: Accessing Sensors and Actuators Adapter Pattern Problem: Sensor, Actuators offer different ways for monitoring and controlling them E.g., temperature sensors might be accessed using different bus types (IIC, CAN, 1-Wire, …) => Northbound layers depend on concrete sensor/actuator type used

Solution: Introduce a combination of Strategy Strategy Pattern and Wrapper/Facade Pattern to hide implementations. Introduce a framework for all sensor and actuator types being used Examples: Johnny Five JavaScript Framework, Cloud Foundy

Siemens AG 2019 Page 502019 Michael Stal, CT RDA SSI 50

Handout 50 Communication Patterns by Intel

Request/Response Known Uses: HTTP, WebServices, REST, CoAP, XMPP Reliable Messaging Known Uses: MQTT, AMQP, via extensions in HTTP, XMPP Asynchronous Messaging Known Uses: XMPP, AMQP und UDP. Fundamental Pattern Event Subscription Clients registers with server Multicasting. Sender delivers message to registered receivers. Known Uses: XMPP, AMQP, UDP Publish/Subscribe Known Uses: MQTT, AMQP, DDS, XMPP

Siemens AG 2019 Page 512019 Michael Stal, CT RDA SSI 51

Handout 51 Communication Patterns by Intel (continued)

Queues Known Uses: AMQP Message Brokers (Centralized Message Broker) Known Uses: XMPP, AMQP, MQTT, DDS. Federation (Divide-and-Conquer-Strategy => Subnets. In HTTP, CoAP federation established using internet domains) Known uses: XMPP (and SMTP = Simple Mail Transport Protocol) Discovery (Registration of things that are found by mapping logical name into physical location) Known Uses: XMPP extension Delegation of Trust Known Uses: XMPP extension

Siemens AG 2019 Page 522019 Michael Stal, CT RDA SSI 52

Handout 52 Edge Computing - System of Patterns

Siemens AG 2019 Page 532019 Michael Stal, CT RDA SSI 53

Handout 53 Structural Pattern Edge Pattern: Edge Provisioning Pattern Devices

Context: IoT devices scattered geographically. Ops must be able to reconfigure devices or provide new ones Problem: How can developers and Ops ensure edge devices are started with a reliable baseline environment Solution: Use container-based virtualization like Chef, Puppet, Docker

Siemens AG 2019 Page 542019 Michael Stal, CT RDA SSI 54

Handout 54 Structural Pattern Edge Pattern: Edge Code Deployment Pattern Devices

Context: Ensure maintainability for remote IoT devices Problem: Developers need to deploy code to many IoT devices quickly and safely, and configure them. Solution: Utilize Git to push a specific branch on a remote Git repository. Server triggers build system, builds and pushes new docker image that is pulled by device. Devices ask for updates periodically

Siemens AG 2019 Page 552019 Michael Stal, CT RDA SSI 55

Handout 55 Behavioral Pattern Edge Pattern: Edge Orchestration Pattern Devices

Context: Edge nodes in a cluster layer must be checked, reconfigured. They provide new services, find each other Problem: How to orchestrate IoT devices in accordance with their tightly scripted configurations as nodes of a cluster remotely and how to let edge cluster nodes detect services Solution: Edge infrastructure toolkits treat and provides edge devices as constrained cluster nodes, and introduces IoT microservices. In addition, discovery mechanisms are provided

Siemens AG 2019 Page 562019 Michael Stal, CT RDA SSI 56

Handout 56 Accounting Pattern Edge Pattern: Edge Diameter of Things Pattern Devices

Context: Introducing metering models for varying business models such as pay-per-use, event based, usage time, prepaid Problem: How to monitor and meter the usage of IoT deployment units in (near-to-)real-time in order to monetize them Solution: Light-weight metering protocol that supports the telemetry of composite IoT applications deployed on resource constrained devices based on a metering plan (subscription type, list of microservices provided, usage pattern and measurement unit, price for each allocated service unit, price for underlying resource usage, resource used unit update rate for each service, subscription fee for prepaid) Roles: Metering Server and Metering Agent

Siemens AG 2019 Page 572019 Michael Stal, CT RDA SSI 57

Handout 57 Application Logic and Infrastructure - System of Patterns

Siemens AG 2019 Page 582019 Michael Stal, CT RDA SSI 58

Handout 58 Advanced Patterns: CQRS (Command-Query-Responsibility- Segregation) Pattern

Context: Efficient Handling of Database Commands & Queries Problem: Commands and Queries often follow different models, and have different scalability requirements in SOA systems Solution: Separate Commands and Queries. Maintenance by different teams possible. Can be Thanks to Martin Fowler for the permission to use combined with Event Sourcing. this image

Siemens AG 2019 Page 592019 Michael Stal, CT RDA SSI 59

Handout 59 Advanced Patterns: Circuit Breaker

Context: Handling Error Conditions in Services Problem: Service failure has occured. How can we prevent clients to put load on Client service/infrastructure? Solution: • Introduce intermediary between client and service Circuit Breaker • Intermediary intercepts client requests. • If fault occurs in service, intermediary just returns error message to client • Otherwise, it forwards the request o service, Service receives the answer, and forwards it to client May act as router as well

Siemens AG 2019 Page 602019 Michael Stal, CT RDA SSI 60

Handout 60 API Gateway Pattern

Context: Providing APIs for Clients to access Microservices Problem: Direct access to Microservices by clients has many issues as clients need to handle many dependencies Solution: Introduce API Gateway Additional Patterns used: • Reverse proxy or gateway routing • Requests aggregation Source: Microsoft • Cross-cutting concerns or gateway offloading

Siemens AG 2019 Page 612019 Michael Stal, CT RDA SSI 61

Handout 61 API Management

Context: Managing APIs Problem: In addition to hiding dependencies from clients, further functionality needs to be enriched Solution: Introduce API Management that comprises an API Gateway, authorization, onboarding, developer documentation, conducts usage

Source: Microsoft analysis, and more

Siemens AG 2019 Page 622019 Michael Stal, CT RDA SSI 62

Handout 62 Caveat: Designing APIs

• API Management and API Gateways are only one side of the coin • API Design is the other • Set of Practices required: Scenario-based Design Low initial hurdle Self-explaining Object Models Layers Coding Guidelines Design of a Type System Practices and Extensibility Guidelines Exception Handling Client-centric vs. Service-centric Usage Guidelines Design Patterns Approach!

Siemens AG 2019 Page 632019 Michael Stal, CT RDA SSI 63

Handout 63 AI - System of Patterns

Machine Learning Supervised Learning Unsupervised Learning Reinforcement Learning

Siemens AG 2019 Page 642019 Michael Stal, CT RDA SSI 64

Handout 64 AI Design Pattern: Encapsulate AI Functionality using Agents

• Actor respectively Agent Model to USER integrate AI functionality • Actor: Output • (Autonomous) Black Box (= Active Object) • Access to internal data/services Input prohibited for external agent • If communication required: Asynchronous Request/Response Model (may provide Futures) Memory • Sensor/Request Queueing (optional)

Siemens AG 2019 Page 652019 Michael Stal, CT RDA SSI 65

Handout 65 Classes of Agents

Simple Reflex Model-based Reflex

• Act only based on current perception • Acts only based on current perception and perception history • Uses Condition/Action rules • Rule matching • Environment must be fully observable • Environment can be partially observable: models the structure of unseen world

Goal-Based Utility-based

• Action depends on „distance“ from goal • Used as building blocks • Action should reduce distance • Decides which option is best among multiple alternatives • May select among different options • Actions chosen on preference (utility) for each state: may • Explicit, modifyable knowledge also choose a path that is quicker, safer, … • => Search and Planning required • Utility (real number) = happiness of agent => each action needs to increase happyness

Siemens AG 2019 Page 662019 Michael Stal, CT RDA SSI 66

Handout 66 AI Architectures

Main application: Machine Learning Neural Networks come in different Flavors: • Fully Connected Neural Networks • ConvNets (Convolutional Neural Networks) • RNNs (Recurrent Neural Networks with LSTMs or GRUs) • GANs (Generative Adversial Networks)

and with various architectures: • Example: Inception Net

Siemens AG 2019 Page 672019 Michael Stal, CT RDA SSI 67

Handout 67 Future Outlook

Handout 68 Even more Systems of Patterns

Data Layer Patterns, Preventive Maintenance Patterns, ….

Siemens AG 2019 Page 692019 Michael Stal, CT RDA SSI 69

Handout 69 The Digital(ization) Architect

Embedded/Electronics Microelectronics Robotics Cybersecurity

Problem Domain Knowledge Digitalization Architecture

Additive Manufacturing FPGAs DevOps Digital(ization) Architects Artificial Intelligence require additional knowledge in different Continuous XXX concepts, technologies, Value Engineering methods, and tools Data Science Business Processes Thus, their role should Microservices Virtualization have a defined profile

Systematic Re-use Cloud Computing

Siemens AG 2019 ….. Data Science Page 702019 Michael Stal, CT RDA SSI 70

Handout 70 … all of which need some time to mature

Siemens AG 2019 Page 712019 Michael Stal, CT RDA SSI 71

Handout 71 Mind the Gap: This Talk could only cover the Tip of the Tip of the Iceberg

We are here

Siemens AG 2019 Page 722019 Michael Stal, CT RDA SSI 72

Handout 72 Conclusions and Summary

Handout 73 Conclusions

„General Purpose“ Reference Architectures do seldomly work Better Approach: Domain-Specific Architectures based upon common platforms/technologies such as Cloud Native

Avoid vendor lock-in whenever possible! E.g., use anti- corruption layers

„Old“ Architecture Concepts (old wine) won‘t become obsolete, but are combined with new concepts and technologies (new bottles)

Observation: Most Patterns for Digitalization actually represent a combination or variants of known Patterns, or just represent known uses

Siemens AG 2019 Page 742019 Michael Stal, CT RDA SSI 74

Handout 74 Conclusions (continued)

The Bad News: Cycle times rapidly decrease, while market pressure and number/complexity of technology innovations increase

The Good News: We can leverage Architecture Concepts as fix points in a continuously changing environment

Good engineers stay calm even in challenging situations

Siemens AG 2019 Page 752019 Michael Stal, CT RDA SSI 75

Handout 75 Hope, you had a relaxing time

Siemens AG 2019 Page 762019 Michael Stal, CT RDA SSI 76

Handout 76 Q & A

Siemens AG 2019 Page 772019 Michael Stal, CT RDA SSI 77

Handout 77 The End

Cheers and Thanks for your Attention

Siemens AG 2019 Page 782019 Michael Stal, CT RDA SSI 78

Handout 78 Michael Stal

Prof. Dr. Michael Stal Principal Key Expert Engineer CT / Germany / Mch P / CT RDA SSI Otto-Hahn-Ring 6 81739 München Phone: +49 89 63 66 33 50 8 Fax: +49 89 63 64 54 50 Mobile: +49 172 84 34 66 1 E-mail: [email protected]

siemens.com

Siemens AG 2019 Page 792019 Michael Stal, CT RDA SSI 79

Handout 79