Reference Model Architecture Context/Precursors (ESA 2) It is illegal to copy, share or show this document (or other document published at http://avancier.co.uk) without the written permission of the copyright holder Copyright Limited 2013 2. Architecture context/precursors Initiate Establish 1 Architecture capability and architects Establish 2 Architecture the context precursors Intermediate level Scope 3 Architecture the endeavour frameworks Get vision approved Govern 11 Architecture in Operations 11 Architecture Governance 11 Architecture Change Management 11 Architecture Implementation Intermediate level Architect 4 Business & 5 Data architecture 6 Software & 7 Apps architecture 8 Design for NFRs 9 Infrastructure architecture Practitioner Plan 10 Migration Planning Migration path Business case Delivery Plans Copyright Limited 2013 Copyright Limited 2015 1
2. Architecture precursors 2. Architecture precursors Stakeholders and concerns Structured requirements & constraints Explicit requirements Implicit requirements Target solution hierarchy Scope of architecture work Business case (before architecture) Stakeholders Owners Customers Suppliers Managers Designers Builders Operators Copyright Limited 2013 Stakeholders Stakeholder Stakeholder catalogue Stakeholder management [an actor or role] an individual, team, organization, or class thereof, having one or more concerns about or interests in a system, and/or power over the architecting of it. [an artefact] that contains a list of stakeholders. It might record concerns, interest level, power level, and/or a plan for communicating with that stakeholder [a technique] for ensuring concerns of stakeholders are understood and addressed, with a view to ensuring that stakeholders support changes that are envisaged. A stakeholder s position in a power/interest grid helps to prioritise attention to their concerns and determine a suitable communication plan. Stakeholders Owners Customers Suppliers Managers Designers Builders Operators Copyright Limited 2013 Copyright Limited 2015 2
Enterprise and solution architecture stakeholders include: Architect stakeholder Stakeholders Owners & Customers Managers & Designers Builders & Operators Enterprise and solution architecture stakeholders include: Owners: business and IT board members, customers. Managers: programme/project/change managers. Buyers: procurement/acquisition organisation. Suppliers: service and product providers. Designers, Builders, Testers: other project team members: Users: representatives and domain experts. Operators and Maintainers: IT Services Management. Business sponsors and stakeholders IS sponsors and stakeholders IT sponsors and stakeholders Copyright Limited 2013 Concerns Concern Stakeholders Owners & Customers Managers & Designers Builders & Operators An interest in a system relevant to one or more of its stakeholders. Any topic of interest pertaining to the system. A subject matter that is used to determine coverage of the architecture description, with no target or measure attached. (E.g. system behaviour, development cost, availability, disaster recovery, safety, all requirements, all standards, a particular standard, modularity.) Business sponsors and stakeholders IS sponsors and stakeholders IT sponsors and stakeholders Copyright Limited 2013 Copyright Limited 2015 3
Stakeholders Sponsor Request for architecture work [a stakeholder] who is willing to apportion money or other resources to some work. [a document] a request from a sponsor for an architect to architect one or more systems. The first architecture deliverable to be recorded in an architecting process. Stakeholders Owners Customers Suppliers Managers Designers Builders Operators Copyright Limited 2013 The solution architect is the chief technical risk mitigator Owners: business and IT board members, customers. Explain problems and solutions Sell solutions, manage expectations Managers: programme/project/change managers. Steer plans Buyers: procurement/acquisition organisation. Explain requirements Suppliers: service and product providers. Engage suppliers Apply due diligence to suppliers Monitor quality (and timeliness?) of supplier deliverables Designers, Builders, Testers: other project team members: Approve designs, govern architectures and implementation Monitor quality and timeliness of team deliverables Users: representatives and domain experts Explain problems and solutions Sell solutions, manage expectations Operators and Maintainers: IT Services Management. Shoot troubles For all stakeholders, the architect identifies and mitigates technical risks Copyright Limited 2013 Copyright Limited 2015 4
How to manage stakeholders? The techniques of business and systems analysis can help Interviews Workshops Documentation of problems and requirements Stakeholder management per se is something else 1. Identify Your Stakeholders 2. Prioritize Your Stakeholders: 3. Understand your key stakeholders 4. Classify by attitude 5. Consider how to manage blockers 6. Record you analysis in a stakeholder map. 7. Plan communication with each stakeholder See the process in Methods Copyright Limited 2013 Plan communication with each stakeholder Are you communicating as effectively as you should be with your stakeholders.? The end product Stakeholders Owners & Customers Managers & Designers Builders & Operators Stakeholder Concerns Power (H,M,L) Interest (H,M,L) Communication plan 1 Customer Goal, Deadline High High Involve - Manage closely 2 Manager Reputation, Profit High Low Persuade Satisfy - Monthly status report 3 End user Usability Low High Inform Weekly newsletter JAD workshops 4 Sales person Customer relationship Low Low Monitor Copyright Limited 2013 Copyright Limited 2015 5
2. Architecture precursors 2. Architecture precursors Stakeholders and concerns Structured requirements & constraints Explicit requirements Implicit requirements Target solution hierarchy Scope of architecture work Business case (before architecture) Directives Principle Aims Goal Objective Copyright Limited 2013 CxO level influences CxO-level Influences Driver Mission Vision Influence a belief, fact or statement that acts as a requirement for or constraint on behaviour or choices. Examples include instances of drivers, directives, aims (defined below). Driver [an influence] a force, recognised by managers, that shapes the directives and aims of a business. Driver areas and types include Political, Economic, Social, Technical, Legal and Ecological (PESTLE) and Strengths, Weaknesses, Opportunities and Threats (SWOT). Copyright Limited 2013 Copyright Limited 2015 6
Imposing a structure on the mess of precursors The inputs to architecture definition include high level aims, directives, visions and strategies. During architecture definition, these are decomposed and elaborated. So the outputs include lower-level elaborations of the inputs. This reference model tends to distinguish different levels of decomposition by using different words. CxO level influences Driver Mission Vision EA Could enter here Directives Principle Aims Goal levels Vision Plans Strategy SA Could enter here Objective Outline Programme Could enter here to Build Project Copyright Limited 2013 Business analysis concepts mapped to E&SA concepts SWOT Strengths (internal) Weaknesses (internal) Opportunities (external) Threats (external) Enterprise Business Organisation Directives Principle PESTLE (external forces) Political Economic Social Technological Legal Environment Driver Mission Vision Aims Goal Objective levels Vision Outline to Build Plans Strategy Programme Project 5-forces analysis (external forces) Buyers Suppliers Competitors New entrants Substitute products MOST Mission Objectives Strategy Tactics Business activity model Control activities Monitoring activities Doing activities Enabling activities Planning activities Copyright Limited 2013 Copyright Limited 2015 7
Drivers Drivers are pressures external or internal - e.g. changes in customer behaviour or interest the threat of increased competition from a new entrant to the market. high turnover of staff, with negative reports in leaving interviews. increased media attention to embarrassing loss of citizen data. Drivers stimulate enterprise leaders to define aims and directives for activity. Forces Drivers (SWOT) Visions Mission Directives Aims Copyright Limited 2013 From drivers to directives Driver = high turnover of staff, with negative reports in leaving interviews. Principle = We value our people. Driver = increased media attention to embarrassing loss of citizen data. Principle = Data security is paramount. Drivers (SWOT) Forces Visions Mission Directives Principles Policies s Copyright Limited 2013 Copyright Limited 2015 8
A structured terminology for directives helps people talk about directives at different levels of abstraction Executive level Driver (inc SWOT) Mission Vision EA level Principle Principle Principle Principle Principle SA level Not a strict hierarchy More art than science Copyright Limited 2013 Directives Directive Directives Principle [an influence] a principle or policy, enduring and seldom amended, that steers or constrains behaviour or choices. It may be specifiable as a data processing rule. Directives may be arranged in a hierarchical structure in which principles are supported by lower level policies, and policies are specified as business rules. Copyright Limited 2013 Copyright Limited 2015 9
Directives: Policies Principle [a directive] that is strategic and not-directly-actionable. (E.g. Waste should be minimised. Data security is paramount.) [a directive] that is more tactical than a principle. It may be implemented by business rules. (E.g. The public have minimal access to business data. USB ports are disabled. Messages at security level 3 are encrypted.) Business [a directive] that is formalised in data processing. (E.g. Access Level = Low if User Type = Public. See Process rule and Data rule for further definition.) Copyright Limited 2013 Directives: IT Architecture Principles The practitioner manual has a menu of c80 principles. And this example from one enterprise E.g. a Telco s principles 1. Buy rather than Build 2. Adopt a multi-tier systems architecture 3. Minimise and manage duplication of data and system functionality 4. Maximise the re-use and sharing of information, as far as possible 5. Ensure clarity of systems, processes and data ownership 6. Adopt scalable, proven technology 7. Extend the existing application portfolio as far as possible 8. Use point solutions only when necessary 9. Avoid point-to-point integration by adopting a bus integration architecture 10. Follow a component based approach to shared IT solutions 11. Ensure a consistent user experience across multiple channels 12. Ensure that IT initiatives are guided by business needs and priorities 13. Ensure conformity of IT solutions to IT standards and architecture 14. Use selective sourcing where appropriate Directives Principle Copyright Limited 2013 Copyright Limited 2015 10
Directives: Principles are a tool of governance are simple statements (even aphorisms) define the way an organisation does or wants to operate reflect the goals of the organisation and the intentions of the governance board reflect strengths and weaknesses steer an organisation in directions compatible with strategic business and technical goals and objectives are more abstract than goals; qualitative rather than quantitative both aid and constrain decision making are useful as dispute resolvers facilitate choices between design options often conflict with each other, so trade-offs must be addressed. Directives Principle Copyright Limited 2013 Directives: Principle conflicts The practitioner manual has a menu of c80 principles. Some are contradictory You may select contradictory principles provided you include in them guidance on how to choose one over another e.g. what kind of data must be secure what kind of data must be accessible. Directives Principle Copyright Limited 2013 Copyright Limited 2015 11
From directives to aims Directives Principles Policies s Aims Goals Objectives s SMART Principle data security is paramount Goal in the next year, we shall have no more than 2 top-level security incidents. Principle buy rather than build. Goal in the next year at least 75% of our new application systems will be packages rather than bespoke. Copyright Limited 2013 From drivers to aims Enterprise leaders respond to drivers by defining aims e.g. define expansion goals to ward off competition. As they cascade downwards, broad and high level aims are hierarchically decomposed into narrower and more detailed aims. A lower level aim can support more than one higher level aim so it is not a strict hierarchy. Drivers (SWOT) Forces Visions Mission Aims Goals Objectives s Copyright Limited 2013 Copyright Limited 2015 12
Aim hierarchies There is a loosely structured hierarchy of aims. The terms goal, objective and requirement can be used to differentiate levels within a given aim hierarchy. But there is no sharp or universally agreed distinction between aims at different levels. Aims Goals Objectives s Copyright Limited 2013 A structured terminology for aims helps people talk about aims at different levels of abstraction EA level Executive level Driver Mission Vision SMART Aims Goal Goal Objective Objective Goal Goal Goal SA level Objective Objective Not a strict hierarchy More art than science Objective Objective Objective Objective Objective Copyright Limited 2013 Copyright Limited 2015 13
Aims: Specific Measurable Actionable Realistic Timebound Aim [an influence] a goal or objective that is declared or recognised by business managers, or a requirement for a particular endeavour or system. It should be SMART (Specific, Measurable, Actionable, Realistic and Timebound.). Goal [an aim] that is strategic. It may be quantified using Key Goal Indicators. It may be decomposed into lower level goals or objectives. Objective [an aim] that is more tactical than a goal. It may support one or more higher-level goals. It should be quantified using Key Performance Indicators. It may be decomposed into lower level objectives or seen as a high-level requirement. [an aim] a statement of need with which compliance can be demonstrated in a specific solution or project. It should have acceptance tests and an acceptance authority. It may be captured in a requirements catalogue or in the text of a service contract or use case. It should be traceable to higher level concerns, aims, directives or strategies. Copyright Limited 2013 Aims: top level goals It is common to define business goals under three headings in the iron triangle of project management Aims Goal Objective Time Cost Quality Faster: Deliver sooner or faster Cheaper: Reduce cost Better: Improve quality Copyright Limited 2013 Copyright Limited 2015 14
2. Architecture precursors 2. Architecture precursors Stakeholders and concerns Structured requirements & constraints Explicit requirements Implicit requirements Target solution hierarchy Scope of architecture work Business case (before architecture) Aims Goal Objective Types Regulatory Functional Audit Non-Functional Specific, Measurable, Actionable, Realistic, Timebound Copyright Limited 2013 types catalogue type Functional requirement NFR: Nonfunctional requirement [a document] a structured list of requirement instances in which each is recorded with properties such as reference number, description, source, owner, priority, and requirement type. (E.g. throughput = 100 tps, response time = 1 second.) [a concern] a kind or group of needs that is generally applicable to system structure or behaviour. It usually correspond to a concern that is held by stakeholders or addressed in viewpoints. (E.g. throughput, response time.) [a requirement type] related to services offered by a system, including inputs and outputs, processes and business rules. [a requirement type] that quantifies qualities that specify how well, effectively or efficiently a system should deliver services. (See section 8 for a list of kinds.) Copyright Limited 2013 Copyright Limited 2015 15
2. Architecture precursors 2. Architecture precursors Stakeholders and concerns Structured requirements & constraints Explicit requirements Implicit requirements Target solution hierarchy Scope of architecture work Business case (before architecture) Copyright Limited 2013 Explicit and implicit requirements Explicit requirement Implicit requirement [a requirement type] that classifies requirements that are declared by stakeholders. [a requirement type] that must be addressed, even if never mentioned by stakeholders. Under any best endeavours obligation, the architect must be aware of the possibly implicit requirements below. Copyright Limited 2013 Copyright Limited 2015 16
Regulatory requirements Regulatory requirement Clinger Cohen Act and enterprises from Copyright theft of intellectual Limited 2013 property. [a requirement type] include legislation and regulations that direct or constrain architecture work. IT accountability and procurement: Regulation that makes public sector, IT directors and CIOs accountable for justifying investment in IT and for fair procurement from suppliers. E.g. Information Technology Management Reform act (ITMRA) of 1996, Division E, P.L. 104-106. This Clinger Cohen Act was the stimulus for many early enterprise architecture initiatives. Data protection: Legislation that directs an enterprise to protect data from unauthorised access. E.g. UK's data protection act. Data freedom: Legislation that directs an enterprise to make data available to people who request it. E.g. Freedom of Information Act 2000. Disability and accessibility: Legislation that directs enterprise to build systems that can be accessed by any member of the public. E.g. UK Equality act. US Americans with Disability act. W3C Web Content Accessibility Guidelines. Shareholder protection and audit: Legislation that directs an enterprise to maintain records showing how it has directed, monitored and controlled its business. E.g. US Sarbanes-Oxley act of 2002. Basel II. Intellectual property rights: International and national laws protect people The IT management reform (Clinger-Cohen) act of 1996 A USA federal government regulation A response to the mess IT was in by the early 1990s Clinger and Cohen heard testimony from John Zachman among others Defines roles and responsibilities of IT director CIO Makes CIOs responsible for developing, maintaining and facilitating the implementation of a sound and integrated IT architecture for the executive agency. Copyright Limited 2013 Copyright Limited 2015 17
Office and Management and Budget (OMB) circular Q-130 Refines the definition of EA Requires that EA describes current architecture, target architecture and transition processes The basis of TOGAF s process (ADM) includes a TRM a Standards Profile Hence the TRM in TOGAF Hence the SIB in TOGAF www.opengroup.org search SIB Copyright Limited 2013 Regulatory requirement references UK's data protection act: http://www.opsi.gov.uk/acts/acts1998/19980029.htm Freedom of Information act 2000: http://www.opsi.gov.uk/acts/acts2000/20000036.htm UK Disability Discrimination act: http://www.opsi.gov.uk/acts/acts1995/1995050.htm. W3C Web Content Accessibility Guidelines: http://www.w3.org/tr/wai-webcontent/ US Americans with Disability act. US Sarbanes-Oxley act of 2002. Basel II. Also Solvency 2 PCI FSA VISA Patriots Act International and national laws protect people and enterprises from theft of intellectual property. Copyright Limited 2013 Copyright Limited 2015 18
Standards Standard Enterprise Standards Information Base [a concern] a widely-accepted definition of a structure, process or rules, intended to increase uniformity and interoperability between distinct systems and processes. [an artefact] a catalogue of standards that is recommended or used across the enterprise. (Cf. The Open Group s SIB.) The aim is to ensure your enterprise does not rely on the haphazard knowledge that individual architects have of which standards are relevant See www.opengroup.org search SIB Copyright Limited 2013 Standards bodies An enterprise with a mission to set standards and assess compliance to them. E.g. American National Standards Institute (ANSI). British Computer Society (BCS). Information Systems Examination Board (ISEB). Institute of Electrical and Electronic Engineers (IEEE). Information Systems Audit and Control Association (ISACA) International Standards Organisation (ISO). Office of Government Commerce (OGC). Open Applications Group Standards (OAGIS). Organisation for Advancement of Structured Information Standards (OASIS). The Object Management Group (OMG). The Open Group. US National Institute of Standards and technology (NIST). Software Engineering Institute (SEI). Internet Engineering Taskforce (IETF) Copyright Limited 2013 Copyright Limited 2015 19
Industry standards in the reference model These standards appear (incidentally) in reference model entries: Number Topic Title / subject matter ISO/IEC 42010 ISO/IEC 17799 ISO/IEC 24762:2008 ISO/IEC 27001 CMM-I ISO 9001 ISO/IEC 20000 Architecture Description Security Security Security Quality Quality ITSM Recommended Practice for Architecture Description of Software-Intensive Systems. Information technology: Code of practice for information security management (OLD superseded by 27001) Information technology Security techniques Guidelines for information. Information technology Security techniques Information Capability maturity model integrated (process quality standard) A standard in the ISO 9000 family for quality management systems. An international standard for ITSM (based on the earlier British Standard, BS 15000). Copyright Limited 2013 Other standards Open standards (e.g. W3C). Government standards (e.g. e-gif) Payment card industry, data security standards (PCI DSS) A technical strategy that mandates (say) choice of database or mid-range servers. Copyright Limited 2013 Copyright Limited 2015 20
2. Architecture precursors end of pass 1 SHOW RELEVANT MOCK EXAM QUESTIONS Copyright Limited 2013 2. Architecture precursors 2. Architecture precursors Stakeholders and concerns Structured requirements & constraints Explicit requirements Implicit requirements Target solution hierarchy Scope of architecture work Business case (before architecture) Business case (before architecture) levels Vision Outline to Build Copyright Limited 2013 Copyright Limited 2015 21
2.5: Scoping Real world Example Strategy RFI RFP ITT Overview Design Document High Level Design architecture description vision levels Vision outline Outline [an architecture description] describing a solution to problems and requirements. Its elements may be mapped to directives, aims and plans. Kinds include definitions at different levels of abstraction. briefly describes of a target, just enough to enable options to be compared (including any initial idea of costs and risks) and solution outline work to proceed. It may be a response to a business problem or an elaboration of how to reach a business vision. describes the high-level design of a target system, produced after a first pass architecture description, enough to enable an acceptably accurate estimate of cost, benefits and risks, and projects to be planned. Low Level Design to Build to be built describes a project-ready architecture, completed in sufficient detail for the project to be scheduled and resourced, and the building team to start work. Copyright Limited 2013 Concept/Vision diagram: MODAF style Based around a rich picture or cartoon Copyright Limited 2013 Copyright Limited 2015 22
Iterative elaboration of a solution architecture levels Vision Outline Architecture Levels Enterprise Architecture Architecture Software Architecture Strategy Enterprise Arch Inception & Elaboration Technical Risk Management ITT/Bid Initiation Program or Project to Build Elaboration Construction Copyright Limited 2013 A structured terminology for planning helps people talk about plans at different levels of abstraction EA level Executive level Driver Mission Vision Business Strategy IT Strategy PM methods have variations on this structure EA Project Programme Programme Programme Project Work Package Project Project Project SA level Work Package Work Package Work Package Work Package Work Package Work Package Specialist level Task Task Task Task Task Task Copyright Limited 2013 Copyright Limited 2015 23
2. Architecture precursors 2. Architecture precursors Stakeholders and concerns Structured requirements & constraints Explicit requirements Implicit requirements Target solution hierarchy Scope of architecture work Business case (before architecture) Depth Technology Data Applications Business Constraints Breadth of SYSTEM Copyright Limited 2013 Three dimensions of scope Fix any 2 dimensions, and the 3 rd dimension is derivable Three dimensions of scope Breadth Constraints Depth Size & complexity of system or project Large / Medium / Small Time & resources to describe the system or project Little / Moderate / Lots Level of detail reachable in descriptions or plans Large Little Vacuous Medium Little Sketchy Large Moderate Sketchy Medium Moderate Elaborate Small Little Elaborate Large Lots Elaborate Small Moderate Fulsome Medium Lots Fulsome Small Lots Complete Copyright Limited 2013 Copyright Limited 2015 24
The 4 dimensions in the reference model Scope view [a view] a dimension of scope. Breadth: scope of the enterprise, system or solution. Depth: the detail to which description or design should be completed Constraints on work. Domain in focus: business, application or infrastructure change. Depth Technology Data Applications Business Constraints Breadth of SYSTEM Copyright Limited 2013 Breadth of enterprise or system Breadth of enterprise or system a scope view] that may be defined in several ways. Sales person Marketeer Aim view: goal/objective/requirement catalogue Supplier System Fulfiller Customer Service view: a service catalogue. Sales person Review Sale Marketeer System view: a top-level context diagram. Fulfiller Supplier Goods Out Goods In Customer Process view: a top-level process map or use case diagram. Customer Sale Product Stock Depot Data view: a conceptual/domain/business data model. Copyright Limited 2013 Copyright Limited 2015 25
The scope of an enterprise or system Context Diagram [an artefact] that shows a system s scope in terms of inputs consumed, outputs produced, and the external entities (actors and/or roles) that send inputs and receive outputs. The system is shown as a black box. As in SIPOC in Six Sigma Supplier Input Process Output Customer Enterprise Supplier Input Output Customer Or System Shows why the system exists the system that is the focus of design the external entities, inputs and outputs around the boundary. Does not show what the system is made of parts or components are hidden from view Copyright Limited 2013 2nd dimension: constraints Constraint (on work) [a scope view] a factor such as time, budget and resources that limits work to be done, or potential options. Depth Technology Data Applications Business Breadth of SYSTEM Constraints Time, cost, resource You can only do what you have time, money and resources to do Copyright Limited 2013 Copyright Limited 2015 26
2. Architecture precursors 2. Architecture precursors Stakeholders and concerns Structured requirements & constraints Explicit requirements Implicit requirements Target solution hierarchy Scope of architecture work Business case (before architecture) Copyright Limited 2013 Business planning context Planning is addressed in last two sections of the reference model Business case (before architecture) [a document] that justifies work to build or change systems. It will be outlined at the start and updated as need be. It will be reviewed and refined several times while architecture work is done. It may be decomposed into business cases for specific options, stages or projects within the overall solution. [See the Migration Planning section for further definitions of supporting terms below. Return on Investment (ROI) Cost-benefit analysis options Risk analysis Gap analysis (options) Trade-off analysis.] Copyright Limited 2013 Copyright Limited 2015 27
Business planning context Planning is addressed in last two sections of the reference model Business scenario Business scenariodriven design [an artefact] that outlines a process, along with the human and computer actors involved in the process steps. It is useful in creating and presenting an architecture description. It may be defined to support a solution vision or business case. It may be defined during business architecture description. It may be presented as an example instance of a business process. [a technique] that proceeds by defining four main elements: The aims (outcomes or effects) of the process. The outputs (products or services) the process produces The steps of the process (scenario or value stream) The actors/components involved in the process. There are two or three business scenario exercises in the course Copyright Limited 2013 Business Scenario (much adapted from a TOGAF example) Precondition: Sales visit to customer premises has been agreed and scheduled Human actors Computer actors Process Customer Sales person Client app use case Data centre app 1 Initiate sales process with the customer Accept sales person 2 Discuss customer requirements Explain problems & requirements 3 Work with customer to create a product configuration 4 Verify that the desired configuration can be delivered 5 Determine price of requested configuration 6 Confirm customer desire to purchase Select one option based on capabilities Greet customer Listen Show product and configuration options Show availability to customer Copyright Limited 2013 Get product description Assemble configuration Check configuration availability Product Configurator App Inventory App Accept Show delivery date to customer Get delivery date Scheduling App Accept Show price to customer Price configuration Pricing App Accept Show offer in full 7 Place an order Capture order details and print Enter order Get fax response 8 Customer acceptance Sign Request signature Post condition: Order captured Order App Copyright Limited 2015 28