Systems architecting techniques for IoT, smart cities and cyber-physical systems
•Download as PPTX, PDF•
4 likes•470 views
Systems architecting experience
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Systems architecting techniques for IoT, smart cities and cyber-physical systems
Similar to Systems architecting techniques for IoT, smart cities and cyber-physical systems (20)
More from Alexander SAMARIN
More from Alexander SAMARIN (9)
Recently uploaded
Recently uploaded (20)
Systems architecting techniques for IoT, smart cities and cyber-physical systems
- 2. • An enterprise architect – from a programmer to a systems architect (systems of various sizes: company, corporate, canton, city, country, continent) – have created production systems which work without me • Some of my professional roles – “cleaning lady” (usually in an IT department) – “peacemaker” (between the IT and business) – “swiss knife” (for solving any problem) – “patterns detective” (seeing commonalities in “unique” cases) – “assembler” (making unique things from commodities) – “barriers breaker” (there is always a bigger system) – “coordinator” (without any formal authority over components) 2017-05-24 Systems architecting experience, v1 2 About me
- 3. • I am involved in the system-level standardisation of Active Assisted Living for people with disabilities, Smart Cities, IoT and Smart Homes • These systems are uber-complex, real-time, socio- technical systems of cyber-physical and IT systems with the following characteristics: – huge volume of digital data and information – software-intensive (“software is eating the world”) – distributed and decentralized – great influence on our society (including economy) – ability to interact with the physical world – security, privacy and safety by design – low cost of operations and short time-to-market • Therefore these systems must be carefully architected to deliver their desired capabilities 2017-05-24 Systems architecting experience, v1 3 WHY of this talk
- 4. • This presentation will discuss how several modern techniques and methodologies can be combined together – systems approach and some architecture viewpoints – digitalisation – explicit security – platform-based implementation – microservices • Some materials from my two previous eSummit presentations will be reused (2017-04 about IoT and 2016-04 about Business Architecture) 2017-05-24 Systems architecting experience, v1 4 HOW of this talk
- 5. • systems approach and some architecture viewpoints • digitalisation • explicit security • platform-based implementation • microservices 2017-05-24 Systems architecting experience, v1 5 Techniques and methodologies
- 6. • systems approach – holistic approach to understanding a system and its elements in the context of their behaviour and their relationships to one another and to their environment – Note: Use of the systems approach makes explicit the structure of a system and the rules governing the behaviour and evolution of the system • Four levels of architecting – reference model – reference architecture – solution architectures – implementations 2017-05-24 Systems architecting experience, v1 6 Definitions (1)
- 7. Reference architecture 2017-05-24 Systems architecting experience, v1 7 Levels of architecting Reference model Implementation A2 Solution architecture B Solution architecture A Implementation A1 Reference Implementation Reference solution architecture build and test build and testdesign and experiment field feedback feasibility feedback design and engineer architect extract essentials constraints and opportunities refinement A few scenario reference architectures may be derived from the reference architecture. For example, Smart Cities: metropolis, city, village, island Scenario 2 reference architecture Scenario 1 reference architecture constraints and opportunities design and engineer Problem space Solution space Various needs architect extract Not in the scope of standardisation
- 8. • Explain to any stakeholder how future implementations (which are based on the reference architecture) can address his/her concerns and change his/her personal, professional and social life for the better – explicitly link needs (or high-level requirements) with the principles of reference architecture • Provide a common methodology for architecting systems in the particular system domain – different people in similar situations find similar solutions or propose innovations • Help stakeholders, programmes and projects to collaborate and coordinate their efforts – common agreements (i.e. standards) on various system elements (e.g. services, interfaces, data, etc.) 2017-05-24 Systems architecting experience, v1 8 Purpose of reference architecture
- 9. Geometrical viewpoints of buildings are viewed side by side — as a composition From ISO/IEC/IEEE 42010 View (system-in-focus dependent) vs viewpoint (system-in-focus dependent) Multiple viewpoints are mandatory Architecture viewpoints are often originated by different people — thus they must be aligned to be used together 2017-05-24 Systems architecting experience, v1 9 Each model kind consists of artefacts (e.g. applications, servers, etc.) and relationships between them (those applications are deployed on this servers)
- 10. 2017-05-24 Systems architecting experience, v1 10 Use of views View A Model A1 Model A2 View B Model B1 Techniques, patterns, guesses, magic, full traceability, etc.
- 11. 2017-05-24 Systems architecting experience, v1 11 Some standard viewpoints
- 12. 2017-05-24 Systems architecting experience, v1 12 http://www.slideshare.net/craigrmartin /design-of-business-in-an-age-of- disruption/68
- 13. • Slide 6 from http://www.slideshare.net/TheDesignOfBusiness/introducing-the-open-group-it4it- standard • https://www.salesforce.com/blog/2016/04/how-salesforce-does-enterprise-architecture-.html • https://www.linkedin.com/pulse/design-direct-monitor-enterprise-digital-using-sarath-chandran 2017-05-24 Systems architecting experience, v1 13 Examples from various sources
- 14. • motivation outline viewpoint • big picture viewpoint • capability map viewpoint • design viewpoint – service map – process map – function map – organigramme – system (actually, technical components) model • performance viewpoint • security framework viewpoint • privacy framework viewpoint • safety framework viewpoint • implementation framework viewpoint • deployment framework viewpoint • etc. 2017-05-24 Systems architecting experience, v1 14 Systems approach viewpoints and their model kinds
- 15. • Stakeholders, their roles and their concerns • Needs (or high-level requirements) 2017-05-24 Systems architecting experience, v1 15 Motivation outline viewpoint: stakeholders’ needs analysis
- 16. • Mission – a statement that describes the problem you are setting out to solve, typically including who you are solving it for • Vision – an idealized solution that addresses the problem you’ve articulated in your mission 2017-05-24 Systems architecting experience, v1 16 Motivation outline view: mission and vision
- 17. 2017-05-24 Systems architecting experience, v1 17 Big picture viewpoint: illustrative (example from AAL) An informal description of a future system or organisation in its environment
- 18. 2017-05-24 Systems architecting experience, v1 18 Big picture view: illustrative (from Descriptive Framework)
- 19. • Based on the Business Model Canvas 2017-05-24 Systems architecting experience, v1 19 Big picture viewpoint: business model canvas
- 20. • Essential characteristics of the solution • Dependency matrix between needs and essential characteristics • Architecture principles of the solution architecture • Dependency matrix between essential characteristics and architecture principles 2017-05-24 Systems architecting experience, v1 20 Big picture viewpoint: additional model kinds
- 21. • Leading capabilities – Overall city governance, management and operations • Core capabilities – water, energy, waste, etc. • Enabling capabilities (shared among CORE capabilities) – geomatics, census, registries, etc. • Supporting capabilities – finance, legal, PMO, ICT, media, procurement, etc. 2017-05-24 Systems architecting experience, v1 21 Capability map view: level 1 modularization (example from SC) Structural decomposition of the mission into groups or domains or value streams. All organisations in the same industry sector have the same capability map (and different levels of maturity).
- 22. 2017-05-24 Systems architecting experience, v1 22 Capability map viewpoint: level 1 (example from IoT)
- 23. 2017-05-24 Systems architecting experience, v1 23 Capability map view: level 1 and level 2 (example from IoT)
- 24. 2017-05-24 Systems architecting experience, v1 24 Capability map view: examples from different industries Accept Orders Contact Customer Manage the Business Deliver Orders Support the Business Process Orders Consolidate Orders Manage Production Management Manage Licensee Outbound Operations Manage Materials Receipt and Verification Manage Facility Pre- Production Processing Manage Container & Label Strategies Manage Vehicles Manage Equipment and Equipment-Strategies Manage Facility Property Manage Relationship with Licensees Manage Asset Service Providers Manage Transport Sub-Contracts for Delivery Manage NCR-Code Configurations Define Processing Strategies Define Performance Management Manage Production Systems Strategies Design and Develop Facility Infrastructure Manage Production- Planning Strategies Manage Facility Information Manage Core Business Manage Post- Production Operations Setup for Contractor Delivery Manage Equipment Maintenance Manage Production Operations Accept from Agency Accept from Contractor Accept at Facility Accept at Customer Location Manage FinanceManage Human Resources Manage Facility Administration Manage Materials Strategies Prepare Customer Transfer Support Customer Bulk Orders Handle Customer Complaints & Inquiries Process Service Requests Fulfil Order Prepare Fulfillment Transfer Support Bulk Fulfillment Orders Handle Fulfillment Complaints & Inquiries Process Fulfillment Requests Customer OutboundInbound Support Transport Process Check and prepare vehicle Road Transport Operations Drop Off Orders & empty containers Handle vehicle incidents (breakdowns, re-fuel, etc.) Capture transport run events Drive transport vehicle between locations Pick Up Orders & empty containers Complete preparation of orders into consignments Commence carrier service Carrier staff verify consignment details & hand over consignment to contractor Lodge consignments with carrier Verify / accept consignment Visit "trans-ship" port Complete carrier service Receive & verify consignments Handle consignment exceptions Separate and store containers etc. in preparation for transport to facility Domestic Carrier Transport Operations Planning & Monitoring of Carrier Services Determine required lodgement & handover times Receive new/ updated schedules from carriers Develop & maintain carrier lodgement schedules Monitor carrier services & provide corrective action Assess disputed/ late consignments Transport Facility Management Time and Attendance Monitoring & Control Review Facility Performance & implement improvements Planning & Scheduling Staffing & Rostering Manage Stream orders into production batches Manage batch containers prior to pick up Consolidate Orders Create & Maintain Facility NCR-Code Plans Estimate Production Volumes Plan & Schedule Production Operations Staffing & Rostering Time and Attendance Monitor Order Processing Review Facility Performance & imp. improvements Corrective Action for Processing Quality Control Dock Management Production Management Corrective Action for Transport & Delivery Materials Receipt and Verification Inspection of inbound materials Process “Under Bond” Materials Process Hazardous Materials Handover Materials to Warehouse Licensee Outbound Operations Inspection of outbound product Prepare licensee consignment for despatch Capture outbound volumes and events Despatch outbound product via licensee carrier Receive Transfers at Facility Transfers Damage Check Slotting / Sequencing Interleaving Pre-Mould Verify Slippage Adjustment Batch Alignment for Moulding Pre-Production Processing at Facility Capture Processing Events Prepare Customer Transfer Plan Transfer Production Prepare Transfer Data Prepare Transfer Production Prepare Transfer Documentation Support Customer Bulk Orders Advise customer of bulk-order issues Manage Customer Order Quality Support customer bulk orders Handle Customer Complaints & Inquiries Receive & record notification of problems Investigate & resolve problems Report Status of Order Handle general inquiries Process Service Requests Process Requests Process Other Requests Process Payment for Service Consumable Tools Management Specify Tools requirements Acquire & Locate Consumable Tools Maintain inventory of Consumable Tools Manage & perform maintenance of Consumable Tools Container & Label Management Specify container requirements Acquire & Supply Containers Manage & perform maintenance of containers Maintain inventory of containers Label Policy & Design Manage Label Stock Specify vehicle requirements Vehicle Management Purchase or Lease vehicles (& accessories) Dispose of vehicles Maintain inventory of vehicles Manage contracts with fuel suppliers Monitor payments to fuel suppliers Manage allocation of vehicles to facilities Manage vehicle registration & insurance Prepare claims for diesel & alternative fuel grant Manage maintenance of vehicles Design, Specify & Evaluate New Equipment Purchase/Dispose Equipment & Spares Install & Relocate Equipment Develop Maintenance Strategies Monitor & Optimise Performance & Reliability Equipment Management Ensure Logistics & OH&S Compliance Manage Equipment Configuration Manage Technical Documents & Support Systems Manage Inventory, Repairs & Stores Infrastructure Property Management Specify Property Requirements Acquire Property Dispose of Property Manage Building Administration Establish & Maintain Relationships with Licensees Manage Relationship with Licensees Calculate Revenue due from Licensees Specify materials requirements Materials Management Acquire & Locate Materials Maintain inventory of Materials Select & Manage Asset Maintenance Service Providers Evaluate & select Asset Maintenance Service Providers Establish & maintain Asset Maintenance Contracts Monitor Service Provider performance Terminate Contract Manage Transport Sub-Contractors Maintain Contractor Service Information Evaluate & Select Transport Contractors Establish & Maintain Transport Contracts Monitor Contractor Performance Manage Payments to Contractors Terminate Contract Select & Manage Agencies Evaluate & Select Agencies Establish & Maintain Contracts with Agencies Monitor Agencies Performance Manage Payments To/From Agencies Terminate Contract with Agency NCR-Code Management NCR-Data Strategy, Policy & Procedures Maintain NCR Information Maintain Machine Configuration Data NCR Configuration Improvement Manage Machine- Specific NCR Configuration NCR Code-Sharing Management & Support Processing Policy, Procedures & Governance Processing Strategies Sorting Strategy & Design Develop Processing Plans Measurement of Service Quality Measure Financial Performance Measurement of Resource Utilisation Performance Analysis Performance Management Production Systems Initiate Project Evaluate Solutions Finalise Project Systems support & maintenance Develop / Enhance System Implement System Determine business systems strategies Systems control & Administration Specify Facility Requirements Model Proposed Solutions Select & Design Preferred Solution Plan & Schedule Facility Development Implement Facility Changes Construct Facilities & Equipment Facility / Infrastructure Design & Development Production Planning Determine prod’n strategy & direction Capacity Planning Investment Planning Determine prod’n principles & policies Legislative Compliance Develop & maintain Dangerous Goods policies & procedures Production Capability Analysis Manage Facility Information Define Costing Reference Data Maintain Prod’n Structure Information Define terminology, & codes Manage barcoding standards, formats & characteristics Manage central storage of event information Manage inventory of scanners Manage central storage of production volumes International Carrier Transport Operations Receive inbound containers at origin port Handover outbound containers at destination port Transport bond containers from origin port to destination port Manage Core Business Develop Business Strategies Manage business performance & operations Co-ordinate Projects Develop Business Plans Manage Projects Develop business perf. measures & targets Receive Container from Contractor Drop-Off Setup for Contractor Delivery Receive Misdirected Container from Contractor Deliver Container via Contractor Record errors & notify customer Store articles Verify Customer Pick-up Handle Undeliverables (including missorts) Calculate Priority Delivery Charge Capture Contractor Delivery Events Despatch Container for Contractor Pick-Up Handle delivery vehicle incidents Check & Prepare Delivery Vehicles Document Handover to Transport Driver Capture Non-Contractor Delivery Events Setup for Non-Contractor Delivery Handle Customer Returns Deliver Container to Customer Operate Vehicle for Transport Runs Drop Off / Pick Up at Facility Depot Establish Production Volumes Time and Attendance Monitor Post- Production Operations Corrective Action Review Facility Performance & Implement Improvements Manage Post- Production Operations Staffing & Rostering Plan & Schedule Operations NCR-Code Updates Capture Machine Configuration Changes Capture Tool Changes Capture Machine Changes Capture and Notify NCR-Code Changes Equipment Maintenance Plan & Schedule Equipment Maintenance Perform & Reord Equipment Maintenance Correct & Record Equipment Faults & Parts Usage Monitor & Report Maintenance Compliance Modify Equipment Optimise Equipment Performance & Reliability Handle Non-Valid Orders Machine Preparation Moulding Capture volumes & machine statistics Prepare agency consignments Prepare product for road transport Production Operations Capture production events Inward Dock Operations Initial Preparation Move Product between processing steps Order Configuration Machine Production Manual Preparation Capture Order Assemble Order Prepare order documentation Accept from Contractor Accept Agency Order Capture inbound order events Receive inbound order from agency Print & apply agency identifier labels Reconciliation of agency bills & orders Record agency order violations Handover order documentation to transport driver Receive Order Lodgement Accept at Facility Receive electronic order via internet Process electronic order via email Verify Order Preparation & Streaming Handle Rejected Orders Capture Order information Process Payment for Order Handover Order to Transport Driver Capture actual acceptance events Verify Order Accept at Customer Location Finance Provide Financial Analysis & Direction Support Business Cases Produce budgets & forecasts Manage Financial Policy & Procedures Record & monitor expenditure Human Resources Succession Planning Recruitment Maintain employee records Occupational Health & Safety Operational Training Leave Administration Staff Development Industrial Relations Facility Administration General Administration Perform & Manage Stores Function Manage Technical Documents Maintain Technical Help Desk Capture Consolidation Events Accept Inbound Requests
- 25. • capability, <systems approach> – ability of a system or a system element to do something at a required level of performance • Capability is a concept that captures – “what” an organisation must do to achieve its mission and – “how well” (or “wow”) an organisation must doing that “what” to achieve its mission • Think football – a lot people can play football, but only some of them can play football at the level required to win EURO 2016 2017-05-24 Systems architecting experience, v1 25 About the concept `capability’ (1)
- 26. • Capability is independent from “how” we do it, “where” we do it, “who” does it, “which tools” are used – The concept “capability” is more generic than technical components, data, interfaces, functions, services, applications, processes, roles and organisations – But to provide a capability, several technical components, data, interfaces, functions, services, applications, processes, roles and organisations are, usually, required • There are two major sides of the concept ‘capability’: – capability as a discrete-unit-of-purpose (or discrete-unit-of- mission) – capability as a measure-of-performance (maybe in respect to some maturity matrix) 2017-05-24 Systems architecting experience, v1 26 About the concept `capability’ (2)
- 27. • How to use a capability map – analyse a comprehensive and well-structured set of capabilities – benchmark the particular organisation via the maturity levels of its capabilities (also known as “heat map”) – take an informed (and depending on the unique situation with the particular organisation) decision about each capability 1. to implement it at a particular level of maturity as one or many functions 2. to obtain it from business-to-business partners (outsource or insource) 3. to obtain it from commodity markets 4. to ignore it for now 2017-05-24 Systems architecting experience, v1 27 About the concept `capability’ (3)
- 28. • process map • service map • functional map • organigramme • system (actually, technical components) model 2017-05-24 Systems architecting experience, v1 28 Design viewpoint: additional model kinds
- 29. • systems approach and some architecture viewpoints • digitalisation • explicit security • platform-based implementation • microservices 2017-05-24 Systems architecting experience, v1 29 Techniques and methodologies
- 30. • Business artefacts are available in digital formats (thus formal and machine-executable) • Digital is the master media for business artefacts • Business artefacts can be moved between digital, analogue and physical medias (e.g. with 3D printing and capturing techniques) • Organisation, ecosystem and society “understand” the digital formats for business artefacts • Organisation can transmit, protect, validate, enrich, interpret and manipulate digital business artefacts at their whole life cycle • Organisation knows all the dependencies between its digital business artefacts • Organisation can generate new knowledge from digital business artefacts • Organisation can adapt digital business artefacts (extract, combine, change presentation, convert, etc.) to fit the current needs of a particular customer • People can delegate to "things" (i.e. computers, sensors, actuators, robots, etc.) some routine activities with their business artefacts (e.g. with the use of IoT) • With the progress of IoT, "things" become more capable actors of digital business processes ("things" may form temporary groups to carry out a particular activity) 2017-05-24 Systems architecting experience, v1 30 A digital manifesto
- 31. • For a man-made object, a digital twin comes first • For a nature-made object, a digital twin comes second • Versioning, versioning, versioning and configuration management • Versioning of atomic objects • Versioning of compound objects 2017-05-24 Systems architecting experience, v1 31 Some recommendations
- 32. 2017-05-24 Systems architecting experience, v1 32 Techniques and methodologies • systems approach and some architecture viewpoints • digitalisation • explicit security • platform-based implementation • microservices
- 33. 2017-05-24 Systems architecting experience, v1 33 How to satisfy the requirement “security by design” Attack Vulnerability Technical asset Risk can exploit causes harm Threat provokes Security define the level of undermines leads Adverse impact Likelihood Predisposing conditions Processes Services Outcomes Objectives slows down underperforming missing exposing toArchitecture Organisation occurs with Risk management
- 34. • Threats and vulnerabilities are universal • There is a registry for publicly known information-security vulnerabilities and exposures https://cve.mitre.org/ • The level of adverse impact from an attack depends on the architecture of the system-of-interest • Security and risk can be objectively link by architecture 2017-05-24 Systems architecting experience, v1 34 Improving security (1)
- 35. • Architecture must know all the relationships between all the artefacts (technical assets, services, processes, etc.) to statically evaluate risks • If the implementation of a system is based on business processes then it can dynamically evaluate risks • Knowing the level of risk, one can implement a set of changes to reduce this level to acceptable one 2017-05-24 Systems architecting experience, v1 35 Improving security (2) security measureResidual risk Widely acceptable risk Acceptable risk Unacceptable risk
- 36. • Each system element (tangible assets, intangible assets, peoples) must be explicitly protected – for its confidentiality, integrity and availability – in rest, in transit and in use – throughout its life cycle (within the system-of-interest life cycle) • Relationships between system elements are used to know how changes in one system element effects other system elements – those relationships must be protected as well – ideally, those relationships are explicit and machine-executable 2017-05-24 Systems architecting experience, v1 36 Systems approach to security
- 37. • The best, so far, privacy regulation is EU General Data Protection Regulation (GDPR) to be applied from May 2018 • Challenges of the GDPR – privacy by design and by default – EU citizen is the new data owner – explicit confidentiality and sensitive data protection – very process-driven – data protection officer • In general, no problems with the GDPR compliance: – Use of explicit and machine-executable business processes – Request GDPR compliance from all partners – Use digital contracts (to be discussed later) 2017-05-24 Systems architecting experience, v1 37 How to satisfy the “privacy” requirement
- 38. • At present, many devices from the IoT “world” act as wild animals thus being dangerous in the our world • As in our world, we, people, follow contracts, let us consider rules / regulations / laws for IoT as cyber- physical systems to tame IoT • But we need something more simple and more concrete than the famous “The three laws of robotics” • Let us consider “digital contracts” • Each digital contract is a set of explicit and machine-executable processes between Things, Services and Persons 2017-05-24 Systems architecting experience, v1 38 How to satisfy the “group functioning of IoT devices” requirement
- 39. – with Persons who are living in a particular household – with a producer of this Fridge – with a service company for maintenance of this Fridge – with some online shops to order various food – with some other Things within a particular household to achieve together some goals of energy consumption • Note: The in-house network Router knows that this Fridge has rights to connect only to a few external sites; any other contacts will be blocked by the Router • More info http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html 2017-05-24 Systems architecting experience, v1 39 Example: Smart Fridge’s digital contracts
- 40. • The “point-to-point” pattern can be implemented by simple processes – master-slave processes – co-processes • The “majordomo” pattern is about interactions between one master (major-domo, castellan, concierge, chamberlain, seneschal, mayor of the palace, maître d'hôtel, head butler and chief steward) and many servants; several coordination techniques are mandatory: – shared calendars – event-processing – resource allocation, levelling and balancing – processes and cases 2017-05-24 Systems architecting experience, v1 40 A couple of group functioning patterns
- 41. • Because group functioning depends on sharing data and information (including certificates, ID, etc.) their security must be enhanced by a solid records management • Blockchain-based implementations may be considered for more secure records management 2017-05-24 Systems architecting experience, v1 41 Improving security for group functioning
- 42. • systems approach and some architecture viewpoints • digitalisation • explicit security • platform-based implementation • microservices 2017-05-24 Systems architecting experience, v1 42 Techniques and methodologies
- 43. • Certainly, various Smart Cities systems are similar and different at the same time. Platforms can synergize diversity and uniformity to reduce the cost and time: – The platform frees up resource to focus on new opportunities – Successful agile innovations are rapidly scaled up when incorporated into the platform – An agile approach requires coordination at a system level – To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives – Existing elements of the platform also need periodic challenge 2017-05-24 Systems architecting experience, v1 43 How to satisfy “low cost of operations” and “short time-to-market”
- 44. Solution 1 … Platform Security management Business process management Operational and analytical data Decision management Master and reference data Reporting management Analytics management Drivers … Solution 2 Domain specific layer Service management Event management 2017-05-24 Systems architecting experience, v1 44 Implementation framework viewpoint: platform-based
- 45. 2017-05-24 Systems architecting experience, v1 45 Example: City Unified Business Execution (CUBE) Platform Platforms combine: - diversity - uniformity More info about platforms http://improving-bpm-systems.blogspot.ch/search/label/%23platform
- 46. • systems approach and some architecture viewpoints • digitalisation • explicit security • platform-based implementation • microservices 2017-05-24 Systems architecting experience, v1 46 Techniques and methodologies
- 47. • MicroService Architecture (MSA) is an architectural style for implementing applications as a coherent set of microservices • Microservice is a service with the same boundaries as – a unit-of-functionality (for Biz) – a unit-of-deployment (for Dev) – a unit-of-execution (for Ops) • Microservices are dependent at the design-time • Microservices are independent at the deployment-time • Microservices are interdependent at the run-time 2017-05-24 Systems architecting experience, v1 47 Go back to basics
- 48. • Some experts in SOA consider MSA as a set of technical solutions; MSA is neither architecture nor a variant of SOA - see https://www.linkedin.com/feed/update/urn:li:activity:6266622261210411008/ • Technical people consider that REST over HTTP is mandatory for MSA; actually no https://blog.poki.com/from-monolith-to-microservices-b16bae1d6c9d • Some IT executives consider that MSA forces to rewrite everything (i.e. only the option “build” in “build/buy/rent”)- see comments to https://www.linkedin.com/pulse/beauty- microservices-maturity-model-alexander-samarin – Fortunately, microservices allow the fourth option – “assemble” • Some architects consider that microservices are only atomic – no, a microservice with “wide” responsibility can be assembled from a set of microservices with “narrow” responsibilities 2017-05-24 Systems architecting experience, v1 48 There are many misunderstandings about MSA
- 49. 2017-05-24 Systems architecting experience, v1 49 Process-centric and microservice-based solutions via MSA MSA is enabling BizDevOps culture
- 50. • Any application comprises 10+ artefacts: event, role, rule, data, service, coordination, audit trail, report, etc. • Ideally, each artefact must be handled – Explicitly – As a set of microservices – Via APIs – With versioning – By a specialized COTS tool, e.g. data structures are handled by a database, processes are handled by a BPM-suite tool – In a Domain Specific Language (DSL), e.g. BPMN for processes, DMN for rules – Over its whole life cycle 2017-05-24 Systems architecting experience, v1 50 How to transform a monolith (1)
- 51. • Externalise various artefacts – rules via a decision management tool – coordination as explicit and machine-executable processes via a BPM-suite tool – roles via an access management tool – documents via an ECM tools – automation fragments as scripts in an interpretive language and execution robots – reports view a BI tools 2017-05-24 Systems architecting experience, v1 51 How to transform a monolith (2)
- 52. 2017-05-24 Systems architecting experience, v1 52 Transformation initial planning
- 53. • The proposed use of architecture, digital contracts, explicit processes, microservices and blockchain can make an impression that they will increase the complexity of the system-of-interest • In accordance with the Cynefin framework, the explicit linking allows progressing – from “Complex” situation (in which the relationship between cause and effect can only be perceived in retrospect, but not in advance) – to “Complicated” situation (in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge) • Thus, “complicated” systems can evolve must faster than “complex” systems 2017-05-24 Systems architecting experience, v1 53 Conclusions
- 54. • Personal website: http://www.samarin.biz • Blog http://improving-bpm-systems.blogspot.com • LinkedIn: http://www.linkedin.com/in/alexandersamarin • E-mail: alexandre.samarine@gmail.com • Twitter: @samarin • Mobile: +41 76 573 40 61 • Book: www.samarin.biz/book 2017-05-24 Systems architecting experience, v1 54 Questions?
Editor's Notes
- http://improving-bpm-systems.blogspot.ch/search/label/%23platform
- Candidate: economy…..