Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Business Architecture Concepts and Application


Published on

Published in: Education, News & Politics
  • Be the first to comment

Business Architecture Concepts and Application

  1. 1. Presentation to IRMAC Business Architecture Concepts and Application
  2. 2. Agenda <ul><li>Introduction </li></ul><ul><li>Architecture versus design </li></ul><ul><li>Bus. Arch.Context </li></ul><ul><li>Bus. Arch Trends </li></ul><ul><li>Business Reference Models </li></ul><ul><li>Programs and Services </li></ul><ul><li><BREAK> </li></ul><ul><li>Processes </li></ul><ul><li>Performance Management </li></ul><ul><li>Business Transformation </li></ul><ul><li>Contribution to IT </li></ul><ul><li>Governance </li></ul><ul><li>Summary </li></ul>
  3. 3. Goals <ul><ul><li>A better understanding and applicability of using business architecture models in both the public and private sector </li></ul></ul><ul><ul><li>An understanding of how to define processes at an enterprise level and find patterns and opportunities for common automation solutions </li></ul></ul><ul><ul><li>An appreciation of techniques to better align IT solutions to the business </li></ul></ul><ul><ul><li>An appreciation of how to design an integrated performance management framework </li></ul></ul><ul><ul><li>An understanding of formal service definitions and its benefits in better aligning business and IT design to the end customer </li></ul></ul><ul><ul><li>LEAVE YOU WITH ONE NEW IDEA!! </li></ul></ul>
  5. 5. The “architecture” of a complex thing: <ul><li>Its essential structure </li></ul><ul><li>Its overall design </li></ul><ul><li>The orderly arrangement of its parts </li></ul><ul><li>The way its components fit together </li></ul>Architecture consists of the pieces of the puzzle! Design is the picture on the puzzle box!
  6. 6. Enterprise Architecture Definitions <ul><li>An enterprise architecture contains formal specifications for all the elements of an enterprise </li></ul><ul><li>An enterprise architecture function develops, harvests and applies the specifications to all change initiatives </li></ul><ul><li>ARCHITECTURE: (ANSI / IEEE Std 1471-2000) &quot;the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution&quot; </li></ul>
  7. 7. Architect vs. Designer <ul><li>Defines a formal model to represent the whole problem space </li></ul><ul><li>“ Populates” the model to define the problem space architecture </li></ul><ul><li>Defines logical constraints -design standards, rules, etc. </li></ul><ul><li>Is “whole system forever” oriented </li></ul><ul><li>Solves a problem in the problem space </li></ul><ul><li>Uses the architecture to create a design </li></ul><ul><li>Works within constraints </li></ul><ul><li>Is problem and solution-oriented </li></ul>
  8. 8. Recognized realms of architecture (Key parts needing orderly arrangement) <ul><li>Information (data entities) </li></ul><ul><li>Applications (business logic) </li></ul><ul><li>Technology (technology components) </li></ul><ul><ul><li>Network (network technology components) </li></ul></ul><ul><li>Security (security components) </li></ul><ul><li>Business (processes) </li></ul><ul><ul><li>Work (processes) </li></ul></ul><ul><ul><li>Organization (roles & responsibilities) </li></ul></ul><ul><ul><li>Policy (business rules) </li></ul></ul>Automation Architectures Business Architecture
  9. 9. Architectural Components <ul><li>Business: </li></ul><ul><ul><li>Services, Processes, Resources, Roles etc. </li></ul></ul><ul><li>Logical: </li></ul><ul><ul><li>System Functions, Entities, Logical Applications, Nodes, Domains etc. </li></ul></ul><ul><li>Physical: </li></ul><ul><ul><li>Databases, Applications, Servers etc. </li></ul></ul>
  10. 10. BUSINESS ARCHITECTURE Setting Context
  11. 11. What is Business Architecture <ul><li>A formal way of describing the key components of your business (current or future) and their relationships </li></ul><ul><ul><li>Sample components include: </li></ul></ul><ul><ul><ul><li>Services, Programs (Markets), Activities, Resources, Organization, Performance Measures, Locations, Business Cycles </li></ul></ul></ul><ul><ul><li>Sample relationships include: </li></ul></ul><ul><ul><ul><li>(services to activities) </li></ul></ul></ul><ul><ul><ul><li>(activities to organization) </li></ul></ul></ul><ul><li>Simplifies the understanding of an enterprise by breaking it down into manageable chunks and relationships </li></ul><ul><li>An asset: an authoritative source of business knowledge that is used by many parties for different purposes </li></ul>
  12. 12. Goals and Objectives <ul><li>The main goal of business architecture is to support the integration </li></ul><ul><li>and alignment of : </li></ul><ul><ul><li>Business strategy and operations </li></ul></ul><ul><ul><li>Business strategy and IT strategy planning and design </li></ul></ul><ul><ul><li>Business programs and initiatives throughout change processes </li></ul></ul><ul><li>Results in greater enterprise efficiency, quality, effectiveness </li></ul><ul><li>and change capability </li></ul><ul><li>KEY THEMES: </li></ul><ul><ul><li>Shared common language and representation </li></ul></ul><ul><ul><li>Defined linkages </li></ul></ul>
  13. 13. 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
  14. 14. Where does business architecture fit? Enterprise Architecture Business Architecture Business Vision Technology Architecture Business & IM/IT Innovation Opportunities Application Architecture Innovation Opportunities Information Architecture Future Business Requirements Security Architecture Future Business Requirements Integration Requirements Integration Requirements Alignment & Integration Requirements Business & IM/IT Innovation Opportunities
  15. 16. Zachman vs Business Architecture Familiar Territory
  20. 21. Meta Group <ul><ul><li>By 2005, 70% of Global 2000 enterprises will move beyond a pure technology architecture focus to include enterprise business architecture (50%), enterprise information architecture (60%), and enterprise solution architecture (70%). Architecture teams that fail to move beyond a technical focus will come under increasing pressure to demonstrate business value. </li></ul></ul><ul><ul><ul><ul><ul><li>META Trend (March 2003): </li></ul></ul></ul></ul></ul>
  21. 22. In the USA <ul><li>Legislated or mandated EA initiatives </li></ul><ul><li>Established Federal EA PMO </li></ul><ul><ul><ul><ul><li> </li></ul></ul></ul></ul><ul><li>Most still struggle with “how-to” </li></ul><ul><li>Other trends & signs </li></ul><ul><ul><li>George Bush allocates $1 Billion to EA (Feb 2003) </li></ul></ul><ul><ul><li>Government EA conference – June </li></ul></ul><ul><ul><li>Business Reference Model </li></ul></ul>
  22. 23. FEAPMO - USA <ul><li>“To facilitate efforts to transform the Federal Government to one that is citizen-centered, results-oriented, and market-based, the Office of Management and Budget (OMB) is developing the Federal Enterprise Architecture (FEA), a business-based framework for Government-wide improvement” </li></ul>
  23. 24. Canadian Municipalities <ul><li>Municipal Reference Model </li></ul><ul><ul><li>Generic business model of municipal programs and services </li></ul></ul><ul><ul><li>Adopted by MISA (Municipal Information Systems Association) </li></ul></ul><ul><ul><li>Used by 27+ Canadian municipalities and at least 2 foreign municipalities </li></ul></ul><ul><ul><li>Proved to be extremely valuable during the many municipal amalgamations </li></ul></ul>
  24. 25. Canadian Provinces <ul><li>Ontario – perceived leader </li></ul><ul><ul><li>Using PSRM for past 8 years </li></ul></ul><ul><ul><li>Formal architecture and planning process and governance structure for the province </li></ul></ul><ul><ul><li>Have detailed architecture framework and standards for Ontario’s Enterprise Information Architecture </li></ul></ul><ul><li>Alberta, N.B. & B.C. and perhaps others also embarking on similar initiatives </li></ul>
  25. 26. Canadian Federal Govmt <ul><li>Started with FAP (Federated Architecture Program) </li></ul><ul><ul><li>Iteration One: Connectivity, Access to electronic information, Public assurances of confidentiality, improvement of government administration </li></ul></ul><ul><li>BTEP (Business Transformation Enablement Program) </li></ul><ul><ul><li>Next Iteration of FAP </li></ul></ul><ul><ul><li>Much stronger business focus </li></ul></ul><ul><ul><li>BTEP overviews being given to individual departments, ARB, … </li></ul></ul>
  26. 27. More Trends <ul><li>Business Architecture (BA) still evolving </li></ul><ul><ul><li>Bottom Up trend still evident </li></ul></ul><ul><ul><li>Methods and models being refined </li></ul></ul><ul><ul><li>Tools like artifact repositories are immature </li></ul></ul><ul><li>Control & Interest is shifting </li></ul><ul><ul><li>Today: CIO’s to promote BA as part of the overall Enterprise Architecture </li></ul></ul><ul><ul><li>Business is fast adopting BA and making it part of the strategic and business planning </li></ul></ul>
  27. 28. BUSINESS ARCHITECTURE Business Reference Models
  28. 29. In addition to Zachman framework, following is required: <ul><li>A business reference model: </li></ul><ul><ul><li>Describes explicitly relationship between business components across rows / columns </li></ul></ul><ul><ul><li>Specifies additional business components and definitions that are relevant for a given business domain e.g. programs, markets </li></ul></ul><ul><li>Methods to describe the processes and dependencies associated with: </li></ul><ul><ul><li>T he population of the Zachman framework through the use of a reference model </li></ul></ul><ul><ul><li>The creation of business designs based on the reference model </li></ul></ul><ul><ul><li>The integration of the business design work in the context of the larger business transformation agenda </li></ul></ul>
  29. 30. Business Reference Models <ul><li>A business reference model contains all the business components and relationships for a given business domain </li></ul><ul><li>The PSRM is a business reference model that is used by the Government of Ontario as a standard description of a public service enterprise </li></ul><ul><li>Business reference models: </li></ul><ul><ul><li>Ensure a standard description of the business across projects / Ministries </li></ul></ul><ul><ul><li>Support re-use of business components </li></ul></ul><ul><ul><li>Used to analyze and ensure alignment, integration </li></ul></ul><ul><ul><li>ALIGNMENT – common ends! </li></ul></ul><ul><ul><li>INTEGRATION – common means! </li></ul></ul>
  30. 31. Public Sector Reference Model Illustration (PSRM) Client Organizations Individual Clients Provider Organizations Used in Deliver Accomplish Outcomes Outputs Governance Authority Accountability Roles Responsibility
  31. 32. Government is Different <ul><li>Mandate </li></ul><ul><ul><li>Retailer closes East Coast outlets </li></ul></ul><ul><ul><li>Canada Post no longer delivers to Nunavut </li></ul></ul><ul><li>Jurisdiction </li></ul><ul><ul><li>Commercial product competes with consumer model </li></ul></ul><ul><ul><li>RCMP decides to expand to provinces </li></ul></ul><ul><li>Expectations </li></ul><ul><ul><li>Door Crasher Special – 50% off to first 500 clients </li></ul></ul><ul><ul><li>E-File promo – first 500 users get 10% income tax rebate </li></ul></ul><ul><li>Service Level </li></ul><ul><ul><li>Lavish Service is desired and appreciated </li></ul></ul><ul><ul><li>Over Serving is deemed wasteful and extravagant </li></ul></ul>
  32. 33. PSRM Adapted to Rows 1 and 2 of the ZFW Business Architecture Zachman Framework Public Service Reference Model
  33. 34. 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
  34. 35. PSRM Elements in the Zachman Framework What How Where Who When Why Resources Semantic Model Services Jurisdictions Parties Roles Target Groups Row 2: Row 1: Schedules Cycles Locations Scenarios Workflows Business Network Model Service Process Models Areas Events Performance Metrics Other Models Service Integration and Alignment Model State Transition Models Program Service Alignment Models Programs Needs Goals Strategies
  35. 36. BUSINESS ARCHITECTURE: Programs and Services
  36. 37. Programs and Services <ul><li>Programs define the organization’s “end” – mandate, target groups, needs </li></ul><ul><ul><li>Key unit of measurement is “outcome” </li></ul></ul><ul><li>Services define the organization’s “means” – modes of production </li></ul><ul><ul><li>Key unit of measurement is “output” </li></ul></ul><ul><li>Collectively define the broad “top-down” business context </li></ul>
  37. 38. Programs <ul><li>Programs specification includes: </li></ul><ul><ul><li>Target group </li></ul></ul><ul><ul><li>Target group needs </li></ul></ul><ul><ul><li>Program outcomes and impacts </li></ul></ul><ul><ul><li>Strategy Model </li></ul></ul><ul><ul><li>Program Accountability </li></ul></ul><ul><li>Programs create context for service delivery and design </li></ul><ul><li>Programs can be grouped together based on affinity between target groups and needs </li></ul><ul><li>Program concept is very close to private sector concept of line of business focused on a target market </li></ul>
  38. 39. Program Profile Example Seniors Health Program <ul><li>Jurisdiction: Federal </li></ul><ul><li>Target Group: Seniors </li></ul><ul><ul><li>Target group is comprised of individuals that are 65 or over </li></ul></ul><ul><ul><li>Are they Residents? Citizens? Visitors? </li></ul></ul><ul><li>Target Group Needs: </li></ul><ul><ul><li>Need for protection from disease </li></ul></ul><ul><ul><li>Need for protection from suffering </li></ul></ul><ul><li>Program Goals </li></ul><ul><ul><li>Reduced level of disease in senior population </li></ul></ul><ul><ul><li>Reduced level of suffering in senior population </li></ul></ul><ul><li>Program Impacts </li></ul><ul><ul><li>Increased mobility and quality of life for seniors </li></ul></ul><ul><ul><li>A more caring society </li></ul></ul><ul><ul><li>Reduced cost of reactive health care </li></ul></ul>Other program profile components not shown Mandate definition Definition of Core Strategies
  39. 40. Need Types for Individual and Groups <ul><li>Individuals </li></ul><ul><li>Physiological: hunger, thirst, bodily comforts, etc.; </li></ul><ul><li>Safety/security: out of danger; </li></ul><ul><li>Belonginess and Love: affiliate with others, be accepted; and </li></ul><ul><li>Esteem: to achieve, be competent, gain approval and recognition. </li></ul><ul><li>Cognitive: to know, to understand, and explore; </li></ul><ul><li>Aesthetic: symmetry, order, and beauty; </li></ul><ul><li>Self-actualization: to find self-fulfillment and realize one's potential; and </li></ul><ul><li>Transcendence: to help others find self-fulfillment and realize their potential. </li></ul><ul><li>Groups: </li></ul><ul><li>Mission fulfillment: drive to accomplish their collective purpose </li></ul><ul><li>Survival: access to resources </li></ul><ul><li>Risk mitigation: protection from destabilizing forces </li></ul><ul><li>Rights: recognition of rights and entitlements as a legal entity </li></ul><ul><li>Stability: capability to grow and/or change </li></ul>
  40. 41. 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
  41. 42. Services <ul><li>Services deliver units of value to clients to meet recognized needs </li></ul><ul><li>Service definitions are defined from the client’s perspective in terms of value received </li></ul><ul><ul><li>Not “ getting a needle ” but “ an inoculation ”, which is a “unit of protection for a period of time” </li></ul></ul><ul><li>From a client’s perspective, services are independent </li></ul><ul><ul><li>e.g. “fixing a pothole” is not a service to the end-client ‘providing road access” is </li></ul></ul><ul><li>Service definition is a key bridge between work/policy design and work design </li></ul><ul><li>Services are not a functional concept, but a value concept! </li></ul>
  42. 43. 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
  43. 44. Program Target Group Need Service accomplishes goals of admits addresses includes includes includes Expressed by Client is member of provides output to Model of Programs and Services
  44. 45. 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.
  45. 46. Standard Service Types (From Federal TBS BTEP) <ul><li>Provide funds </li></ul><ul><li>Provide resources </li></ul><ul><li>Provide transport </li></ul><ul><li>Provide advisory encounters </li></ul><ul><li>Provide matches, referrals and linkages </li></ul><ul><li>Provide new knowledge </li></ul><ul><li>Provide promotional encounters </li></ul><ul><li>Provide recreational and cultural encounters </li></ul><ul><li>Provide educational and training encounters </li></ul><ul><li>Provide care and rehabilitation encounters </li></ul><ul><li>Provide periods of agreement </li></ul><ul><li>Provide periods of permission </li></ul><ul><li>Provide periods of protection </li></ul><ul><li>Provide findings </li></ul><ul><li>Provide interventions </li></ul><ul><li>Provide rulings & judgments </li></ul><ul><li>Provide penalties and periods of sanction </li></ul><ul><li>Provide rules </li></ul><ul><li>Provide implemented changes </li></ul>
  46. 47. BREAK
  48. 49. Bridging the Gap to Processes Standard Service Types Contains Standard Set of Process Types (Service Process Model) Contains Standard Set of Performance Metric Types <ul><li>If you can classify your services in a standard way, you can develop: </li></ul><ul><li>Standard complete set of processes </li></ul>
  49. 50. Service Process Models Principles and Applications <ul><li>Are intended to be: </li></ul><ul><ul><li>Authoritative – for multiple use / change insulated / technology independent </li></ul></ul><ul><ul><li>Coarse level of detail – sets context for detail </li></ul></ul><ul><ul><li>“ Verb Adjective Noun” </li></ul></ul><ul><li>Are useful in supporting: </li></ul><ul><ul><li>Pattern recognition for opportunity identification </li></ul></ul><ul><ul><li>Role / responsibility mapping </li></ul></ul><ul><ul><li>Application portfolio assessment </li></ul></ul><ul><ul><li>Consolidation / Assessment / Leveling of other models </li></ul></ul><ul><ul><li>Aligning process responsibilities to service accountabilities </li></ul></ul><ul><ul><li>Integrated performance management framework </li></ul></ul>
  50. 51. Key Artifact Public Service process models <ul><li>Process model identifies key processes associated with services </li></ul><ul><li>Types of processes included with services include: </li></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Acquisition </li></ul></ul><ul><ul><li>Use (Customer contact / delivery) </li></ul></ul><ul><ul><li>Monitoring & Managing </li></ul></ul><ul><li>A public service provider may outsource one or more of these processes </li></ul><ul><li>Services of “like-type” tend to have common patterns e.g. training service, commodity distribution </li></ul><ul><ul><li>The use of these patterns supports creating quick “strawmen” supporting “edit mode” with client </li></ul></ul>
  51. 52. Service Process Model Provide care and rehabilitation encounters <ul><li>Plan </li></ul><ul><ul><li>Project demand </li></ul></ul><ul><ul><li>Define service objectives & strategies </li></ul></ul><ul><ul><li>Define service performance targets </li></ul></ul><ul><ul><li>Define resource requirements </li></ul></ul><ul><ul><li>Define resourcing strategy </li></ul></ul><ul><li>Acquire </li></ul><ul><ul><li>Acquire resources </li></ul></ul><ul><ul><li>Determination of qualified care providers </li></ul></ul><ul><ul><li>Develop service delivery schedule </li></ul></ul><ul><ul><li>Allocate resources to delivery schedule </li></ul></ul><ul><ul><li>Notify clients of service delivery schedule </li></ul></ul><ul><ul><li>Promote personal care service </li></ul></ul><ul><ul><li>Offset risks attributed to personal care </li></ul></ul><ul><li>Use </li></ul><ul><ul><li>Receive request for personal care </li></ul></ul><ul><ul><li>Qualify request </li></ul></ul><ul><ul><li>Open case </li></ul></ul><ul><ul><li>Assess personal care case rqts </li></ul></ul><ul><ul><li>Assign resources to case </li></ul></ul><ul><ul><li>Develop / modify personal care schedule </li></ul></ul><ul><ul><li>Schedule appointments </li></ul></ul><ul><ul><li>Provide personal care </li></ul></ul><ul><ul><li>Process complaints attributed to service </li></ul></ul><ul><li>Monitor </li></ul><ul><ul><li>Monitor service performance </li></ul></ul><ul><ul><li>Monitor achievement of service objectives </li></ul></ul><ul><ul><li>and strategies </li></ul></ul>
  52. 53. Greater Change Change insulate model through managed leveling Formal Process Leveling Insulates Change Process Activity1 Activity2 Activity3 Activity4 Task1 Task2 Task3 Task4 Contains Contains
  53. 54. Defining all processes within a program Services Service Types Processes Program All your processes in the program Process Types Wallpaper! Enterprise
  54. 55. Single Model Multiple Use ? IT ? Business What common patterns exist for automation? What’s the current application portfolio coverage? Gaps / overlaps? What’s the coverage of our existing process models? Where are gaps and overlaps in role definition? Which are under / over performing? What is the cost? App A App B
  55. 56. Design models that use Processes
  56. 57. Workflow Models <ul><li>Characteristics </li></ul><ul><li>Shows flow of work across roles in response to an event (business scenario) </li></ul><ul><li>Defined in context of “triggering event” and “end goal” </li></ul><ul><li>Has an accompanying business narrative </li></ul><ul><li>Key Benefits </li></ul><ul><li>Easily understood by business stakeholders </li></ul><ul><li>Very powerful in supporting “quick hits” </li></ul><ul><li>A powerful tool for effective work design </li></ul><ul><li>Quality Considerations: </li></ul><ul><li>Roles, Processes, Roles, Events and Resources must be aligned to standard set of business components </li></ul><ul><li>Models should be produced in broader context of evaluating business scenarios, alternatives and exceptions </li></ul><ul><li>To define explicit instances, roles should be mapped to position or individuals </li></ul>
  57. 58. WorkFlow Model A workflow model illustrates the behavior of business in response to a trigger event (typically a service request). It shows the trigger event, roles that respond to the trigger event, sequence of processes performed by the roles and the outcome event(s).
  58. 59. Role Responsibility Mapping <ul><li>Characteristics </li></ul><ul><li>Shows the role relationships between roles and processes </li></ul><ul><li>Can be used to either assess current role definitions or to design target state </li></ul><ul><li>Supports formal alignment of job descriptions </li></ul><ul><li>Key Benefits </li></ul><ul><li>Reveals current gaps and overlaps in responsibility definitions </li></ul><ul><li>Supports formal definition of roles and alignment of job descriptions </li></ul><ul><li>Quality Considerations: </li></ul><ul><li>Must be based on standard set of Role responsibility relationships e.g. (L) – Leads, © Consulted before, (I) Informed After, (S) Supports etc. </li></ul><ul><li>Processes and roles must be aligned to standard business components </li></ul>
  59. 60. Role Responsibility Mapping Activity Name Crime and Community General Investigation Traffic General Duty Corporate Planning Finance Human Resources Information Services Legal and By-law Clerks (+ commun) Office of CS GM Administration Dispatch Fire Prevention Operations Training Facilities Management Recrfeation E & W Parks and Environment Office of the L&P GM Community Planning Development Services Office of the P&D GM 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 A Define By-Law Enforcement Service Requirements L I I L I B Define By-Law Enforcement Service Performance Targets L I I I C Define By-Law Enforcement Service Objectives & Strategies L I I D Define By-Law Enforcement Service Corp. Policies, Proc. & Stnds L I I L E Define By-Law Enforcement Service Delivery Plans L I I L F Promote By-Law Enforcement Service L I I I L G Receive By-Law Enforcement Complaint L I I L I H Qualify By-Law Enforcement Complaint L I I L I I Dispatch Resources to Inspect By-Law Enforcement Complaint I L L I I I I L I J Inspect By-Law Enforcement Complaint I L L I I I L I K Notify Violator of By-Law Enforcement Infraction I L L I I I L I L Enforce By-Law Enforcement Regulation I L L I I I M Collect Fine for By-Law Violation I I L N Monitor By-Law Enforcement Service Delivery Performance L I I I I L I O Monitor By-Law Enforcement Service Objectives L I I L I P Monitor Compliance with By-Law Enforcement Service Policies L I I L I 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Legal & Ordinance Division, Corporate Services Department Ordinance Enforced Service Profile Accountable Organization Unit Service Delivery Unit Client Direct: Ordinance Violator; Indirect: Ordinance Complainant Leisure and Parks City Manager Council Administration Responsible Division Police Fire Rescue Corporate Services Public Service 134 Ordinance Enforcement
  60. 61. BUSINESS ARCHITECTURE: Support for an integrated performance management
  61. 62. Business Architecture Provides Common Framework For Performance Measurement
  62. 63. EQE Framework <ul><li>Three types of performance metrics at each level (program, service,process, resource) </li></ul><ul><ul><li>Efficiency - $ per unit </li></ul></ul><ul><ul><li>Quality – output compared to standard </li></ul></ul><ul><ul><li>Effectiveness – contribution to higher level business component </li></ul></ul><ul><li>Measuring service performance typically requires some budget recasting from organizational based budget – Gives customer-centric view </li></ul><ul><li>Sets foundation for well-formed SLA </li></ul>
  63. 64. 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. 65. Key Performance Management Concepts <ul><li>Business Goal: </li></ul><ul><ul><li>A business view of desired change in state (e.g. increase, decrease) to which effort is directed </li></ul></ul><ul><ul><li>Business goals can be defined for various business components (programs, services, processes, resources) e.g. </li></ul></ul><ul><ul><li>“ Greater consistency of assessment service across CCAC and greater alignment with MOH expectations ” </li></ul></ul><ul><li>Performance Indicator: </li></ul><ul><ul><li>A measurements that relates to and indicates the achievement of a business goal, e.g. “% of compliant assessments ” </li></ul></ul><ul><li>Indicator: </li></ul><ul><ul><li>A measurement that is required to support the calculation of a performance indicator, e.g. “ total number of assessments ” </li></ul></ul>
  65. 66. Business Goals Versus Performance Indicators
  66. 67. BUSINESS ARCHITECTURE: In support of transformation
  67. 68. Transformation Framework
  68. 69. What’s the motivation of the transformation
  69. 70. Comparison of Current to Target Private Sector Example X X X X X X X X Services Markets CURRENT X X X X X X X Markets TARGET New markets New services New customer for existing service Discontinued service Discontinue service for customer
  70. 71. Business Architectural Context for Transformation <ul><li>Business Components </li></ul><ul><li>Programs / </li></ul><ul><li>Target Groups / Needs </li></ul><ul><li>Services </li></ul><ul><li>Processes </li></ul><ul><li>Resources </li></ul><ul><li>Roles / Organizations </li></ul><ul><li>Events / Cycles </li></ul><ul><li>Goals </li></ul><ul><li>etc </li></ul><ul><li>Models </li></ul><ul><li>Program Service Alignment </li></ul><ul><li>Service Integration Model </li></ul><ul><li>Logistics Models </li></ul><ul><li>Swimlane Models </li></ul><ul><li>etc </li></ul>Current Business Model How much to model? Target Business Model <ul><li>Business Components </li></ul><ul><li>Programs / </li></ul><ul><li>Target Groups / Needs </li></ul><ul><li>Services </li></ul><ul><li>Processes </li></ul><ul><li>Resources </li></ul><ul><li>Roles / Organizations </li></ul><ul><li>Events / Cycles </li></ul><ul><li>Goals </li></ul><ul><li>etc </li></ul><ul><li>Models </li></ul><ul><li>Program Service Alignment </li></ul><ul><li>Service Integration Model </li></ul><ul><li>Logistics Models </li></ul><ul><li>Swimlane Models </li></ul><ul><li>etc </li></ul>How much to model? What’s different? What relationships are important or related to the differences ? What dependencies exist? How does this inform the transformation plan? What’s the same?
  71. 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
  72. 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
  73. 74. Scoping projects using a business architectural approach <ul><li>OVERLAP: Does it represent risk or opportunity? </li></ul><ul><li>May need to: </li></ul><ul><ul><li>Elaborate processes in area of overlap </li></ul></ul><ul><ul><li>Explore other business architectural relationships </li></ul></ul><ul><ul><ul><li>process to role responsibilities </li></ul></ul></ul><ul><ul><ul><li>process dependencies </li></ul></ul></ul><ul><ul><ul><li>process to resource </li></ul></ul></ul>Services Service Types Processes Program All your processes in the current program Project A Project B Overlap Project C <ul><li>SCOPING </li></ul><ul><ul><li>Define scope initially in terms of process / elaborate processes </li></ul></ul><ul><ul><li>Identify related business components: </li></ul></ul><ul><ul><ul><li>Roles, resources, organizations, dependencies, performance measures, </li></ul></ul></ul>Process Types
  74. 75. BUSINESS ARCHITECTURE: Contribution to IT
  75. 76. Business transformation dilemma <ul><li>IF no alignment of IT and business Combined system is highly resistant to change </li></ul>Value Chain to System Infrastructure Alignment & Integration Business Model System Model
  76. 77. The Value <ul><li>Business is constrained by IT inability to quickly adapt to its changing needs </li></ul><ul><li>IT a strategic partner with the business </li></ul><ul><li>IT made no contribution at all </li></ul><ul><li>IT as expensive overhead </li></ul>66% 30% 15% 10% Source: Fujitsu’s 2002 Information Technology Services Management Survey
  77. 78. Food for thought <ul><li>… focusing on alignment with business strategy is irrelevant if your &quot;technology portfolio&quot; is leaking oil, spitting gas and spewing smoke </li></ul><ul><li>… make sure you have your lower level architectural needs under control before you start worrying about being the lofty goals of alignment </li></ul><ul><ul><ul><li>Jeff Tash (aka ITscout) Flashmap Systems </li></ul></ul></ul>
  78. 79. Business Architecture versus IT Design <ul><li>More effective IT design requires a formal model of the business to identify common business patterns (integration) </li></ul><ul><ul><li>Business patterns occur at a variety of scales </li></ul></ul><ul><ul><li>e.g. regulatory program versus ‘accept client request’ </li></ul></ul><ul><li>Business component to IT component mapping (alignment): </li></ul><ul><ul><li>Ensures alignment of architectures </li></ul></ul><ul><ul><li>Support graceful change </li></ul></ul><ul><ul><li>Key to aligning business and IT planning </li></ul></ul><ul><li>IT can also be modeled as a business inside a business reference model </li></ul><ul><ul><li>Used to define service level agreements </li></ul></ul><ul><ul><li>Used to align IT / Business performance (alignment) </li></ul></ul>
  79. 80. IT Planning and Architecture in Context Business Planning IT Strategic Planning IT Systems & Technology Delivery Business Architecture Automation Architectures ALIGNMENT IMPACT SCOPE REFINEMENT
  81. 82. Enterprise Architecture – (CMM) Capability Maturity Model <ul><li>Business architecture and I&IT architecture capability </li></ul><ul><li>maturity may evolve at different rates </li></ul><ul><li>Methodology maturity is also evolving </li></ul>Reference Models EWTA Zachman No Standard Framework Independent Project Frameworks Multi- Project Alignment Change Manage- ment Wide- Spread Multi- Program Re-Use
  82. 83. Enterprise/Program/Project Governance Enterprise Program Project 1 Project 2 Project 3
  83. 84. 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
  84. 85. Services of an operational business architecture function <ul><li>Supply standards & guidelines for designers </li></ul><ul><li>Supply re-usable components for designers </li></ul><ul><li>Supply design assistance </li></ul><ul><li>Provide awareness & training to business and IT </li></ul><ul><li>Supply methods & tools for designers </li></ul><ul><li>Provide quality assurance and compliance testing </li></ul><ul><li>Provide stewardship of the architectures and designs (repository services) </li></ul>
  85. 86. Summary
  86. 87. Business Architecture Challenges <ul><li>The discipline of formal language e.g. services, programs, clients </li></ul><ul><ul><li>Client may already have a ‘set of services’ defined </li></ul></ul><ul><li>Perception that business architecture “Slows things down” and adds to cost </li></ul><ul><li>Perception that architecture is technical and owned by IT </li></ul><ul><li>No generally accepted standards for business architecture – immature market place </li></ul><ul><li>Business Architecture tends to be iterative and ongoing </li></ul>
  87. 88. Critical Success Factors <ul><li>Both business and technical staff need to understand the role of business architecture and business architects </li></ul><ul><li>Business needs to expect results, and technical staff need to focus on the delivery of value from architecture </li></ul><ul><li>Acceptance that business architecture is an evolving discipline </li></ul><ul><li>Creation of strong alignment between business and technical architecture </li></ul>
  88. 89. Business Architecture Challenges <ul><li>The discipline of formal language e.g. services, programs, clients </li></ul><ul><ul><li>Client may already have a ‘set of services’ defined </li></ul></ul><ul><li>Challenges of describing business in a technology neutral way </li></ul><ul><li>Perception that business architecture “Slows things down” and adds to cost </li></ul><ul><li>Perception that business architecture is technical and owned by IT </li></ul><ul><li>No generally accepted standards for business architecture </li></ul><ul><li>Business Architecture tends to be iterative and ongoing – it’s a more a process than a thing </li></ul>
  89. 90. Questions and Answers
  90. 91. Enterprise Architecture Resources <ul><li> </li></ul><ul><li> </li></ul><ul><ul><li>See whitepapers </li></ul></ul><ul><li> </li></ul>