Enterprise Architecture: an ideal discipline for use in Supply Chain Management Richard Freggi Senior Supply Chain Architect (TOGAF 9.1 certified level 2) HP Inc.
Content Understanding Supply Chain Management and its challenges Understanding Enterprise Architecture and its artifacts Overcoming Supply Chain Management challenges with Enterprise Architecture 2
Executive summary Supply Chain Management has a wide and diverse scope, with high time pressure and high cost of failure This results in several challenges Enterprise Architecture provides practical ways to overcome these challenges Correct use of Enterprise Architecture artifacts is necessary to overcoming the challenges UML notation (supported by a suitable CASE tool) is a proven way to develop and use EA artifacts and overcome SCM challenges One notation, one CASE tool (open source: free of charge) for all required artifacts A change in any artifact is easily and accurately propagated to all the others E.g. a business process change can be accurately reflected in data model and system architecture change Artifacts are easy to reuse and exchange with 3 rd parties Due to clear and well documented UML standard for model semantics, diagrams and file format 3
Understanding Supply Chain Management
The SCOR model is the most widely accepted definition of Supply Chain Management SCOR Model = Supply Chain Operations Reference Model APICS = American Production and Inventory Control Society Leading professional association focused on Supply Chain Management Founded in 1957 Provides research, education and certification 5
SCOR defines the Supply Chain as a thread of 7 processes Source: SCOR 11 (APICS) 6
SCOR provides metrics to measure process performance Source: SCOR 11 (APICS) 7
The goal of Supply Chain Management is to achieve the optimal compromise of performance metrics The 5 performance attributes metrics are inter-related Due to the thread of business processes within an organization and across organizations Optimizing one metric while ignoring the other metrics leads almost always to net overall reduction in performance Local optimization must be balanced against global optimization The cost of reduced performance can be very high Lower customer service level, loss of market share Slower response to demand / supply disruptions Higher operating costs and capital expenses, missed financial targets Higher inventory carrying costs and scrap/obsolescence Etc 8
Typical scenarios requiring compromises between Supply Chain performance metrics M&A, Divesture, reorganization Combine redundant processes and systems Organizational design, roles and responsibility alignment Identify gaps and determine new process; identify new system requirements Joint Ventures Dictionary to understand each other across language and cultural gaps Government negotiations Authoritative and impartial reference to discuss roles and mutual obligations Green field operations startup Identify skill gaps and determine training of local workforce Reference to map out new roles and organizational design Realistic estimate of implementation costs and schedule New business models Align organization, processes and systems to the target environment Coordinate suppliers and customers for fast, trouble-free business launch 9
Typical challenges of Supply Chain Management Wide scope covering many diverse domains 7 process threads with many specialized sub-processes, industry standards, IT systems Complex processes and systems with multiple cross-dependencies Optimizing each process/system individually does not provide acceptable results Must balance local vs. global optimization Deep integration with 3 rd parties Global optimization must take into account customers and suppliers Different operating models, cultures, organizations, infrastructure, regulatory environment Compromise between conflicting goals/requirements/metrics Low cost vs. high responsiveness High service levels vs. asset management efficiency Different organizations have different priorities Dealing with the unknown and the unpredictable Market changes, technology disruptions, policy changes Many stakeholders have never attempted this before Great time pressure Competitive pressure to respond to change before others Achievement of strategic dates and milestones High cost of failure Direct impact on financial performance: revenue, operating expenses, write-downs etc. 10
Understanding Enterprise Architecture
Enterprise Architecture is commonly confused with Software, Application or System architecture 12
TOGAF is the most widely accepted definition of Enterprise Architecture TOGAF = The Open Group Architecture Framework The Open Group is a global consortium that enables the achievement of business objectives through IT standards Besides TOGAF: UNIX, Trusted Technology and many others TOGAF provides: ADM (Architecture Development Method): a process description From architecture capability to overseeing implementation Including R&R of who should do what, when, how Architecture Content Framework and Enterprise Continuum Artifacts, deliverables and templates for the ADM processes Including content management for reuse and future evolution Reference models Solution taxonomy and semantics Architecture Capability Framework Skills, maturity models, governance principles and best practices 13
The TOGAF content metamodel lists all the key elements of Enterprise Architecture Metamodel Entity Description Actor A person, organization, or system that has a role that initiates or interacts with activities; for example, a sales representative who travels to visit customers. Actors may be internal or external to an organization. In the automotive industry, an original equipment manufacturer would be considered an actor by an automotive dealership that interacts with its supply chain activities. Application Component Assumption Business Service Capability Constraint Contract Control Data Entity Driver Event Function An encapsulation of application functionality aligned to implementation structure. For example, a purchase request processing application. See also Logical Application Component and Physical Application Component. A statement of probable fact that has not been fully validated at this stage, due to external constraints. For example, it may be assumed that an existing application will support a certain set of functional requirements, although those requirements may not yet have been individually validated. Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization. A business-focused outcome that is delivered by the completion of one or more work packages. Using a capability-based planning approach, change activities can be sequenced and grouped in order to provide continuous and incremental business value. An external factor that prevents an organization from pursuing particular approaches to meet its goals. For example, customer data is not harmonized within the organization, regionally or nationally, constraining the organization's ability to offer effective customer service. An agreement between a service consumer and a service provider that establishes functional and nonfunctional parameters for interaction. A decision-making step with accompanying decision logic used to determine execution approach for a process or to ensure that a process complies with governance criteria. For example, a sign-off control on the purchase request processing process that checks whether the total value of the request is within the sign-off limits of the requester, or whether it needs escalating to higher authority. An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations. An external or internal condition that motivates the organization to define its goals. An example of an external driver is a change in regulation or compliance rules which, for example, require changes to the way an organization operates; i.e., Sarbanes-Oxley in the US. An organizational state change that triggers processing events; may originate from inside or outside the organization and may be resolved inside or outside the organization. Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. Also referred to as "business function". Source: TOGAF 9.1 chapter 34: Content metamodel 14
85% of TOGAF metamodel is about business management and logical level blueprint TOGAF content metamodel entities by type Business mgmt Logical level blueprint Tech implementation Actor Applic component Phys applic component Assumption Data Entity Phys data component Business service Gap Phys tec component Capability Info service requirement Technology component Constraint Logical applic component Work package Contract Logical data component Control Logical tech component Driver Platform service Event Function Goal Location Measure Objective Org unit Principle Process Product Requirement Role Service Service quality TOGAF content metamodel entities by type Business Mgmt Logical blueprint Tech implementation 8 5 22 15
Enterprise Architecture is not just about IT; it is about achieving specific objectives using business processes and IT enablers Software architecture: define the structure of source code Solution architecture: determine application configurations System architecture: design the infrastructure Enterprise architecture: translate goals and constraints into an actionable blueprint; and validate that implementation is consistent with the blueprint Blueprint = TOGAF Architecture Definition Document = logical level description of the target state Logical level = implementation independent Therefore flexible to change in implementation approach and 16 technology Description = integrated process / information (data) / enablers (systems) / technology (infrastructure) Blueprint must be actionable = enough detail to validate if implementation is consistent or not Includes implementation roadmap Source: TOGAF 9.1 chapter 34.3.1: Content metamodel
The blueprint is a clear, consistent, actionable, implementationindependent description of the functions, processes, information and systems needed to achieve the objectives 17
A generalized view of the blueprint and its usage Architecture blueprint Goals, roles, stakeholders Process model Information and messages needed to enable processes (UML package diagram) Sequence diagram Constraints, qualities UML documents each part of the blueprint In precise and unambiguous way (UML standard is extremely well defined) UML supports each dependency of the blueprint For example: actors in use case model become participants in sequence diagram; object participants in sequence diagram define classes in class diagram; etc. Functional model Use case diagram Scope, goals, metrics, qualitites Dashed arrows show dependencies: [source] needs something from [target] This works both ways: for example a technical constraint in system architecture can be easily and precisely rolled back to class diagram change -> sequence diagram change -> impact on use cases and requirements Requirements Text list Constraints, qualities System architecture Component diagram Implementation projects Constraints, business rules What data is needed by whom, and how Blueprint and roadmap (project deliverables, schedule and dependencies) Information model Class diagram 18 Project charter
Many excellent free (or almost-free) UML modeling tools support this way of using the blueprint Papyrus UML WhiteStarUML Sparx Enterprise Architect 19
This usage of the blueprint is equivalent to TOGAF ADM phases Architecture blueprint Goals, roles, stakeholders Process model Sequence diagram Information and messages needed to enable processes Equivalent Constraints, qualities Functional model Scope, goals, metrics, qualitites Requirements Constraints, business rules Information model Use case diagram Text list Class diagram Constraints, qualities Dashed arrows show dependencies: [source] needs something from [target] System architecture Component diagram What data is needed by whom, and how Blueprint and roadmap (project deliverables, schedule and dependencies) Implementation projects Project charter 20
The roadmap is a sequence of steps from baseline to target blueprints Each step is a work product or a capability described by the blueprint The sequence of steps is based on the blueprint and various dependencies (organization, risks, technology etc.) Each project schedule, deliverables, vendor contracts, governance is based on the blueprint + roadmap AS-IS TO-BE MILESTONE MILESTONE MILESTONE MILESTONE Capability Capability Work Product Work Product Work Product Work Product Work Product Capability Work Product Capability Work Product Work Product Work Product 21
For more insights see this great presentation on Youtube The Open Group EA and lessons learned in e-government: Paris, October 24, 2016 EA is not IT EA is explicit knowledge of the enterprise and rigorous planning The goal of EA is to understand: Where are we Where do we want to be How do we get there IT is one of the enablers to get there EA can be used to validate IT projects EA should be hosted by the planning and budgeting organization Typically finance related EA best practices https://youtu.be/rzghdjxnb9c?list=pl4uhusjo0stlteua6hay5xnblwgbxq WVC Business managers are responsible to make some decisions and should not delegate everything IT IT may make business decisions based on technical criteria, causing misalignment between processes and systems IT may try to align processes, data and technology at implementation level (physical), which is efficient but not effective Alignment should be at implementation-independent level (logical) to be both efficient and effective 22
How Enterprise Architecture helps to overcome Supply Chain Management challenges
Summary of supply Chain Management challenges and Enterprise Architecture artifacts SCM challenges Wide scope covering many diverse domains Complex processes and systems with multiple cross-dependencies Deep integration with 3 rd parties Compromise between conflicting goals/requirements/metrics Dealing with the unknown and the unpredictable Great time pressure High cost of failure EA artifacts (TOGAF) Blueprint: o Requirements o Scope definition (phase A) o Functional model (phase B) o Information model (phase B and C) o System architecture (phase C) o Infrastructure architecture (phase D) Roadmap: o Work packages, schedule, SOWs (phases E to H) 24
EA artifacts support all Supply Chain challenges SCM CHALLENGES Sponsorship, Document Resolve Coordinate Good program complex domains different resource / project process and teams / Everyone Who Invent Effective Identify Logical Application Clear Validation Reuse Dependency Faster, What does definition we architectural new trouble-free data information and want business understands what, that mechanisms architecture resolve model diagram to the of how achieve process assets ensures gaps, R&R / Gantt budget Efficient, terminology Validate problems Validation with quality clear, commitment assurance business at effective, that unambiguous right the level process / system risk of exactly Sponsorship, need Find gaps, No integration overlaps high based messages, Fast application Early / implementation Who Blueprint surprises decision quality workarounds to should overlaps identification operating change processes, interfaces, support architecture / decide, during resource fully projects vendor model aligned quick of who / will and just Harmonize actionable Resolve integration abstraction topology documentation mitigation ambiguous, and negotiation (domain requirements, sizing of who will with does responsibilities budget Validate Quantify implementation, Maintain Modify business requirements datastores choice meet hardware risk with consulted mitigation clear / commitment processes data RFP and responsibilities procurement (governance) targets well models IT / requirements and RFQ or aligned architecture suitability testing, / constraints adoption IT and between quickly system and with go- constraints suppliers, contradicting Achieve dictionary) meet what Manage for process vendor full implementation customers, process requirements concepts performance IT different and Written live consistency in Easier, with x-functional award Robust physical of No Consensus response new arguing unexpected feasibility traceability criteria; faster, requirements solutions record changes parties to between to (including processes, trouble-free improvisation unexpected fast, of dependencies that to strategy free quickly infrastructure constraints slowing different implementation user go-live no scale down process parties/priorities training gaps/overlaps / to constraints progress high volume existing many / 3 Risk Government Improve system Introduce mitigation consistency x-functional new concepts and rd / and Everybody with constraints SOW and has signed the same off after Ensure Identify agreements Fast parties) goals requirements, communication solutions understanding blueprints of targets Wide scope covering many diverse domains Complex processes and systems with multiple cross-dependencies Deep integration with 3rd parties Compromise between conflicting goals/requirements/metrics Dealing with the unknown and the unpredictable Great time pressure ENTERPRISE ARCHITECTURE ARTIFACTS Scope definition (Phase A) Functional model (Phase B) Information model (Phase B and C) System architecture (Phase C) Infrastructure architecture (Phase D) Work packages, schedule, SOWs (Phase E to H) High cost of failure 25
The blueprint and roadmap are critical for project planning, project definition and governance Artifacts are critical to: Identify all stakeholders and viewpoints: what is obvious to one party may be not be noticed by another Agree on the engagement model, methodology and governance Define the scope, areas of influence and responsibilities Agree on what are the goals and how to achieve them Document all this in project charters and obtain signoff If no time or resources for project planning and definition: Do it before actual project kickoff; or in parallel with project EA artifacts will help to finalize planning and definition quickly even in a difficult environment Reuse stakeholder definitions (UML actor patterns) Reuse scope definition (UML package diagram patterns) Make a shortlist of critical processes and information (Use Cases and Classes) Benefits Realistic project plans with schedules and activities Effective milestones and pass/fail criteria Effective handling of risks, issues and change requests, especially in new environments Better coordination of sub-project teams 26 Planning VISION PHASE phase Definition PLANNING phase PHASE Review current/future projects that could create dependencies Determine which migration strategy has less risks and impact Determine scope,development approach and timing Discuss goals and context with stakeholders Decide engagement model and methodology customization Understand what requirements can be implemented and what not Agree level of effort and sign contract with business partners Review repository of building blocks Define governance process Signoff project charter
The blueprint and roadmap reduce the time, cost and risk of Supply Chain projects and maximize benefits The logical level blueprint and its roadmap change project approach from case-by-case to controlled evolution 27
The blueprint and roadmap change projects from case-by-case to controlled evolution Provide a common language to coordinate implementation of processes, data and systems Minimize duplicate processes / data / systems that impact referential integrity and scalability Identify and manage functional / IT dependencies (including 3rd parties) Reduce system interfaces; minimize chance of things going wrong Improve flexibility to evolve Critical input for project management Define project deliverables Solution assessment, gap analysis and make/buy decision Manage dependencies between projects Approach, interoperability requirements, deliverables, schedule Maintain a consistent data model across solutions Define test plans, test datasets / procedures, acceptance criteria 28
End of presentation