Transcript www.irmac.ca

Presentation to IRMAC
Use of the Zachman Framework
for Enterprise Architecture
and
Business Architecture
July 21, 2015
(C) Chartwell 2001
1
Agenda
• Introduction
• Enterprise Architecture
–
–
–
–
–
Enterprise Architecture Context
Examples of Architectural Models
Two interpretations of Enterprise Architecture
Implementing an Architecture program
Zachman and Enterprise Architecture
• Business Architecture
–
–
–
–
Business Architecture in Ontario Public Sector
Key Business Artifacts
The Business Architecture Function
Business Architecture Implementation
• Conclusion
• Q&A
July 21, 2015
(C) Chartwell 2001
2
INTRODUCTION
July 21, 2015
(C) Chartwell 2001
3
About Us
• Sandy McBride
– Chartwell Partner
– Architecture Practice Leader
– 20+ years in IT
• John Bruder
– Senior Consultant
– 15+ years in IT
– Business Architecture practitioner
July 21, 2015
(C) Chartwell 2001
4
About Chartwell
• Founded in 1984
• Initial focus - Information Resource
Management
• Evolution:
– IT Strategic Planning
– Business Modeling….Business Architecture
– Information, Application and Technology
Architecture
July 21, 2015
(C) Chartwell 2001
5
About Chartwell
• Evolution (cont’d)
– IT Methods, Standards, Tools
– IS High Performance Program
•
•
•
•
IT Function - Organization and Job Design
IT Function - Process Improvement
IT Function - Performance Management
IT Function - support systems & tools
– Business Intelligence services
– Application Integration services
– Program Management services
• Future
– IT investment portfolio management
July 21, 2015
(C) Chartwell 2001
6
Enterprise Architecture
Context
July 21, 2015
(C) Chartwell 2001
7
IT Planning and Architecture
in Context
Business
Planning
ALIGNMENT
Business
Architecture
IMPACT
SCOPE
IT Strategic
Planning
Automation
Architectures
REFINEMENT
July 21, 2015
(C) Chartwell 2001
IT Systems
& Technology
Delivery
8
Traditional automation barriers
Change
- methods
- tools
- skills
- data
Change
- methods
- tools
- etc.
Again
Operation
Construction
Representation
July 21, 2015
(C) Chartwell 2001
9
Technical promise of architecture:
the model is the enterprise
Operation
Construction
Representation
July 21, 2015
(C) Chartwell 2001
10
Business promise of architecture
“When people understand the vision
and larger tasks of their enterprise,
and are given the right information,
resources and responsibilities,
they will ‘do the right thing!’”
- W. C. Hansen The Integrated Enterprise
July 21, 2015
(C) Chartwell 2001
11
The “architecture” of a
complex thing:
•
•
•
•
Its essential structure
Its overall design
The orderly arrangement of its parts
The way its components fit together
Architecture consists of the pieces of the puzzle!
Design is the picture on the puzzle box!
July 21, 2015
(C) Chartwell 2001
12
Architect vs. Designer
• Defines a formal model to
represent the whole problem
space
• Solves a problem in the
problem space
• “Populates” the model to
define the problem space
architecture
• Uses the architecture to
create a design
• Defines logical constraints design standards, rules, etc.
• Is “whole system forever”
oriented
July 21, 2015
• Works within constraints
• Is problem and solutionoriented
(C) Chartwell 2001
13
Architectures achieve success
by enabling design success
Examples
Alignment Goals
Integration Goals
(common ends)
Align automated
capabilities with business
needs
(common means)
Build multi-purpose
components, e.g.
“integrated financial
system”
Work Design
Align accountabilities,
processes, motivations,
performance measures,
etc. with business goals
Create multi-purpose
processes, resources,
roles, e.g. “one-stop, one
window service”
Policy/Strategy
Design
Align social/business
goals and services with
public/market needs
Develop multi-service
concepts, e.g. “treat the
person, not the disease”
Automation Design
July 21, 2015
(C) Chartwell 2001
14
Recognized realms of
architecture
(Key parts needing orderly arrangement)
• Information (data entities)
• Applications (business logic)
Automation
• Technology (technology components) Architectures
– Network (network technology components)
• Security (security components)
• Business (processes)
– Work (processes)
– Organization (roles & responsibilities)
– Policy (business rules)
July 21, 2015
(C) Chartwell 2001
Business
Architecture
15
Examples of Architectural
Models
July 21, 2015
(C) Chartwell 2001
16
Model of a problem space, e.g
a public sector agency
Provider
Organizations
Governance
Outcomes
Client
Organizations
Accomplish
Roles
Accountability
Responsibility
Authority
July 21, 2015
Deliver
Outputs
Individual
Clients
Used
in
(C) Chartwell 2001
17
Populating the model to create a fragment
of the “process architecture”
Plan
Project Demand for Human Resources
Define Objectives & Strategies for Management
Define Position Specifications
Define Performance Targets
Define Resources Required for Management
Acquire
Develop Job Requirements
Develop Job Qualifications
Recruit
Negotiate Job Performance Contract
Offset Risks Related to Work
Use
Assign to Job
Record Activities
Pay
Develop Skills
Counsel
Recognize Achievements
Mediate Contract Dispute
Account for Utilization
Transfer
Terminate
Dispose
July 21, 2015
(C) Chartwell 2001
18
Clients
Needs
Strategy/Policy
Realm
Services
Processes
Resources
Work
Realm
Organization
Workflow
Roles
Automation
Realm
Locations
Applications
Domains
Another model of a
public sector
enterprise
July 21, 2015
Nodes
Databases
(C) Chartwell 2001
Interfaces
Infrastructure
Components
19
A Private Sector Enterprise Model
Business
Goals
Business
Trends
Business
Strategies
Markets/
Clients
Business
Plans
Processes
Services/
Products
Resources
Workflow
Domains
Applications
Nodes
Roles
Target
Architectures
July 21, 2015
Locations
Information
Subjects
Suppliers
Organization
Business
Model
(extended)
(C) Chartwell 2001
Databases
Interfaces
Infrastructure
Components
20
Technology Integration Model
“a structure for classifying and selecting the real-world products and technologies the
enterprise will use to construct its systems”
Systems Components and Services
Security Services
Systems Management
Application
and Data
Presentation
Logic
Presentation
Services
Infrastructure
Services
Business Logic
Application
Services
Data
Data
Services
Distributed Services
(Middleware)
Network
Base
Platforms
System Software
Hardware
July 21, 2015
(C) Chartwell 2001
21
Future State Technology Architecture:
Patterns and Architectures - Meta Group
“Starter Kit”
Start with ……...
Transact Patterns
1-Tier Transact
Publish Patterns
Collaborate Patterns
Client/Server Publish
Real-Time Collaborate
Text, Audio, Video Stream
Screens and
Keystrokes
Rows (SQL)
Client
Server
Client
Data Server
Client
Server
?
Web Publish
2-Tier Transact
Rows (SQL)
Client
Server
Store and Forward Collaborate
Documents, Files
Web
Server
Client
TBD
Files,
Rows
Pages
Client
Data Server
Client
Client
Data Server
TBD
3/N-Tier Transact
Client
Audio/Video
Stream
Server
Server
Done
July 21, 2015
Stream Publish
Rows
(SQL)
Requests
TBD
Client

Server
Structured Collaborate
Documents, Files
Files
Data Server
Client
Client
App/Data Server
TBD
…...….
(C) adapt
Chartwell to
2001support your business
TBD
22
Two Interpretations of
Enterprise Architecture
July 21, 2015
(C) Chartwell 2001
23
Two interpretations of
enterprise architecture
• Enterprise-wide technology architecture
(EWTA)
– “Business” architecture serves automation
needs
• Architecture of the enterprise (EA)
– Business architecture serves business
needs as well as automation needs
July 21, 2015
(C) Chartwell 2001
24
What is EWTA trying to
accomplish?
• More responsive automation services through
better engineering of parts and components
– Re-usable components (lower cost, higher quality,
faster time to service, longer life in service)
• More effective automation
– Rapid and continual re-alignment of systems
capabilities as business needs change
• More automation
– Automation playing larger and larger role in
business operations
July 21, 2015
(C) Chartwell 2001
25
What is EA trying to
accomplish?
• More agile enterprise through engineering of
parts for re-use and multi-use
– E.g. know-how, policies, processes, organization
structure, roles, jobs, skills, etc.
• Better alignment of all business units with
common goals
• Better integration of all resources and
capabilities of all business units (not just
automation)
July 21, 2015
(C) Chartwell 2001
26
What are the drivers for architecture?
Traditional
•Exploding investment
in technology
EWTA
•Life cycle cost
•Inflexibility
•High cost and risks of
dis-integrated
EA information
•Responsiveness to
change
July 21, 2015
New
•Exploding complexity
of technology
•Proliferation of
technology
•eBusiness
•eCommerce
•ESD
(C) Chartwell 2001
27
Portal rule-of-thumb
90 day release
cycle for database
changes
July 21, 2015
30 day release
cycle for portal
changes
60 day release
cycle for workflow
(C) Chartwell changes
2001
28
Implementing an Architecture
Program
Key Considerations
July 21, 2015
(C) Chartwell 2001
29
Architecture Development Approaches
• Top Down
– Enterprise-wide IT Strategic Architecture
Planning
• Incremental
– Develop Architectures as part of major ITenabled change initiatives
July 21, 2015
(C) Chartwell 2001
30
Enterprise Architecture Process
Model
Architectural Methodology
Environmental
Environmental Trends
Trends
Organize
Organize
Arch.
Arch.
Effort
Effort
Business
Business
Visioning
Visioning
Define/
Define/
Refine
Refine
EBA
EBA
D?
Define/
Define/
Refine
Refine
EIA
EIA
D?
Define/
Define/
Refine
Refine
EWTA
EWTA
D?
Document
Document Current
Current Environment
Environment
• Change Projects
• Information Projects
• Application Projects
• Technology Projects
Implementation
Implementation
Planning
Planning
Define/
Define/
Refine
Refine
EAP
EAP
D?
Gap
Gap
Analysis
Analysis
Migration
Migration
Planning
Planning
Enterprise Architecture Governance and Evolution, Organizational Impact, & Communication
The process model provides the framework for
reconciling standards efforts and enterprise initiatives
9
© 2000 META Group Inc., Stamford, CT, (203) 973-6700,
metagroup.com
July 21, 2015
(C) Chartwell 2001
31
General governance model for change
initiatives Directional
Coherence
Strategic
Planning
Enterprise
Architecture
Design
Coherence
July 21, 2015
Project
Projects Management
(Office)
Logistics
Coherence
(C) Chartwell 2001
32
Services of an operational
architecture function
•
•
•
•
•
•
•
Supply standards & guidelines for designers
Supply re-usable components for designers
Supply design assistance
Provide awareness & training to business and IT
Supply methods & tools for designers
Provide quality assurance and compliance testing
Provide stewardship of the architectures and designs
(repository services)
July 21, 2015
(C) Chartwell 2001
33
Architecture compliance process
Project Context,
Objectives & Scope
Identify component overlaps and linkages
with other projects
Conceptual Design
Project demonstrates alignment of
business and automation design
Logical Design
Project demonstrates integration of
business and automation design
Physical Design
Project demonstrates efficiency of design
Implementation
Project demonstrates effectiveness of
design (or lessons learned)
July 21, 2015
(C) Chartwell 2001
34
Critical questions…
• Where are the architect’s sources of authority
for standards and approaches?
– i.e. “commonly accepted architecture procedures”
• Where are the architect’s sources of authority
for the architecture once created?
– Sponsorship
– Artifact ownership and management
July 21, 2015
(C) Chartwell 2001
35
Zachman and Enterprise
Architecture
July 21, 2015
(C) Chartwell 2001
36
ENTERPRISE ARCHITECTURE - A FRAMEWORK
DATA
What
FUNCTION
How
NETWORK
Where
PEOPLE
Who
TIME
When
TM
MOTIVATION
Why
SCOPE
(CONTEXTUAL)
List of Things Important
to the Business
List of Processes the
Business Performs
List of Locations in which
the Business Operates
Planner
ENTITY = Class of
Business Thing
Function = Class of
Business Process
Node = Major Business
Location
e.g. Semantic Model
e.g. Business Process Model
e.g. Business Logistics
System
Ent = Business Entity
Reln = Business Relationship
Proc. = Business Process
I/O = Business Resources
Node = Business Location
Link = Business Linkage
e.g. Logical Data Model
e.g. Application Architecture
e.g. Distributed System
Architecture
e.g. Human Interface
Architecture
e.g. Processing Structure
Ent = Data Entity
Reln = Data Relationship
Proc .= Application Function
I/O = User Views
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
People = Role
Work = Deliverable
Time = System Event
Cycle = Processing Cycle
End = Structural Assertion
Means =Action Assertion
TECHNOLOGY
MODEL
(PHYSICAL)
e.g. Physical Data Model
e.g. System Design
e.g. Technology Architecture
e.g. Presentation Architecture
e.g. Control Structure
e.g. Rule Design
TECHNOLOGY
MODEL
(PHYSICAL)
Builder
Ent = Segment/Table/etc.
Reln = Pointer/Key/etc.
Proc.= Computer Function
I/O = Data Elements/Sets
Node = Hardware/System
Software
Link = Line Specifications
Time = Execute
Cycle = Component Cycle
End = Condition
Means = Action
Builder
e.g. Data Definition
e.g. Program
e.g. Network Architecture
Ent = Field
Reln = Address
Proc.= Language Stmt
I/O = Control Block
Node = Addresses
Link = Protocols
People = Identity
Work = Job
e.g. DATA
e.g. FUNCTION
e.g. NETWORK
e.g. ORGANIZATION
ENTERPRISE
MODEL
(CONCEPTUAL)
Owner
SYSTEM
MODEL
(LOGICAL)
Designer
DETAILED
REPRESENTATIONS
(OUT-OFCONTEXT)
SubContractor
FUNCTIONING
ENTERPRISE
List of Organizations
Important to the Business
List of Events Significant
to the Business
List of Business Goals/Strat
People = Major Organizations
Time = Major Business Event
Ends/Means=Major Bus. Goal/
Critical Success Factor
e.g. Work Flow Model
e.g. Master Schedule
e.g. Business Plan
Time = Business Event
Cycle = Business Cycle
End = Business Objective
Means = Business Strategy
People = Organization Unit
Work = Work Product
People = User
Work = Screen Format
e.g. Security Architecture
e.g. Timing Definition
Time = Interrupt
Cycle = Machine Cycle
e.g. SCHEDULE
e.g., Business Rule Model
e.g. Rule Specification
SCOPE
(CONTEXTUAL)
Planner
ENTERPRISE
MODEL
(CONCEPTUAL)
Owner
SYSTEM
MODEL
(LOGICAL)
Designer
DETAILED
REPRESENTATIONS
(OUT-OF
CONTEXT)
SubContractor
End = Sub-condition
Means = Step
e.g. STRATEGY
FUNCTIONING
ENTERPRISE
John A. Zachman, Zachman International (810) 231-0531
July 21, 2015
(C) Chartwell 2001
37
The Zachman Framework classifies the details
of an underlying model of the enterprise into an
enterprise architecture.
Governance
Outcomes
Provider
Organizations
The Public
Accountability
Roles
Individuals &
Organizations
Outputs
Responsibility
Authority
Business Architecture
Information & Technology
Architectures
Needs
Clients
Services
Processes
Resources
Business architecture drives automation architectures
Artifact standards guide architecture development
Transformation standards maintain architectural integrity
July 21, 2015
(C) Chartwell 2001
Organization
Roles
Workflow
Locations
Applications
Domains
Nodes
Databases
Interfaces
Infrastructure
Components
38
More Zachman classification of IT
architectures
EIA
FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
CONTEXTUAL
Business Architecture
CONCEPTUAL
LOGICAL
Data
Architecture
PHYSICAL
COMPONENTS
FUNCTIONAL
July 21, 2015
(C) Chartwell 2001
39
More Zachman classification of IT
architectures
EIA
FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
CONTEXTUAL
Business Architecture
CONCEPTUAL
LOGICAL
PHYSICAL
Application
Architecture
COMPONENTS
FUNCTIONAL
July 21, 2015
(C) Chartwell 2001
40
More Zachman classification of IT
architectures
EIA
FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
CONTEXTUAL
Business Architecture
CONCEPTUAL
LOGICAL
PHYSICAL
Technology
Architecture
COMPONENTS
FUNCTIONAL
July 21, 2015
(C) Chartwell 2001
41
Zachman Framework does not prescribe
sequence of Architecture Development
- Slivers and Slices
EIA
FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
CONTEXTUAL
CONCEPTUAL
LOGICAL
PHYSICAL
COMPONENTS
FUNCTIONAL
July 21, 2015
= slice
(C) Chartwell 2001
= sliver
42
Business Architecture
July 21, 2015
(C) Chartwell 2001
43
What is Business Architecture
• A formal way of describing the key components of your business
(current or future) and their relationships
– Sample components include:
• Services, Products, Markets, Processes, Resources, Organization,
Performance Measures, Locations, Business Cycles
– Sample relationships include:
• Services to processes (value chain)
• Processes to organization (role-responsibility)
• Simplifies the understanding of an enterprise by breaking it
down into manageable chunks and relationships
• An asset: an authoritative source of business knowledge that is
used by many parties for different purposes
July 21, 2015
(C) Chartwell 2001
44
Business Architecture versus
Zachman Framework
EIA
FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
CONTEXTUAL
Business Architecture
CONCEPTUAL
LOGICAL
PHYSICAL
Each cell contains one more
specified artifacts
COMPONENTS
FUNCTIONAL
July 21, 2015
(C) Chartwell 2001
45
Artifact Definitions
• One or more artifacts must be specified for
each cell in row 1 and row 2
– Based on general business metamodel
• Artifact specifications and standards include
–
–
–
–
Format of artifact (e.g. indented list, matrix, map)
Description, Purpose
Inclusion Criterion
Profile information
July 21, 2015
(C) Chartwell 2001
46
Business Architecture in
Ontario Public Sector
July 21, 2015
(C) Chartwell 2001
47
Ontario Public Sector Business
Architecture
• 1996 OPS formulated shared services strategy and common
approaches I.e. technical components
• Key recommendation was to address IT architecture on OPSwide basis
• 1997-1998 early work was done, decision to use Zachman
framework
• Chartwell was selected to lead the development of the
application of the Zachman framework to OPS
– Definition of all architectural deliverables
– Overall architectural process - methods , governance
– Developing “shared” and “common” content for many aspects of the
architectures
July 21, 2015
(C) Chartwell 2001
48
Ontario Public Sector Business
Architecture
• Chartwell has since led several OPS
business architecture assignments including:
–
–
–
–
–
–
Ministry of Education
Water Management Architecture
Integrated Service Delivery
Recorded Information Management
Office of the Public Guardian
Ministry of Health
July 21, 2015
(C) Chartwell 2001
49
Key Business Artifacts
July 21, 2015
(C) Chartwell 2001
50
Public Sector Row 1 & 2 Artifact Examples
What? (Column 1)
Who? (Column 4)
– Row 1
– Row 1
•
•
•
–
Resource Types
Row 2
•
–
Semantic Model
•
– Row 1
Programs / (Markets - Line of
Business)
Services / (Product Lines)
•
•
Process Model (Value Chain)
Where? (Column 3)
Master schedule
Why (Column 6)
– Row 1
– Row 1
•
•
Business Cycles and Events
– Row 2
– Row 2
•
Workflows
When? (Column 5)
– Row 1
•
Row 2
•
How? (Column 2)
Roles
Individuals and Orgs.
•
•
•
Locations
Geographic Areas
Client Needs
Mandate, Strategy, Goals
Statutes
– Row 2
– Row 2
•
•
July 21, 2015
Logistics Model
(C) Chartwell 2001
Performance Model
51
Meta-Model of Public Sector
Key Artifacts
Provider
Organizations
Governance
Outcomes
Client
Organizations
Accomplish
Roles
Accountability
Responsibility
Authority
July 21, 2015
Deliver
Outputs
Individual
Clients
Used
in
(C) Chartwell 2001
52
Key Artifact
Programs (Row 1, Column 2)
• Programs specification includes:
–
–
–
–
–
Target group
Target group needs
Government goals
Strategy Model
Program Accountability
• Programs create context for service delivery and design
• Programs can be grouped together based on affinity between
target groups and needs
• Program concept is very close to private sector concept of line
of business focused on a target market
July 21, 2015
(C) Chartwell 2001
53
Target Group
“Hierarchy”
Individuals
Needs “Hierarchy” Strategy Policy Model
Safety
Prevention:
Focus on abuser
Women
Freedom from
Violence
Treatment:
Focus on victim
Abused
Women
Freedom from
Domestic Violence
Abused Women Program
Program attaches social mandates
in terms of will of the electorate to
address this need, and social goal
in terms of trends in level of need
in target group.
July 21, 2015
(C) Chartwell 2001
Goals
Reduced frequency of
abuse recurrence
Services
Housing
Financial assistance
Counseling
Vocational skills training
54
Enterprise Context for Public Services
LEGACY VIEW
“Service
Provider”
Ontario
Government
“OPS” View
Public
Services
“Service
Consumer”
Partner
Agent
“Service
Provider”
Public
Services
“Partner” View
The Public
“Service
Consumer”
TARGET VIEW
Ontario Government
&
Partners & Agents
“Service
Provider”
July 21, 2015
Public
Services
(C) Chartwell 2001
The Public
“Public
Clients”
55
Key Artifact
Public Service (Row 1, Column 2)
Public Services :
•
•
•
•
•
Provides a discrete, measurable deliverable to a public client
Provides perceived value to a public client
It is independent of other public services
Is not administrative in nature
Does not provide support to an internal party (Ministry staff,
other ministries, etc.)
• Public services are “classified” under standard patterns to
support “pattern discovery” across Ministry and program
boundaries
• Note: We make a distinction between public services and
“internal services”
July 21, 2015
(C) Chartwell 2001
56
Public Service Specification
Public service specification includes:
•
•
•
•
Service Name
Service description
Service delivery unit
Associated roles:
– Client, Delivery partner, stakeholders
• Performance metrics
– Quality, Efficiency, Effectiveness
July 21, 2015
(C) Chartwell 2001
57
Service Example
• Name:
Abused women housing provision
• Description:
The abused women housing provision service
provides temporary housing for women escaping domestic violence
• Delivery Unit: One placement
• Associated Roles:
– Client - abused woman (links to program)
– Delivery Partner - housing provider
• Performance Metrics
– Unit cost per placement (efficiency)
– Provision compared to standards (quality)
– Impact of housing placement on overall abuse statistics
(effectiveness)
July 21, 2015
(C) Chartwell 2001
58
Program/Service Relationships
Program A
Program B
Service 1
A service contributes to a program’s goals by providing a valuable output
to eligible members of the program’s recognized target group, meeting a
recognized need. Well-designed services meet multiple needs of multiple
target groups in multiple programs.
July 21, 2015
(C) Chartwell 2001
59
Internal Services are Consumed by
Internal Customers
Systems Services
Human Resources Services
Financial Services
Internal Services observe the Service Output Principle
but service outputs always relate to types of resources!
July 21, 2015
(C) Chartwell 2001
60
Key Artifact
Public Service process models
(Row 2, Column 2)
• Process model identifies key processes associated with
services
• Types of processes included with services include:
–
–
–
–
Planning
Acquisition
Use (Customer contact / delivery)
Monitoring & Managing
• A public service provider may outsource one or more of these
processes
• Services of “like-type” tend to have common patterns e.g.
training service, commodity distribution
– The use of these patterns supports creating quick “strawmen”
supporting “edit mode” with client
July 21, 2015
(C) Chartwell 2001
61
Service Value Chain Example
(Row 2, Column 2)
Personal Care Provision
Use
Plan
–
–
–
–
Project demand
Define service objectives & strategies
Define service performance targets
Define resource requirements
Acquire
–
–
–
–
–
–
–
–
–
Receive request for personal care
Qualify request
Open case
Assess personal care case rqts
Assign resources to case
Develop / modify personal care schedule
Schedule appointments
Provide personal care
Process complaints attributed to service
– Determination of qualified personal
care provider
– Develop service delivery schedule
– Allocate resources to delivery
Monitor
schedule
– Notify clients of service delivery
– Monitor service performance
schedule
– Monitor achievement of service objectives
– Promote personal care service
– and strategies
– Offset risks attributed to personal care
July 21, 2015
(C) Chartwell 2001
62
Key Artifact
Performance Model Example (row 2, Col 6)
Metric
Def’n
Workplace
Program
Safety
Service
Process
Efficiency
Measures
Quality
Measures
Effectiveness
Measures
Output Value
Input Cost
Comparison
to Standards
Contribution
to Higher Goal
Total cost
per capita
Meeting public
expectations
Workplace
safety
trends
Certification
accuracy &
timeliness
Compliance
Capacity
& Accident
trends
Average cost
per site visit
Site visit
completeness &
timeliness
Capacity
SiteCapacity
visiting
capabilities
System cost
per accident
reported
System
accuracy &
timeliness
Safety
Average cost
Certification per certification
Site Visit
Resource Accident
Reporting
System
July 21, 2015
(C) Chartwell 2001
Capacity
Capacity
System
Capacity
capabilities
63
Program
Measures
Service
Performance Measures
Process Performance Measures
Resource Performance Measures
Business Architecture Provides Common
Framework For Performance Measurement
July 21, 2015
(C) Chartwell 2001
64
Key Artifact
Semantic Model (Row 2, Col 1)
• Describes overall structure of domain
• Shows key relationships between artifacts
across columns
• Set foundation for common understanding
and data architecture
July 21, 2015
(C) Chartwell 2001
65
Key Artifact
Semantic Model (row 2, col 1)
Core
Businesses
(C6-Why)
Goals and
Strategies
(C6-Why)
provide
framework
for
GO
Organizations
(C4-Who)
define
nature of
responsible for
Rules
(C6-Why)
administer
Programs
(C2-How)
define
terms of
Resources
(C1-What)
fund
constrain
delivery of
Business
Cycles
(C5-When)
provided
at
trigger
delivery of
Business
Events
(C5-When)
found at
Services
(C2-How)
determine
timing of
Locations
(C3-Where)
address
provided
by
impact
Needs
(C6-Why)
experienced
by
Partners
(C4-Who)
Stakeholders
(C4-Who)
are involved
as
Clients
(C4-Who)
Organizations
(C4-Who)
deliver
services as
receive
services as
Individuals
(C4-Who)
July 21, 2015
(C) Chartwell 2001
66
The Business Architecture
Function
July 21, 2015
(C) Chartwell 2001
67
Value of Business Architecture
• Business Improvement
–
–
–
–
Supports impact assessment of change initiatives
Ensures integration of policy, work and automation design
Foundation for clarifying roles and responsibilities
Foundation for performance management
• Strategic and Operational alignment
– Common planning framework and language links all business areas
and functions
– Supports alignment of strategic and operational views
– Ensures flexibility for ongoing change
• IT planning and design
– Supports development of business-driven automation architectures
– Supports development of integrated applications and databases
July 21, 2015
(C) Chartwell 2001
68
Business Architecture - value
proposition - 1
• To the CIO business architecture supports:
– alignment of the IT function with the business
– identification of IT-enabled (and other) business
process improvement opportunities
– identification of data and application integration
opportunities
– identification of opportunities for IT to contribute to
business strategy, by extending the reach of the
enterprise
• e.g. electronic service delivery, electronic
supply chain
July 21, 2015
(C) Chartwell 2001
69
Business Architecture - value
proposition - 2
• To the executive responsible for an enterprise, or
for business integration, business architecture
integrates:
– Policy, program, line-of-business, service design
– Business process re-design
– Performance management model design
• Plus:
– Job design
– Organization design
July 21, 2015
(C) Chartwell 2001
70
Business Architecture Value
Proposition 3
• To a project manager responsible for
managing a large project
–
–
–
–
–
Project scoping and planning
Impact analysis
Project portfolio sequencing and analysis
Resource requirements
Library of reusable patterns
July 21, 2015
(C) Chartwell 2001
71
Business Architecture Links Strategic and
Operational Business Views
Strategic View
Who are we?
Enterprise
What
groups
do we
target?
Services
What
resources
are needed
What do
we deliver?
Alignment
What activities
are required to
deliver the service?
Who
does what?
Activities
Resources
Operational View
July 21, 2015
(C) Chartwell 2001
72
Business Architecture Supports Planning & Change
Management
Current Bus Arch.
Strategic
Plan and Define
Enterprise
Enterprise
Strategic Direction
Services /
Product Lines
Services /
Services
Product Lines
Requires
Requires
Operational
Target Bus Arch.
Design Build and Operate
Processes
Processes
Corporate Initiatives
Resources
Activities
Activities
Resources
Resources
July 21, 2015
Activities
Resources
Activities
Resources
Resources
(C) Chartwell 2001
73
Business Architecture Challenges
• The discipline of formal language e.g. services,
programs, clients
– Client may already have a ‘set of services’ defined
• Perception that business architecture “Slows things
down” and adds to cost
• Perception that architecture is technical and owned
by IT
• No generally accepted standards for business
architecture
• Business Architecture tends to be iterative and
ongoing
July 21, 2015
(C) Chartwell 2001
74
Critical Success Factors
• Both business and technical staff need to understand
the role of business architecture and business
architects
• Business needs to expect results, and technical staff
need to focus on the delivery of value from
architecture
• Acceptance that business architecture is an evolving
discipline
• Creation of strong alignment between business and
technical architecture
July 21, 2015
(C) Chartwell 2001
75
Enterprise Architecture
Organizational Capability Maturity Model
(CMM)
No
Standard
Framework
Independent
Project
Frameworks
MultiProject
Alignment
Change
Management
WideSpread
MultiProgram
Re-Use
•Business architecture exists in context of larger maturity model
• Business architecture and I&IT architecture capability
maturity may evolve at different rates
• Methodology maturity is also evolving
July 21, 2015
(C) Chartwell 2001
76
Business Architecture
Implementation
Key Considerations
July 21, 2015
(C) Chartwell 2001
77
Business Architecture Planning Considerations
– What constitutes the enterprise?
– Trade-off between top-down business architecture and change
initiative driven?
– Is focus on as-is model , or to-be , or both?
– What level of detail is required? Support for planning or design?
– Who are the primary stakeholders ? Sponsor?
– What documentation exists to support the process?
– What primary initiatives are being supported by business
architecture construction?
– What set of deliverables will be produced?
• Note: Not all artifacts are produced for each project
– What’s the discovery strategy?
July 21, 2015
(C) Chartwell 2001
78
Implementation Considerations
• Just Enough Architecture:
– High level architecture is good for planning and scoping
– Detailed architecture is required for implementation
– Zachman’s “slice and sliver” concept applies
• Just in Time Architecture:
– Prior to project or initiative (just in time), build detailed
business architecture to describe project domain and impact
of change
July 21, 2015
(C) Chartwell 2001
79
Primitives Versus Composites
Primitive Artifacts
Use of composites supports
primitive discovery
Needed to construct
composites
Composite Artifacts
•Are easily categorized into
Zachman framework
•Don’t contain any contextual
knowledge
•One type e.g. processes
•Are not easily categorized
into Zachman framework
•Represents contextual
knowledge
•Supports completeness
•Relates more than one type
of artifact e.g. workflow
(party, process, events)
July 21, 2015
(C) Chartwell 2001
80
Composite artifacts support the discovery
process
Program Profiling
EIA
FRAMEWORK
CONTEXTUAL
INFORMATION
PROCESS
Programs
NETWORK
Jurisdiction
Services
PEOPLE
TIME
RATIONALE
Target group
Goals
Clients,
Accountable
Orgs, Partners
Needs
Strategies
Performance
Metrics
Performance
Metrics
CONCEPTUAL
Service Profiling
July 21, 2015
(C) Chartwell 2001
81
Discovery Process is iterative between row 1
and row 2
EIA
FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
CONTEXTUAL
Row 1 artifacts are
used in row 2
Completion of row 2 confirms
/ extends row 1 artifacts
CONCEPTUAL
July 21, 2015
(C) Chartwell 2001
82
Conclusion
July 21, 2015
(C) Chartwell 2001
83
How do you know when your
architecture program has failed?
• When all funding remains on a project basis
• When the last time the architectures were
updated was the last strategic plan
• When IT complains about “red tape”
• When business sponsors don’t know about or
understand architecture role
• When head architect can’t point to concrete
business value added by architecture
July 21, 2015
(C) Chartwell 2001
84
Architecture success factors
• Set realistic goals for the architecture function
• Keep the architecture function close to real projects –
ideally joined to a PMO function
• Don’t be shy about the compliance role – use it to
educate
• Pay for good people
• Top of house for IT must sponsor EWTA
• Build a constituency for EA in business planning and
policy
• Be prepared to justify the value of architecture every
day forever
July 21, 2015
(C) Chartwell 2001
85
Questions and Answers
July 21, 2015
(C) Chartwell 2001
86