Architecting modern informaiton systems M2a business architecture

407 views

Published on

Module 2 (first part) "business architecture" of the course "Architecting modern information systems" .

Some slides use animation.

Published in: Technology, Business, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
407
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Architecting modern informaiton systems M2a business architecture

  1. 1. Architecting moderninformation systems Module 2 Business architecture A. Samarin
  2. 2. 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. 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. 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. 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. 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. 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
  8. 8. Example: component business model from IBM© A. Samarin 2012 Architecting modern information systems - Module 2 8
  9. 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. 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. 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. 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. 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. 14. Value-stream (5) from www.enterprisebusinessarchitecture.com© A. Samarin 2012 Architecting modern information systems - Module 2 14
  15. 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. 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. 17. Value & Expenses Basin (1) This is a flow of performance metrics© A. Samarin 2012 Architecting modern information systems - Module 2 17
  18. 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. 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. 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. 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. 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. 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. 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. 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
  26. 26. Coordination between activities (3)© A. Samarin 2012 Architecting modern information systems - Module 2 26
  27. 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. 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. 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. 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 companys 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. 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. 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
  33. 33. Business architecture artefacts (4)• Business performance artefacts© A. Samarin 2012 Architecting modern information systems - Module 2 33
  34. 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. 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. 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. 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. 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. 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. 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. 41. Different types of improvement• Operational• Tactical• Strategic• Competitiveness© A. Samarin 2012 Architecting modern information systems - Module 2 41
  42. 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. 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. 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. 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. 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. 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. 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. 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. 50. Quality management system documentationBusiness processes “In” quality Business Records manual proceduresQuality management 1 ~5 ~100Sales 1 ~10 ~10 000Customer services 1 ~10 ~10 000Production 1 ~10 ~100 000Covered by traditional applications for quality managementCovered by various business applications, paper and manual workHaving these documents is not enough; are they traceable, secure andcorrectly managed throughout their life cycle?© A. Samarin 2012 Architecting modern information systems - Module 2 50
  51. 51. Process improvement disciplines© A. Samarin 2012 Architecting modern information systems - Module 2 51
  52. 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. 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. 54. Process-oriented view of an enterprise (before BPM)© A. Samarin 2012 Architecting modern information systems - Module 2 54
  55. 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” processesThe theory The toolsBPM 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. 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. 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. 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. 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. 60. Be ready for common (mis-)understanding© A. Samarin 2012 Architecting modern information systems - Module 2 60
  61. 61. Different types of process• Core-mission processes• Leading / controlling processes• Supporting processes© A. Samarin 2012 Architecting modern information systems - Module 2 61
  62. 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. 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. 64. Process-oriented view of an enterprise (with BPM)© A. Samarin 2012 Architecting modern information systems - Module 2 64
  65. 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. 66. Variant 1 – classic (one template is used for many instances)© A. Samarin 2012 Architecting modern information systems - Module 2 66
  67. 67. Variant 2 – tailoring (a template is adjusted for each instance)© A. Samarin 2012 Architecting modern information systems - Module 2 67
  68. 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. 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. 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. 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

×