Your SlideShare is downloading. ×
* (C) Chartwell 2001 1 Presentation to IRMAC
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

* (C) Chartwell 2001 1 Presentation to IRMAC

531
views

Published on

Published in: Business, Design

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
531
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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.)
  • 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. Pattern Thumbnail Legend
  • 1
  • No good, until I consider the alternatives New flavour of the month Pretend adopt stage Better start serious resistance here
  • Transcript

    • 1. Presentation to IRMAC Use of the Zachman Framework for Enterprise Architecture and Business Architecture
    • 2. 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
    • 3. INTRODUCTION
    • 4. About Us
      • Sandy McBride
        • Chartwell Partner
        • Architecture Practice Leader
        • 20+ years in IT
      • John Bruder
        • Senior Consultant
        • 15+ years in IT
        • Business Architecture practitioner
    • 5. About Chartwell
      • Founded in 1984
      • Initial focus - Information Resource Management
      • Evolution:
        • IT Strategic Planning
        • Business Modeling….Business Architecture
        • Information, Application and Technology Architecture
    • 6. 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
    • 7. Enterprise Architecture Context
    • 8. IT Planning and Architecture in Context Business Planning IT Strategic Planning IT Systems & Technology Delivery Business Architecture Automation Architectures ALIGNMENT IMPACT SCOPE REFINEMENT
    • 9. Traditional automation barriers Representation Construction Operation Change - methods - tools - skills - data Change - methods - tools - etc. Again
    • 10. Technical promise of architecture: the model is the enterprise Representation Construction Operation
    • 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
    • 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!
    • 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
    • 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
    • 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
    • 16. Examples of Architectural Models
    • 17. Model of a problem space, e.g a public sector agency Client Organizations Individual Clients Provider Organizations Used in Deliver Accomplish Outcomes Outputs Governance Authority Accountability Roles Responsibility
    • 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  
    • 19. Needs Clients Services Processes Workflow Organization Roles Locations Domains Nodes Infrastructure Components Applications Databases Strategy/Policy Realm Automation Realm Another model of a public sector enterprise Resources Interfaces Work Realm
    • 20. A Private Sector Enterprise Model Markets/ Clients Services/ Products Processes Information Subjects Organization Locations Domains Nodes Infrastructure Components Applications Databases Business Model (extended) Target Architectures Resources Interfaces Business Trends Business Goals Business Strategies Business Plans Suppliers Roles Workflow
    • 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
    • 22. Future State Technology Architecture: Patterns and Architectures - Meta Group “Starter Kit” Start with ……... Done TBD TBD TBD TBD TBD ? … ...…. adapt to support your business 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
    • 23. Two Interpretations of Enterprise Architecture
    • 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
    • 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
    • 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)
    • 27. What are the drivers for architecture? EWTA EA 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
    • 28. Portal rule-of-thumb 30 day release cycle for portal changes 60 day release cycle for workflow changes 90 day release cycle for database changes
    • 29. Implementing an Architecture Program Key Considerations
    • 30. Architecture Development - Approaches
      • Top Down
        • Enterprise-wide IT Strategic Architecture Planning
      • Incremental
        • Develop Architectures as part of major IT-enabled change initiatives
    • 31. Architectural Methodology © 2000 META Group Inc., Stamford, CT, (203) 973-6700, metagroup .com 9 Enterprise Architecture Process Model Enterprise Architecture Process Model Enterprise Architecture Governance and Evolution, Organizational Impact, & Communication   • Change Projects • Information Projects • Application Projects • Technology Projects Environmental Trends Environmental Trends Environmental Trends Organize Arch. Effort Organize Organize Arch. Arch. Effort Effort Business Visioning Business Business Visioning Visioning Define/ Refine EBA Define/ Define/ Refine Refine EBA EBA Define/ Refine EIA Define/ Define/ Refine Refine EIA EIA Define/ Refine EWTA Define/ Define/ Refine Refine EWTA EWTA Define/ Refine EAP Define/ Define/ Refine Refine EAP EAP Document Current Environment Document Current Environment Document Current Environment Gap Analysis Gap Gap Analysis Analysis Migration Planning Migration Migration Planning Planning Implementation Planning Implementation Implementation Planning Planning   The process model provides the framework for reconciling standards efforts and enterprise initiatives The process model provides the framework for reconciling standards efforts and enterprise initiatives
    • 32. General governance model for change initiatives Projects Directional Coherence Design Coherence Logistics Coherence
    • 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)
    • 34. Architecture compliance process Project demonstrates effectiveness of design (or lessons learned) Implementation Project demonstrates efficiency of design Physical Design Project demonstrates integration of business and automation design Logical Design Project demonstrates alignment of business and automation design Conceptual Design Identify component overlaps and linkages with other projects Project Context, Objectives & Scope
    • 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
    • 36. Zachman and Enterprise Architecture
    • 37.  
    • 38. The Zachman Framework classifies the details of an underlying model of the enterprise into an enterprise architecture. Business Architecture Information & Technology Architectures Business architecture drives automation architectures Artifact standards guide architecture development Transformation standards maintain architectural integrity The Public Outcomes Individuals & Organizations Outputs Governance Provider Organizations Authority Accountability Roles Responsibility Needs Clients Services Processes Workflow Organization Roles Locations Domains Nodes Infrastructure Components Applications Databases Resources Interfaces
    • 39. EIA FRAMEWORK INFORMATION PROCESS NETWORK PEOPLE TIME RATIONALE CONTEXTUAL CONCEPTUAL LOGICAL PHYSICAL COMPONENTS FUNCTIONAL Business Architecture Data Architecture More Zachman classification of IT architectures
    • 40. EIA FRAMEWORK INFORMATION NETWORK PEOPLE TIME RATIONALE CONTEXTUAL CONCEPTUAL LOGICAL PHYSICAL COMPONENTS FUNCTIONAL Business Architecture Application Architecture More Zachman classification of IT architectures PROCESS
    • 41. EIA FRAMEWORK INFORMATION NETWORK PEOPLE TIME RATIONALE CONTEXTUAL CONCEPTUAL LOGICAL PHYSICAL COMPONENTS FUNCTIONAL Business Architecture Technology Architecture More Zachman classification of IT architectures PROCESS
    • 42. EIA FRAMEWORK INFORMATION NETWORK PEOPLE TIME RATIONALE CONTEXTUAL CONCEPTUAL LOGICAL PHYSICAL COMPONENTS FUNCTIONAL Zachman Framework does not prescribe sequence of Architecture Development - Slivers and Slices PROCESS = slice = sliver
    • 43. Business Architecture
    • 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
    • 45. EIA FRAMEWORK INFORMATION NETWORK PEOPLE TIME RATIONALE CONTEXTUAL CONCEPTUAL LOGICAL PHYSICAL COMPONENTS FUNCTIONAL Business Architecture Business Architecture versus Zachman Framework PROCESS Each cell contains one more specified artifacts
    • 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
    • 47. Business Architecture in Ontario Public Sector
    • 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
      • 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
    • 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
    • 50. Key Business Artifacts
    • 51. Public Sector Row 1 & 2 Artifact Examples
      • What? (Column 1)
        • Row 1
          • Resource Types
        • Row 2
          • Semantic Model
      • How? (Column 2)
        • Row 1
          • Programs / (Markets - Line of Business)
          • Services / (Product Lines)
        • Row 2
          • Process Model (Value Chain)
      • Where? (Column 3)
        • Row 1
          • Locations
          • Geographic Areas
        • Row 2
          • Logistics Model
      • Who? (Column 4)
        • Row 1
          • Roles
          • Individuals and Orgs.
        • Row 2
          • Workflows
      • When? (Column 5)
        • Row 1
          • Business Cycles and Events
        • Row 2
          • Master schedule
      • Why (Column 6)
        • Row 1
          • Client Needs
          • Mandate, Strategy, Goals
          • Statutes
        • Row 2
          • Performance Model
    • 52. Meta-Model of Public Sector Key Artifacts Client Organizations Individual Clients Provider Organizations Used in Deliver Accomplish Outcomes Outputs Governance Authority Accountability Roles Responsibility
    • 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
    • 54. Individuals Women Abused Women Safety Freedom from Violence Freedom from Domestic Violence Target Group “ Hierarchy” Needs “Hierarchy” Strategy Policy Model Prevention: Focus on abuser Treatment: Focus on victim Abused Women Program Services Housing Financial assistance Counseling Vocational skills training 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. Goals Reduced frequency of abuse recurrence
    • 55. Enterprise Context for Public Services Ontario Government “ Service Provider” Partner Agent The Public “ OPS” View “ Service Consumer” “ Service Provider” Public Services Public Services LEGACY VIEW “ Partner” View “ Service Consumer” Public Services The Public TARGET VIEW “ Service Provider” “ Public Clients” Ontario Government & Partners & Agents
    • 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”
    • 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
    • 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)
    • 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.
    • 60. Internal Services are Consumed by Internal Customers Internal Services observe the Service Output Principle but service outputs always relate to types of resources! Systems Services Human Resources Services Financial Services
    • 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
    • 62. Service Value Chain Example (Row 2, Column 2) Personal Care Provision
      • 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
      • 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
    • 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 Capacity Capacity Capacity Accident Reporting System System cost per accident reported System accuracy & timeliness System capabilities Resource Capacity Capacity Site Visit Average cost per site visit Site visit completeness & timeliness Site visiting capabilities Process Safety Certification Average cost per certification Certification accuracy & timeliness Service Capacity Compliance & Accident trends Workplace Safety Total cost per capita Meeting public expectations Program Workplace safety trends Def’n
    • 64. Business Architecture Provides Common Framework For Performance Measurement
    • 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
    • 66. Key Artifact Semantic Model (row 2, col 1)
    • 67. The Business Architecture Function
    • 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
    • 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
    • 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
    • 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
    • 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
    • 73. Business Architecture Supports Planning & Change Management Services Current Bus Arch. Requires Strategic Operational Target Bus Arch. Resources Processes Organization Requires Services / Product Lines Enterprise Programs / Markets Strategic Direction Plan and Define Corporate Initiatives Resources Activities Org. Resources Activities Org. Design Build and Operate Resources Activities Org. Resources Activities Org. Resources Processes Organization Enterprise Programs / Markets Services / Product Lines
    • 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
    • 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
    • 76. Enterprise Architecture Organizational Capability Maturity Model (CMM)
      • 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 Standard Framework Independent Project Frameworks Multi- Project Alignment Change Manage- ment Wide- Spread Multi- Program Re-Use
    • 77. Business Architecture Implementation Key Considerations
    • 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?
    • 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
    • 80. Primitives Versus Composites Primitive Artifacts 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)
      Use of composites supports primitive discovery Needed to construct composites
    • 81. EIA FRAMEWORK INFORMATION PROCESS NETWORK PEOPLE TIME RATIONALE CONTEXTUAL CONCEPTUAL Composite artifacts support the discovery process Service Profiling Clients, Accountable Orgs, Partners Performance Metrics Services Program Profiling Goals Jurisdiction Target group Needs Strategies Performance Metrics Programs
    • 82. Discovery Process is iterative between row 1 and row 2 Row 1 artifacts are used in row 2 Completion of row 2 confirms / extends row 1 artifacts EIA FRAMEWORK INFORMATION PROCESS NETWORK PEOPLE TIME RATIONALE CONTEXTUAL CONCEPTUAL
    • 83. Conclusion
    • 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
    • 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
    • 86. Questions and Answers