Towards software-defined organisations

Towards Software-
Defined Organisations
Alexander SAMARIN

• 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

• 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

• Many products but they do not form a system
Example 1 – Active Assisted Living (AAL)
for people with incapabilities

• 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
Example 2 – Smart Cities

Relations between some systems
domains
IoT
Smart
manufacturing
Smart
Homes
AAL
Smart Cities
Smart
Energy

• 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

• 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
Software-Defined Organisations are
digital systems

• 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)
Understanding digital (1)

• 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
Understanding digital (2)

• 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
Systems architecting (1)

• 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)

• 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

• 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

Some standard viewpoints

http://www.slideshare.net/craigrmartin
/design-of-business-in-an-age-of-
disruption/68

• 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
Examples from various sources

• SDO ontology
• SDO artefacts
• SDO viewpoints
• SDO model kinds
• SDO patterns (or methods)
• SDO scenarios
• SDO skeletons
• SDO guidance
Software-Defined Organisations need
more details and formal methods

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

• 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
Core viewpoints

• 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
Value viewpoint

• Stakeholders, their roles and their concerns
Value viewpoint:
stakeholders and dependencies

• 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>
Value viewpoint:
high-level requirements

• 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>,
Value viewpoint:
high-level stories

• 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>,
Value viewpoint:
high-level use cases

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

• 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
Big picture viewpoint

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

Illustrative model(s) of the future solutions
AAL Smart Cities

• 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
The solution space essential characteristics

• 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
The architecture principles of the
solution space

Dependency matrix

The high-level design for AAL solutions

The high-level design for AAL at home

• 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
Capability viewpoint:
definition

• Low-level use cases
• Value stream model
• Function map
• Service map
• Process map
• Events model
• Data model
• Information flow map
• Document/content classification
Engineering viewpoint

Algorithm (1) — mission of the company
Mission
Value viewpoint

Algorithm (2) — capability as discrete
unit of mission
Mission
Value viewpoint
Capability A2Capability A1
Capability B1 Capability B2 Capability B3 Capability B4
Capability viewpoint

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
Engineering viewpointB2C

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
Some other viewpoints

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
Some other viewpoints
Implementation viewpointComposite microservice
API
BPM-suite formSpecific development
COTS B2B service

• Various industry reference models
Using capability map

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

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.)

Addressing B2C concerns about
customer experience

• 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

• 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
Security, safety and risk viewpoint:
digital contracts

Operational viewpoint
example

• 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
Implementation viewpoint:
platform-based approach

example (1)

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
example (2)

• 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

Towards software-defined organisations

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Towards software-defined organisations

Similaire à Towards software-defined organisations (20)

Plus de Alexander SAMARIN

Plus de Alexander SAMARIN (15)

Dernier

Dernier (20)

Towards software-defined organisations

Notes de l'éditeur