More Related Content Similar to Architecting modern informaiton systems M2a business architecture (20) More from Alexander SAMARIN (20) Architecting modern informaiton systems M2a business architecture2. Terminology (1)
• organisation, noun
– group of persons associated by some common tie or occupation
(for the purpose of administering something) and regarded as an
entity
– Etymology: The word is derived from the Greek a word oργανον
meaning “tool”.
• enterprise, noun
– collection of organisations that share a common set of goals and
objectives
– Remark 1: An enterprise can be, for example, a business unit or
department, an entire corporation, a government agency or a
collection of businesses joined together in a partnership.
– Remark 2: An enterprise can be considered as a system whose
parts are people, processes, information and technology.
© A. Samarin 2012 Architecting modern information systems - Module 2 2
3. Terminology (2)
• enterprise business system, noun
– top level view of an enterprise as a system for conducting the
business
– Remark 1: This top level view may concentrate on how the
business is structured, what it does and what it needs to do to
meet its goals.
– Remark 2: The issues of greatest importance for enterprise
business systems are the following:
– the core end-to-end business processes (also known as value
streams);
– the governance structures;
– the core business information (semantics);
– the communication with the core business partners.
© A. Samarin 2012 Architecting modern information systems - Module 2 3
4. Terminology (3)
• business architecture, noun
– that part of enterprise architecture concentrating on the
conceptualisation and evolution of the form and structure of the
enterprise business system
• stakeholder, noun
– person, group or organisation who affects and can be affected by
an enterprise‟s actions
© A. Samarin 2012 Architecting modern information systems - Module 2 4
5. General approach
• Is this a complex dynamic self-evolving system of
systems?
• What is the boundary of this system?
• What is its environment?
• What are the parts of the system (artefacts) and
relationships between them?
• What are the principles of evolution of this system?
• What are the current goals of evolution of this system?
• What are the changes to be done to achieve these goals?
• How to carry out these changes and measure their effect?
© A. Samarin 2012 Architecting modern information systems - Module 2 5
6. More terms
• An enterprise creates a result which has value to a
customer who pays for this result.
• The enterprise acts as a provider (supply-side) and the
customer acts as a consumer (demand-side).
• There is a (business) transaction between the provider
and the consumer.
• From the point of view of the consumer (the outside-in
view) the transaction is bounded by the pair “request and
result”. Request is an external business event.
• From the point of view of the provider (the inside-out
view) the transaction is a set of several distinct activities
(or units of work) which function together in a logical and
coordinated manner to satisfy / delight the consumer.
© A. Samarin 2012 Architecting modern information systems - Module 2 6
7. Business functions (1)
• Functions deliver identifiable changes to assets
• Abstract and self-contained grouping of activities that
collectively satisfy a specific operational purpose (e.g.
management of relationships with partners)
• A business function typically has the suffix „management‟
in its name (e.g. „Customer Relationship
Management‟), but it can also be a noun (e.g.
„Marketing‟); usually, function name specifies something
that is performed continuously.
© A. Samarin 2012 Architecting modern information systems - Module 2 7
9. Business functions (2)
• Functions are unique within the enterprise and should not
be repeated
• Functional view has a hierarchical structure
• This structure is very static (with a low rate of change).
• The functional view emphasizes WHAT the whole
enterprise does to deliver value to the customer (without
the organizational, application, and process constraints).
• Some organisational units can span several functions.
Furthermore, organization charts (organigrammes) may
change while the function does not.
© A. Samarin 2012 Architecting modern information systems - Module 2 9
10. Value-stream (1)
• Value-stream is an end-to-end collection of those
activities (both value-added and non-value-added)
currently required by an enterprise to create a result for a
customer.
• Value-streams are named according to an initiating event
and its result.
– Prospect-to-Customer
– Order-to-Cash (order fulfilment process)
– Manufacturing-to-Distribution (manufacturing process)
– Request-to-Service
– Design-to-Build
– Build-to-Order
© A. Samarin 2012 Architecting modern information systems - Module 2 10
11. Value-stream (2)
• Value-streams are directly linked to desired results, goals
and objectives, i.e. WHY
• Ideally, each value-stream should align with at least one
long-range objective and its business performance metrics
[key performance indicators (KPIs)].
• For example, one objective of the success of the “Order-
to-Cash” value-stream may be measured as “96% of
orders delivered within 3 days”.
• If this value-stream‟s actual performance is delivering
only “90% of orders within 3 days” then a corrective
action should be taken (e.g. a new strategic initiative is
developed and its priority determined).
© A. Samarin 2012 Architecting modern information systems - Module 2 11
12. Value-stream (3)
• Value-stream is an explicit HOW the desired results are
achieved
© A. Samarin 2012 Architecting modern information systems - Module 2 12
13. Value-stream (4)
from www.enterprisebusinessarchitecture.com
The enterprise and related external partners The enterprise as a set of aggregations of
selected value-streams
Strategic visioning, Custom-centric, Business-enabling and People-caring
© A. Samarin 2012 Architecting modern information systems - Module 2 13
14. Value-stream (5)
from www.enterprisebusinessarchitecture.com
© A. Samarin 2012 Architecting modern information systems - Module 2 14
15. Value-chain
from www.enterprisebusinessarchitecture.com
• An enterprise consists of a collection of value-streams. Its
value-streams are interdependent; a value-stream may
rely on the results of other value-streams.
• Value-chain of an enterprise is a network of strategically
relevant components of value-streams of the enterprise.
• Value-chain is important
to obtain competitive advantage.
This is the principal end-to-end
view of the enterprise.
© A. Samarin 2012 Architecting modern information systems - Module 2 15
16. Linking WHY, WHAT and HOW
• WHY + WHAT of the whole enterprise should be used to
define WHY + WHAT of each activity. The glue between
them is HOW.
© A. Samarin 2012 Architecting modern information systems - Module 2 16
17. Value & Expenses Basin (1)
This is a flow of performance metrics
© A. Samarin 2012 Architecting modern information systems - Module 2 17
18. Value & Expenses Basin (2)
• It represents a dynamic, actual and contextual
contribution of different activities to the value and
expenses associated with a particular result.
• The business can be attentive to different “tributaries”
which are
– the most value-adding,
– the most wasteful,
– doing worse than defined by WHY, and
– doing better than defined by WHY.
© A. Samarin 2012 Architecting modern information systems - Module 2 18
19. Managing the complexity (1)
• A service is a consumer-facing formal representation of a
self-contained provider‟s repeatable set of activities which
creates a result for the consumer.
• It is considered that there are internal (even within an
enterprise) providers and consumers. Some functions are
wrapped as services. A service may wrap several
functions.
• Service is an operationally-independent functional block –
its internal functioning is hidden from its consumers
• A “proper” service can be relatively easily outsourced.
• Services are expressed in terms of expected
products, characteristics and delivery options
(cost, quality, speed, capacity, geographic location, etc.)
© A. Samarin 2012 Architecting modern information systems - Module 2 19
20. Managing the complexity (2)
• Complex services are created by means of the
coordination of more simple services and/or activities
• In the same way that an orchestra is a coordination of
individuals and their actions
• In this sense, an enterprise is
a mega-service composed
of a network of nano-services
© A. Samarin 2012 Architecting modern information systems - Module 2 20
21. Managing the complexity (3)
• Performance of one request to the service vs performance
of all requests to the service during a given period of
time.
• Somebody should:
– know/estimate the demand-side needs (the service may have
many different consumers who will be using it with different
frequencies), and
– design/organise/create in advance the supply-side capabilities to
ensure those needs are satisfied.
© A. Samarin 2012 Architecting modern information systems - Module 2 21
22. Capability
• Capability is the proven possession of characteristics
required to perform a particular service (to produce a
particular result, which may include the required
performance) and the functions which are wrapped by this
service.
• Capability needs to “understand” the mechanics of
delivering that service. The mechanics include the
resources, skills, policies, powers/authorities, systems,
information, other services, etc., as well as the
coordination of work within the service. Capability is
named after the expected result/performance, e.g. “2CV”.
© A. Samarin 2012 Architecting modern information systems - Module 2 22
23. Ensure the required characteristics?
• There are three control options:
1. by contract (“re-active” approach) – acquire a service with the
required characteristics, use it, check that its performance is
acceptable and replace it if something is wrong with it;
2. by measurement (“active” approach) – implement a service, use
it, measure it, improve or re-build it, etc.;
3. by design (“pro-active” approach) – build a service model, run a
simulation test, improve the model, build the service, use
it, measure it, improve it, etc.
• The first option can work with some support services
• The second option can work with lead services
• The third option should be used for core business
services.
© A. Samarin 2012 Architecting modern information systems - Module 2 23
24. Coordination between activities (1)
• An enterprise may have several value-streams running in
parallel.
• Some activities can be shared between different value-
streams and some value-streams may compete for limited
resources.
• An activity from one value-stream can obtain some assets
(business objects) which belong to another value-
stream. This is pull-like coordination.
• An activity from one value-stream can send some assets
to another value-stream. The latter interprets appearing
of the assets as an event to be treated. This is push-like
coordination.
© A. Samarin 2012 Architecting modern information systems - Module 2 24
25. Coordination between activities (2)
• Interdependencies between activities must be managed
• Coordination can be:
– Implicit vs explicit
– Human vs automated
– Centralised vs decentralised
– Imperative vs declarative
– Strong vs weak
• May change over the time (e.g. a crisis situation)
© A. Samarin 2012 Architecting modern information systems - Module 2 25
27. Coordination between activities (4)
• Flow of pages
• Integration of services
• Human workflow
• Business-to-business
© A. Samarin 2012 Architecting modern information systems - Module 2 27
28. The explicit coordination brings several
advantages
• It allows planning and simulation of the behaviour of a
service to evaluate its performance. If that service uses
other services, then the demand-side needs for those
services can also be evaluated.
• It can be made to be executable, thus guiding how work
is done.
• It allows control that the actual behaviour of the service
matches its intended behaviour, thus pro-actively
detecting potential problematic situations.
• It allows the measurement within a service of the
dynamics of different characteristics, e.g.
valuing, costing, risk, etc.
© A. Samarin 2012 Architecting modern information systems - Module 2 28
29. Explicit coordination techniques
• template-based (or token-based)
• event-based (or business-events-based)
• data-based (or business-objects-based)
• rule-based (or business-rules-based)
• role-based (or business-roles-based)
• intelligence-based (or business-intelligence-based)
• community-based
• etc.
© A. Samarin 2012 Architecting modern information systems - Module 2 29
30. Business architecture artefacts (1)
• Business Strategy Artefacts
– Vision statement - outlines what the organization wants to be
– and related “ends” chain: desired result, goals, and objectives.
– Mission statement - is a brief description of a company's
fundamental purpose. A mission statement answers the
question, "Why do we exist?"
– and related “means” chain: course of
action, strategy, tactic/projects.
© A. Samarin 2012 Architecting modern information systems - Module 2 30
31. Business architecture artefacts (2)
• Structure & Governance Artefacts
– Organizational Structure
– Organizational Governance
– Governance RACI matrix
– Supplier, providers, customers,
and other partners
© A. Samarin 2012 Architecting modern information systems - Module 2 31
32. Business architecture artefacts (3)
• Business Function Artefacts
– Business Function Model
• Business Process Artefacts
– Business Process Model
• Business Information Artefacts
• Value artefacts
© A. Samarin 2012 Architecting modern information systems - Module 2 32
34. Address the complexity via system-
thinking way
• Principles:
– All artefacts must have formally described
– All artefacts must be versionable throughout their lifecycle
– All relationships between these artefacts are modelled explicitly
– All models are made to be executable
• Use the model:
– collect artefacts
– find and formalise relationships between them
Note: some artefacts are relationships
– run the simulation of that model
– change (iteratively) the model to get the desired effect
– implement validated improvements
© A. Samarin 2012 Architecting modern information systems - Module 2 34
35. Homework 2
• Define capabilities of a consulting company
• Define capabilities of “Faculté des Sciences Economiques
et de Gestion de Nabeul”
© A. Samarin 2012 Architecting modern information systems - Module 2 35
36. The context for the architecture (1)
• Permanent improvement of enterprise efficiency and
effectiveness is mandatory
– increasing agility & durability of an enterprise
– managing cost, risk and quality of changes
© A. Samarin 2012 Architecting modern information systems - Module 2 36
37. The context for the architecture (2)
• Carry out improvements
by small steps
– evolution via a
feed-back loop
© A. Samarin 2012 Architecting modern information systems - Module 2 37
38. The context for the architecture (3)
• To choose the best possible improvement, it is necessary
to have good information and knowledge about the
functioning of the enterprise
© A. Samarin 2012 Architecting modern information systems - Module 2 38
39. The context for the architecture (4)
• To implement a selected improvement, it is necessary to
be sure that modifications are feasible
© A. Samarin 2012 Architecting modern information systems - Module 2 39
40. The context for the architecture (1 - 4)
Permanent
improvement
of enterprise
efficiency and • Small
effectiveness is steps
mandatory
• Good
• Feasible information and
knowledge
© A. Samarin 2012 Architecting modern information systems - Module 2 40
41. Different types of improvement
• Operational
• Tactical
• Strategic
• Competitiveness
© A. Samarin 2012 Architecting modern information systems - Module 2 41
42. Feedback improvement loop
• An enterprise is a complex, dynamic and adaptive
system; one can improve it by:
– measuring
– observing
– deciding
– implementing
2
3
4 1
© A. Samarin 2012 Architecting modern information systems - Module 2 42
43. The Deming cycle, PDCA
• PLAN Establish the objectives and processes necessary to
deliver results in accordance with the specifications
• DO Implement the processes
• CHECK Monitor and evaluate the processes and results
against objectives and report the outcome
• ACT Apply actions to the outcome for necessary
improvement. This means reviewing all steps and
modifying the process to improve it before its next
implementation (next iteration?)
© A. Samarin 2012 Architecting modern information systems - Module 2 43
44. Toyota production system
• Long-term philosophy
• The right process will produce the right results
• Add value to the organisation by developing your people
and partners
• Continuously solving root problems drives organisational
learning
© A. Samarin 2012 Architecting modern information systems - Module 2 44
45. Waste in processes
• Waiting, Defects, Extra processing, Inventory, Excessive
motion, Transportation, Underutilised
people, Overproducing
© A. Samarin 2012 Architecting modern information systems - Module 2 45
46. Lean production is an example of
optimisation in industry
• See the whole picture
• Learn constantly
• Decide as late as possible
• Deliver as fast as possible
• Eliminate waste
• Empower the team
• Build in integrity
• Avoid sub-optimisation
© A. Samarin 2012 Architecting modern information systems - Module 2 46
47. 6 Sigma
• An example of perfection to minimize variations, but
necessary at the enterprise level
• Used to realize cost savings using the traditional DMAIC
[define, measure, analyse, improve, control]
• Often it is departmental piecemeal thinking
• Best suited for problems which are “hard to find and easy
to fix”
• In theory, 6 Sigma is based on business process principles
© A. Samarin 2012 Architecting modern information systems - Module 2 47
48. ISO 9001 quality management system
• Process-centric approach (since year 2000)
• It is not a “system based only on documents” even if they
contain diagrams of business processes
• It is a “system for an organisation to manage its business
processes”
– maintenance of the quality management system documentation is
only one of the needs
© A. Samarin 2012 Architecting modern information systems - Module 2 48
49. Quality management system
documentation
• Quality policy: Defines commitment by top management
to comply with requirements and to improve continually
the effectiveness of the quality management system
• Quality manual: Defines the scope of the quality
management system and the documented procedures;
describes the interactions between the processes
• Documented procedures required by ISO 9001
• Documents needed for planning, operation and control of
the organisation‟s processes
• Records (evidence): Results of the use of the system
© A. Samarin 2012 Architecting modern information systems - Module 2 49
50. Quality management system
documentation
Business processes “In” quality Business Records
manual procedures
Quality management 1 ~5 ~100
Sales 1 ~10 ~10 000
Customer services 1 ~10 ~10 000
Production 1 ~10 ~100 000
Covered by traditional applications for quality management
Covered by various business applications, paper and manual work
Having these documents is not enough; are they traceable, secure and
correctly managed throughout their life cycle?
© A. Samarin 2012 Architecting modern information systems - Module 2 50
52. Services and processes (1)
• Services are considered to be explicitly-defined and
operationally-independent units of functionality
– Formal description
– Operational independence
– Invisible implementation
© A. Samarin 2012 Architecting modern information systems - Module 2 52
53. Services and processes (2)
• Processes are considered to be an explicitly-defined
coordination of services to create a particular outcome
– Formal description
– Coordination
© A. Samarin 2012 Architecting modern information systems - Module 2 53
54. Process-oriented view of an enterprise
(before BPM)
© A. Samarin 2012 Architecting modern information systems - Module 2 54
55. Business Process Management (BPM) is a
tool for improving business performance
A natural evolution of
BPR, Lean, ISO 9001, 6 A multitude of tools
Sigma “handle” processes
The theory The tools
BPM as a discipline BPM as software:
The aim is to have a single
(use processes to business
description of BPM suite (BPMS)
manage an
processes:
enterprise)
- model in design
- input for project
planning and execution An enterprise portfolio
- executable program for of the business
coordination of work processes as well as
- documentation for all the practices and tools
staff members for governing the
- basis for management design, execution and
decisions evolution of this
The practice portfolio
Any process-centric enterprise has some BPM, but
how can we industrialise this BPM?
© A. Samarin 2012 Architecting modern information systems - Module 2 55
56. Business processes are complex
relationships between artefacts
• Who (roles) is doing What (business objects), When
(coordination of activities), Why (business rules), How
(business activities) and with Which Results (performance
indicators)
• Make these relationships explicit and executable
What you model is
what you execute
© A. Samarin 2012 Architecting modern information systems - Module 2 56
57. Process anatomy (1)
• The business is driven by events
• For each event there is a process to be executed
• Process coordinates execution of activities
• The execution is carried out in accordance with business
rules
© A. Samarin 2012 Architecting modern information systems - Module 2 57
58. Process anatomy (2)
• Each business activity operates with some business
objects
• A group of staff member (business role) is responsible
for the execution of each activity
• The execution of business processes produces audit
trails
• Audit trails (which are very detailed) are also used for the
calculation of Key Performance Indicators (KPIs)
© A. Samarin 2012 Architecting modern information systems - Module 2 58
59. Different enterprise artefacts
• Business artefacts
– Events
Human
– Processes “workflow”
Data structures
– Activities Roles
– Roles Documents
Events
– Rules Rules
Processes
– Data & documents Services
Audit trails
– Audit trails
KPIs
– Performance indicators
– Services
• Organisational and technical artefacts …
© A. Samarin 2012 Architecting modern information systems - Module 2 59
60. Be ready for common
(mis-)understanding
© A. Samarin 2012 Architecting modern information systems - Module 2 60
61. Different types of process
• Core-mission processes
• Leading / controlling processes
• Supporting processes
© A. Samarin 2012 Architecting modern information systems - Module 2 61
62. BPM as a management discipline (1)
• BPM as a management discipline about how to use
processes to manage the enterprise
– to model, automate, execute, control, measure and optimise the
flow of business activities that span the enterprise‟s
systems, employees, customers and partners within and beyond
the enterprise boundaries
• Model means to make known, to describe or to
communicate a plan of how to carry out future actions to
obtain a desired outcome
– To plan
– To simulate
© A. Samarin 2012 Architecting modern information systems - Module 2 62
63. BPM as a management discipline (2)
• Automate means to instrument the proposed plan of
work by some existing or new tools.
– To instrument
• Optimise means to introduce formally justified changes
– To reflect
– To refactor
– To improve
• Those 6 BPM functions are applied iteratively and
continuously
© A. Samarin 2012 Architecting modern information systems - Module 2 63
64. Process-oriented view of an enterprise
(with BPM)
© A. Samarin 2012 Architecting modern information systems - Module 2 64
65. Process templates and instances
• Process template – a formal description of the process
Templates Instances
and their
• Process instance – versions
enactment of a process
template
• Different variations of
relationship between
template and instance
© A. Samarin 2012 Architecting modern information systems - Module 2 65
66. Variant 1 – classic (one template is used
for many instances)
© A. Samarin 2012 Architecting modern information systems - Module 2 66
67. Variant 2 – tailoring (a template is
adjusted for each instance)
© A. Samarin 2012 Architecting modern information systems - Module 2 67
68. Variant 3 – reactive (no initial template
and next activity is selected based on
the current situation)
© A. Samarin 2012 Architecting modern information systems - Module 2 68
69. Variant 4 – proactive planning (similar
to variant 3, but a few next activities
[fragment] are executed together)
© A. Samarin 2012 Architecting modern information systems - Module 2 69
70. Variant 5 – scenario-based (similar to
variant 4, but a few scenarios are
considered)
Process fragments are used; those may be patterns
© A. Samarin 2012 Architecting modern information systems - Module 2 70
71. Homework 3
• Give real-life examples for all scenarios
• Invent the scenario 6
• More examples of core-business, leading and supporting
processes
© A. Samarin 2012 Architecting modern information systems - Module 2 71