O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Towards software-defined organisations

395 visualizações

Publicada em


Publicada em: Tecnologia
  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto

Towards software-defined organisations

  1. 1. Towards Software- Defined Organisations Alexander SAMARIN
  2. 2. • An enterprise architect – from a programmer to a systems architect – have created production systems which work without me • My professional “roles” – “cleaning lady” (at an ICT department) – “peacemaker” (between ICT and the business) – “coordinator” (without formal authority, of course) – “swiss knife” (for solving any potential problem) – “patterns detective” (seeing commons in unique cases) – “assembler” (making unique things from commodities) – “barriers breaker” (always there is a bigger system) 2017-08-15 Towards Software-Defined Organisations 2 About me
  3. 3. • The goal of this talk show how the use of the systems approach to address typical enterprise challenges – an algorithm to generate an organisation’s blueprint – different people in similar situations come to similar solutions and possibly bring innovations – an algorithm to build a bigger enterprise from smaller ones • Management discipline is a coherent set of governing rules for the better management of the organisation functioning in support of the enterprise goals • Applied means that existing scientific knowledge is used to develop more practical applications, like technology or inventions Software-Defined Organisations via systems- approach applied management discipline 2017-08-15 Towards Software-Defined Organisations 3
  4. 4. • Many products but they do not form a system 2017-08-15 Towards Software-Defined Organisations 4 Example 1 – Active Assisted Living (AAL) for people with incapabilities
  5. 5. • Many common goals: sustainable development, better efficiency, resilience, safety and wider support for citizen’s, engagement and participation • Many common technologies: big data, mobile, IoT, etc. • Smart Cities are unique and common at the same time • But current implementation practices are rather disjoint – programmes and projects are, primarily, local initiatives – programmes and projects are considered as technology projects – many independent Smart Cities interest groups – efforts for development of a common vision are insufficient – typical financing patterns do not promote a common vision • There is a systemic problem 2017-08-15 Towards Software-Defined Organisations 5 Example 2 – Smart Cities
  6. 6. 2017-08-15 Towards Software-Defined Organisations 6 Relations between some systems domains IoT Smart manufacturing Smart Homes AAL Smart Cities Smart Energy
  7. 7. • Creation every 4 years of an ad-hoc company with a 5-year life cycle • Contracting key partners (venues, national associations, broadcasters) • Defining the services to be delivered (VIP, broadcast rights, ticketing, etc.) • Developing the organisational structure including one team per venue • Contracting people (including volunteers) and training them • Organising travel, accommodation, logistics, uniforms, etc. for staff and VIPs • Setting-up venues • Operating, i.e. executing, the event (many activities each day) • Dismantling of venues • Post-event placement of volunteers • Liquidation of the ad-hoc company Example 3 — a sports event company 2017-08-15 Towards Software-Defined Organisations 7
  8. 8. • They are uber-complex real-time systems of cyber- physical, socio-technical and classic IT systems with the following characteristics: – digital data and information in huge volumes – software-intensive – distributed and decentralized – great influence on our society – ability to interact with the physical world – many essential characteristics which are required by design and by default (e.g. security, safety, privacy and resilience) – low cost of operation – short time to market • To build right, good and successful digital systems it is mandatory to think about their architectures 2017-08-15 Towards Software-Defined Organisations 8 Software-Defined Organisations are digital systems
  9. 9. • 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-08-15 Towards Software-Defined Organisations 9 Understanding digital (1)
  10. 10. • Employ the concept of “digital twins” - computerized companions of physical assets that can be used for various purposes • For a man-made object, a digital twin comes first • For a nature-made object, a digital twin comes second • Example – a house is designed as “ideal digital house” – this digital form drives 3D printers and robots to build a real house – this real house is equipped by IoT sensors which generate “real digital house” – differences between “ideal digital house” and “real digital house” is used for maintenance and various improvements 2017-08-15 Towards Software-Defined Organisations 10 Understanding digital (2)
  11. 11. • system – set of interacting discrete parts organised as a whole which exhibits (as the result of interaction between the parts) some emergent characteristics indispensable to achieve one or more stated purposes • systems approach – holistic approach to understanding a system and its discrete parts 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 • Any enterprise is a socio-technical system 2017-08-15 Towards Software-Defined Organisations 11 Systems architecting (1)
  12. 12. • Architecting is about – making essential decisions about the system-in-focus to enable the achievement of its desired emergent characteristics – understanding the relationship between structure and behaviour, between design and outcomes • An architect is a person who a) translates a customer’s requirements into a viable plan and b) guides others in its execution Systems architecting (2) 2017-08-15 Towards Software-Defined Organisations 12
  13. 13. • With the required by digital speed and scale, there is no time for human intervention and errors • The focus in systems architecting is changing – FROM the thing (or the artefact) – TO how the thing changes – SUBJECT how things change together • “In the digital age innovation depends on process automation” Effect of digital 2017-08-15 Towards Software-Defined Organisations 13
  14. 14. • Geometrical viewpoints of buildings are viewed side by side — as a composition From ISO/IEC/IEEE 42010 about architecture description • View (system-in-focus dependent) vs viewpoint (system-in-focus dependent) • Multiple viewpoints are mandatory • Architectural viewpoints are often originated by different people — thus they must be aligned to be used together 2017-08-15 Towards Software-Defined Organisations 14
  15. 15. 2017-08-15 Towards Software-Defined Organisations 15 Some standard viewpoints
  16. 16. 2017-08-15 Towards Software-Defined Organisations 16 http://www.slideshare.net/craigrmartin /design-of-business-in-an-age-of- disruption/68
  17. 17. • 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-08-15 Towards Software-Defined Organisations 17 Examples from various sources
  18. 18. • SDO ontology • SDO artefacts • SDO viewpoints • SDO model kinds • SDO patterns (or methods) • SDO scenarios • SDO skeletons • SDO guidance 2017-08-15 Towards Software-Defined Organisations 18 Software-Defined Organisations need more details and formal methods
  19. 19. 2017-08-15 Towards Software-Defined Organisations 19 4 Levels of architecting 2.Reference architecture 1.Reference model 4. Implementation A2 3. Solution architecture B 3.Solution architecture A 4. Implementation A1 4. Reference Implementation 3. Reference solution architecture build and test build and testdesign and engineer field feedback feasibility feedback design and engineer architect extract essentials constraints and opportunities refinement constraints and opportunities design and engineer Problem space Solution space Various high-level requirements from - stakeholders - guiding principles - systems approach architect extract
  20. 20. • Value viewpoint • Big picture viewpoint • Capability viewpoint • Engineering viewpoint • Organisational viewpoint • Operational viewpoint • Implementation viewpoint • Deployment viewpoint • Compliance viewpoint • Regulations viewpoint • Security, safety and risk viewpoint • Privacy viewpoint • Reliability and resilience viewpoint • Governance viewpoint 2017-08-15 Towards Software-Defined Organisations 20 Core viewpoints
  21. 21. • Problem space description • Problem space influencing factors study • The problem space terminology • The problem space constrains • The mission statement and the vision statement • The future solutions stakeholders nomenclature • Stakeholders’ concerns nomenclature • Dependencies between architecture systems roles, stakeholder and stakeholders’ concerns • Some classifications which are specific for the problem space and pertinent for the solution space • The high-level requirements • The high-level stories • The high-level use cases • The common high-level requirements • The problem space coverage by the high-level use cases 2017-08-15 Towards Software-Defined Organisations 21 Value viewpoint
  22. 22. • Stakeholders, their roles and their concerns 2017-08-15 Towards Software-Defined Organisations 22 Value viewpoint: stakeholders and dependencies
  23. 23. • Definition – A high-level requirement is a need, expressed by primary beneficiaries, to the systems do something for them • Pattern to express AAL high-level requirements – As a <WHO - person with a lack of particular capability>, I want the AAL systems <DO SOMETHING - help me to overcome the limitations of this incapability and reduce risks caused by this incapability>, thus <WHY (expected outcome) – I can have active personal, social and professional life> 2017-08-15 Towards Software-Defined Organisations 23 Value viewpoint: high-level requirements
  24. 24. • Definition – A high-level story is a high-level requirement in a context • One high-level requirement may lead to a few high-level stories • Pattern to express high-level stories – As a <WHO - person with a particular incapability>, <WHEN/WHERE – I am in a particular situation>, I want the AAL systems <DO SOMETHING – help me to overcome limitations of this incapability and reduce risks caused by this incapability>, thus <WHY (expected outcome) – I can have active personal, social and professional life> 2017-08-15 Towards Software-Defined Organisations 24 Value viewpoint: high-level stories
  25. 25. • Definition – A high-level use case is a description of interactions between a primary beneficiary, the system or its elements (all as different actors) to achieve the expected outcome as described in a related high-level story • One high-level story may lead to a few high-level use cases • Pattern to express high-level use cases – As a <WHO - person with a particular incapability>, <WHEN/WHERE – I am in a particular situation>, <DO some interaction between actors>, thus <WHY (expected outcome) – I can have active personal, social and professional life> 2017-08-15 Towards Software-Defined Organisations 25 Value viewpoint: high-level use cases
  26. 26. 2017-08-15 Towards Software-Defined Organisations 26 Value viewpoint coverage by the high-level use cases 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 Context Category Chart 2
  27. 27. • The solution space terminology • The solution space constrains • Some classifications which are specific for the solution space • Illustrative model(s) of the future solutions • The solution space essential characteristics • The architecture principles of the solution space • The high-level design for the future solutions 2017-08-15 Towards Software-Defined Organisations 27 Big picture viewpoint
  28. 28. 2017-08-15 Towards Software-Defined Organisations 28 Big picture viewpoint: The solution space constrains Smart Cities  interoperability  simplicity  low cost of operation  short time to market  self-referential AAL  interoperability  simplicity  low cost of operation  short time to market
  29. 29. 2017-08-15 Towards Software-Defined Organisations 29 Big picture viewpoint: Illustrative model(s) of the future solutions AAL Smart Cities
  30. 30. • AAL – Continuous monitoring of primary beneficiaries’ state anywhere and anytime – Fast and coordinated delivery of the AAL services to primary beneficiaries – Helping primary beneficiaries with mobility and social interactions – Helping primary beneficiaries with coordination in time and space – Provisioning assistance to primary beneficiaries in various languages and countries – Handling primary beneficiaries’ well-being and medical records – Protecting primary beneficiaries’ privacy 2017-08-15 Towards Software-Defined Organisations 30 Big picture viewpoint: The solution space essential characteristics
  31. 31. • AAL – Explicit AAL system architecting and engineering to achieve the required level of operational excellence, security, privacy and safety – Separation of concerns between IoT, Smart Homes and Smart Cities system domains – AAL is an assembly to be very adaptive and flexible – AAL is a coordination environment for many products – AAL employs many IoT intelligent devices; AAL may be integrated in Smart Homes – Use innovative means to achieve “security by design”, e.g. digital contracts between people, services, applications, devices, robots and organisations – Time-bound and place-bound (or space-bound) synergy 2017-08-15 Towards Software-Defined Organisations 31 Big picture viewpoint: The architecture principles of the solution space
  32. 32. 2017-08-15 Towards Software-Defined Organisations 32 Big picture viewpoint: Dependency matrix
  33. 33. 2017-08-15 Towards Software-Defined Organisations 33 Big picture viewpoint The high-level design for AAL solutions
  34. 34. 2017-08-15 Towards Software-Defined Organisations 34 Big picture viewpoint The high-level design for AAL at home
  35. 35. • capability, <systems approach> – ability of a system or a system element to do something to achieve its mission at a required level of performance • Think football – a lot people can play football, but only some of them can play football at the level required to win EURO 2016 • All the systems in the particular industry sector have the same (reference) capability map • Each capability is realised in one of the following ways 1. implement it at a particular level of maturity as one or many functions 2. obtain it from business-to-business partners (outsource or insource) 3. obtain it from commodity markets 4. ignore it for now 2017-08-15 Towards Software-Defined Organisations 35 Capability viewpoint: definition
  36. 36. • Low-level use cases • Value stream model • Function map • Service map • Process map • Events model • Data model • Information flow map • Document/content classification 2017-08-15 Towards Software-Defined Organisations 36 Engineering viewpoint
  37. 37. Algorithm (1) — mission of the company Mission Value viewpoint 2017-08-15 Towards Software-Defined Organisations 37
  38. 38. Algorithm (2) — capability as discrete unit of mission Mission Value viewpoint Capability A2Capability A1 Capability B1 Capability B2 Capability B3 Capability B4 Capability viewpoint 2017-08-15 Towards Software-Defined Organisations 38
  39. 39. Algorithm (3) — implementations of capabilities Mission Value viewpoint Capability A2 Function A2 Capability A1 Function A1 Capability B1 Commodity Capability B2 B2B service Capability B3 Process B3 Capability B4 COTS Big picture viewpoint Capability viewpoint Engineering viewpointB2C 2017-08-15 Towards Software-Defined Organisations 39
  40. 40. Algorithm (4) — operating model Mission Value viewpoint Capability A2 Function A2 Capability A1 Function A1 Capability B1 Commodity Capability B2 B2B service Capability B3 Process B3 Capability B4 COTS Big picture viewpoint Capability viewpoint Engineering viewpointB2C Some other viewpoints 2017-08-15 Towards Software-Defined Organisations 40
  41. 41. Algorithm (5) — machine-executable Mission Value viewpoint Capability A2 Function A2 Capability A1 Function A1 Capability B1 Commodity Capability B2 B2B service Capability B3 Process B3 Capability B4 COTS Big picture viewpoint Capability viewpoint Engineering viewpointB2C Some other viewpoints Implementation viewpointComposite microservice API BPM-suite formSpecific development 2017-08-15 Towards Software-Defined Organisations 41 COTS B2B service
  42. 42. • Various industry reference models Using capability map 2017-08-15 Towards Software-Defined Organisations 42
  43. 43. Matching business functions and tools Business Functions Tools Concrete business capabilities Specific technical capabilities Generalised Technical capabilities Uniform Business capabilities Tools Implicit Implementation Business Functions Magic • Various patterns and good business practices 2017-08-15 Towards Software-Defined Organisations 43
  44. 44. Modelling of processes on demand L1 Value- steam s L2 Clusters-of- processes L3 Coordination of fragments L4 Coordination of activities L5 Automation of activities and processes Departmental projects to implement the processes of a particular business domain with a BPM-suite tool Quick enterprise-wide “landscape” project to develop L1 and L2 processes and to establish common practices (modelling procedures, patterns, etc.) 2017-08-15 Towards Software-Defined Organisations 44
  45. 45. Addressing B2C concerns about customer experience 2017-08-15 Towards Software-Defined Organisations 45
  46. 46. • How can you manage efficiently many contracts? • Consider each contract is a process-centric solution (who is doing what, when, how well, etc.) • But such a contract must be “immutable”: – open-source BPMs tool – standardised and certified execution semantic – contract process definition is immutable (save it in a blockchain!) – all the audit-trails and collected data are immutable – potentially, BPM-suite tool is operated by a certified third-party – potentially, my “digital” lawyer is one of the miners in this blockchain B2B and commodities — many contracts to manage 2017-08-15 Towards Software-Defined Organisations 46
  47. 47. • IoT device Fridge has a few digital contracts: – 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-08-15 Towards Software-Defined Organisations 47 Security, safety and risk viewpoint: digital contracts
  48. 48. 2017-08-15 Towards Software-Defined Organisations 48 Operational viewpoint example
  49. 49. • Main challenge – combine uniformity and diversity – The platform standardise and simplify core functionality – For any elements outside the platform, new opportunities should be explored using agile principles – These twin approaches should be mutually reinforcing: the platform frees up resource to focus on new opportunities while successful agile innovations are rapidly scaled up when incorporated into the platform – An agile approach requires coordination at a system level – Existing elements of the platform also need periodic challenge • Essential technologies ad methodologies: BPM and microservices 2017-08-15 Towards Software-Defined Organisations 49 Implementation viewpoint: platform-based approach
  50. 50. 2017-08-15 Towards Software-Defined Organisations 50 Implementation viewpoint: example (1)
  51. 51. Reference architecture Reference modelReference platform S2 …S1 S3 platform in City B S2 … B2B1 platform in City A A2 …S1 platform in City T S2 …T1 T3 Cooperation and coordination Telecommunication providers Industries Academic and research institutes Financial organisations Standards Development Organizations Specialized consulting firms Implementation viewpoint: example (2) 2017-08-15 Towards Software-Defined Organisations 51
  52. 52. • 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 Towards Software-Defined Organisations 52 Questions? 2017-08-15