The tale of three ATAMs ... Dr. Andrzej J. Knafel
Stage & Prologue: Scenery, Actors, Use Cases, History Act 1: ATAM of the "Old System" Act 2: ATAM of the "Reference Architecture" Act 3: ATAM of the "Implementation Architecture" Epilogue: Conclusions 2
The stage … Scenery Business applications at Roche enterprise as sources or destinations of data and interactions … … connect through Roche intranet, services, Internet and customer ´s IT with … … Roche medical systems (devices) located at clinical laboratories worldwide. 3
The stage … Actors: Roche Devices for In-Vitro Diagnostics Person icon made by Freepik from www.flaticon.com 4
The stage … Actors characteristics 1. Device locations – Worldwide • Different medical device regulations • Different privacy and security regulations – Various maturity of IT environment • High, e.g., hospital clinical labs • Low, e.g., pharmacies, doctor practices 2. Connectivity Number of connected devices: n x 10 6 – – Data volume exchanged: • MBs/day for ~ 9 / 10 of devices • GBs/day for ~ 1 / 10 of devices 5
The stage … Major Use Cases Business Applications 1. Registration and configuration of devices Remote 2. Download Service Apps Transfer of data from Roche enterprise applications to the devices End-to-End Processes 1. Processing parameters ⇔ Registration & configuration 2. Software updates / upgrades Remote Service ← Download data & SW ⇔ Remote interaction 3. Upload → Upload data Transfer of data from devices to Roche enterprise applications 1. Alerts / Events 2. Operational counters 3. Logs 4. Raw measurements Gateway 4. Remote interaction, e.g., screen sharing Device 6
The play in 3 acts … Plot: the journey of architecture decision making Prologue Act 1 Act 2 Act 3 Epilogue “Homegrown” C Improvement of Current Systems “Commercial” “Homegrown” D ATAM 1 of old system + AIW Proof-of-Concept “Commercial” Elaboration of ATAM 2 of Pre-Selection of Implementation Reference “Reference Solution and start Architecture Architecture” Service Providers ATAM 3 of “Implementation Architecture” N N+4 N+16 Months ATAM – Architecture Tradeoff Analysis Method AIW – Architecture Improvement Workshop 7
The prologue … History • High increase in number of connected systems • Bought in 2008 • New use cases � • Unsuccessful roll-out until increase load of data • Incrementally developed at 2014 • More demanding Quality Roche until 2007 Attribute measures • Still operational under load >7x original specifications Future demand Commercial (2008) Homegrown (2000) 8
Stage & Prologue: Scenery, Actors, Use Cases, History Act 1: ATAM of the "Old System" Act 2: ATAM of the "Reference Architecture" Act 3: ATAM of the "Implementation Architecture" Epilogue: Conclusions 9
Act 1 … where are we? ATAM1 - risks with the existing systems # Quality Attributes Risks in System 1 Availability Commercial 70 Risks 2 Reliability Commercial Evaluated 32 scenarios 3 Accuracy 4 Performance / Commercial Scalability Homegrown Concern of not being able to fulfill the growing 5 Interoperability business needs and 6 Extensibility / Homegrown Modifiability customer expectations 7 Maintainability 8 Security 10
Act 1 … where can we go? AIW – planning improvements • Outcome summary organization change recommended � improvements to existing systems � architecture looking for alternative technical solutions � Decision to use ATAM in further phases of the project � 11
Stage & Prologue: Scenery, Actors, Use Cases, History Act 1: ATAM of the "Old System" Act 2: ATAM of the "Reference Architecture" Act 3: ATAM of the "Implementation Architecture" Epilogue: Conclusions 12
Act 2 … examining the options Improvements • Successful – The old “Homegrown” system can handle load ~18x higher than specification – Expanded time window for finding good solution • Unfortunate – Not resolved risks and limitations of the “Commercial” system High importance of searching for alternative solution � 13
Act 2 … looking for alternative Reference Architecture Business Applications 1. Reference Architecture – Patterns solving all major Remote Service Apps risks from ATAM1 Business Applications • Fault handling built into – Technology agnostic Integration end-to-end xfer protocol End-to-End Processes – Used in solution & vendors • Command – ⇔ Registration & configuration Remote Service Response behavior evaluation (part of RFP) ← Download data & SW with sender-controlled, ⇔ Remote interaction Cross-cutting time-constrained, Concerns, e.g., multi-level → Upload data Fault handling, acknowledgment 2. Architecture Governance Authenticity, • Service Interface Integrity, … – Organization Gateway - Devices • Multiple, extensible – Strict governance of channels • Interfaces testable for • Multiple deployment models for connectivity conformance Gateway Interfaces to • Cross-cutting concerns Instrument Applications Device 14
Act 2 … where are we? ATAM2 - reference architecture & 1st solution # Quality Attributes Risks 1 Availability ok 2 Reliability ok 23 Risks Evaluated 38 scenarios 3 Accuracy ok 4 Performance / ok Scalability 5 Interoperability ok Concern of many unknowns, level of architecture decisions, 6 Extensibility / ok Modifiability and management of the service / 7 Maintainability ok solution provider 8 Security ok 15
Act 2 … where should we go? Deriving planning decisions from ATAM2 1. Stabilize the Reference Architecture & specify interfaces in detail 2. Define a Proof-of-Concept to confirm architecture decisions 3. Continue with service & solution provider selection (2 nd phase RFP) – Define “required” SLAs for service provider based on the Quality Attributes – Distribute to pre-selected candidates – Quality Attributes (incl. scenarios) – Reference Architecture – Required SLAs – Commercial requirements (responsibility outside of Architecture dept.) – Assess implementation architecture based on pre-defined evaluation criteria 16
Stage & Prologue: Scenery, Actors, Use Cases, History Act 1: ATAM of the "Old System" Act 2: ATAM of the "Reference Architecture" Act 3: ATAM of the "Implementation Architecture" Epilogue: Conclusions 17
Act 3 … architecting examples Cloud related Remote Service requirements 1. Connection performance of the “last mile” to the customer � latency based connection node location 2. Exchange of data with Roche Business Applications deployed – in the same cloud – in the different cloud – on premises 3. SLAs based on Remote Service use cases and not individual services of cloud provider 4. Global availability – conformance to regional & country regulations 18
Act 3 … architecting examples Remote Service for the IoT Cloud The Availability , Reliability and Performance of connectivity and data processing are well supported by Cloud technology , if the architecture properly utilizes its capabilities Use cloud design patterns Apply best cloud practices • Asynchronous Messaging • Compensating Transaction • Compute Partitioning • Health Endpoint Monitoring • Autoscaling • Messaging • Data Partitioning • Scheduler Agent Supervisor • Data Replication & Synchronization • Retry • Multiple Datacenter Deployment • Queue-based Load Leveling • Service Metering • Event Sourcing • Caching • Competing Consumers • Sharding 19
Act 3 … architecting examples Complex Events Processing (CEP) Connectivity Heartbeat Monitor • – Sequence of events to detect anomalies Connectivity Response Monitor • – Multi-level commands-response tracking – Time-out tracking System / Device Health Monitoring • – Real-time security breach detection – Data and identity protection services – Degradation of customer experience Preventive Maintenance • – Multi-alert pattern analysis – Automatic service scheduling Benchmarking • – Notification when diagnostics process is degraded – On-line calculation of statistical parameters 20
Act 3 … where are we? Proof-of-Concept Setup Devices (n x 10 5 ) simulated by VMs in one 1. cloud environment 2. Prototype of Remote Service in another cloud environment (different technology, different provider) 3. Evaluation of data logs with measurements Results 1. All scenarios fulfilled the required Quality Attributes 2. Some results exceeded the expectations 21
Act 3 … where are we? ATAM3 – target implementation architecture # Quality Attributes Risks 1 Availability ok 23 Risks 2 Reliability ok Evaluated 64 scenarios 3 Accuracy ok 4 Performance / ok Scalability Concern of integration of the 5 Interoperability ok Remote Service 6 Extensibility / into Roche business processes, ok Modifiability incomplete operational concepts, 7 Maintainability ok migration. 8 Security ok 22
Stage & Prologue: Scenery, Actors, Use Cases, History Act 1: ATAM of the "Old System" Act 2: ATAM of the "Reference Architecture" Act 3: ATAM of the "Implementation Architecture" Epilogue: Conclusions 23
Recommend
More recommend
