2. richard-ea for supply chain - · pdf filesenior supply chain architect (togaf 9.1 certified...

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Enterprise Architecture: an ideal discipline for use in Supply Chain ManagementRichard FreggiSenior Supply Chain Architect (TOGAF 9.1 certified level 2)HP Inc.

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2

ContentUnderstanding Supply Chain Management and its challenges

Understanding Enterprise Architecture and its artifacts

Overcoming Supply Chain Management challenges with Enterprise Architecture


Executive summarySupply Chain Management has a wide and diverse scope, with high time pressure and high cost of failureThis results in several challenges

Enterprise Architecture provides practical ways to overcome these challengesCorrect 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 challengesOne 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 3rd parties

• Due to clear and well documented UML standard for model semantics, diagrams and file format


Understanding Supply Chain Management


The SCOR model is the most widely accepted definition of Supply Chain ManagementSCOR Model = Supply Chain Operations Reference ModelAPICS = American Production and Inventory Control SocietyLeading professional association focused on Supply Chain ManagementFounded in 1957Provides research, education and certification


SCOR defines the Supply Chain as a thread of 7 processes

Source: SCOR 11 (APICS)


SCOR provides metrics to measure process performance

Source: SCOR 11 (APICS)


The goal of Supply Chain Management is to achieve the optimal compromise of performance metricsThe 5 performance attributes metrics are inter-relatedDue to the thread of business processes within an organization and across organizationsOptimizing one metric while ignoring the other metrics leads almost always to net overall reduction in performanceLocal optimization must be balanced against global optimizationThe cost of reduced performance can be very highLower customer service level, loss of market shareSlower response to demand / supply disruptionsHigher operating costs and capital expenses, missed financial targetsHigher inventory carrying costs and scrap/obsolescenceEtc…


Typical scenarios requiring compromises between Supply Chain performance metricsM&A, Divesture, reorganizationCombine redundant processes and systemsOrganizational design, roles and responsibility alignmentIdentify gaps and determine new process; identify new system requirementsJoint VenturesDictionary to understand each other across language and cultural gapsGovernment negotiationsAuthoritative and impartial reference to discuss roles and mutual obligationsGreen field operations startupIdentify skill gaps and determine training of local workforceReference to map out new roles and organizational designRealistic estimate of implementation costs and scheduleNew business modelsAlign organization, processes and systems to the target environmentCoordinate suppliers and customers for fast, trouble-free business launch


Typical challenges of Supply Chain ManagementWide scope covering many diverse domains7 process threads with many specialized sub-processes, industry standards, IT systemsComplex processes and systems with multiple cross-dependenciesOptimizing each process/system individually does not provide acceptable resultsMust balance local vs. global optimizationDeep integration with 3rd partiesGlobal optimization must take into account customers and suppliersDifferent operating models, cultures, organizations, infrastructure, regulatory environmentCompromise between conflicting goals/requirements/metricsLow cost vs. high responsivenessHigh service levels vs. asset management efficiencyDifferent organizations have different prioritiesDealing with the unknown and the unpredictableMarket changes, technology disruptions, policy changesMany stakeholders have never attempted this beforeGreat time pressureCompetitive pressure to respond to change before othersAchievement of strategic dates and milestonesHigh cost of failureDirect impact on financial performance: revenue, operating expenses, write-downs etc.


Understanding Enterprise Architecture


Enterprise Architecture is commonly confused with Software, Application or System architecture


TOGAF is the most widely accepted definition of Enterprise ArchitectureTOGAF = The Open Group Architecture FrameworkThe Open Group is a global consortium that enables the achievement of business objectives through IT standardsBesides TOGAF: UNIX, Trusted Technology and many othersTOGAF provides:ADM (Architecture Development Method): a process description• From architecture capability to overseeing implementation• Including R&R of who should do what, when, howArchitecture Content Framework and Enterprise Continuum• Artifacts, deliverables and templates for the ADM processes• Including content management for reuse and future evolutionReference models• Solution taxonomy and semanticsArchitecture Capability Framework• Skills, maturity models, governance principles and best practices


Source: TOGAF 9.1 chapter 34: Content metamodel

The TOGAF content metamodel lists all the key elements of Enterprise Architecture

Metamodel Entity DescriptionActor 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

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.

Assumption 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.

Business Service Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.

Capability 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.

Constraint 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.

Contract An agreement between a service consumer and a service provider that establishes functional and non-functional parameters for interaction.

Control 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.

Data Entity 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.

Driver 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.

Event 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.

Function Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. Also referred to as "business function".


85% of TOGAF metamodel is about business management and logical level blueprint

22

8

5

TOGAF content metamodel entities by typeBusiness Mgmt Logical blueprint Tech implementation

TOGAFcontentmetamodelentitiesbytypeBusinessmgmt Logicallevelblueprint TechimplementationActor Appliccomponent PhysappliccomponentAssumption DataEntity PhysdatacomponentBusinessservice Gap PhysteccomponentCapability Infoservicerequirement TechnologycomponentConstraint Logicalappliccomponent WorkpackageContract LogicaldatacomponentControl LogicaltechcomponentDriver PlatformserviceEventFunctionGoalLocationMeasureObjectiveOrgunitPrincipleProcessProductRequirementRoleServiceServicequality


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 codeSolution architecture: determine application configurationsSystem architecture: design the infrastructureEnterprise 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 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 roadmapSource: TOGAF 9.1 chapter 34.3.1: Content metamodel


The blueprint is a clear, consistent, actionable, implementation-independent description of the functions, processes, information and systems needed to achieve the objectives


A generalized view of the blueprint and its usage

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.

• This works both ways: for example a technical constraint insystem architecture can be easily and precisely rolled back to class diagram change -> sequence diagram change -> impact on use cases and requirements

Architectureblueprint

RequirementsFunctionalmodel

Processmodel

Informationmodel

Systemarchitecture

Implementationprojects

Usecasediagram

Sequencediagram

ClassdiagramTextlist

Componentdiagram

Projectcharter

Dashedarrowsshowdependencies:[source]needssomethingfrom[target]

Goals,roles,stakeholders

Whatdataisneededbywhom,andhow

Constraints,businessrules

Constraints,qualities

Informationandmessagesneededtoenableprocesses

Blueprintandroadmap(projectdeliverables,scheduleanddependencies)


Scope,goals,metrics,qualitites

(UML package diagram)


Many excellent free (or almost-free) UML modeling tools support this way of using the blueprint

WhiteStarUML

Papyrus UML

Sparx Enterprise Architect


This usage of the blueprint is equivalent to TOGAF ADM phases

Architectureblueprint

RequirementsFunctionalmodel

Processmodel

Informationmodel

Systemarchitecture

Implementationprojects

Usecasediagram

Sequencediagram

ClassdiagramTextlist

Componentdiagram

Projectcharter

Dashedarrowsshowdependencies:[source]needssomethingfrom[target]

Goals,roles,stakeholders

Whatdataisneededbywhom,andhow

Constraints,businessrules


Informationandmessagesneededtoenableprocesses

Blueprintandroadmap(projectdeliverables,scheduleanddependencies)


Scope,goals,metrics,qualitites

Equivalent


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

Work Product

Work Product

Work Product

Capability

Work Product

Work Product

Work Product

MILESTONEMILESTONE

Work Product

Work Product

Work Product

Capability

Capability

MILESTONE

Capability

MILESTONE


For more insights see this great presentation on YoutubeThe Open Group – EA and lessons learned in e-Government: Paris, October 24, 2016EA is not ITEA is explicit knowledge of the enterprise and rigorous planningThe goal of EA is to understand:• Where are we• Where do we want to be• How do we get thereIT 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 relatedEA best practicesBusiness managers are responsible to make some decisionsand 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

https://youtu.be/RzGHdjxnB9c?list=PL4uhUsJo0STlTeUA6HAy5xNBLWGbxqWVC


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 3rd 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 Requirementso 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)


ENTERPRISEARCHITECTUREARTIFACTS

Scopedefinition

(PhaseA)

Functionalmodel

(PhaseB)

Inform

ationmodel

(PhaseBandC)

Systemarchitecture

(PhaseC)

Infrastructurearchitecture

(PhaseD)

Workpackages,schedule,

SOWs(PhaseEtoH)

WidescopecoveringmanydiversedomainsComplexprocessesandsystemswithmultiplecross-dependencies

Deepintegrationwith3rdparties

Compromisebetweenconflictinggoals/requirements/metricsDealingwiththeunknownandtheunpredictable

Greattimepressure

Highcostoffailure

SCMCHA

LLEN

GES

EA artifacts support all Supply Chain challenges• What we want to achieve• Who should decide, who just

consulted (governance) • Consensus between many

different parties/priorities

• What we want to achieve• Who should decide, who just



• What we want to achieve• Who should decide, who just



• Reuse architectural assets• Sponsorship, resource /

budget commitment between different parties

• Ensure no gaps/overlaps

• Sponsorship, resource / budget commitment

• Harmonize requirements, constraints

• Risk mitigation

• Who does what, how R&R need to change

• Validate process suitability and feasibility

• Identify process constraints

• Efficient, effective, actionable negotiation with suppliers, customers, Government

• Invent new mechanisms• Find workarounds• Quantify responsibilities• Written record of

agreements

• Identify and resolve process gaps, overlaps

• Modify processes quickly in response to unexpected requirements / constraints

• Reuse architectural assets• No surprises during

implementation, testing, go-live

• Fast user training

• Everyone understands exactly operating model and responsibilities

• No arguing or improvisation after go-live

• Document domains and terminology

• Resolve ambiguous, contradicting concepts

• Improve x-functional communication

• Validate business process integration

• Achieve full process / IT system consistency

• Effective business process integration

• Maintain process / IT system consistency (including 3rd

parties)

• Resolve complex process problems at right level of abstraction (domain dictionary)

• Introduce new concepts and solutions

• Identify information gaps, overlaps

• Modify data models quickly in response to unexpected requirements / constraints

• Logical data model ensures high quality / fully aligned business and IT architecture

• Easier, faster, trouble-free implementation

• Application architecture based on processes, requirements and constraints with traceability to strategy / goals

• Clear definition of messages, interfaces, datastores well aligned with x-functional processes, requirements, constraints

• Reuse architectural assets• Fast decision on vendor

choice / RFP / RFQ and award criteria; fast, trouble-free implementation

• Validation that the application architecture will meet process requirements

• Robust solutions that quickly scale to high volume

• Validation that the system topology and sizing will meet process requirements and constraints

• Validation that the system topology and sizing will meet process requirements and constraints

• Reuse architectural assets• Early identification of

hardware procurement and physical changes to existing infrastructure

• Coordinate different teams with clear, unambiguous documentation of who does what for implementation

• Everybody has the same understanding of targets

• Coordinate different teams with clear, unambiguous documentation of who does what for implementation

• Everybody has the same understanding of targets

• Dependency diagram / Gantt / Blueprint support quick risk mitigation or adoption of new requirements / constraints

• Faster, trouble-free implementation projects with clear targets

• No unexpected dependencies slowing down progress

• Good program / project quality assurance / risk mitigation

• Manage vendor performance with SOW and signed off blueprints


– 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

The blueprint and roadmap are critical for project planning, project definition and governanceArtifacts are critical to:

Discuss goals andcontext withstakeholders

Decide engagementmodel and methodology

customization

Define governanceprocess

Review current/futureprojects that could

create dependencies

Determinescope,developmentapproach and timing

Review repositoryof building blocks

Understand whatrequirements can be

implemented and what not

• 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 signoffIf 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

• Identify all stakeholders and viewpoints: what is obviousto one party may be not be noticed by another

VISI

ON P

HASE

Impact of Vision Phase in typical Supply Chain project

Plan

ning

pha

sePL

ANNI

NG P

HASE

Signoff projectcharter

Agree level of effort andsign contract withbusiness partners

Determine whichmigration strategy hasless risks and impact

Def

initi

on p

hase


The blueprint and roadmap reduce the time, cost and risk of Supply Chain projects and maximize benefitsThe logical level blueprint and its roadmap change project approach from ‘case-by-case’ to ‘controlled evolution’


The blueprint and roadmap change projects from ‘case-by-case’ to ‘controlled evolution’Provide a common language to coordinate implementation of processes, data and systemsMinimize duplicate processes / data / systems that impact referential integrity and scalabilityIdentify and manage functional / IT dependencies (including 3rd parties)Reduce system interfaces; minimize chance of things going wrongImprove flexibility to evolve

Critical input for project managementDefine 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 solutionsDefine test plans, test datasets / procedures, acceptance criteria


End of presentation

2. richard-ea for supply chain - · pdf filesenior supply chain architect (togaf 9.1 certified...

Documents