The document discusses business architecture from an enterprise architecture perspective. It provides an overview of enterprise architecture and discusses various architecture viewpoints including business motivation, business outline, operating outline, and governance outline. It also presents some relationships between model kinds and scenarios for using architecture viewpoints, such as creating a new system from scratch or changing an existing operating outline. The overall agenda covers systems architecting, viewpoints, model relationships, transformation scenarios, and conclusions.
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)
2016-04-20 #bizarch from the #entarch point of view 2
About me
3. • Systems architecting
• Architecture viewpoints and model kinds
• Some simple relationships between model kinds
• Scenarios for using architecture viewpoints together
• Several paths of transformation
• Conclusion
2016-04-20 #bizarch from the #entarch point of view 3
Agenda
4. • System
– set of interacting discrete parts organized as a whole which
exhibits (as the result of interaction between the parts) some
emergent characteristics indispensable to achieve one or more
stated purposes
• Architecting is about making essential decisions to
enable desired characteristics
• It is about an understanding of the relationship between
structure and behaviour, between design and outcomes
• Architect is a person who
1. translates a customer’s requirements
into a viable plan and
2. guides others in its execution
2016-04-20 #bizarch from the #entarch point of view 4
Systems architecting
5. • Architecting socio-technical systems (i.e. any enterprise)
is more complex than architecting technical systems
– relationship between cause and effect can only be perceived in
retrospect
– self-evolving
– always have non-linear behaviour
– For want of a nail the shoe was lost.
– For want of a shoe the horse was lost.
– For want of a horse the rider was lost.
– For want of a rider the message was lost.
– For want of a message the battle was lost.
– For want of a battle the kingdom was lost.
– And all for the want of a horseshoe nail.
• Everything must be considered together and
synergetically
2016-04-20 #bizarch from the #entarch point of view 5
Socio-technical systems architecting
6. • #entarch a system-thinking applied management
discipline for coordinating people, processes, projects and
products in many dimensions:
1. scope span (device, activity, …, country, market)
2. value-stream span (domain-dependent)
3. interoperability layer (business, information, apps, etc.)
4. time span (project life-cycle, solution life-cycle, etc.)
5. sector span (various industries)
6. problem space (situation-specific)
7. solution space (context, conception, …, operations - ZF rows)
8. social space (gender equality, consensus building, conflict resolutions)
9. cultural space (multi-lingual communication, national mentality, regional mentality, corporate
mentality)
10. media span (physical vs analogue vs digital vs bionic)
11. authority span (top management, …, workers)
12. person span (aura/body, house, personal cars, etc.)
13. financial span
14. CX span (touch point, journey, storytelling, lifecycle)
2016-04-20 #bizarch from the #entarch point of view 6
Yet another definition of #entarch
7. • In systems architecting the focus is changing
– FROM the thing
– TO how the thing changes
– SUBJECT how things change together
• With new speed and scale, there
is no time for human intervention and
errors in routine operations and
at interfaces
• To enable innovations
– “in the digital age innovation depends on
process automation”
7
Effect of digital
2016-04-20 #bizarch from the #entarch point of view
8. • Customers
• Shareholders
• Corporate board
• Top management
• Line management
• Super users
• Normal users
• Project managers
• IT architects
• Developers
• Operators
• …and all of them must be comfortable with the system
A lot of stakeholders
2016-04-20 #bizarch from the #entarch point of view 8
9. • Systems architecting
• Architecture viewpoints and model kinds
• Some simple relationships between model kinds
• Scenarios for using architecture viewpoints together
• Several paths of transformation
• Conclusion
2016-04-20 #bizarch from the #entarch point of view 9
Agenda
10. • Architecture view
– work product expressing the architecture of a system-in-focus
from the perspective of specific system concerns
• Architecture viewpoint
– work product establishing the conventions for the construction,
interpretation and use of architecture views to frame specific
concerns
– Note: Architecture viewpoints are not system specific, unlike the
stakeholders, concerns and architecture view
• Model kind
– convention for a type of modelling
– Note: Models kinds usually establish relationships between various
types of artefacts
– Note: Model kinds are not system specific
2016-04-20 #bizarch from the #entarch point of view 10
Nomenclature of architecture viewpoints
and model kinds (ISO/IEC/IEEE 42010)
11. • Concepts system or terminology or “common taxonomy”
– explains for a particular subject field all the essential concepts and
relationships between them
• Spatial-like classification
– defines a spatial classification of
essential parts in a particular
subject field
• Business motivation
– explains the reason for which a system (e.g. an enterprise) exists
and ambitions of its stakeholders
– example – BMM from OMG
2016-04-20 #bizarch from the #entarch point of view 11
Architecture viewpoints (1)
12. • Business outline
– describes means and methods those a system (e.g. an enterprise)
employs to earn the revenue projected in its business motivation
– Note 1: This architecture viewpoint answers the question, "How is
the enterprise going to make money to survive and grow?"
• Note 2: This architecture viewpoint may be actually a combination
of several model kinds.
2016-04-20 #bizarch from the #entarch point of view 12
Architecture viewpoints (2)
13. • Example - BMC internal relationships from
https://www.linkedin.com/pulse/strategy-business-model-
mihai-ionescu
2016-04-20 #bizarch from the #entarch point of view 13
Architecture viewpoints (3)
14. • Capability-as-a-discrete-unit-of-mission decomposition
– describes a system (e.g. an enterprise) as an approximate
hierarchy of all the discrete-units-of-mission those a system must
be doing to achieve its mission
– Note: Not all units-of-mission are implemented within an
enterprise – some units-of-mission may be outsourced and some
units-of-mission can be obtained from partners
– Note: If outsourcing, partnership and sharing are ignored, all
enterprises in the same industry sector have the same capability-
as-a-discrete-unit-of-mission decomposition (industry ref. model)
– Note: Variant “discrete-unit-of-purpose”
2016-04-20 #bizarch from the #entarch point of view 14
Architecture viewpoints (5)
15. • Functional anchor
– describes a system (e.g. an enterprise) as a structure of unique
functions
– Note: Function is an in-house implementation of a capability-as-a-
discrete-unit-of-mission
2016-04-20 #bizarch from the #entarch point of view 15
Architecture viewpoints (5)
16. • Operating outline
– explains how a system (e.g. an enterprise) functioning to deliver
on its service or product promises in accordance with its business
outline
– Note 1: This architecture viewpoint is actually a combination of
several model kinds
– Note 2: A business-outline presents invariants that are (relatively)
stable, while an operating-outline presents, well, operations that
are much more volatile and the pre- and post-conditions of which
have to satisfy these invariants
2016-04-20 #bizarch from the #entarch point of view 16
Architecture viewpoints (4)
17. • Process map
– describes a system (e.g. an enterprise) as a set of processes
2016-04-20 #bizarch from the #entarch point of view 17
Architecture viewpoints (6)
18. • Capability-as-performance
– describes measure of ability of a system’s part (function, process,
etc.) to do achieve a particular result
– Note: this measure aggregates the usage of all sub-ordinated and
shared parts
– Note: this measure is not binary; it is qualitative or quantitate
2016-04-20 #bizarch from the #entarch point of view 18
Architecture viewpoints (7)
19. • Organisational chart
• Service map
• Data / Information nomenclature
• Events (triggers) nomenclature
• …
2016-04-20 #bizarch from the #entarch point of view 19
Architecture viewpoints (7)
20. • Systems architecting
• Architecture viewpoints and model kinds
• Some simple relationships between model kinds
• Scenarios for using architecture viewpoints together
• Several paths of transformation
• Conclusion
2016-04-20 #bizarch from the #entarch point of view 20
Agenda
21. • Pattern “Strategy To Executable Portfolio (STEP)”
• Pattern “Stakeholder Analysis”
• Pattern “Structure IT Organisation (SITO)”
• Pattern “Process Set Solidity Test (PSST)”
2016-04-20 #bizarch from the #entarch point of view 21
Some simple relationships
22. • Business concern
– dealing with the project portfolio during evolution of the strategy:
intended, emerging and realised
• Logic
– explicitly linking strategic objectives, initiatives, business
capabilities, IT capabilities, IT tools and projects
– add priorities
2016-04-20 #bizarch from the #entarch point of view 22
Strategy To Executable Portfolio (STEP)
24. • Implications
– A formal way to discover points of the most leverage
– The decision-making process is explicit and transparent
– A strategy adjustment and validation becomes a routine on-going
activity during its implementation (like functioning of the GPS
navigator)
2016-04-20 #bizarch from the #entarch point of view 24
Implications and example
25. • Establish explicit relationships between
– Stakeholders of a system
– Their concerns
– Architecture viewpoints to address those concerns
– Model kinds to compose each of selected viewpoints
– IT tools which support the model kinds
2016-04-20 #bizarch from the #entarch point of view 25
Stakeholder analysis
26. Matrix – stakeholders vs architecture
viewpoints
2016-04-20 #bizarch from the #entarch point of view 26
27. • Business concern: How to structure a business unit
• Logic
– Collect functions
– Draw a matrix of mutual relationships between those functions
– The relationships may be like “synergy”
– The relationship may be like “prohibition”, e.g. SoD
– Find clusters in the matrix
2016-04-20 #bizarch from the #entarch point of view 27
Structure IT Organisation (SITO)
28. • Prohibition rules:
– P1 Separate doing and supervising/controlling – SoD
– P2 Separate architecture/design and implementation – SoD and
quality at entry
– P3 Separate implementation and operation – SoD and quality at
entry
– P4 Policy vs applying it – legislation vs executive separation
– P5 Specialisation
• Synergy rules:
– S1 Close work
– S2 Architecture role to guide
– S3 Synergy between technical and administrative activities (how
you do something may be more important what you do)
2016-04-20 #bizarch from the #entarch point of view 28
Example of rules
30. 2016-04-20 #bizarch from the #entarch point of view 30
Process Set Solidity Test (PSST)
• To check that your set of processes / functions /
capabilities is complete – map functions vs primary
artefacts
31. • Systems architecting
• Architecture viewpoints and model kinds
• Some simple relationships between model kinds
• Scenarios for using architecture viewpoints together
• Several paths of transformation
• Conclusion
2016-04-20 #bizarch from the #entarch point of view 31
Agenda
32. 1. Creating from scratch
2. Changing operating outline
3. Changing business outline
4. Building systems via incorporation
2016-04-20 #bizarch from the #entarch point of view 32
Scenarios for using architecture
viewpoints in architecting
33. • Synonyms
– greenfield
– top-down
– design of business
• Examples
– start-up (medium-term and long-term)
– sports event (short- and medium-term)
– military mission
– ad-hoc working group
– development project
2016-04-20 #bizarch from the #entarch point of view 33
Creating from scratch
34. 1. Business motivation viewpoint (A system-in-focus is
mainly considered as a black-box via “external”
viewpoints)
– Stakeholders (external)
– Mission
– Vision
2016-04-20 #bizarch from the #entarch point of view 34
Algorithm of creating (1)
35. 2. Business outline (a system-in-focus is considered as a
grey-box via “high-level structural details” viewpoints)
2016-04-20 #bizarch from the #entarch point of view 35
Algorithm of creating (2)
a) Define your capability-as-a-discrete-unit-of-mission
(high-level) – take an industry model if available
b) Define B2C (including customer segments,
channels, relationships, value proposition)
c) Define B2C services
d) Link B2C services with some capabilities-as-a-
discrete-unit-mission (high-level) to be
implemented in-house as functions
e) Define B2B (including key partners, their offers,
etc.)
f) Define B2B services
g) Link B2B services with some capabilities-as-a-
discrete-unit-of-mission (high-level) to be
implemented in-house as functions
h) Understand your functional anchor
(high-level), i.e. key activities
Check: Capability-as-a-discrete-unit-of-
mission (high-level) = Functional anchor
(high-level) + B2B offers
i) Identify value-streams (or processes
L1& L2) in functional anchor (high-level)
Hint: they start from B2C services
j) Capability-as-performance (qualitative
evaluation of the functional anchor)
k) Financial flows (high-level for cost
structure and revenue streams)
+$$ B2C services
-$$ functional anchor
-$$ B2B offers
36. 3. Operating outline (a system-in-focus is mainly considered as
a white-box via “high-level behavioural details” viewpoints)
a) Functional anchor (detailed)
b) Capability-as-performance (qualitative)
c) Defined your processes (L3, etc.)
d) Isolate shared services
e) Derive organisational structure (units and key positions)
f) Data / information (syntax, semantic and lifecycles)
g) Select technologies
h) Capability-as-performance (quantitative) – use some simulation
i) Restart from c) if the top management not happy with the
performance figures
2016-04-20 #bizarch from the #entarch point of view 36
Algorithm of creating (3)
37. 4. Governance outline
5. Implementation plan
– macro-planning architecture viewpoint
– project portfolio architecture viewpoint
– application architecture viewpoint
– data/information architecture viewpoint
– technology architecture viewpoint
2016-04-20 #bizarch from the #entarch point of view 37
Algorithm of creating (4)
38. • 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
2016-04-20 #bizarch from the #entarch point of view 38
Examples
39. • Creating a new enterprise
• Contracting key partners (venues, clubs, national
associations)
• Services to be delivered (VIP, broadcast, ticketing, etc.)
• Developing the organisational structure
• Contracting people (including volunteers)
• Travel, accommodations, logistic for staff and VIP
• Setting-up venues
• Operating, i.e. executing the event
• Dismantling venues
• Post-event placement of volunteers
• Liquidating the enterprise
2016-04-20 #bizarch from the #entarch point of view 39
Example: sports event
40. • Changing operating outline
– Synonyms
• modernizing, optimizing, refactoring, restructuring,
rationalisation, standardisation, etc.
– Examples
• BPR, CPI, TQM, etc.
• Changing business outline
– Synonyms
• rethinking, reimagining, reinventing, innovations, etc.
– Examples
• disruptive strategy
2016-04-20 #bizarch from the #entarch point of view 40
Two variants of “Creating from scratch”
41. • Synonyms
– bottom-up
– integration
– “old-farm renovation”
• Examples
– silos removal
– M & A
– system of systems, i.e. no control
over constituting systems
– supply-chain
– smart-city
– smart-energy
– healthcare
– e-government
2016-04-20 #bizarch from the #entarch point of view 41
Building systems via incorporation
42. • Question: What should be done to say “all the interacting
discrete parts of the system-in-focus work as a whole”?
• Answer: all the interacting discrete parts of the system-
in-focus must be incorporated structurally and
behaviorally to guarantee the desired characteristics
• Question: What are the system-forming factors for a
this system-in-focus?
• Answer:
– Start with “dimensions” as integration pillars
– Determine “dimensions” which are most
import for the system-in-focus
– Integrate between “dimensions”
2016-04-20 #bizarch from the #entarch point of view 42
General approach for this scenario
43. • Energy stream or “domains” (energy generation, energy
transmission, energy delivery, energy consumption)
• Operating span or “zones” (process, field, station,
operation, enterprise, market)
• Interoperability layers (business, functions, information,
communication, components)
2016-04-20 #bizarch from the #entarch point of view 43
Dimensions in reference classification
IEC SyC “Smart Energy”
44. • Interoperability layers business, functions, information,
communication, components
• Operating span or “Hierarchy Levels” (product, field
device, control device, station, work-centre, enterprise,
connected-world)
• Value stream
2016-04-20 #bizarch from the #entarch point of view 44
Dimensions in reference classification
Germany, Industry 4.0
45. • Proximity (aura/body, home, personal vehicle, public
building, global)
• Enablers (monitoring, audio-visual interaction, assistance
systems, data acquisition, mechatronics and control, data
aggregation and storage, defined function control and
support, complex cross-function service control and
support, integral service programs)
• Interoperability layers (business, functions, information,
communication, components)
2016-04-20 #bizarch from the #entarch point of view 45
Dimensions in reference classification
IEC SyC “Ambient Assisted Living”
46. • Align terminology or, even better, make an ontology
– concept system architecture viewpoint
• Understand concerns of all people involved
– stakeholders analysis architecture viewpoint
• Develop common syntax, semantic and lifecycles for all
assets
– data/information nomenclature architecture viewpoint
• List external and internal (change lifecycle phases) events
– event nomenclature architecture viewpoint
• Analyse functions for all existing parts
– functional anchor architecture viewpoint
– use-cases architecture viewpoint
2016-04-20 #bizarch from the #entarch point of view 46
Algorithm of incorporation (1)
(a happy path only)
47. • Consider implementation of functions as services
– service map architecture viewpoint
• Consider implementation of services (actually some of
their operations) as processes
– process map architecture viewpoint
• Find dependencies between functions and events (e.g.
function is invoked because of an event) and
express them via different coordination techniques
(flow-chart, schedule, decision, etc.)
– various model kinds for coordination
• Find implicit processes and make them explicit
– process map architecture viewpoint
2016-04-20 #bizarch from the #entarch point of view 47
Algorithm of incorporation (2)
48. • Analyse future system-in-focus functions
– functional anchor architecture viewpoint
– use-cases architecture viewpoint
• Consider implementation of functions as services
– service map architecture viewpoint
• Consider implementation of services (actually some of
their operations) as processes
– process map architecture viewpoint
• Find shared services
– service map architecture viewpoint
2016-04-20 #bizarch from the #entarch point of view 48
Algorithm of incorporation (3)
49. • Find various gaps
– integration points
– coordination points
– touch points
– missing parts
• Road mapping to close the gaps
• Consider data-level integration, application-level
integration and process-level integration
• Important!
– Use the same methodology to model artefacts. Thus, different
people in similar situations will find similar solutions or propose
innovations.
2016-04-20 #bizarch from the #entarch point of view 49
Algorithm of incorporation (4)
50. • But, there are a few real-life difficulties: you have
– to do many puzzles at the same time
– to use pieces from other puzzles
– to propose new pieces
– to optimise the number of pieces
– to transform some puzzles
– etc.
• It should be a lot of fun!
2016-04-20 #bizarch from the #entarch point of view 50
Algorithm of incorporation (5)
51. • The users told us that their processes are unique thus
they need different applications
• We modelled their processes with the same modelling
procedure
• We found the same services and very similar processes
2016-04-20 #bizarch from the #entarch point of view 51
Example – replacing 23 electronic
publishing applications
52. • Orchestration-centric
– temporal-based
– flow-chat-based
– pattern-based
• State-centric
– life-cycle-based
• Decision-centric
– rule-based
– behaviour-based
– managerial
– instinct-based
2016-04-20 #bizarch from the #entarch point of view 52
About coordination techniques (1)
53. • Various
– resource-based
– goal-based
– event-based
2016-04-20 #bizarch from the #entarch point of view 53
About coordination techniques (2)
54. Coordination
technique
Level of
coordination
Type of
coordination
Nature of
coordination
Horizon of
coordination
Intensity of
coordination
Scope of
coordination
Flexibility of
coordination
Orchestration strong imperative explicit future high group low
State strong imperative explicit now low individual low
Decision weak declarative both now low individual low
Event weak declarative implicit now various individual++ high
2016-04-20 #bizarch from the #entarch point of view 54
Comparison of coordination techniques
– level: weak (crowd) or strong (army)
– type: imperative (working instruction) or declarative (a set of constrains)
– nature: explicit (as state laws or directives) or implicit (tacit, social)
– horizon: now or future
– intensity: low or high or various
– scope: individual or group (set)
– flexibility: low or high
55. • Systems architecting
• Architecture viewpoints and model kinds
• Some simple relationships between model kinds
• Scenarios for using architecture viewpoints together
• Several paths of transformation
• Conclusion
2016-04-20 #bizarch from the #entarch point of view 55
Agenda
56. Several paths of transformation
2016-04-20 #bizarch from the #entarch point of view 56
• Because it is not possible to define everything in advance, it
is necessary to considered the following paths
1. Process-innovation centric
2. ERP-decomposition centric
3. Off-The-Shelf (OTS) product centric
4. Project-opportunity centric
5. Operational-improvement centric
1. Areas of least resistance
2. Performance errors hunting
3. Points of most leverage
• And be capable to handle all of them TOGETHER
57. To know about each path
2016-04-20 #bizarch from the #entarch point of view 57
• Initiators
• Pre-requisites
• Benefits
• Potential targets / examples
• Risk factors
• Expected ROI
• Priority
58. Generic approach
2016-04-20 #bizarch from the #entarch point of view 58
• Following the enterprise pattern STEP
• Establish dependencies between the following enterprise
artefacts
– business process (E2E, macro-process, individual process, etc.)
– legacy application (including functionality in ERP)
– capability (business and technical ones)
– tools and technologies
– business benefits
• Quantify those dependencies
59. Business-innovation centric path
2016-04-20 #bizarch from the #entarch point of view
E2E or macro
process (P1)
Innovation
(I2)
benefits from
B1
Innovation
(I1)
is built on
is enabled by
E2E or macro
process (P2)
Capability
(C1)
Technology /
tool (T1)
Technology /
tool (T2)
Capability
(C2)
59
60. ERP-decomposition centric path
2016-04-20 #bizarch from the #entarch point of view
ERP functionality
(F1)
Capability
(C2)
is improved by
B2
Capability
(C1)
Technology /
tool (T1)
Technology /
tool (T2)
is enabled by
ERP functionality
(M2)
60
61. OTS-product-centric path
2016-04-20 #bizarch from the #entarch point of view
OTS product
Capabilities
(C1)
Capabilities
(C2)
E2E process
(Pn)
ERP functionality
(Fn)
is provided by
is improved by
B3
61
BPM-suite
62. Project-opportunity centric examples
2016-04-20 #bizarch from the #entarch point of view 62
Project (J1)
Capability
(C2)
requires
Capability
(C1)
Technology /
tool (T1)
is enabled by
OTS product
B4
63. Operational-improvement centric
2016-04-20 #bizarch from the #entarch point of view 63
Capabilities
(C1)
Capabilities
(C2)
E2E process
(Pn) can be improved by
B5
1. Areas of least resistance
2. Performance errors hunting
3. Points of most leverage
64. What is a capability?
2016-04-20 #bizarch from the #entarch point of view 64
• Capability is a measure of the ability of a part of a system-
in-focus to achieve a particular result
– A lot of people are able to play football
– How many of them are capable to play at the Champions League
final?
• The most popular measure is the maturity level
• Thus to know your gaps and how to close them (i.e. a
capability may be improved) Capabilities
(C1)
Capabilities
(C2)
E2E process
(Pn)
needs level 4 of C1
needs level 3 of C2
current level of C1 is 3
current level of C2 is 3
65. Important for any transformation
2016-04-20 #bizarch from the #entarch point of view
• Consider all paths together
• Capability as a unifying artefact
• Combine business improvements with technological changes
• Quick experimenting
• Know your gaps and manage how to close them
• Paths of transformation help to the typical #bizarch
problems mentioned in the presentation “Architecture of
Business in a Dynamic Market” given by Dr Poulin
65
66. • Systems architecting
• Architecture viewpoints and model kinds
• Some simple relationships between model kinds
• Scenarios for using architecture viewpoints together
• Several paths of transformation
• Conclusion
2016-04-20 #bizarch from the #entarch point of view 66
Agenda
67. Conclusion
2016-04-20 #bizarch from the #entarch point of view 67
• Formalise your artefacts – syntax and semantic
• Define their lifecycles
• All artefacts must be versionable throughout their lifecycle
• All artefacts must evolve to become digital, externalised,
virtual and cloudable
• All relationships between artefacts must be modelled
explicitly
• All models must be made to be machine-assisted executable
• Next step is “software-defined enterprise” to be
presented at a conference in Portugal, June 23th