Mini-course at VFU - Architecting modern digital systems - 1

Architecting
digital
systems
Module 1
System, digital and architecture
Alexander Samarin

• system
set of interacting discrete elements organised as a whole
which exhibits (as the result of interaction between the
elements) some emergent characteristics indispensable to
achieve one or more stated purposes
– Etymology: from the Latin systēma, which in turn is derived from
the Greek σύστημα meaning “together”
• “Discrete" means "individually
separate and distinct"
• Systems are different from
structural assemblies
• A system is more than a sum
of its discrete elements
© A. Samarin 2018 Architecting digital systems - Module 1 2
Definition of system

– A system is encapsulated, has a boundary
– A system can be nested inside another system
– A system can overlap with another system
– A system is bounded in time; it has its own life cycle
– A system is bounded in space, though the elements are not
necessarily co-located
– A system receives input from, and sends output into, the wider
environment
– A system consists of processes majority of them transform inputs
into outputs
– A system for somebody is an element for another
– Different stakeholders see the same system differently
System’s characteristics

• structure <of a system>
internal arrangement of, and relationship between,
elements
– Etymology: from the Latin structūra meaning “a fitting together”
• behaviour <of a system>
what a system will do in response to its external
environment without referring to details on
implementation
– Note: In some cases, the behaviour of a system cannot be
explained in terms of the behaviour of its elements
– Note: Some emergent characteristics are the result of a system’s
behaviour
Related concepts

• Chaotic vs. organised
• Accidental vs. intentional
• Static vs. dynamic
Any system has a structure

• Unlimited life-cycle (unpredictable and incremental
evolution)
• Socio-technical
• Collaborative
• Industrialised
• Ability for rapid innovation is important
• Variety of services
• High level of security for data
• Customer experience
• Self-referential
Systems are complex

• architecture <of a system>
fundamental orderliness (embodied in its components,
their relationships to each other and the environment),
and the principles governing the design, implementation
and evolution
• 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

• Enterprise architecture is sometimes translated into
French as “urbanisation”
Architecture used to construct Garthage

Importance of architecture
 No architectural blueprint
 38 years of construction
 160 rooms, 497 doorways, 950 doors
 Over 20 tonnes of paint required
 No disruption of river traffic activities
 The committee evaluated 50 projects
 Three architectural techniques
 8 years of construction
 Modernised for new technology

• Digital triumphs physical
• Fast triumphs slow
• Group triumphs single
• Big triumphs small
• With this new speed and scale, there is no time for human
intervention and errors in routine operations and at
interfaces
Digital age

• Digital system
– a system which building its life cycles of its primary artefacts on
the primacy of explicit, formal, computer-readable and computer-
executable description of those artefacts
• Example
– an ideal digital description of a house is designed
– this digital description is used to create a physical copy of the
house, e.g. with the use of 3D industrial printers
– various implanted IoT devices permanently monitor the real
situation with the house and create a real digital description
– the real digital description of the house is used for its maintenance
– the real digital description of the house is used to improve its ideal
digital description
About Digital Systems

• Employ the concept of “digital twins”
– Digital twins refer to computerized companions of physical
assets that can be used for various purposes. Digital twins use
data from sensors installed on physical objects to represent their
near real-time status, working condition or position.
• For a man-made object, a digital twin comes first
• For a nature-made object, a digital twin comes second
• Versioning and configuration management are
fundamental
• Versioning of atomic objects
• Versioning of compound objects
Some recommendations related digital
systems

• Healthcare, Smart Cities, Smart Homes, Smart Energy,
IoT and Smart Manufacturing 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
– security, safety, privacy and resilience are required by design
• To build right, good and successful Digital Systems it is
mandatory to think about their architectures
We deal with Digital Systems

• Why do we need methodology?
– the goal: different people in similar situations find similar
solutions/services/components or bring innovations
• systems approach
holistic approach to understanding a system and its
discrete 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
Systems architecting methodology

Eight areas of six systems traditions

System-of-interest and its environment

• Formalise your artefacts – syntax and semantic
• Define their life cycles
• All artefacts must be versionable throughout their lifecycle
• All artefacts must evolve to become externalised, virtual
and cloudable
• Assemble some artefacts into other artefacts
• All relationships between artefacts must be modelled
explicitly – thus the system’s structure is explicit
• All models must be made to be machine-executable –
thus the system’s behaviors can be simulated in advance
• Adjust the artefacts and models to achieve the optimal
behaviors for emergent characteristics
Ideal (happy) path

• Strategy
– top manager
• Business
– manager
– process owner
– super-user
– user
• Project
– manager
– business analyst
• IT
– manager
– enterprise IT architect
– solution architect
– developer
– operator
Different stakeholders have different
views and concerns

4 levels of systems architecting
2.Reference
architecture
1.Reference
model
4. Implementation
A2
3. Solution
architecture B
3.Solution
architecture A
4. Implementation
A1
4a. Reference
Implementation
3a. 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
needs
architect
extract
See some definitions
at the end of this
slide deck

• 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 approach 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.), common vision, etc.
Purpose of reference architecture

Geometrical views of buildings
are viewed side by side —
as a composition
Architecture description: Viewpoints,
models kind, views and models
View (system-in-focus dependent) vs viewpoint
(system-in-focus independent)
Multiple viewpoints are mandatory
Architectural views are often
originated by different people —
thus they must be aligned to
be used together
Each model kind consists of artefacts (e.g.
applications, servers, etc.) and relationships
between them (those applications are
deployed on this servers).
In accordance with
ISO/IEC/IEEE 42010

• One of three International Standard Development
Organisations
– ISO
– ITU
– IEC
• www.iec.ch
2018-03-12 Syc Smart Cities for Varna 24
International Electrotechnical
Commission

• About 10 years ago IEC found that some problems are
bigger than a few Technical Committees
• System Committee (SyC) has to analyse a domain and
propose missing standards to be developed
– SyC Smart Energy
– SyC Active Assisted Living (AAL)
– SyC Smart Cities
– SyC Low Voltage Direct Current (LVDC)
– SEG 7 Smart Manufacturing
– SEG 8 Communication Technologies and Architectures
– SEG 9 Smart Home/Office Building Systems
– SRG Systems Resource Group
System Committee concept

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

• 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 which has to be addressed
with the IEC SRG Systems Approach
Smart City as a System is important

Achieve synergy between
diversity and uniformity
A
unique
A
common
B
unique
B
common
T
unique
T
common
Let us
1) Build common understanding
2) Isolate common parts
3) Find how to integrate unique and common parts
4) Develop common parts once and with high quality as a platform
5) Have an individual version of the common platform at each Smart City
6) Cooperate and coordinate among Smart Cities
Together Smart Cities will gain a lot in quality, time and money

Reference architecture helps to isolate
unique & common parts of Smart Cities
A
unique
A
common
B
unique
B
common
T
unique
T
common
Reference architecture

Reference architecture
Reference modelReference CUBE platform
S2
…S1 S3
CUBE platform in City B
S2
… B2B1
CUBE platform in City A
A2
…S1
CUBE 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
City Unified Business Execution (CUBE)
Common parts
Unique parts

• N is the total cost of a Smart City implementation
(construction and operating)
• 70 % - common, 30 % - unique
• Total cost for 100 Smart Cities WITHOUT standardization
– N * 100
• Total cost for 100 Smart Cities WITH standardization
– N * 100 * 0.3 (unique parts) + N * 1 * 0.7 (common parts) * 3
(complexity factor) = N * (30 + 2.1) = N * 32.1
• Cost difference is (N*100) / (N*32.1) ≈ 3 times!
• Thus good, right and successful architecture for Smart
Cities is very important
Simple calculations

• Value viewpoint
– stakeholders, high-level requirements, mission, vision
• Big Picture viewpoint
– illustrative, essential characteristics, architecture principles
• Capability Map viewpoint
– level 1 modularisation, level 2 modularisation
• System Target Operating Model (STOM) engineering viewpoint
– function map, service map, process map, data flows, organigramme
• Operating viewpoint
• Performance viewpoint
• Implementation viewpoint
• Security, Safety, Risk, Privacy and Resilience viewpoint
• Standards viewpoint
Smart Cities Reference Architecture
Methodology: essential viewpoints

• Stakeholders, their roles and their concerns
Value view:
stakeholders’ needs analysis

• The guiding principles for defining the Smart Cities
architectures are
– interoperability
– safety
– security (including confidentiality, integrity and availability)
– privacy
– resilience
– simplicity
– low cost of operation
– short time to market
– combining diversity and uniformity
– self-referential
Value view:
guiding principles

• List of high-level requirements
– Adequate water supply
– Assured electricity supply
– Sanitation, including solid waste management
– Efficient urban mobility and public transport
– Affordable housing, especially for the poor
– Robust IT connectivity and digitalisation
– Good governance and citizen participation
– Sustainable environment
– Safety and security of citizens, particularly women, children and
the elderly
– Affordable healthcare for everyone
– Modern education for children and adults
– Attractive for business
Value view:
high-level requirements (example)

Big picture view:
illustrative (from Descriptive framework)

• Flows handling: Cities are self-referential systems of flows ( see
http://www.academia.edu/15717758/Conceptualising_the_Urban_System_as_a_System_of_Flows )
and, those flows are flows of entities of various types: digital, physical, living, social, political, legal, etc.
If no flows then a city is dead.
• Multidimensionality: Those flows co-exist and interrelate in the several dimensions: spatial, temporal,
cybernetical, technological, etc.
• Unpredictability of growth: Smart Cities are organically-grown and must be scalable. (What do you
see in 70 million people moving to cities every year?)
• Technology absorption: Because of the technology progress, many various (and unknown right now)
intellectual devices (or “Things” from the IoT) and digital technologies will progressively automate,
improve and drastically change various aspects of Smart Cities functioning including planning,
execution, monitoring, prediction, optimisation of flows.
• Synergy: Intellectual devices, digital applications and digital services must work synergistically in
several dimensions.
• Holistic overview: Various aspects of the Smart Cities functioning (e.g. level of security,
environmental impact, etc.) must be integrally (i.e. including all the available data, information and
knowledge) anticipated, monitored, analysed, controlled, alerted and acted on.
• Trustworthiness: High level of trustworthiness (includes security, privacy, safety, reliability, and
resilience) is mandatory.
Big picture view:
essential characteristics (example)

Big picture view:
high-level requirements vs. essential
characteristics
High-level requirements
Essential
characteristics

• Explicit systems architecting and engineering is only a way to
achieve essential characteristics of Smart City implementations
• Smart City as a System of Digital Interrelated Flows
(SCaaSoDIF) which implies total digitalisation and intensive use of
intellectual devices from the IoT
• Separation of concerns is very critical to reduce the complexity of
Smart City implementations
• SCaaSoDIF is an assembly to be very adaptive and flexible
• SCaaSoDIF as an assembly is constructed and operating on the basis of
explicit and machine-executable digital contracts between people,
services, applications, devices and organisations
• Time and place must be integrated to handle flows properly
• Ontology is a must because this system-domain covers many,
historically, disjoint subject fields
Big picture view:
architecture principles (example)

Big picture view:
essential characteristics vs. principles
Architecture
principles
Essential
characteristics

• 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.
Capability map view:
level 1 modularization
Structural decomposition of the
city mission into groups or
domains or value streams
All Smart Cities have the same capability map (and different levels of maturity).
Each Smart City will implement (at a particular moment) only some capabilities
from this map

Capability map view:
level 1 visualisation (example)
Leading
capabilities
ProcurementFinance Legal Media PMO ICT …
Supporting
capabilities
Facilities&buildingsmanagement
Energymanagement
Watermanagement
Wastemanagement
Publicsafetyandsecuritymanagement
Environment(nature)management
Transportationmanagement
Healthcaremanagement
Educationmanagement
Socialsidemanagement
Economicdevelopmentmanagement
Culture&entertainmentmanagement
Geomatics Census Registries Urban info
Enabling
capabilities
Core
capabilities
Management Operations
Governance
Security
Safety
Privacy
Resilience
Interoperability
Low cost for operations
Short time to market
Emergent characteristics
by design
Business continuity
Tourismmanagement

§
STOM engineering view:
operational patterns (example)
Data
analysis
Data
enrichment
Decision
selection
Action
activation
Continuous
monitoring
Observe, Orient, Decide, Act (OODA) pattern
Coordination, Event Streams, Analytics, Rules
(CESAR) pattern
Sensor A
Sensor B
Sensor C
Situation
prediction
Case (e.g. incident)
coordination
Rules
application
Actions
execution
Case (e.g. incident)
data
flow-of-control
flow-of-data
flow-of-events

• In general, no problems with the GDPR compliance:
– Use of explicit and machine-executable business processes
– Request GDPR compliance from all partners (including IoT devices
providers)
• Use digital contracts ( see http://improving-bpm-
systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html )
Security, safety, risk, privacy and
resilience view: example

Solution 1
…
CUBE platform
Security
management
Business process
management
Operational and
analytical data
Decision
management
Master and
reference data
Reporting
management
Analytics
management
Drivers for IoT
…
Solution 2
Smart Cities specific layer
Service
management
Event
management
Implementation view:
platform-based approach (example)
City Unified Business Execution (CUBE) platform
Digital flow
management

Questions?

• Explain to each group of stakeholders
– Artefacts under their control
– Relationships under their control
– How to address their concerns (i.e. carry out a particular potential
change)
• Example
– architectural framework for improving BPM systems
– A comprehensive set of recommendations, models, patterns and
examples of how to transform existing disparate IT systems into a
coherent, agile and flexible BPM/SOA solution
Architecting digital systems - Module 1 47
Communication to stakeholders
© A. Samarin 2018

• The architectural framework is not about how to make
your products better, different and more attractive for the
market place – this is for you to decide
• What it offers is to help you reduce the overheads in
doing so – your flexible BPM system will become an
enabler for your business innovations
Strategy: top managers

Maturity
level
Technology
architecture
Data
architecture
Application
architecture
Business
architecture
Enterprise
architecture
Optimising
Managed
Defined
Under
development
Initial
None
Business: enterprise architects
• Help in the definition of the different types of architecture
© A. Samarin 2018

• The architectural framework goal is to help you to
streamline your critical business processes by
– automating their management
– eliminating work which does not add value
– integrating existing applications around the business needs
– evolving information systems
in a coordinated manner
• Should make use of the
synergy that exists between
business needs
and IT potentials
Business: managers
© A. Samarin 2018

• The architectural framework classifies all human activities
as intellectual (evaluation, decision-making, etc.),
verification or administrative
• The goal is that the humans should perform only
intellectual activities, and other activities should be
automated (which may also improve quality)
Business: process owners

• Proactive control over execution of business processes
• Delegation of complex tasks to less-qualified staff
members
• Some maintenance without systematic involvement
of the IT
Business: super-users

• Common dashboard (over different applications) with
tasklist, worklist, notifications
• Common approach for the implementation of different
solutions
Business: users

• Achievement of common understanding within a project
through clarification of the different views of artefacts
• Better visibility of artefacts
• Shorten the gap between modelling and implementation
Project: managers
Today Tomorrow
© A. Samarin 2018

• The architectural framework offers a modelling procedure
to guide you to produce executable models
• Such a model acts as a skeleton or foundation to which
the IT attaches services to obtain the implementation
Project: business analysts

• A modelling procedure
– four-phase guidance to produce executable models
– diagramming style
– naming conventions
– several practical patterns
• Promoting joint work between
the business and IT
• Quick iterations for building
an operational prototype
Project: business analysts
KPIs
Processes
Services
Events
Roles
Data
structures
Documents
Rules
Human
“workflow”
Audit
trails
© A. Samarin 2018

• Considerable reduction of TCO
IT: managers
v.1 v.2 v.3 v.4 v.5
Life-cycle
TCO
First BPM/SOA project
Further BPM/SOA projects
Each subsequent solution is cheaper because it
reuses the same tools, the same services, the same
architecture
Maintenance
approx. 80 %
Initial
development
approx. 20 %
Typical IT projects

• Architected flexibility – your BPM system is easily
adaptable to practically all aspects of the organisation
– policies and priorities
– constantly changing business processes
– business innovations
– computer knowledge and culture of the users
– IT systems
– size and complexity
– data
– SLA
IT: enterprise IT architects

• Implementation layers of artefacts
IT: architects

• Relationship of BPM/SOA with other technologies
IT: architects (cont.)

• Transformation from typical inter-application data flows to
end-to-end coordination of services
IT: developers

• The architectural framework helps to manage the
complexity of a mixture of interconnected and
interdependent services by making explicit all
relationships between services
• It thus allows a correct evaluation of the availability of
business-facing services from the known availability of
technology-related services
IT: operators

• The simplest
• Zachman framework
• The Open Group Architecture Framework (TOGAF)
• Federal Enterprise Architecture Freamework (FEAF)
• Model of C. Longépé
Some EA frameworks

• Nomenclature / taxonomy of artefacts
• Building blocks
• Layers
• Improvement cycle
– As-is architecture
– Transitional architecture(s)
– To-be architecture
• Governance processes
• Top-down vs bottom-up
• Views and viewpoints
Some EA concepts

Views of information system

• Pros:
– Simple and easy to understand for everyone
– Historically well known
• Cons:
– Too simple
– Do not show the constraints and links between layers
– Requires to be described twice for the as-is and for the to-be
The simplest
Strategy and Planning
IT Architecture
Infrastructure

Zachman framework (1)

• WHAT – assets (physical and electronic ones)
• WHO – roles (e.g. people, organizations)
• WHERE – places (physical and virtual ones)
• HOW – functions (actions of making some assets from
other assets, adding value, etc.)
• WHEN – events (temporal, systematic, spontaneous,
external, internal)
• WHY – reasons (e.g. motivation, rules, internal and
external constrains including desired performance,
principles)
Zachman framework (2)

• www.theopengroup.org
TOGAF (1)

TOGAF (2)

TOGAF – Architecture development method
(ADM)

FEAF (1)

• Four reference models for the US governmental agencies
FEAF (2)

Model of C. Longépé
Description du métier
compréhensible par les
acteurs du métier
Description et
structuration fonctionnelle
du système d’information
(Services)
Description et structuration
du système informatique
en composants logiciels
(Implémentation des
Services)
Infrastructure de fonctionnement
du système d'information et des
composants logiciels et
applicatifs
Métier
Applicative
Technique
Fonctionnelle
:
: : : : :
Systèmeinformatique
Systèmed’Information

Comparison

Collection and alignment of EA
Operation units
& security
Tool reviews
Feasibility studies
Competence centers
Architecture
Enterprise
Livre Blanc :
• Vue 6
• Vue 7
• NOCA
• Fiches
signalitiques
• Configurateur
Projects
CollectionofEArules
UseofEA
Capitalization
PMO
Macro-planning
Tools:
• PM methodology tailoring
• “Dossier architecture”
• “Fiche chiffrage”
• “Fiche qualité”

Vue 6 – conceptual architecture

Vue 7 – technical architecture

• Three different sources of complexity:
– natural complexity (problem space)
– cultural complexity (social space)
– undesired complexity (solution space)
• The purpose of Enterprise Architecture (EA)
– promote the use explicit and executable techniques to reduce the
natural complexity
– guide solution architecture to follow the natural complexity to
avoid adding undesired complexity
– liberate resources to handle the natural complexity
Managing complexity

• capability, <systems approach>
– ability of a system or a system element to do something at a
required level of performance
• Capability is independent from “how” we do it, “where” we
do it, “who” does it, “which tools” are used
• Capabilities are grouped by levels (see example below)
Reminder the concept “capability”
Level 1
Level 2

Mini-course at VFU - Architecting modern digital systems - 1

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Mini-course at VFU - Architecting modern digital systems - 1

Semelhante a Mini-course at VFU - Architecting modern digital systems - 1 (20)

Mais de Alexander SAMARIN

Mais de Alexander SAMARIN (15)

Último

Último (20)

Mini-course at VFU - Architecting modern digital systems - 1