1. Presentation to IRMAC
Use of the Zachman Framework for Enterprise Architecture
and
Business Architecture
April 16, 2017
(C) Chartwell 2001

2. Agenda Introduction Enterprise Architecture Business 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
Introduction - 15 min
Sandy & John
Chartwell
Today’s Objectives
Context - EAP (20 min.)
Why an architecture
History (clients)
Architectures (business, applications, data, tech, security, organization) - integration issue
What makes a good architecture
Business Architecture (50 min)
methods
examples
Conclusions/Benefits (15 min.) - What you can do with a business architecture - what you can do with the Zachman Framework
How to implement the framework
Questions and Answers (30 min.)
April 16, 2017
(C) Chartwell 2001

3. INTRODUCTION
April 16, 2017
(C) Chartwell 2001

4. About Us Sandy McBride John Bruder Chartwell Partner
Architecture Practice Leader
20+ years in IT
John Bruder
Senior Consultant
15+ years in IT
Business Architecture practitioner
April 16, 2017
(C) Chartwell 2001

5. About Chartwell Founded in 1984
Initial focus - Information Resource Management
Evolution:
IT Strategic Planning
Business Modeling….Business Architecture
Information, Application and Technology Architecture
April 16, 2017
(C) Chartwell 2001

6. About Chartwell Evolution (cont’d) Future 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
April 16, 2017
(C) Chartwell 2001

7. Enterprise Architecture Context
April 16, 2017
(C) Chartwell 2001

8. IT Planning and Architecture in Context
Business
Planning
ALIGNMENT
Business
Architecture
IT Strategic
Planning
SCOPE
IMPACT
Automation
Architectures
IT Systems
& Technology
Delivery
REFINEMENT
April 16, 2017
(C) Chartwell 2001

9. Traditional automation barriers
Change
- methods
- tools
- etc.
Again
Change
- methods
- tools
- skills
- data
Operation
Construction
Representation
April 16, 2017
(C) Chartwell 2001

10. Technical promise of architecture: the model is the enterprise
Operation
Construction
Representation
April 16, 2017
(C) Chartwell 2001

11. 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
April 16, 2017
(C) Chartwell 2001

12. 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!
April 16, 2017
(C) Chartwell 2001

13. Architect vs. Designer
Defines a formal model to represent the whole problem space
“Populates” the model to define the problem space architecture
Defines logical constraints -design standards, rules, etc.
Is “whole system forever” oriented
Solves a problem in the problem space
Uses the architecture to create a design
Works within constraints
Is problem and solution-oriented
April 16, 2017
(C) Chartwell 2001

14. Architectures achieve success by enabling design success
Develop multi-service concepts, e.g. “treat the person, not the disease”
Align social/business goals and services with public/market needs
Policy/Strategy Design
Create multi-purpose processes, resources, roles, e.g. “one-stop, one window service”
Align accountabilities, processes, motivations, performance measures, etc. with business goals
Work Design
Build multi-purpose components, e.g. “integrated financial system”
Align automated capabilities with business needs
Automation Design
Integration Goals
(common means)
Alignment Goals
(common ends)
Examples
April 16, 2017
(C) Chartwell 2001

15. Recognized realms of architecture (Key parts needing orderly arrangement)
Information (data entities)
Applications (business logic)
Technology (technology components)
Network (network technology components)
Security (security components)
Business (processes)
Work (processes)
Organization (roles & responsibilities)
Policy (business rules)
Automation
Architectures
Business
Architecture
April 16, 2017
(C) Chartwell 2001

16. Examples of Architectural Models
April 16, 2017
(C) Chartwell 2001

17. Model of a problem space, e.g a public sector agency
Governance
Outcomes
Provider
Organizations
Client
Organizations
Accomplish
Authority
Accountability
Roles
Responsibility
Individual
Clients
Outputs
Deliver
Used in
April 16, 2017
(C) Chartwell 2001

18. 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
Dispose
Transfer
Terminate
April 16, 2017
(C) Chartwell 2001

19. Strategy/Policy Realm Work Automation Another model of a public sector
Needs
Clients
Services
Processes
Workflow
Organization
Roles
Locations
Domains
Nodes
Infrastructure
Components
Applications
Databases
Strategy/Policy
Realm
Automation
Another model of a
public sector
enterprise
Resources
Interfaces
Work
April 16, 2017
(C) Chartwell 2001

20. A Private Sector Enterprise Model
Business
Plans
Business
Goals
Business
Trends
Business
Model
(extended)
Business
Strategies
Processes
Workflow
Services/
Products
Locations
Markets/
Clients
Information
Subjects
Resources
Applications
Domains
Suppliers
Interfaces
Organization
Roles
Nodes
Target
Architectures
Databases
Infrastructure
Components
April 16, 2017
(C) Chartwell 2001

21. Technology Integration Model
“a structure for classifying and selecting the real-world products and technologies the enterprise will use to construct its systems”
Application and Data
Infrastructure Services
Base Platforms
Systems Management
Security Services
Presentation Logic
Business Logic
Data
Presentation Services
Application Services
Data Services
Distributed Services (Middleware)
Network
System Software
Hardware
Systems Components and Services
April 16, 2017
(C) Chartwell 2001

22. Future State Technology Architecture: Patterns and Architectures - Meta Group “Starter Kit”
Start with ……...
Transact Patterns
1-Tier Transact
2-Tier Transact
3/N-Tier Transact
Publish Patterns
Client/Server Publish
Web Publish
Stream Publish
Real-Time Collaborate
Store and Forward Collaborate
Structured Collaborate
Collaborate Patterns ?
TBD
TBD
TBD
META Group’s “starter” patterns are based on knowledge and experience of users that have implemented similar patterns
The fundamental pattern categories are based on the one characteristic that in our experience, has the most systemic impact on an application’s infrastructure: the way in which the application’s data is read, written, and shared.
TBD
TBD
Done
…...…. adapt to support your business
April 16, 2017
(C) Chartwell 2001
Pattern Thumbnail Legend

23. Two Interpretations of Enterprise Architecture
April 16, 2017
(C) Chartwell 2001

24. 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
April 16, 2017
(C) Chartwell 2001

25. 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
April 16, 2017
(C) Chartwell 2001

26. 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)
April 16, 2017
(C) Chartwell 2001

27. What are the drivers for architecture?
Traditional
New
eBusiness
eCommerce
ESD
High cost and risks of dis-integrated information
Responsiveness to change
Exploding complexity of technology
Proliferation of technology
Exploding investment in technology
Life cycle cost
Inflexibility
EWTA EA
April 16, 2017
(C) Chartwell 2001

28. Portal rule-of-thumb 90 day release cycle for database 30 day release
changes
30 day release
cycle for portal
changes
60 day release
cycle for workflow
changes
April 16, 2017
(C) Chartwell 2001

29. Implementing an Architecture Program
Key Considerations
April 16, 2017
(C) Chartwell 2001

30. Architecture Development - Approaches
Top Down
Enterprise-wide IT Strategic Architecture Planning
Incremental
Develop Architectures as part of major IT-enabled change initiatives
April 16, 2017
(C) Chartwell 2001

31. Architectural Methodology
Enterprise Architecture Process
Enterprise Architecture Process
Architectural Methodology
Model
Model
Environmental Trends
Environmental Trends
Environmental Trends
Organize
Organize
Organize
Business
Business
Business
Define/
Define/
Define/
Define/
Define/
Define/
Define/
Define/
Define/
Define/
Define/
Define/
Arch.
Arch.
Arch.
Visioning
Visioning
Visioning
Refine
Refine
Refine
Refine
Refine
Refine
Refine
Refine
Refine
Refine
Refine
Refine
Effort
Effort
Effort
EBA
EBA
EBA
EIA
EIA
EIA
EWTA
EWTA
EWTA
EAP
EAP
EAP D? D? D?
Document Current Environment
Document Current Environment
Document Current Environment
Gap
Gap
Gap
Analysis
Analysis
Analysis •
Change Projects •
Information Projects
Implementation
Implementation
Implementation
Migration
Migration
Migration •
Application Projects
Planning
Planning
Planning
Planning
Planning
Planning •
Technology Projects
Enterprise Architecture Governance and Evolution, Organizational Impact, & Communication
The process model provides the framework for
reconciling standards efforts and enterprise initiatives
© 2000 META Group Inc., Stamford, CT, (203) ,
metagroup
.com 9
April 16, 2017
(C) Chartwell 2001

32. General governance model for change initiatives
Directional Coherence
Projects
Logistics Coherence
Design Coherence
April 16, 2017
(C) Chartwell 2001

33. 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)
April 16, 2017
(C) Chartwell 2001

34. 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)
April 16, 2017
(C) Chartwell 2001

35. 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
April 16, 2017
(C) Chartwell 2001

36. Zachman and Enterprise Architecture
April 16, 2017
(C) Chartwell 2001

37. April 16, 2017
(C) Chartwell 2001 1

38. Business Architecture Information & Technology
The Zachman Framework classifies the details of an underlying model of the enterprise into an enterprise architecture.
The Public
Outcomes
Individuals &
Organizations
Outputs
Governance
Provider
Authority
Accountability
Roles
Responsibility
Business Architecture
Information & Technology
Architectures
Needs
Clients
Services
Processes
Workflow
Organization
Roles
Locations
Domains
Nodes
Infrastructure
Components
Applications
Databases
Resources
Interfaces
Business architecture drives automation architectures
Artifact standards guide architecture development
Transformation standards maintain architectural integrity
April 16, 2017
(C) Chartwell 2001

39. Business Architecture
More Zachman classification of IT architectures
EIA FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
Business Architecture
CONTEXTUAL
CONCEPTUAL
Data
Architecture
LOGICAL
PHYSICAL
COMPONENTS
FUNCTIONAL
April 16, 2017
(C) Chartwell 2001

40. Business Architecture
More Zachman classification of IT architectures
EIA FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
Business Architecture
CONTEXTUAL
CONCEPTUAL
Application
Architecture
LOGICAL
PHYSICAL
COMPONENTS
FUNCTIONAL
April 16, 2017
(C) Chartwell 2001

41. Business Architecture
More Zachman classification of IT architectures
EIA FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
Business Architecture
CONTEXTUAL
CONCEPTUAL
Technology
Architecture
LOGICAL
PHYSICAL
COMPONENTS
FUNCTIONAL
April 16, 2017
(C) Chartwell 2001

42. 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
= slice
= sliver
April 16, 2017
(C) Chartwell 2001

43. Business Architecture
April 16, 2017
(C) Chartwell 2001

44. 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
April 16, 2017
(C) Chartwell 2001

45. Business Architecture
Business Architecture versus Zachman Framework
EIA FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
Business Architecture
CONTEXTUAL
Each cell contains one more specified artifacts
CONCEPTUAL
LOGICAL
PHYSICAL
COMPONENTS
FUNCTIONAL
April 16, 2017
(C) Chartwell 2001

46. 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
April 16, 2017
(C) Chartwell 2001

47. Business Architecture in Ontario Public Sector
April 16, 2017
(C) Chartwell 2001

48. 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 OPS-wide basis
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
April 16, 2017
(C) Chartwell 2001

49. 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
April 16, 2017
(C) Chartwell 2001

50. Key Business Artifacts
April 16, 2017
(C) Chartwell 2001

51. Public Sector Row 1 & 2 Artifact Examples
Who? (Column 4)
Row 1
Roles
Individuals and Orgs.
Row 2
Workflows
When? (Column 5)
Business Cycles and Events
Master schedule
Why (Column 6)
Client Needs
Mandate, Strategy, Goals
Statutes
Performance Model
What? (Column 1)
Row 1
Resource Types
Row 2
Semantic Model
How? (Column 2)
Programs / (Markets - Line of Business)
Services / (Product Lines)
Process Model (Value Chain)
Where? (Column 3)
Locations
Geographic Areas
Logistics Model
April 16, 2017
(C) Chartwell 2001

52. Meta-Model of Public Sector Key Artifacts
Governance
Outcomes
Provider
Organizations
Client
Organizations
Accomplish
Authority
Accountability
Roles
Responsibility
Individual
Clients
Outputs
Deliver
Used in
April 16, 2017
(C) Chartwell 2001

53. 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
April 16, 2017
(C) Chartwell 2001

54. Target Group “Hierarchy” Needs “Hierarchy” Strategy Policy Model
Safety
Individuals
Prevention:
Focus on abuser
Freedom from
Violence
Women
Treatment:
Focus on victim
Abused
Women
Freedom from
Domestic Violence
Reduced frequency of abuse recurrence
Abused Women Program
Goals
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.
Services
Housing
Financial assistance
Counseling
Vocational skills training
April 16, 2017
(C) Chartwell 2001

55. Enterprise Context for Public Services
Ontario
Government
“Service Provider”
Partner
Agent
The Public
“OPS” View
“Service Consumer”
Public
Services
LEGACY VIEW
“Partner” View
Public
Services
The Public
TARGET VIEW
“Service Provider”
“Public Clients”
Ontario Government
&
Partners & Agents
April 16, 2017
(C) Chartwell 2001

56. 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”
April 16, 2017
(C) Chartwell 2001

57. 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
April 16, 2017
(C) Chartwell 2001

58. 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)
April 16, 2017
(C) Chartwell 2001

59. 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.
April 16, 2017
(C) Chartwell 2001

60. 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!
April 16, 2017
(C) Chartwell 2001

61. 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
April 16, 2017
(C) Chartwell 2001

62. Service Value Chain Example (Row 2, Column 2) Personal Care Provision
Use
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
Monitor
Monitor service performance
Monitor achievement of service objectives
and strategies
Plan
Project demand
Define service objectives & strategies
Define service performance targets
Define resource requirements
Acquire
Determination of qualified personal care provider
Develop service delivery schedule
Allocate resources to delivery schedule
Notify clients of service delivery schedule
Promote personal care service
Offset risks attributed to personal care
April 16, 2017
(C) Chartwell 2001

63. Key Artifact Performance Model Example (row 2, Col 6)
Efficiency
Measures
Output Value
Input Cost
Quality
Measures
Comparison
to Standards
Effectiveness
Measures
Contribution
to Higher Goal
Metric
Def’n
Workplace
Safety
Total cost
per capita
Meeting public
expectations
Workplace
safety
trends
Program
Capacity
Safety
Certification
Average cost
per certification
Certification
accuracy &
timeliness
Compliance
& Accident
trends
Service
Capacity
Capacity
Site Visit
Average cost
per site visit
Site visit
completeness &
timeliness
Site visiting
capabilities
Process
Capacity
Capacity
Capacity
Accident
Reporting
System
System cost
per accident
reported
System
accuracy &
timeliness
System
capabilities
Resource
April 16, 2017
(C) Chartwell 2001

64. Business Architecture Provides Common
Framework For Performance Measurement
April 16, 2017
(C) Chartwell 2001

65. 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
April 16, 2017
(C) Chartwell 2001

66. Key Artifact Semantic Model (row 2, col 1)
April 16, 2017
(C) Chartwell 2001

67. The Business Architecture Function
April 16, 2017
(C) Chartwell 2001

68. 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
April 16, 2017
(C) Chartwell 2001

69. 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
April 16, 2017
(C) Chartwell 2001

70. 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
April 16, 2017
(C) Chartwell 2001

71. 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
April 16, 2017
(C) Chartwell 2001

72. Business Architecture Links Strategic and Operational Business Views
Services
Enterprise
Markets - Line of Business
Resources
Activities
Organization
Strategic View
Operational View
Alignment
What do
we deliver?
Who are we?
What groups
do we
target?
What activities
are required to
deliver the service?
Who
does what?
What
resources
are needed
April 16, 2017
(C) Chartwell 2001

73. Corporate Initiatives
Business Architecture Supports Planning & Change Management
Target Bus Arch.
Resources
Processes
Organization
Requires
Services / Product Lines
Enterprise
Programs / Markets
Strategic Direction
Plan and Define
Current Bus Arch.
Strategic
Enterprise
Programs / Markets
Services / Product Lines
Services
Requires
Corporate Initiatives
Resources
Activities
Org.
Design Build and Operate
Operational
Resources
Processes
Organization
April 16, 2017
(C) Chartwell 2001

74. 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
April 16, 2017
(C) Chartwell 2001

75. 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
April 16, 2017
(C) Chartwell 2001

76. Enterprise Architecture Organizational Capability Maturity Model (CMM)No
Standard
Framework
Independent
Project
Frameworks
Multi-
Alignment
Change
Manage-
ment
Wide-
Spread
Program
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
No good, until I consider the alternatives
New flavour of the month
Pretend adopt stage
Better start serious resistance here
April 16, 2017
(C) Chartwell 2001

77. Business Architecture Implementation
Key Considerations
April 16, 2017
(C) Chartwell 2001

78. 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?
April 16, 2017
(C) Chartwell 2001

79. 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
April 16, 2017
(C) Chartwell 2001

80. Primitives Versus Composites
Primitive Artifacts
Are easily categorized into Zachman framework
Don’t contain any contextual knowledge
One type e.g. processes
Use of composites supports primitive discovery
Needed to construct composites
Composite Artifacts
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)
April 16, 2017
(C) Chartwell 2001

81. Composite artifacts support the discovery process
Program Profiling
Goals
Jurisdiction
Target group
Needs
Strategies
Performance Metrics
Programs
EIA FRAMEWORK
INFORMATION
PROCESS
NETWORK
PEOPLE
TIME
RATIONALE
CONTEXTUAL
Service Profiling
Clients, Accountable Orgs, Partners
Performance Metrics
Services
CONCEPTUAL
April 16, 2017
(C) Chartwell 2001

82. 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
April 16, 2017
(C) Chartwell 2001

83. Conclusion
April 16, 2017
(C) Chartwell 2001

84. 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
April 16, 2017
(C) Chartwell 2001

85. 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
April 16, 2017
(C) Chartwell 2001

86. Questions and Answers
April 16, 2017
(C) Chartwell 2001