Enterprise Architecture Process & Methods Handbook

Transcription

1 Government of Ontario Enterprise Architecture Process & Methods Handbook Version 3.0 June 3, 2005 Copyright Information: Queen s Printer for Ontario, 2005

2 Revision History Revision Date Notes Version 1.0 June 25, 2001 First publication for full distribution. Version 1.5 August 30, 2002 Technology Integration Model section removed. Nodes and Components replaced by AIS Adaptive Infrastructure Strategies and Infrastructure Components. Appendix A, OPS EA Glossary updated. Appendix B, Defining Programs & Services in the OPS removed from the EAPM and published as a separate document. It is now available on the EA Web site under Resource Library. Appendix C, Generic Information Technology Principles replaced by the OPS Enterprise Architecture (EA) Principles. Appendix D, a new Security Principles document has replaced the Security Design Principles document. Appendix E, Information Modeling Handbook (IMH) removed from the EAPM. It is now available on the EA Web site under Resource Library. Version 2.0 June 16, 2003 Appendix C, moved into the body of the EAPM as Section 5.2. Appendix D, moved into the body of the EAPM as Section 5.3. A chapter of the IMH, Introduction to Data Warehouse Design and Architecture moved to the EAPM as Section Artifact summaries and details in Section 1.1 updated to be in accord with version 1.02 of the Checklist Guidebook. Alignment of terminology in the EAPM with usage in the Information Modeling Handbook. Alignment of terminology in the EAPM with usage in Defining Programs and Services in the OPS. Update the Architecture Methods section to reflect the 3- checkpoint architecture review process. Restructure and expand the Table of Contents and each corresponding chapter to present material in more consistent logical groupings. Version 3.0 April 28, 2005 Updated Introduction to the EAPM Handbook to position the Handbook as the overarching manual in a set authoritative documents that together define the OPS mandatory and bestpractice processes, methods and tools used in the development of enterprise architecture. ii EAPM Version 3.0

3 Contributors Name Role Coordinates L. C. (Skip) Lumley Principal author and editor Chartwell IRM Inc. Ian Gilmour Contributing author Chartwell IRM Inc. Estell MacKinnon Editor Chartwell IRM Inc. Architecture Core Team (ACT) Corporate Architecture Review Review Branch Corporate Architecture Contributing author Peter Churchard Mike Knowles Contributing Author IBM Andrew Dudas Sylvia Smart Anthony (Tony) Brown Senior Technical Writer TAMBI Corporation Standards and Architecture Librarian Contributing Author Allstream IT Services June 3, 2005 iii

4 Introduction to the EAPM Handbook Overview of the Enterprise Architecture Process and Methods (EAPM) Handbook The purpose of the EAPM Handbook, hereafter referred to as EAPM or as Handbook, is to serve as an EA approach in Business and Business initiatives solutions. It is also an EA reference manual for those assigned to work on any aspect associated with the development, management and maintenance of the Ontario Government s Enterprise Architecture (EA). The EAPM covers all general aspects concerning EA activities. Additional or specialized guidance is contained in the following companion publications: Information Modeling Handbook for the OPS Defining Programs and Services in the Ontario Public Service Application Architecture Guidebook Checklist for Change Initiatives and Checklist Guidance documents The EAPM information that will also be made available in the EA Repository as time goes on. Target audience Knowledge prerequisites The target audience for the Handbook includes anyone who has any role to play in the Ontario Government Enterprise Architecture Program, uses the EA approach in the Business Solutions initiatives, I&IT Architects (Business, Information, Applications, Technology and Security), Business Analysts, I&IT Managers, Project Managers, System Developers, Librarians, and Methodologists. This may be expanded to include Business Planners and Policy Analysts in the future. Some knowledge is assumed as a pre-requisite for reading the Handbook. This includes: An understanding of the Zachman Framework and its basic concepts and structure An understanding of the META Group approach to Enterprise Architecture General understanding of systems analysis and design methods General understanding of project management approaches Knowledge of the Structure Index Directory tool to access the EA Repository (if needed) The Handbook does not address any specific tools or brand name methods other than the Zachman Framework. iv EAPM Version 3.0

5 TABLE OF CONTENTS CHAPTER 1: EA ARCHITECTURE FRAMEWORK Introduction to EA Frameworks Principles of Framework Definition Overview of Framework Artifacts EA Federated Frameworks Vote and Item Architecture Frameworks The EA Meta-framework and Libraries Managing Architectural Knowledge General Concepts of EA Development and Management Authoritative vs. Project Frameworks Architecture Framework Maintenance Access to Architecture Knowledge What Is Relevant Architecture Knowledge Use of Modeling Tools and Repositories Architecture Maintenance CHAPTER 2: INTRODUCTION TO OPS EA PROGRAM The OPS EA Program Profile Architecture Services Client Needs for Architecture Services Architectural Policies & Standards Service Enterprise Architecture Development Service Change Initiative Architecture Development Service Architecture Education Service Architectural Consulting Service Methods and Tools Service Architecture Review Service Repository Service Reference Model Service Architect Certification Service Architecture Project Planning Service Architecture Governance Governance Parties and Roles June 3, 2005 v

6 2.4 Corporate Architecture Governance Corporate Governanace Bodies Deputy Ministers Committee on OPS Transformation Transformation Leadership Committee I&IT Executive Leadership Council Information Technology Standards Council Architecture Review Board Corporate Architecture Core Team (ACT) Business Architecture Domain WG Information Architecture Domain WG Application Architecture Domain WG Technology Architecture Domain WG Security Architecture Domain WG EA Methodology WG Cluster Architecture Governance Cluster Governance Bodies Cluster Architecture Review Board (ARB) Cluster Architecture Core Team (ACT) Artifact Creation and Approval Roles Scope Artifact Roles (Row 1) Conceptual Model Artifact Roles (Row 2) Logical Model Artifact Roles (Row 3) Physical Model Artifact Roles (Row 4) Component Artifact Model Roles (Row 5) CHAPTER 3: ARCHITECTURE ROLES, RESPONSIBILITIES AND SKILLS Architecture Roles, Responsibilities and Skills Enterprise Architect Business Architect Information Architect Application Architect Technology Architect Security Architect EA Methodologist EA Repository Librarian CHAPTER 4: ARCHITECTURE METHODS vi EAPM Version 3.0

7 4.1 Starting the Project Project Initiation Project Compliance Review Process Standards Development Reusable Components Development The Architecture Process Definition of Architecture Process Enterprise Architecture Starting Points Enterprise Analysis and Planning Architecture & Project Lifecycles Planning and Architecture Role of Project Architectural Planning Determining Architectural Scope Business Case for Architectural Support Statement of Architectural Work Architecture and Special Initiatives Introduction to Data Warehouse Design and Architecture What is a Data Warehouse? Data Warehouse Architecture CHAPTER 5: ARCHITECTURE PRINCIPLES General Concepts General Concepts of Principles-Driven Architectures Object-oriented Models Templates and Patterns EA Principles Global Architecture Principles Business Architecture Principles Information Architecture Principles Application Architecture Principles Technology Architecture Principles Security Architecture Principles APPENDIX A: OPS EA GLOSSARY... APPENDIX-A APPENDIX B: EAPM ACRONYMS... APPENDIX-B June 3, 2005 vii

8 viii EAPM Version 3.0

9 Chapter 1: EA Architecture Framework

10 Chapter 1: EA Architecture Framework Introduction to EA Frameworks 1.1 Introduction to EA Frameworks Describes architecture frameworks and the Zachman Framework in the context of the Ontario Public Service. Transforming the Ontario Government is an ongoing, multidisciplinary endeavour, involving strategic planning, business process modeling, business planning, enterprise architecture, project management, and systems development. Enterprise architecture (EA) in the OPS is used to define and scope the change initiatives (projects) needed to enable ministry business plans and to ensure that all new information systems contribute to an increasingly integrated government business and technology environment. The architecture of an enterprise is the set of models that represent and describe it. Enterprise models serve as a basis for analysis, aiding managers determine the changes needed to achieve government and ministry goals and objectives. They act as blueprints to guide and coordinate the efforts of those engaged in building new enterprises or changing existing ones. In addition, enterprise models act as standard interchangeable parts as they are re-used within and across enterprises, thereby contributing to the goals of integration and reduced systems development time. EA as a discipline consists of the process and methods used to develop and implement enterprise models. In large organizations, enterprise models are developed in different locations and by different teams, who, unless they work within a common framework, tend to create architecture products that may meet their own requirements but usually cannot be applied elsewhere without a great deal of modification. Accordingly, when an organization wishes to standardize the work products of all its teams who are engaged in any aspect of EA, one of the first measures that must be implemented is to establish a common EA framework. The OPS has adopted the Zachman Framework for Enterprise Architecture, a universal de facto standard, as the basis of a common EA framework to be applied throughout the Ontario Government. The Zachman Framework is a structure for identifying, classifying and organizing the descriptive representations (models) that are significant to the management of an enterprise as well as to the development of the enterprise's systems. Figure 1-1 illustrates the Zachman Framework. Copies may be downloaded from the website of the Zachman Institute for Framework Advancement ( There are four levels of abstraction pertaining to the Zachman Framework, described as follows: The base level is a framework used in the design of a complex product, e.g., an airplane, which is manufactured by an enterprise. Product frameworks could be used in the OPS for organizing the design of entities such as highway systems. This application of the Framework, however, will not be covered in this handbook. 1-2 EAPM Version 3.0

11 The next level is a framework used in the design of an enterprise. According to the logic of the Zachman Framework approach, one EA framework is initiated for each enterprise. In large enterprises that consist of several semiautonomous business units, however, each business unit may be considered to be a sub-enterprise of a larger enterprise. Accordingly, an EA framework may be established to guide the design of each sub-enterprise. In such cases, the EA frameworks for the sub-enterprises are peers of each other and are therefore candidates for integration. This is the level of framework that most people engaged in EA development in the OPS will use and contribute to, either through stand alone EA development projects or through change initiatives. The third level is a framework that defines the models to be created in an EA framework. This kind of framework is referred to as the EA metaframework because it specifies the EA metamodels of the enterprise s models. Metamodels, similar in concept to templates, describe the content requirements of the models to be created in an EA framework for an enterprise or for peer enterprises. An EA meta-framework is the primary means of standardizing the design of models that are created in a body of peer EA frameworks. This level of framework is the primary focus of the EAPM. The fourth level is called the meta-meta level. It is a high level of abstraction providing guidance for the architecture method or approach. Figure 1-1 is a graphical depiction of a meta-meta framework level. Figure 1-1:The Zachman Enterprise Architecture Framework June 3,

12 Chapter 1: EA Architecture Framework Introduction to EA Frameworks The following describes the way in which the Ontario Government has adapted the Zachman Framework approach to EA: The sub-enterprises of the Ontario Government enterprise are defined as the highest groupings of activities that are planned and managed by ministries (identified as Votes and Items in ministry business plans). These enterprises will be architected according to a set of peer frameworks, collectively known as the Federated Frameworks Model (FFM). The FFM is described in more detail in Section 1.2. To ensure reusability of models across all of the FFM member frameworks where appropriate, an EA meta- framework will be established to define the structures and content requirements for all cell models. At the time of writing, a formal EA meta-framework has not yet been established. General guidance for creating models and other EA artifacts, however, is provided in the Checklist Guidebook. Although some architecture content for FFM frameworks will be provided by EA projects or by EA modelers on staff, most will be generated as a result of change initiatives and adapted from designs created as a result of the systems development process. 1-4 EAPM Version 3.0

13 Principles of Framework Definition Principles of Framework Definition General principles for identifying and defining architecture frameworks and their scope, purpose and ownership. The Zachman Framework in the Context of the Ontario Government This section presents the general principles and concepts underlying the definition of an EA framework in the context of the Ontario Government. Just as it is not feasible for all government intentions to be recorded in a single business plan document, it is not feasible to use a single EA framework to encompass the architecture of the entire government. Multiple frameworks based on the government s business planning structure (Votes and Items) will collectively represent the authoritative architecture of the OPS as an enterprise. Additional frameworks, called change initiative frameworks, are used in the systems development process carried out in I&IT projects and contain proposed architecture, which includes models that may be added to or used to change the architecture associated with an authoritative EA framework. General Principles of Framework Definition According to the concept of EA frameworks, an instance of a framework contains all relevant design knowledge about a defined enterprise for a specific purpose. Each framework instance must have: A scope a formal listing of all elements of a specified enterprise that may potentially be modeled (architected). The scopes of the frameworks in the Federated Frameworks Model vary according to levels within the overall Ontario Government enterprise. This concept is addressed later in the Handbook. A goal the goal of any EA endeavour and therefore of any framework used to guide its development is always to achieve higher levels of alignment and integration of business and automation capabilities than would otherwise be possible without EA. The purpose of EA frameworks is operational, meaning the most efficient and effective delivery of programs and services. The goal of a change initiative framework is transformational, meaning the improvement of existing operations. An owner a person who is accountable for achieving the goal of an EA framework, and in the theory of the Zachman Framework, the owner of the Business Model (Row 2) of the enterprise framework. The formal owner of an authoritative framework is the person who is accountable for achieving the goals of the enterprise in question. The owner of a change initiative framework is the sponsor of the transformation represented in the framework. An architect a person who is responsible for translating and representing the vision expressed by the owner for the future state of the enterprise into sets of models according to an accepted EA methodology. June 3,

14 Chapter 1: EA Architecture Framework Introduction to EA Frameworks Overview of Framework Artifacts Provides an introduction to the description of artifacts in the EA Frameworks and commentary on the distinction between rows. Framework Artifacts Overview The following sections highlight the contents of the standard EA Framework and its purposes. Although the EA Framework is based on the Zachman Framework, several adaptations have been specifically designed to address public sector requirements in general and the Ontario Government context in particular. The general instructions provided for Zachman Framework content have been tailored for use in the OPS without compromising framework theory and concepts. In general, the EA Framework uses the following key terminology: Artifact: John Zachman adopted the term artifact to refer to any work product created in the EA process. There are two kinds of artifacts associated with the Zachman Framework: lists and models. Row 1 artifacts are lists identifying all elements that comprise a specific enterprise and that may potentially be modeled and will comprise the enterprise s architecture. The artifacts associated with Rows 2, 3, and 4 the Owner, Designer and Builder Perspectives are models. The artifacts associated with Row 5 are lists (sometimes referred to as listings to differentiate them from the Row 1 lists) identifying the actual enterprise elements that have been developed or acquired. Artifact Definitions: the specifications of the artifacts to be created. The artifacts are defined by name, description, purpose, syntax, content requirements, and, in the case of models, notational standards. Artifact Instance: an actual instance of the architecture or design of a specific thing, such as a process model for a health registration service. This will generally be equivalent to (manifest as) a file or document. The work of managing artifact instances, versions, etc. is the work of an architecture librarian. Model: a representation of something that has been or will be created, e.g., a business process model. Primitive Model: in the context of the Zachman Framework, a primitive model is one whose elements are of a single type (or variable), corresponding to one of the six interrogatives for any of the three perspectives that are associated with enterprise models (Owner, Designer, Builder). The six cell models corresponding to each of the Owner, Designer and Builder perspectives are called primitives because they completely describe the perspectives and do not overlap. They may be thought of as an enterprise s primary building blocks. Understanding the concept of primitive models is essential to understanding and implementing the Zachman Framework approach to EA. Composite Model: a model formed by combining two or more different kinds of elements, e.g., a data flow model, consisting of data and process 1-6 EAPM Version 3.0

15 Overview of Framework Artifacts elements. Composite models are used in the design of business and information systems according to any particular systems development methodology. Reusability: in the context of models, the ability of a model or any of its elements to be shared or reused across an enterprise or in different business and information system solutions. Primitive models tend to be reusable in the designs of different business and information system solutions in the same way, for example, that standard interchangeable parts may be used in different models of automobiles. Composite models tend to be solution specific and therefore generally are not reusable. Transformations and Decompositions The concept of transformation with regards to the Zachman Framework approach to EA is critical to achieving the goal of aligning business planning and the expectations of senior executives with what is eventually implemented as a functioning enterprise. The Business Model (Owner s Perspective - Row 2) is constrained by the scope defined by the Planner s Perspective (Row 1). The Business Model is transformed into a System Model (Designer s Perspective Row 3), which in turn is transformed into a Physical Model (Builder s Perspective Row 4) of the enterprise. Finally, the Physical Model is transformed into tool-specific entities listed in Row 5 and employed in the transformation to implementation (Row 6). In a perfectly designed enterprise, it should be possible to trace any aspect of it back through the various models to the Row one lists. The concept of decomposition pertains to the level of detail in any given cell model where elements may be subdivided the desired number of times. The artifacts in each row are described as follows: Row 1: Scope The Row 1 artifacts identify all of the categories or classes of elements that are of interest to the enterprise and that potentially may be architected (modeled). The main artifact type associated with this row is a list, one for each cell. Row 1 is also called the planner's perspective and organizes the information that defines the total context or scope for the enterprise being represented in the framework. The information is used to ensure that all fundamental elements in the business environment of the program have been recognized. Example: in the EA Framework, service locations is an example of a Row 1 artifact type. Planners may list only in-province and out-ofprovince locations (high level model), or distinguish a regional office from a field office and an embassy from a trade office (decomposition more detailed model). The level of granularity is determined by the need to indicate whether something is in or out of scope. Row 2: Business Model (Conceptual) The Row 2 artifacts (cell models) collectively represent the business of the enterprise. The level of granularity should be sufficient to ensure that all stakeholders can understand and agree with the operating principles or June 3,

16 Chapter 1: EA Architecture Framework Introduction to EA Frameworks functions represented. It is used to reach agreement among those stakeholders on how the enterprise works (or will work) how its functions, structures, and behaviors address the requirements expressed in Row 1. The transformation from Row 1 to Row 2 takes place when the classes of elements that are identified in the Row 1 lists are expressed as the Owner conceives them to be for the enterprise in question. For example, all of the types of locations of interest to the enterprise will be identified in Row 1, and in Row 2 they will be identified specifically by name and by how the enterprise business owners intend for them to relate to each other. The Business Model is considered to be conceptual because it describes conceptually what the enterprise is thought to be or what it is planned to become. Row 3: System Model (Logical) The Row 3 artifacts (cell models) collectively represent the logical (implementation/technology neutral) systems of the enterprise. All enterprise systems may be represented in this row, e.g., the legal system, the accounting system, the business planning system, the library system, the information system, and so on. The System Model is considered to be logical because it describes logically how the enterprise is to be designed. The System Model is the result of considering logical alternatives to transforming the Business Model into a working enterprise. Row 4: Technology Model (Physical) The Row 4 artifacts (cell models) collectively represent physically how the enterprise is intended to be built. The Technology Model is considered to be physical because it represents design decisions for the technology that has been selected to be applied in implementing the systems of the enterprise. 1-8 EAPM Version 3.0

17 Overview of Framework Artifacts Row 5: Detailed Representations (Out-of-Context) The Row 5 artifacts are tool-specific listings of solutions or capabilities employed in the transformation to full implementation. Row 5 artifacts are characterized as out-of-context because the toolspecific components are often built from specifications provided to system developers who need not be concerned with the overall context or structure of the enterprise. Row 6: Functioning Enterprise This is a notional row in the Zachman Framework. There are no models associated with it because it represents the actual enterprise. High-Level vs. Detailed Models In the context of the EA frameworks, the notion of High level model vs. Detailed model must be understood and used carefully. A conceptual model should not be thought of as a high-level model, and a logical model or physical model as a detailed model. Each row of the EA framework can be as general, and high-level has needed or as specific and detailed as the circumstances require. The phrase degree of granularity is a useful description of the measure of level of detail. Generally speaking, each row or model will have criteria based on the general principles expressed above by which the required degree of granularity can be determined, but it should be adapted to the task at hand. Thus, for example, a conceptual model of an area that is well understood by everyone could be signed off with a low degree of granularity [i.e. high-level] by the framework owners and stakeholders. In another situation, a very detailed conceptual model [i.e. very high level of granularity] may be required to gain the understanding and approval of all parties. Business and Automation Architectures Rows 1 and 2 of the EA framework are considered to be business architecture. Generally speaking, the Row 3, 4 and 5 models are where the requirements and details of information and information technology architecture first appear, although this distinction is not intended to be exclusive of business information. Because of this practice however, the line between Rows 2 and 3 is sometimes called the automation boundary, and Rows 3 through 5 are called the automation architectures. Another useful way to think of the distinction between business and automation architectures is to imagine that the business architecture in Rows 1 and 2 should be defined in an implementation independent way, meaning it could be implemented with people and computers, or with people using pens and paper, or with technology almost extensively (a dot.com or an automated factory). June 3,

18 Chapter 1: EA Architecture Framework EA Federated Frameworks 1.2 EA Federated Frameworks Describes the use of multiple frameworks to organize the enterprise architecture information of the OPS. EA programs aim at enabling transformational goals for increased alignment and integration across enterprises and with their partners. Alignment is achieved when all elements of an enterprise and those of its partners contribute to attaining common goals. Integration is achieved when common elements of an enterprise and its partners are used in the process. The underlying principle of EA is that alignment and integration will not occur unless they are formally and proactively designed into the enterprise, which requires all knowledge of the enterprise to be made explicit by means of models that can be aligned with each other and reused wherever possible. Architecting provincial government programs and services is a daunting task. Aligning and integrating services across different government jurisdictions to enable such concepts as single-window of access to citizens is even more daunting. To help make these challenges feasible, the entire architecture endeavour may be divided into smaller, more manageable proportions where sub-enterprises of the larger enterprise are architected separately according to a common architecture discipline that will still enable alignment and integration in the parent enterprise. The Ontario Government s architecture is structured along these lines according to a set of frameworks known as the Federated Frameworks Model (FFM). This section describes the FFM and the overall approach to developing and managing the Government s federated architecture. Working Vocabulary Architectures are explicit design knowledge. An architecture is a formal representation of the design elements of a complex object such as an enterprise. An enterprise is any purposeful endeavour. The Ontario Government is notionally a single enterprise. For business planning and architecture purposes, however, the Ontario Government is a multi-enterprise organization whose enterprises are defined at the highest level by Votes and Items that are approved by Parliament and are managed by ministries. An architecture has a commissioned scope. Commissioning is the governance process which validates the scope of the architecture by specifying the contents of the architecture what is to be included and what is to be excluded. This is important because if an element is to be included, it must be integrated into the total design represented by the architecture, and if it is to be excluded, the architecture does not have to take it into account. Two architectures have overlapping scope if they create or use design knowledge or representations of the same component Federated architectures use common standards for design knowledge and have processes to integrate designs. Architecture frameworks are schema 1-10 EAPM Version 3.0

19 Overview of Framework Artifacts for classifying and organizing architectural knowledge towards some goal or analytic purpose. An implementation of a framework is a mechanism for bounding the scope of an architecture Federated frameworks are multiple framework implementations to manage federated architectures. OPS Enterprise Architecture Knowledge The following figure identifies all categories of OPS EA knowledge and illustrates how it is classified and organized. Figure 1-2: OPS Enterprise Architecture Knowledge and Federated Frameworks The body of OPS EA knowledge is comprised of two main categories of information. The first category consists of all of the information needed to guide and assist all those who are carrying out any assignments related to EA. This information is organized into libraries. The second category pertains to actual architecture, which is classified and organized according to an arrangement of frameworks known as the Federated Frameworks Model (FFM). Each of the elements in the preceding diagram will now be explained in detail. OPS Enterprise Architecture Knowledge Framework The OPS Enterprise Architecture Knowledge Framework is the root framework for the entire EA knowledge base and serves as a single access viewpoint for all artifacts that are associated with any given cell. Artifacts are not assigned directly to it; rather, it acts as a navigational device to all other artifacts and integrating them in a virtual sense. This framework also serves to June 3,

20 Chapter 1: EA Architecture Framework EA Federated Frameworks bind the categories of processes, rules, templates, standards, etc., represented by the left side of the diagram, with the architecture that is made rigorous with it and represented by the right side of the diagram. Meta-framework OPS Federated Framework OPS Corporate Frameworks Corporate Frameork Cluster Frameworks Vote Frameworks Item Frameworks The Meta-framework contains metamodels, or definitions of cell models that are to be created in the federated architecture frameworks. This ensures that any model that is created for any of the federated frameworks may be reused readily in other frameworks and thereby contributes to pan-government integration. The metamodels in the Meta-framework are in human readable form, as documents, and, wherever possible, as model templates in modeling tools. [Note: At the time of writing, the Meta-framework has not yet been established. Guidance for creating models and other EA artifacts is contained in the Checklist Guidebook.] The OPS Federated Framework is a root framework for other frameworks that contain architecture. Its purpose is to present a view of all architecture information contained in the other levels of frameworks - Corporate, Cluster, Vote/Item, and change initiative frameworks. The OPS Corporate Framework is the home framework for architecture that spans more than one Cluster or the entire OPS. It also serves as the parent framework for corporate program architectures. Corporate Frameworks are home frameworks for architectures of corporate programs, e.g., EA Program, HR Management Program, etc. Cluster Frameworks are home frameworks for architecture that is common across Vote and Item architectures, which are developed and managed by cluster I&IT organizations. Votes and Items are business planning terms that relate to groupings of activities aimed at providing programs and services to the public or supporting ministry or government operations. These activities are approved for funding as Votes and Items in the Legislative Assembly and are carried out as ministry programs and services. As such, Votes and Items represent the business breakdown structure of the OPS, the sub-enterprises comprising the Ontario Government Enterprise. EA. Frameworks for Vote and Item architectures will be commissioned with familiar sounding business names, e.g., Natural Resource Management Program. Vote frameworks correspond to major lines of business and are home frameworks for architecture that spans or is common to the programs identified in the Votes. Item frameworks are home frameworks for architecture developed for programs and their services. It should be noted that any of the authoritative frameworks (frameworks that contain authoritative artifacts) may be associated with either public or internal programs. Public programs are defined as those whose target groups are external to the OPS, while the target groups of internal programs are members of the OPS and are more related to government operations. For a more 1-12 EAPM Version 3.0

21 Overview of Framework Artifacts detailed explanation of public and internal programs, refer to the document Defining Programs and Services in the Ontario Public Service. Change Initiative Frameworks Standards and Guidelines Library Topics Library Patterns, Templates and Reusable Components Library Authoritative Artifacts In the context of EA, change initiatives are projects that are considered essential for implementing the target architectures of the enterprises that sponsor them. In mature EA programs, change initiatives for any enterprise ideally stem from a gap analysis of the enterprise s as is and to be architectures. The OPS EA Program is not yet at this stage of maturity because its enterprise architectures, e.g., Vote architectures, have not been completed to the extent needed for analysis. It is not feasible to stop all project activity until all enterprise architectures are completed, and, for the foreseeable future, change initiatives will be expected to contribute architecture content to their sponsoring enterprises, while reusing whatever architecture that may be available in the designs of new business and I&IT capabilities. Accordingly, change initiative frameworks are established to classify and organize architecture and system design artifacts that are produced by project teams so that they may readily contribute to the architectures of their sponsoring agencies. Change initiative frameworks are not limited to I&IT projects or to projects associated with the right hand side of the FFM. They may also be established for projects to create products for the libraries on the left hand side of the FFM. This library is a repository for publications such as GO IT Standards, EA best practices, etc. This library provides views into the entire body of available architecture based on desired topics or themes, e.g., water management, privacy, organization, domain, etc. [Note: This description implies that this library will contain the results of searches, perhaps in the form of static documents. As such, they may not be up to date as more architecture content becomes available. A more dynamic capability to see views of architecture may be available through the EA Repository when it is implemented.] This library is a repository for elements of designs that may be reused as required, e.g., a client-server pattern. The concept of Authoritative Artifacts as shown in Figure 1-2 refers to all such artifacts as having gone through an approval process and have been authorized for use as enterprise architecture or to develop enterprise architecture. Architecture artifacts associated with change initiative frameworks do not become authoritative as EA artifacts until they undergo a formal approval process. June 3,

22 Chapter 1: EA Architecture Framework EA Federated Frameworks Explanation of Icons Used in the FFM Diagram Implications of the Federated Frameworks Approach Federated Frameworks Model Conventions First Convention - Accountability The icons associated with frameworks are miniature representations of the Zachman Framework, indicating actual architecture content or navigation to architecture content. The icons associated with the libraries are miniature folders with small frameworks contained therein. This represents the idea that while some of the content may not be directly related to Zachman Framework artifacts some may provide guidance or other information associated with specific cells of the Framework. The OPS EA Program s federated approach to the development of EA implies more than the division of responsibility for the development and management of EA content. The OPS EA Program is also federated in the following senses: Each cluster has considerable latitude in the development of its EA capability and its approach to EA service delivery. The Corporate Architecture Branch and the clusters contribute jointly to the development and approval of EA methodology and follow agreed-upon methodology. Each cluster participates in the management of the EA Program through its participation in the Architecture Core Team (ACT) and the Architecture Review Board (ARB). There are several conventions that explain the basic function and interrelationship of the different types of frameworks in the Federated Framework Model. The first convention is that artifacts are bound to one or more frameworks. One framework is considered its home and establishes accountability for the artifact EAPM Version 3.0

23 Overview of Framework Artifacts Figure 1-3: The first convention of the Federated Frameworks Model There are no assumptions regarding the physical location of any artifact. An instance of a framework is treated as a window into the repository, wherever it may be located physically. An artifact may appear in one framework or many, and is said to be attached or bound to the framework(s) in which it appears. The owner of the framework who has the final say on the artifact is accountable for that artifact, and the framework in question is said to be the home framework for the artifact. (The term artifact pool in the preceding diagram simply refers to all available artifacts under consideration.) Second Convention - Inheritance The second convention in the Federated Frameworks Model means that attaching an artifact to a framework that is a subordinate framework, automatically attaches it to the superior framework in the group. June 3,

24 Chapter 1: EA Architecture Framework EA Federated Frameworks Figure 1-4: The second convention of the Federated Frameworks Model The second convention means that higher-level frameworks can be considered to consolidate the architectures in lower level frameworks. This makes it possible to address higher-level views of the architecture such as organizational views and to address higher levels of integration across multiple frameworks. Third Convention - Projection The third convention is that a single framework instance can be intentionally attached to or grouped within many different and independent presentations. The third convention is a very important convention. It means that a pattern, template or re-usable component, in the form of an artifact, or a whole framework of artifacts, can be attached to one or more frameworks, and the artifacts in the pattern will appear in the appropriate row and column of every framework they are attached to. If an artifact is changed in the pattern, its new form will appear in the frameworks into which it has been projected. This is relevant to standards and guidelines artifacts as well, which provide guidance to the architect in terms of how to carry out business and technical design tasks. The EA Repository, which is being implemented at the time of writing, will be capable of allowing a user to query a given artifact to determine if an authoritative pattern was used in creating it. The architect would then know that some enterprise commonality was applied. In the future, if the pattern is changed, a query could be invoked to determine the impacts on the EA artifacts that were created from the pattern EAPM Version 3.0

25 Overview of Framework Artifacts Figure 1-5: The third convention of the Federated Frameworks Model Fourth Convention - Embedding The fourth convention is that a single framework instance can be intentionally embedded within multiple frameworks as an artifact to represent a complex object. The fourth convention is the means by which the Federated Framework Model is used to manage the complexity of the architectures as these continue to be developed in more and more detail. June 3,

26 Chapter 1: EA Architecture Framework EA Federated Frameworks Figure 1-6: The fourth convention of the Federated Frameworks Model In the preceding figure, a pattern has been established in the Patterns, Templates and Reusable Components Library either as an individual artifact intended for one particular row and column, or as a group of related pattern artifacts appearing in several cells of a framework, such as a complete set of context row artifacts. By attaching the individual pattern artifact or entire pattern framework to a target change initiative or authoritative services framework, the pattern is available to the architects working with the target framework, and changes made to the source pattern may be reflected in the target framework. Architecture Domains Architecture domains are components of an EA requiring specialized expertise. The OPS EA Program recognizes five architecture domains: Business Architecture Domain Information Architecture Domain Application Architecture Domain Technology Architecture Domain Security Architecture Domain Each architecture domain is the focus of attention of working groups who provide guidance for creating models and other artifacts associated with their specialized areas of expertise. The Zachman Framework approach to EA provides a convenient framework for integrating and harmonizing the work of 1-18 EAPM Version 3.0

27 Overview of Framework Artifacts the domain architecture working groups, as illustrated in the following figure showing their spheres of interest. Figure 1-7: The Architecture Domains Mapped on a Framework The domain architecture working groups produce and publish guidebooks relating to their areas of focus as follows: Working Group Business Architecture Domain Information Architecture Domain Application Architecture Domain Technology Architecture Domain Security Architecture Domain Guidebook Defining Programs and Services in the OPS Information Modeling Handbook for the OPS Application Architecture Guidebook [Not yet available.] [Not yet available.] June 3,

28 Chapter 1: EA Architecture Framework EA Federated Frameworks Each domain architecture addresses alignment and integration issues in many dimensions. The Federated Frameworks Model is intended to enable integration both within individual instances of a framework, and across multiple frameworks. Domain architects depend on several elements of the EA program to ensure alignment and integration across frameworks: Design standards, including those for artifacts associated with the EA Federated Frameworks Model, and other standards as well: technology, best practices, etc. which are defined in the Standards Library described later in this chapter. The compliance and certification processes associated with corporate and cluster Architecture Core Teams (ACTs) and Architecture Review Boards (ARBs). Use of patterns, templates and re-usable components, making the task of designing faster, less costly, and more robust. As is and To be Architectures The as is architecture of an enterprise is comprised of the sets of models that represent it s current state. The to be architecture of an enterprise, also known as target architecture, consists of the sets of models that represent its envisioned future state. Implementing target architecture requires the following steps: Performing a gap analysis of the present and envisioned future states of the enterprise in order to identify the deficiencies that will need to be resolved to enable the target architecture. Performing an affinity analysis on the target architecture in order to identify requirements that may be satisfied with common means (i.e., engineering commonality into the enterprise). Defining and scoping the change initiatives that will need to be undertaken over the planning period (i.e., the period covered by the enterprise s business plan) in order to bring about the envisioned changes. Approving and implementing all identified change initiatives. Assessing any additional proposed change initiatives for compliance with the approved corresponding target architecture. After the changes have taken place, the target architecture becomes the new as is architecture. As can be seen, the process of implementing target architecture begins with analyses that require as is and to be architecture to be available. In the Zachman Framework approach, the two states of architecture may be recorded in two ways, either by creating and denoting as is and to be models for each cell in a single framework for an enterprise or by establishing two separate frameworks, one for the present state and one for the target state. The latter is considered to be the most practical approach EAPM Version 3.0

29 Vote and Item Architecture Frameworks Vote and Item Architecture Frameworks Describes the concepts and use of Vote and Item Frameworks Votes and Items Vote and Item Frameworks Programs EA Ownership and Custodianship A Vote is a business planning term for a broad segregation of spending authority for some intended purpose, such as expenditures for a group of programs or for capital investments. A Vote corresponds to the highest level grouping of activities that is planned and managed by a ministry. As an enterprise to be architected and implemented, a Vote equates to one or more of a ministry s programs. An Item is a subdivision of a Vote and corresponds to a significant activity such as a program that is planned, funded and managed by a ministry. Votes and Items have been selected as the basis for Ontario government s EA to help align government objectives in the form of planned outcomes described in ministry budget submissions, with actual outcomes achieved by ministry programs. The role of EA is to aid in the design the ministry enterprises, or to make changes to existing enterprises, that are needed to achieve the goals or outcomes that ministries are mandated to accomplish by virtue of their Votes and Items submissions having been approved by the Legislative Assembly. A rule of thumb for establishing EA frameworks is to create them for the levels within an enterprise for which alignment and integration of resources and activities is most desired. In the ministry business planning process, the activities that are grouped and covered by Votes are already based on some affinity or commonality, such as client types. This makes it desirable in theory to establish a single framework for architecting a Vote-based program or set of programs. If this proves to be unwieldy in practice for any situation, then it may be appropriate to establish Item-based frameworks under their parent Vote-based frameworks. Cluster EA teams must decide on the most feasible approach for their jurisdictions as to whether frameworks are required for Items in addition to the Votes associated with the ministries that they support. Whether a given EA Framework is based on a Vote or an Item, the implemented management structures are programs. Accordingly, the plain language names given to Vote and Item architecture frameworks should correspond to the names of ministry programs. Detailed information regarding the definition and profiling of programs for EA purposes is available in the publication Defining Programs and Services in the Ontario Public Service. The two key roles in any EA program are owners and architects. The formal owner of an enterprise s architecture is the most senior executive who is accountable for the enterprise achieving the outcomes that the enterprise has been mandated to bring about. In the context of the OPS EA Program and federated frameworks, the owners of the frameworks and associated June 3,

30 Chapter 1: EA Architecture Framework EA Federated Frameworks architecture content are program managers or their superiors, depending on the scope of any framework. In the most mature of EA programs, EA owners provide subject matter expertise for the creation of their enterprise s as is and to be architectures. They endorse their architectures as they become ready for review, as well as the analysis that results in the required action plan and change initiatives needed to enable the envisioned target architectures. They are also involved in decisions regarding the need for any deviations from the action plan in light of the approved target architectures. EA owners do not need to be knowledgeable of EA methodology, the Zachman Framework, etc. They must, however, understand the concepts and benefits associated with EA and for the kind of work and level of effort needed to make it work effectively. At the time of writing, the OPS business community is not yet as engaged in EA to the extent that has been described, but progress is being made. The role of the EA architect is to be the expert in EA process and methodology and to lead or provide direction for the formal modeling work that results in the creation of architecture. The EA architect also leads EA analysis work that leads to defining and scoping change initiatives. Finally, the EA architect is the custodian of the artifacts resulting from the EA program and ensures their life-cycle management EAPM Version 3.0

31 The EA Meta-framework and Libraries The EA Meta-framework and Libraries Describes the EA Meta-framework and Libraries used to support EA. The EA Meta-framework [Note: At the time of writing, the EA Meta-framework has not yet been established for the OPS EA Federated Frameworks. This section explains what it is and its importance in relation to the development of architecture across the OPS.] The success of the federated frameworks approach to EA that has been adopted by the OPS is predicated on the ability to share models across the entire body of frameworks, or subsets of them, as required. If a model of a particular process has been approved as a standard, for example, it ought to be applied in any program that uses that process. This promotes integration of government programs and saves modeling time. The ability to share models, however, is seriously impeded if models are not created according to specifications that define the content and structure requirements for each kind of model. A registration process designed for Program A, for example, may not contain sufficient information to satisfy the design of a registration system in Program B, and therefore may not reused readily in Program B s architecture. Defining the content requirements for the various kinds of models that are identified in the Zachman Framework and that are meant to apply to all federated EA frameworks is the purpose of the EA Metaframework. The kind of models that it contains are said to be metamodels of the cell models that form the architecture content of the federated EA frameworks. The following figure illustrates the relationship between EA metamodels and models. The concept of using elements of models in system designs that lead to implementations that in turn contribute to an increasingly integrated I&IT infrastructure is also illustrated. June 3,

32 Chapter 1: EA Architecture Framework EA Federated Frameworks Figure 1-8: Metamodels, Models and System Designs The preceding figure depicts an ideal situation whereby models have been created for the federated EA frameworks based on a common set of metamodels. The figure also shows three projects that have been chartered to develop I&IT solutions. In this case, system designers assigned to Project A and B, which are sponsored by their program whose architecture has been captured in the framework as shown, have used elements of authorized models when creating their system designs. Similarly, Project C s system design has been created from elements of the models from its sponsoring program. Figure 1-7 highlights a most important and fundamental need for EA. In order for an enterprise s I&IT infrastructure to be integrated and aligned with the goals of the enterprise, the designs of every implementation that contributes to the infrastructure must be based on architecture that has been engineered for commonality and alignment. As stated previously, the OPS EA Program is not yet at the stage where the concept illustrated in Figure 1-8 can be put into practice. In fact, for the foreseeable future, many change initiatives will be contributing more content to the architectures of their sponsoring programs than they will be withdrawing EAPM Version 3.0

33 The EA Meta-framework and Libraries A future update of the EAPM Handbook will include a more detailed discussion of the EA Meta-framework with descriptions of the metamodels for all of the Zachman Framework cell models. The Standards and Guidelines Library The Standards and Guidelines Library contains standards, guidelines, and best practices for enterprise architecture, domain architectures, and systems development. Some of the content in this library is broad in scope, e.g., the EAPM Handbook. Some pertains to particular areas of expertise, e.g., information architecture and the Information modeling Handbook for the OPS. IT standards play an important role in the development of technology architecture (Row 4) and the development or selection of technical solutions (Row 5) to meet enterprise requirements. There are four categories of IT standards: Technical Standards describing Protocols, Specifications, Common Data Formats and APIs. Functional Criteria for product selection where technical standards are not sufficient to ensure interoperability. Development guidelines describing methods (best practices) for application development and implementing code using specific protocols, API and data formats. Architecture models describing the design models for a logical enterprise architecture to meet specific business needs. As projects and initiatives are reviewed, existing systems, products, and technology will be assigned a status. Transitional and obsolete standards in any row of the framework will need to be phased out over time. The Topics Library Patterns, Templates and Reusable Components Library The idea behind the Topics Library is to provide a repository for customized views of the growing body of knowledge within the federated EA frameworks, e.g., all artifacts pertaining to training. This library has not yet been established and it is possible that it may be more virtual than physical if the EA Repository that is under development at the time of writing is capable of providing dynamic searching for any subject area. This library contains special forms of artifacts patterns, templates and reusable components which are intended to be incorporated into architectures via change initiatives. Patterns, templates and re-usable components may be single artifacts or groups of artifacts intended to be used together. They will arise from several different sources: from industry standards adopted by the OPS; from projects tasked with identifying and building them; from analysis of common reoccurring patterns, etc. in existing architectures carried out by corporate, cluster and project architecture functions. The governance process must ensure that these are managed and made available to all projects as appropriate. June 3,

34 Chapter 1: EA Architecture Framework EA Federated Frameworks Generally, the contents of these frameworks are intended to be copied and used in change initiative frameworks. We will use the following conventions when speaking of the contents of these frameworks: Patterns are intended to be instantiated by making a copy of the original artifact and modifying or adapting it. The instantiation may or may not be required to continue to be related to the original pattern. The instantiation may or may not begin a separate version history. Templates are intended to copied and configured, filled out, completed, without altering or adapting the original template. A form is an example of a template. The configured instance may or may not be required to be related to the original template. The configured instance may or may not begin a separate version history. Reusable Components are intended to be used as found without modification or with only allowable modification as in configuring. The new component may be an exact copy of the original or it may in fact be the original. The new component may or may not be required to remain related to the original. Versioning is a general requirement for pattern, template and re-usable component artifacts as well as actual design artifacts, and must be supported by the EA Repository that will ensure that the history of any artifact is fully known. The EA Repository will play the major role in determining what types of reuse can be supported, and how the reusable components will be accessed and incorporated into new designs. In the initial implementation, this will be primarily a manual function performed by librarians and architects. In the initial implementation, it is possible to make changes to artifacts in patterns and templates and the changes will be visible to architects working in all frameworks into which those patterns, templates, have been projected. However, if they have made copies of the patterns, the changes in the original pattern will not be reflected in the copies. This type of feature awaits the next round of repository implementation EAPM Version 3.0

35 The EA Meta-framework and Libraries 1.3 Managing Architectural Knowledge Describes the elements to be managed and the approach and tools for managing change to the architectures. The following sections discuss the elements of the architectural knowledge to be managed and the approach and tools for managing them. The key elements to be managed include: Frameworks Artifacts The number of frameworks is expected to be significant over time as architecture is developed for Votes, Items, programs, etc. EA frameworks may be managed in two versions: as is and to be. As to be architecture are implemented, the former as is architecture and framework may be archived. In general, the life cycle of an EA framework parallels the life cycle of the enterprise that it describes. If the government eliminates a program, or merges it with another, then its EA framework will either be archived or merged with another. Change initiative frameworks are archived once projects are terminated and their artifacts are assigned to their sponsoring authoritative EA frameworks. In the context of EA, an artifact is an architecture product something created as a result of some activity in the OPS EA Program. The EAPM Handbook is an artifact, for example, as are individual diagrams, lists, etc. They exist in different versions, and are always attached to a home framework or library (to establish accountability) and also to one or many other frameworks (if they describe elements common to all or shared by many designs). Artifacts have a lifecycle they are created (often by copying other artifacts), evolve, and become obsolete. Artifacts are produced by tools simple tools like word processors and spreadsheets, and complex tools like CASE tools. Artifacts tend to be tangible, fixed content documents, most suitable for human readability or presentation. Primitives In the context of the Zachman Framework, primitives refer to the contents in Rows 1 to 5 of the framework. They are called primitive because of the logic behind the six interrogatives that differentiate them. For any given Row or Perspective, the answers to the six interrogatives describe completely the enterprise perspective in question, and they do not overlap. They comprise the primary building blocks of the enterprise. The primitives that make up Rows 1 and 5 are lists. The primitives that comprise Rows 2, 3 and 4 are models. A well-formed primitive model consists one or more elements of a single type or variable, e.g., only data elements OR only process elements OR only organization elements, etc, and a defined relationship with itself. John Zachman advocates designing enterprises as sets of primitives because primitives are easier to integrate and change than composite models. June 3,

36 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Primitives may be managed as artifacts. However, a best practice calls for managing architecture as data for ease of analysis, navigation, correlation, and management. Regardless of how they are maintained, as artifacts or as elements in a repository s database, primitive models must be versioned and must be subject proper life cycle management with assigned custodians, who are responsible for maintaining them, and owners who are responsible for the currency and accuracy of the primitives contents. Metamodels Composites Other Metamodels are the sets of definitions of the 30 primitives in an EA framework. They may be managed as artifacts for presentation purposes, but their primary form will be as templates in EA modeling tools. They must be versioned and assigned custodians and owners. [Note: At the time of writing, the EA Meta-framework and metamodels to be used in the creation of primitives in EA frameworks have not yet been created. Until that time, artifact definitions found in the Checklist Guidebook are to be used instead.] Composites are design products that are composed of different kinds of elements. A data flow model, for example, may contain data elements and process elements. System development methodologies require composites, and a given set constitutes the design of a point-in-time solution. A longterm goal is for all designs of I&IT solutions to be created by selecting and combining appropriate elements from the primitive models in the architecture of the change initiative s sponsoring enterprise. Composite models comprise an important part of an I&IT solution s design and as built documentation and must be maintained at least as long as the I&IT solution is in operation. This short list of architectural framework constructs to be managed is not meant to indicate that there are no other forms of information pertinent to architecture. There are many documents containing plans, evaluations, and strategies that must be managed as part of the overall architecture function, usually by document management systems. However, the challenge is to manage the architectural framework constructs identified above, and provide appropriate levels of access, security and functionality (searching, filtering, analyzing, testing) for practicing architects and architecture librarians EAPM Version 3.0

37 General Concepts of EA Development and Management General Concepts of EA Development and Management Describes in general terms the major concepts associated with the development and management of architecture within the context of the Federated Frameworks Model. Principle of Alignment This section outlines the principles to be used in the operation of the Federated Frameworks Model. What is alignment? Alignment with Target Architecture Design Alignment Alignment in the context of an enterprise is the state that is achieved when the physical implementation of an enterprise the funding, the staff, the systems, the infrastructure, etc. is entirely accounted for and aligned with the mission and goals of the enterprise as expressed by senior management in strategic and business plans. An aligned enterprise is one whose resources are all employed to achieve enterprise goals and nothing else. There are two ways in which EA aids in enabling alignment. The first, for any given enterprise, is to compare its target business architecture with current capabilities for the purpose of identifying the changes that would be needed in order to implement the target architecture. With this approach, change initiatives are not defined or approved for any enterprise until such a gap analysis is completed. Accordingly, change initiatives and whatever they implement are automatically aligned with target architecture. The capability has not yet been developed in the OPS EA Program to carry out this approach, largely because the resources, methods and skills to create top-down target architectures are not yet available. The second way to enable alignment is for change initiatives to follow an approach in the design of capabilities such that all levels of design from conceptual to physical are aligned with each other when meeting the requirements of a defined business requirement of the change initiative s sponsoring enterprise. This approach is the current focus of the OPS EA Program. Change initiatives that are considered to be prime candidates for the reviews that are needed to confirm alignment are of most interest to the OPS EA Program. Besides the normal documentation associated with project management, these change initiatives initiate frameworks, based on the Zachman Framework, and create specified mandatory and optional design artifacts per the Checklist for Change Initiatives document and its accompanying Checklist Guidebook. Alignment is confirmed by means of checkpoint reviews by an Architecture Core Team (ACT) or Architecture Review Board (ARB), often with representation from various architectural domains. The three main checkpoint reviews occur at the following stages: June 3,

38 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Principle of Integration Checkpoint 1: Also known as the Business Architecture of the project. The artifacts involved in this checkpoint involve the Scope/Contextual/Planner and Owner/Conceptual artifacts that occur in Rows 1 and 2 of the Zachman Enterprise Architecture Framework. Checkpoint 2: Also known as the Logical Architecture of the project. Artifacts for this checkpoint are developed with a Systems/Logical/Designer perspective and are based on further elaborations of the artifacts produced during Checkpoint 1 development phase. Checkpoint 3: The final physical description, through detailed artifacts and representation, of the technology implementation of the project presented from the Builder/Sub-Contractor perspective. The purpose of the reviews is to ensure that the models align with the business requirement for the change initiative and with each other, leading to the implementation of a new or changed capability. In addition, the various models created by change initiatives are assessed for compliance with any applicable enterprise and domain-specific standards. What is integration? How is integration achieved? Architectural Product Lifecycles Integration in the context of an enterprise is the use of common means to achieve enterprise goals, e.g., common staff, processes, infrastructure, data, etc. The chief benefit of integration is efficiency if fewer resources overall are used in the activities needed to achieve the mission and goals of the enterprise. Integration is achieved by actively engineering commonality into the enterprise, preferably from the top down. This is done by creating and reusing common enterprise models to use in business and system designs so that implementations contribute to increasingly integrated business and I&IT environments. A full set of reusable models for any enterprise is not yet available to business and system designers, however, and in fact may never become available due to the size and complexity of the Ontario Government and its programs. Reusable models are gradually accumulating, however, either by direct architecture work or as by products of change initiatives. As models become available they are certified as authoritative and assigned to their home frameworks, where they await reuse in change initiative designs wherever possible. Reuse of available enterprise models is addressed in the checkpoint reviews. The architectural product lifecycle for any artifact is represented in the state diagram below. The lifecycle assumes a number of basic architectural processes that change the status of a product as appropriate. All artifacts will move through these lifecycle states either explicitly or implicitly EAPM Version 3.0

39 General Concepts of EA Development and Management Figure 1-9: Generic Architecture Product Lifecycle Generic Architectural Product Lifecycle Commission Develop / Refine Revise (Next version) Approved Created Submit for Approval Revise Revise Endorse for Approval Endorsed Decommission Proposed Propose for Approval Retire Retired Retire Retire States in the diagram The following observations apply to the states in the diagram: Created Proposed Architectural product construction has been commissioned by some party and designed by some party In this state the architecture product may be known, but does not have official acknowledgement. Product design changes and revisions are done only in this state. The architecture product has been put forward for certification by at least one party, not necessarily the commissioning or creating party The proposal incorporates all appropriate pre-requisite attributes such as security level, sharing level, required use, etc. In this state, the product is considered officially acknowledged and all parties are considered to be put on notice that there may be implications to them as a result of the existence of this product. In this and all subsequent states the product is frozen for change. If the product must be changed to reflect integration and/or any other project or enterprise requirement, its status will be reset to Created. June 3,

40 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Endorsed Approved Agreement to the proposal for certification has been given by at least one party in addition to the proposing party In this state, the meaning of endorsed is that the product s implications for endorsing party or parties has been accepted by them. Agreement to the proposal and implications has been given by all relevant parties This states reflects the intended final state of the product and documents its provenance and history. Evolution of Architecture Product The following diagram captures the evolution of an artifact starting in a project framework and ending in any of the authoritative frameworks public/internal services frameworks, library frameworks, etc. Figure 1-10: ArtifactEvolution Artifact Evolution Commission Develop / Refine Revise (Next version) Approved ( Project Approved ) Submit for Commissioning Develop / Refine Authoritative Revise (Next version) Approved ( Authoritative ) Authorization Created Created Submit for Approval Revise Revise De-commission Endorse for Approval Submit for Approval Revise Revise Endorse for Approval Decommissioning Proposed Endorsed Retire Proposed Endorsed Propose for Approval Retire Retire Propose for Approval Retire Retire Retire Retired Project The Submit for Authorization process accomplishes Promotion of artifacts from non-authoritative to authoritative frameworks. By attaching or binding the promoted artifact to an authoritative framework, this process in principle changes the home or owning framework of the artifact from some project framework to some authoritative framework, and this is the mechanism by which it is declared authoritative. Note that this process does not copy the artifact to the new framework an artifact may be attached to 1-32 EAPM Version 3.0

41 General Concepts of EA Development and Management many frameworks, only one of which is considered its home (although there are physical considerations involved with repositories and tools which may mean that artifacts will actually be copied as an implementation mechanism for promotion). Appropriate metadata changes to both the artifact and the originating and receiving frameworks will reflect the transaction. The processes associated with an artifact s states in relation to the project framework will be primarily project and cluster responsibilities. The processes associated with an artifact s states in relation to the authoritative frameworks will be primarily cluster and corporate responsibilities. The processes associated with state changes in relation to the authoritative framework reflect the potential for streamlining or normalizing or generalizing the artifact to conform to the particular framework s requirements. However they are the same processes in principle as those related to the project framework. June 3,

42 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Authoritative vs. Project Frameworks Describes the frameworks containing authoritative artifacts and the relationships of project and authoritative frameworks. Authoritative Frameworks The EA Federated Frameworks Model distinguishes strongly between Authoritative Frameworks and Change Initiative Frameworks. In this section, the movement of artifacts between project and authoritative frameworks is explained. The Authoritative Frameworks contain artifacts that have been reviewed and certified or approved. This can come about in two fundamentally different ways: Because the artifact describes something which already exists, e.g., an existing business process. This kind of artifact is often called an as-built artifact, meaning it describes something that has been designed and implemented. Such artifacts contribute to an enterprise s as is architecture. Because the artifact describes something, which, although it does not exist yet, has been approved for construction, and will likely be constructed. Such artifacts contribute to an enterprise s target architecture. The term authoritative means that the models contained in those frameworks, if shown to be relevant to some proposed change, must be taken into account. The responsibility for determining relevance lies with the owners of the frameworks containing the authoritative information, and the owners of the frameworks containing the proposed changes (change initiative frameworks). The following figure identifies the kinds of frameworks that are deemed to be authoritative compared with Change Initiative Frameworks EAPM Version 3.0

43 Authoritative vs. Project Frameworks Figure 1-11: Authoritative Frameworks Change Initiative Frameworks The term change initiative refers to an activity, such as a project, that has been established to bring about an approved change within the OPS, such as, for example, the automation of a process that previously was carried out manually. Any project whose mission is to change any aspect business process, technology, etc. of a government program is of primary interest to the OPS EA Program, for two reasons. First, the mandate of the OPS EA Program is to support and harmonize the work of projects so that whatever they implement assists in enabling the target architectures of their sponsor enterprises and contribute to increasingly integrated business and I&IT environments. Second, the resources currently assigned to the OPS EA Program are not sufficient for all enterprise architecture to be developed from the top down as a separate activity. Accordingly, it is necessary to require projects to contribute content to EA frameworks as part of their systems development work. Some artifacts may remain entirely unchanged from the when they are copied from their home framework and attached to a Change Initiative Framework. It represents a mandatory or common design elements that must be incorporated into the design of the solution that will result from the project. Some artifacts may be copies of authoritative artifacts, with proposed changes. These elements could be versions of the originals and would then be tracked, certified and approved as the project moves through the stages of architecture development and review, taking into account the fact that the result may be several versions of the same artifact that could all be authoritative in different settings. June 3,

44 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Some artifacts will be brand new and will be subject to normal review and approval as the project moves through its life cycle. Most new artifacts originate from the Change Initiative Frameworks process. New artifacts that have been approved as part of a project review process are certainly authoritative in some sense. If it is clear what Authoritative Framework they should be assigned to, and the Authoritative Framework already exists, then the approved artifact is explicitly assigned to the Authoritative Framework as its home. If there is no Authoritative Framework for new artifacts, then an Authoritative Framework will be created by a joint cluster and corporate process. The following figures illustrate the four main steps in this process. Figure 1-12: Identifying Artifacts Requirements The first step involves reviewing the Checklist for Change Initiatives to identify all of the mandatory and optional artifacts that will be required for the particular project. Figure 1-13: Importing Artifacts Assuming that any given project is sponsored by some OPS enterprise, such as that represented by a Vote or Item for which an authoritative EA framework has been established, the next step is to review the artifacts that may have already been created for that enterprise and import any that may be applicable into the project s Change Initiative Framework. The difference between the artifacts that were identified in Step 1 and the ones that were found to be applicable in Step 2 is the set of new artifacts that must be produced by the project EAPM Version 3.0

45 Authoritative vs. Project Frameworks Figure 1-14: Creating New Models/Artifacts Guidance for creating primitive models is found in the EA Meta-framework in the form of metamodels or templates for adding model content to. [Note: The EA Meta-framework is not yet established at the time of writing.] Guidance pertaining to primitive models (until available in the EA Metaframework) and composite models is also available in the Checklist Guidebook. Figure 1-15: Exporting Artifacts Lastly, after a project has implemented whatever it was commissioned to do, the new primitive models that were created for its Change Initiative Framework are reviewed and if deemed acceptable they become authoritative by virtue of being incorporated into the project s sponsoring authoritative EA framework. June 3,

46 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Architecture Framework Maintenance Describes the approach to maintaining the Federated Frameworks and using the initial FSI Structure Software tool Artifact & Framework Management Processes The following processes will be recognized in architecture framework and artifact maintenance scenarios: Framework Management Processes: F1. Commission F2. Submit for Approval F3. Propose for Approval F4. Endorse for Approval F5. Submit for Authorization F6. Decommission F7. Retire Artifact Management Processes: A1. Commission A2. Submit for Approval A3. Propose for Approval A4. Endorse for Approval A5. Submit for Authorization A6. Decommission A7. Retire Since Decommissioning and Retirement are unlikely to be used in the short term these will not be addressed in detail in this version of the EAPM Handbook. The scenarios assume certain governance roles that have been defined in general, but which must be interpreted by each cluster and project in their own context. Within a project environment the existing governance structure will play the roles indicated in the scenarios. The following roles are proposed in the scenarios. The governance models for projects, clusters and the corporate EA function will determine the final roles EAPM Version 3.0

47 Architecture Framework Maintenance Project Team Librarian Architecture Team Endorser Approver Individual designers and architects developing artifacts in the project context. Generic repository librarian role whose scope depends on the context of the scenario: project, cluster or corporate (enterprise). Generic role that, depending on the context, applies project, cluster and/or enterprise perspectives to evaluate an artifact s architectural fit. Generic role that represents a party endorsing the approval of an artifact, in a project, cluster or corporate context. Generic role that represents a party approving the architectural fit of an artifact in a project, cluster or corporate context. Currently, Structure 2001 is being used as the EA repository tool for indexing and classifying artifacts using the Zachman framework. The FSI Structure tool requires that the individuals charged with managing the artifacts and their repository metadata work with the physical artifact files outside the tool, i.e. directly using the host file system. This creates the need for clearly defined administrative manual processes to manage the repository (FSI Structure database and file system directories.) The following diagrams depict the way those repository users will interact with the environment. June 3,

48 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Figure 1-16: Working with Structure - The architect's view Figure 1-17: Working with Structure - The librarian's view The following tables describe the different scenarios to be used in the lifecycle management of frameworks and artifacts. The tools used in the scenarios are the following: Scenarios for the use of tools in the lifecycle management of frameworks and artifacts 1-40 EAPM Version 3.0

49 Architecture Framework Maintenance Artifact Creation Tool The OS File System (Currently Windows NT) FSI Structure The appropriate native form artifact creation and maintenance tool such as a CASE tool (e.g. System Architect, Rational Rose), a word processing (e.g. MS Word) or electronic spreadsheet (e.g. MS Excel) tool, a drawing tool (e.g. VISIO) The file management tools supported by the Windows OS (including the security administration tool) The repository tool selected by the OPS Framework Lifecycle Management These scenarios describe the management of the lifecycle of frameworks. These are notional scenarios that will be refined with use over time. The specific metadata required for the creation of a framework is described under separate cover. Figure 1-18: Framework Lifecycle Management Scenario F1 Framework Commissioning June 3,

50 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Figure 1-19: Framework Lifecycle Management Scenario F2 Submit Framework for Approval 1-42 EAPM Version 3.0

51 Architecture Framework Maintenance Figure 1-20: Framework Lifecycle Management Scenario F3 Propose Framework for Approval Figure 1-21: Framework Lifecycle Management Scenario F4 Endorse Framework for Approval June 3,

52 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Figure 1-22: Framework Lifecycle Management Scenario F5 Endorse Framework for Approval 1-44 EAPM Version 3.0

53 Architecture Framework Maintenance Artifact Lifecycle Management The newly created or submitted artifacts are described by items of metadata defined under separate cover. Figure 1-23: Artifact Lifecycle Management Scenario A1 Artifact Commissioning June 3,

54 Chapter 1: EA Architecture Framework Managing Architectural Knowledge Figure 1-24: Artifact Lifecycle Management Scenario A2 Submit Artifact for Approval Figure 1-25: Artifact Lifecycle Management Scenario A3 Propose Artifact for Approval 1-46 EAPM Version 3.0

55 Architecture Framework Maintenance Figure 1-26: Artifact Lifecycle Management Scenario A4 Endorse Artifact for Approval Figure 1-27: Artifact Lifecycle Management Scenario A5 Submit Artifact for Authorization June 3,

56 Chapter 1: EA Architecture Framework Managing Architectural Knowledge The submit for authorization process attaches the artifact to the appropriate authoritative framework. Once the Repository Librarian validates the artifact, the subsequent processes are the same as the previous 4 scenarios EAPM Version 3.0

57 Architecture Framework Maintenance 1.4 Access to Architecture Knowledge Section discusses the types of knowledge and the approaches to creating and finding it in the Federated Frameworks Model This part of the EAPM Handbook addresses important questions about the nature of architectural information and access to that information in different forms. The following subsection What is Relevant Architecture Knowledge? discusses an important set of definitions concerning artifacts, primitives, and composites. June 3,

58 Chapter 1: EA Architecture Framework Access to Architecture Knowledge What Is Relevant Architecture Knowledge Discusses the types of architecture information and the reasons for needing access What Constitutes Architecture Knowledge? This is an important question and architects should be aware of the strategy for addressing this in the OPS. Today we have an approach that is designed to achieve several near and mid-term goals (Near-term) alignment of major business and infrastructure projects by means of more standardization of design products and design reviews Share as much architectural and design knowledge as possible as soon as possible (Mid-term) management of change through better and more standardized information about existing designs, enhancing the effectiveness of standards for design products and design review processes. One goal of architecture has always been to reduce the costs and construction time for new business processes and systems through the engineering-based approach of re-usable components but this is a longer-term goal. Today s approach to Enterprise Architecture in the OPS might be characterized as composite-friendly as opposed to primitive-friendly, meaning that considerable attention has been paid to providing guidance for standardizing composite models for I&IT solution designs. While this is important and worthwhile, it must be kept in mind that composite models that are designed for one implementation generally are not reusable other implementations. The quality of reusability in the context of architecture requires the elements in any given model to be of one type only. To illustrate, a data flow model, which is a composite containing at least two kinds of design elements, data and processes, that has been created to aid in the design of a particular information system cannot be used in any other implementation unless it is needed to meet the exact same business requirement elsewhere. For example, it could be a registration process requiring access to student records, with the data flow model specifying particular databases. A process model, on the other hand, is a primitive consisting of only process elements. Process models, e.g., a generic registration process, may be reused wherever those processes are desired. Primitives are the essential ingredients for achieving re-use and its accompanying benefits flexibility, quality, speed, lower cost, etc. This is achieved by reusing primitives that may be created for one part of the enterprise in other parts. This is particularly effective when it is desired to standardize processes, policies, data, etc., across an enterprise that consists of several semi-independent business units. Primitives are also essential for enterprise analysis. For example, if one wanted to know all of the information requirements for all of the enterprise s processes, it would be extremely difficult to determine this by comparing all of the data flow models for all of the implemented information systems. The 1-50 EAPM Version 3.0

59 What Is Relevant Architecture Knowledge complexity and redundancy in the set of such models make them almost useless for analytical purposes at the enterprise level. The answer would be relatively easy to determine, however, by creating a matrix of two sets of primitives (all enterprise data requirements and all process requirements) so that their points of intersection indicate the data needed to support each process. Such a matrix is highly useful in identifying data that may be shared among different processes, for example, thereby enabling decisions for removing data redundancies.in the context of EA, well-formed composite model used for EA analysis, such as the example of the matrix described in the preceding paragraph or a model used in an implementation, such as a data flow model, is one whose elements are drawn from an authoritative source of primitives. June 3,

60 Chapter 1: EA Architecture Framework Access to Architecture Knowledge Use of Modeling Tools and Repositories Discusses the uses of and relationships between modeling tools and repositories Synopsis Enterprise Architecture and Systems Development Systems Development Life Cycle Methodology Until recently, the modeling tools used to create most of the higher level artifacts associated with any EA or Change Initiative Framework have been mainly limited to word processing, spreadsheet, presentation, and diagramming software. Detailed designs such as data models have been created with more specialized modeling tools. Repositories have been ordinary file servers aided by indexing software. At the time of writing, the OPS has selected more powerful EA modeling and repository technology and is developing procedures for putting it into practice. The purpose of this section is to explain the use of modeling tools and repositories in terms of how they are used in both EA and systems development and how they relate to each other. EA is a discipline used in the design of enterprises. Systems development is a discipline employed to design and build systems that comprise of enterprises. Enterprises that engage in systems development without the benefit of EA tend to build systems that are not integrated or interoperable and may not be aligned with enterprise goals (even if they meet individual business requirements within the enterprise). Enterprises that engage in EA and systems development tend to build systems that contribute to increasingly integrated business and I&IT environments and are aligned with and enable the strategic goals of the enterprise. EA and systems development are different, but complementary, disciplines. The key to ensuring they complement each other to achieve common goals is to ensure that information (e.g., models) can be exchanged readily among EA modelers and systems development teams through the use of compatible modeling tools and repositories. In the remainder of this section, the methodologies associated with each discipline will be described with the aim of illustrating the importance of modeling tools and repositories in fulfilling their complementary roles. Systems development life cycle (SDLC) methodology, or software development methodology (SDM), is a body of procedures, techniques, tools and documentation aids that help people design and build information systems. There are many methods: process driven methods, data driven methods, user driven methods, iterative methods, waterfall methods, object oriented methods, rapid application development methods, hybrid methods, etc. Whatever the method, there usually are three major phases of work, which result in the following outputs: 1-52 EAPM Version 3.0

61 Use of Modeling Tools and Repositories 1. The conceptual design, describing the business requirement and the operational deficiency that requires an I&IT solution; 2. The logical design, identifying and relating all of the elements that will need to be factored into the solution; and 3. The physical design, the design of the actual I&IT solution that will support the logical design. The Importance of Design Artifacts The Importance of Standard Elements in Design Artifacts The Importance of Standard Elements when Storing Designs Many artifacts are created in the lifecycle of an I&IT project. Some artifacts, such as the Project Charter and Work Plan, are important in the management of the project, but have no architectural interest. The artifacts that are the outputs of design activities are of immense significance to enterprise architecture, however, because they lead to changes in the enterprise, and they contribute a great deal to the enterprise s body of explicit knowledge about itself. Design elements are the building blocks of designs, e.g., the organization and process elements that comprise a swim lane diagram. If the enterprise does not create a body of design elements (e.g., primitive models) for use in the designs created in multiple I&IT projects, then designers are forced to develop their own as they go, which leads to the development of information systems that are not integrated or interoperable. Therefore, when enterprises wish their information systems to become integrated or interoperable, they must ensure that the design methods that are used in I&IT projects include procedures for accessing a body of standard design elements, selecting the ones that are needed for the particular solution designs, and employing them in whatever tools the designers are using. The following implications arise from this: The enterprise models must be stored in a way that will facilitate the viewing and selection of the appropriate elements. It is desirable for the tools used by designers to be capable of importing elements of enterprise models directly from the tool used to store them (i.e., the repository). Otherwise, design element data will have to be entered manually. The enterprise models should conform to one information standard, e.g., XML structures, to facilitate their maintenance and navigation by means of a single viewing tool such as a browser. It also facilities query and analysis of the entire body of models. Designs typically are in the form of documents that contain diagrams and tables. If they were stored only in this form, the ability of OPS knowledge workers to derive knowledge from them by correlating the elements used to make up the designs would be limited to text searches. It is better for designs to be stored in a more granular level to enable the kind of query, analysis, inference, and reporting that is associated with databases and data June 3,

62 Chapter 1: EA Architecture Framework Access to Architecture Knowledge warehouses. The use of standard elements in the designs would permit this kind of correlation across different designs, as long as the design methods include procedures for storing their design products in this way. Regardless of the tool used to create the designs, the granular design data that will be stored centrally must conform to a common information standard, e.g., XML, in order to enable analysis on the total body of design artifacts. (Note: It is recognized that not all design tools in use throughout the OPS are capable of exporting design data as XML documents.) Enterprise Architecture Methodology The Multi-project Environment What the Modeling Tools Create Enterprise architecture methodology is a body of procedures, techniques, tools and documentation aids that help people describe enterprises. Enterprise architecture methodology is not as mature as SDM, so it is not surprising that its procedures, etc, are not as finely defined compared with SDM. The Zachman Framework is not a methodology per se, that is, it does not prescribe any procedures, techniques, tools or documentation aids beyond the rationale for its classification scheme. Consequently, enterprises that use the Zachman Framework must also develop or adopt a methodology for creating primitive models and for their use in system design (hence the need for this handbook). Aligning enterprise architecture methodology with SDM is particularly challenging for large organizations in which I&IT projects are carried out by different teams in different jurisdictions using different design procedures, techniques, tools and documentation aids. The Change Initiative Checklist has addressed this problem to some degree by defining the mandatory and optional design artifacts that each I&IT project is expected to create. As the OPS EA Program matures, less attention will need to be given to specifying the design artifacts for I&IT projects, and more attention given to creating the reusable content for whatever design artifacts are needed by any given I&IT project. Figure 1-28 illustrates the entire modeling environment, taking into consideration EA models as well as system design models created as part of an SDM. The two methodologies are depicted as a continuum or continuous processes in an ideal setting EAPM Version 3.0

63 Use of Modeling Tools and Repositories Figure 1-28: EA ~ System Design Continuum The two main processes in the EA side of Figure 1-28 are creating metamodels and creating enterprise models. Creating metamodels means to create templates for the modeling tool that is used to create the enterprise models. [Note: Enterprise models refers to primitive models and to any reference models or patterns that may be made standard for the enterprise.] The metamodels will be physically created by someone skilled in the use of the tool used to create them, but will be designed by subject matter experts for each kind of model. Create enterprise model means to add content to metamodel templates and form associations between model elements using a modeling tool for the purpose. In practice, this is often accomplished by selecting templates and association types from palettes within the modeling tool and adding content by entering text. This requires subject matter expertise for the different kinds of models in question. The right hand side of Figure 1-28 shows the system design process of systems development. In this case, rather than starting from scratch, the system designer is shown selecting elements of authoritative EA models (from the project s sponsoring EA framework) and combining them to form specific instances of designs needed in the development of the system the designer is working on. Also shown is the concept of storing the design in two June 3,

64 Chapter 1: EA Architecture Framework Access to Architecture Knowledge forms: (1) as a design artifact in human readable form; and (2) as design data suitable for advanced query and analysis. All of the EA and system design products are stored in a single (virtual or physical) repository. It is important to note that the Metamodels, EA models and Design Data are stored in the form of data in a suitable standard (e.g., XML) so as to permit the ready sharing among all of the modeling tools used in EA and systems development. In addition, this also allows all such information to be correlated through query and analysis, thereby providing the ability to derive knowledge that is otherwise almost impossible to ascertain from large bodies of fixed content documents. Modeling in the Larger Context Figure 1-28 expands upon Figure 1-27 and illustrates the roles of all key participants in both EA and systems development, including the products that they produce. Figure 1-29: The Big Picture Develop EA methodology EA Methodologist Builder Subject Matter Expert Designer Standards Setter Provide subject matter advice Set standard EA Metamodeler EA Modeler Create design Develop solution Create metamodel Create enterprise model Design instance Metamodels Enterprise Models Design Data Design Artifacts "As built" Artifacts Implemented Solution Enterprise Architecture Repository Manage repository EAR Librarian/Administrator 1-56 EAPM Version 3.0

65 Use of Modeling Tools and Repositories Conclusion The concepts described in this section are idealized and have not yet been implemented in the OPS. For the foreseeable future, system designers in fact will be creating EA models through the Change Initiative Framework process, and so will be carrying out the dual roles of EA modeler and system designer depicted in Figures 1-27 and June 3,

66 Chapter 1: EA Architecture Framework Access to Architecture Knowledge Architecture Maintenance Overviews the maintenance of architecture information. Synopsis Synopsis This section will present the practical steps to be taken by librarians and architects at the project, cluster and corporate levels to add frameworks, artifacts and content primitives and composites to the file system, Structure database, and repository databases. These steps will be mapped to the services to be provided by the OPS architecture function, and their associated processes. [Note: Left unchanged in Version 3 update pending the development of new procedures for the EA Repository.] 1-58 EAPM Version 3.0

67 Chapter 2: Introduction to OPS EA Program

68 Chapter 2: Introduction to OPS EA Program The OPS EA Program Profile 2.1 The OPS EA Program Profile Centre of Excellence project was undertaken in 2004 to design the business architecture of the OPS EA Program. The content of this and the following sections stems from the work of that project. The purpose of this section is to describe the profile of the OPS EA Program. Background Program Outcomes Increased Alignment of Business and I&IT The Enterprise Architecture Program (EAP) was conceived as part of the Information and Information Technology (I&IT) strategy for the Ontario Government in At that time, the development of an Enterprise Information and Information Technology Architecture (redefined later as Enterprise Architecture) for the OPS was identified as one of nine strategic initiatives aimed at providing the technology needed to advance the Government s business vision for flexible, responsive and innovative public service. The EA program is not a front-line public program in that its target population is not directly the general public of Ontario. It is a "provider" program in that it supports front-line providers of services to the public. It does so by enabling the design of transformations and improvements of these services to make them more effective and efficient and to improve the quality and consistency of service delivery. A key assumption of the EAP is that the transformation and improvement of service delivery by the OPS and the broader public sector (BPS) can be enabled through the judicious use of management information for decision support and of information technology to automate business processes. The EAP has the following program outcomes: Increased alignment of business and IT plans and strategies with intentions of governors. Increased stakeholder assurance that changes proposed in the design will achieve the benefits, and risks are mitigated. Increased alignment of change initiative participants with government strategies. Greater enterprise design knowledge. Increased change designer competence. Accountability for EAP outcomes resides with the Office of the Chief Technology Officer (OCTO). The following describes each outcome in turn. Included in each description is reference to other OPS programs that the EAP supports. The EAP encourages the development of target architectures for the future design of the OPS and its supporting I&IT assets. These target architectures support business and I&IT planning and promote increased alignment of business and IT plans and strategies with the policy and planning intentions of 2-2 EAPM Version 3.0

69 program governors. By promoting business and I&IT alignment at the planning level, the program contributes to the I&IT program of the OPS. Increased Stakeholder of Assurance of Success Increased Alignment of Change Initiative Participants with Government Strategies Greater Enterprise Design Knowledge Increased Change Design Competence Program Impacts The program supports the creation of: as-is and to-be architectures of an OPS enterprise a gap analysis between the two architectures an analysis of the risks and benefits of migrating from the as-is to the to-be enterprise. The use of architecture to analyze the risks and benefits of a change to the enterprise design leads to increased stakeholder assurance that changes proposed in the design will achieve the benefits, and risks are mitigated. As such, the program contributes to the controllership and risk management program of the OPS (part of the mandate of Management Board Secretariat). The EAP encourages program managers and change initiatives to explore enterprise design options for service transformation by applying such strategies as alternate, integrated or electronic service delivery to existing service delivery models. The discussion and exploration of design options leads to greater alignment amongst stakeholders of a transformation or change initiative on the design of the optimum enterprise model. As such, the EAP contributes to the outcomes of the transformation program of the OPS, currently governed by the Deputy Minister's Committee on Transformation (DMCOT). The program supports the development of architectural blueprints of the structure, function and behaviour of: the OPS and the delivery of its programs and services as a business (the business model ) the I&IT assets of the OPS (the system model ). Collectively, an enterprise model includes the business model and the system model. As such, the EAP contributes to the broader knowledge management program of the OPS. Accountability for the outcomes of the knowledge management program resides with the I&IT Policy, Planning and Strategy Branch (the Knowledge Management Secretariat), within the Office of the Corporate Chief Strategist. EA is an emerging discipline, and there are relatively few practitioners within the OPS. Given the increasing demand to support service transformation initiatives, the OPS will experience substantial demand for skilled business and I&IT architects to design changes to the business and its supporting I&IT assets for the foreseeable future. The EAP is supporting the development of knowledgeable, skilled and productive architects throughout the OPS and therefore contributes to the goals of the human resources program. The outcomes of the EAP have the following impacts on the function of the OPS as an enterprise. June 3,

70 Chapter 2: Introduction to OPS EA Program The OPS EA Program Profile Increased Enterprise Change Success Increased Enterprise Effectiveness, Efficiency and Adaptiveness Historically, policy and planning changes are passed to operations for implementation without sufficient guidance to assure success. The design function is the missing link between planning and implementation that assures a change initiative where: the change initiative has been properly scoped and estimated; the risks have been identified, quantified and mitigated where feasible; and the benefits are measurable and have a reasonable probability of attainment. The program increases project success by reducing the probability of failure caused by improper design. Change initiatives within the OPS are intended to increase the effectiveness, efficiency and adaptiveness of the OPS as an enterprise. By reducing the probability of design failure, the program contributes to these key outcomes of enterprise transformation. 2-4 EAPM Version 3.0

71 2.2 Architecture Services The Following table summarizes the set of services that are required to achieve the outcomes of the EAP. The list of services provides an indication of the activities, resources, and skills needed to offer a complete EA program. Table 2-1: Enterprise Architecture Service Portfolio Service Architectural Policies & Standards Tools & Methods Reference Model Architecture Education Curriculum Development Architecture Education Delivery Repository Architecture Review Change Initiative Architecture Development Service Description Provide policies and standards that govern I&IT design and construction, and support business planning and design, jurisdictional scope, conformance to Threat Risk Assessments and Privacy Impact Assessments, and compliance with I&IT directives. Provides architectural tools including guidelines, best practices and methodology guidebooks (e.g., defining programs and services in the OPS Handbook) as well as automated architectural tools such as EA modeling and CASE tools. Provides a reference model for re-use in change initiatives. A reference model is a generic design for an enterprise component for which there may be multiple instances throughout the enterprise. Provides architecture related education and training materials. This may include information, educational materials and/or training sessions. Provides architecture related education and training. This may include providing information, educational materials and/or training sessions. Provides artifacts related to previous architecture and design efforts regarding component designs for business and I&IT. This involves collection, storage, stewardship, and access to design artifacts. Provide an assessment of architecture for compliance with the intentions of the governors as well as the applicable policies and standards. Ensures alignment of I&IT plans, designs and constructed components with I&IT governors strategies and standards, and with business strategies and standards. Develops a new change initiative architecture version. This service will comply with applicable policies and standards, and will align the architecture with the target EA. This architecture alignment will ensure the new change initiative architecture is aligned wit the intentions of the enterprise governors. This service may use outputs from the repository in the form of previous component design artifacts and/or reference model artifacts. These outputs may come from previous change initiatives and/or from the EA Development Service. This is a sub-type of what might be termed an Architecture development Service. Its key role in EA warrants distinction, however. June 3,

72 Chapter 2: Introduction to OPS EA Program Architecture Services Enterprise Architecture Development Architectural Consulting Architecture Project Planning Architect Certification Develops a target EA version that reflects the intended future state of the enterprise. This future state represents the intentions of the enterprise governors. This service helps enterprise planning functions by describing fundamental organization, components, and principles of design and evolution. The many change initiatives along the way to this future state are intended to result in something approaching this target architecture. As change initiatives are completed, the target architecture would be updated as appropriate. Provides advice for business and I&IT design. This includes recommendations, reports, referrals of qualified designers, etc. Produces architectural project plans. This service assists change initiatives in planning for architecture related activities. Certifies an architect as competent to create architecturally compliant design models. 2-6 EAPM Version 3.0

73 Client Needs for Architecture Services Client Needs for Architecture Services The OPS EA Program delivers a set of services to a defined target client population within the Ontario Government. Then purpose of this section is to describe the kinds of clients who benefit from the EA Program and their needs that are met by it. Target Client Population The following table identifies and describes the groups of individuals within the OPS who derive value from the OPS EA Program. Table 2-2: Target Population of the OPS EA Program Target Group Subgroup Descriptions Change Architect & Designer Change Manager Enterprise Component Manager Governor Architect Designer Change Initiative Manager I&IT Planner/Policy Manager Business Planner/Policy Manager Program Manager I&IT Service Manager Business Service Manager A person accountable for conceiving an implementable change to a business component and documentating that change ina form that facilitates development. Includes enterprise architect and any domain architect, e.g., business architect, security architect, etc. Includes business designer and designer). A manager accountable for an aspect of Initiative. I&IT designer (system a Change The manager accountable for the outcome of the Change Initiative. The manager accountable for I&IT plans and policy (through the Change Initiative Manager). The manager accountable for business plans and policy (through the Change Initiative Manager). A role within an organization accountable for the outcomes of a component of the enterprise. The Component Manager has a mandate within which he/she operates the program on a day-to-day basis. A role within an organization outcomes of a program. accountable for the A role within an organization accountable for outcomes of an I&IT Service. A role within an organization accountable for outcomes of a Business Service. the the A person or institution to which an enterprise is accountable for its performance. An Enterprise Governor leads the enterprise by formulating intentions for the enterprise and expressing those intentions to the management of the enterprise to be carried out. (The term enterprise is meant in a fractal sense, as an Enterprise may consist of one or more enterprises.) June 3,

74 Chapter 2: Introduction to OPS EA Program Architecture Services Enterprise Governor Business Governor I&IT Governor Change Initiative Governor Architectural Educator Architectural Educator A person or institution to which an enterprise is accountable for its performance. A person or institution to which a business component an enterprise is accountable for its performance. A person to which an I&IT business component is accountable for its performance. A person or institution to which a change initiative is accountable for its performance. An individual who delivers an architectural education encounter. of Client Needs Productivity: Skill: Knowledge: Assurance: Alignment: Adaptiveness: Integration Accountability: Quality: Effectiveness: Efficiency: The EAP recognizes the following needs: The need for outcomes The need for functions. change designers to use minimal resources to achieve intended change designers to be able to perform particular tasks or The need for change designers to understand their roles in the grater context of EA and OPS transformation. The need for confidence that intended outcomes have a reasonable probability of being obtained. This includes the need for assurance that risks of unintended or negative consequences due to changes, threats, or chance have been mitigated. The need for enterprise. coordination of components to meet the outcomes of the The need for readiness for change. The need to combine into a whole. The need to be able to measure performance on intended outcomes to meet the obligations of accountability. The need for improved program and service quality. The need to achieve the intended outcomes of the enterprise. The need to use minimal resources to achieve intended goals. 2-8 EAPM Version 3.0

75 Architectural Policies & Standards Service Architectural Policies & Standards Service The OPS EA Program provides policies and standards that govern I&IT design and construction, and support business planning and design, jurisdictional scope, conformance to Threat Risk Assessments and Privacy Impact Assessments, and compliance with I&IT directives. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers An authoritative standard or policy. Table 2-3 defines the events that trigger delivery of this service TService delivery triggers for the Architectural Policies & Standard Services Table 2-3: Service triggers for the Architectural Policies & Standards Services Category Event Major Trigger Regular Trigger Routine Response Business (budget) planning cycle IT strategic planning cycle IT project milestones IT product or service acquisition Proactive Response Government or legislation change Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change EA Program Initial architecture development Architecture program event Technology trends Unpredictable Events Audits FOI request Major crisis June 3,

76 Chapter 2: Introduction to OPS EA Program Architecture Services Service delivery roles Table 2-4 identifies the particular parties that play various roles in the delivery of this service. Table 2-4: Architectural Polices & Standards Service delivery roles Role Corporate level Cluster level Project level Vote/Item & external level Client Architects Business Planners planner & designers Provider IT Architects Partner IT Planners IT Architects IT Planners Regulator (PR) ITELC Regulator (BS)) Regulator (IS) Regulator (QS) ARB, ACT, ITSC, Shared risk Auditors, suppliers Corporate FOI, HR Stakeholders Other stakeholder Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Establish a structure for defining and publishing policies and standards Determine priorities for policies or standards development Commission projects to develop a proposed policy or standard Evaluate and approve a proposed policy or standard Approve or reject exceptions to a policy or standard Promulgate policy or standard Incorporate a new policy or standard into planning and project reviews Monitor compliance with policies and standards Review policies and standards periodically for effectiveness Monitor service performance measures and achievement of goals EAPM Version 3.0

77 Architectural Policies & Standards Service Roles in service life cycle activities Corporate roles in service life cycle activities Parties at the corporate, cluster and ministry levels may play prime, involved or approver roles in the activities of the Architectural Policies & Standards Service. Parties at the project level are clients of this service but do not play active roles in its delivery. Table 2-5 summarizes the roles played by corporate parties in the activities of the standards setting services. Table 2-5: Corporate roles in life cycle activities for Architectural Policies & Standards Service y Service Life Cycle Activity C ITEL ARB T e I C o rpor at Plan ners ate e c ts C o rpor Archit tanda rd s IT S Coun ci l MBC ners Bus Plan Archit e c ts itor Aud Agenc FOIPIP st hivi Arc Define service goals & performance measures A P A P Establish a structure for defining and publishing A I P I A P policies and standards Determine priorities for policies and standards A P I I I A I I I I development Commission projects to develop policies and P 1 I I I P 1 I I I I standard Evaluate proposed policies and standards & approve A 1 I P 1 I A 1 P 1 I I I Approve/reject exceptions to a policy or standard A P I I A I Publicize policy and standard and incorporate into reviews P 1 P 1 Monitor compliance with policies and standards P 1 P 1 I Review periodically effectiveness for P 1 P 1 I Monitor performance measures & achievement A P A P 1 Common and shared principles, standards, guidelines, etc. Bold cells: Business-related principles, standards, guidelines, etc. June 3,

78 Chapter 2: Introduction to OPS EA Program Architecture Services P=Prime, I=Involved, A=Active Cluster roles in service life cycle activities Table 2-6 summarizes the roles played by cluster parties in the activities of the Architectural Policies and Standards Service. Table 2-6: Cluster roles in lifecycle activities in the Architectural Policies and Standards Service. Service Life Cycle Activity Clus t er C I Os Clus t er A r chitects Clu ster IT Plan ne rs Clus t er A R B Define service goals & performance measures I Establish a structure for defining and publishing policies and standards I I Determine priorities for policies and standards development I Commission projects to develop policies and standard P 1 I Evaluate proposed policies and standards & approve P 1 I A 1 Approve/reject exceptions to a policy or standard Publicize policy and standard and incorporate into reviews I P 1 I Monitor compliance with policies and standards Review periodically for effectiveness Monitor performance measures & achievement I P 1 I P 1 I 1 Cluster-specific principles, standards, guidelines, etc EAPM Version 3.0

79 Architectural Policies & Standards Service Ministry roles in service life cycle activities Table 2-7 summarizes the roles played by ministry parties in the activities of the standards setting services. Table 2-7: Ministry roles in lifecycle activities in the Architectural Policies and Standards Service Service Life Cycle Activity ADMs Business Area Leaders Bus Planners Architects Shared Public Service Providers Define service goals & performance measures I Establish a structure for defining policies and standards Determine priorities for development Commission projects standard and publishing A P policies and standards A I I to develop policies and P 1 I I Evaluate proposed policies and standards & approve A 1 P 1 I Approve/reject exceptions to a policy or standard A I I Publicize reviews policy and standard and incorporate into Monitor compliance with policies and standards Review periodically for effectiveness Monitor performance measures & achievement P 1 P 1 P 1 I I I 1 Cluster/business specific principles, standards, guidelines, etc. Bold cells: Business-related principles, standards, guidelines, etc. June 3,

80 Chapter 2: Introduction to OPS EA Program Architecture Services Enterprise Architecture Development Service The Enterprise Architecture development Service develops a target EA version that reflects the intended future state of the enterprise. This future state represents the intentions of the enterprise governors. This service helps enterprise planning functions by describing fundamental organization, components, and principles of design and evolution. The many change initiatives along the way to this future state are intended to result in something approaching this target architecture. As change initiatives are completed, the target architecture would be updated as appropriate. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers A new target EA version. [Note: The ability to perform this service anywhere in the OPS is very limited at present.] Table 2-8 defines the events that trigger delivery of this service. Table 2-8: Service delivery triggers for EA Development Service Category Event Major Trigger Regular Trigger Business (budget) planning cycle Routine Response IT strategic planning cycle IT project milestones IT product or service acquisition Government or legislation change Proactive Response Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change EA Program Unpredictable Events Initial architecture development Architecture program event Technology trends.. Audits FOI request Major crisis EAPM Version 3.0

81 Enterprise Architecture Development Service Service delivery roles Table 2-9 defines the parties that play various roles in the delivery of this service. Table 2-9: A Development Service delivery roles Role Corporate level Cluster level Project level Vote/Item & external level Client Architects Planners Business planner & designers Provider IT Architects Partner IT Planners IT Architects IT Planners Regulator (PR) ITELC Regulator (BS)) Regulator (IS) Regulator (QS) ARB, ACT, ITSC, Auditors, Corporate FOI, HR Stakeholders Shared risk suppliers Other stakeholder Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Define framework for EA development (i.e., EA Meta-framework) Determine priorities for EA development Commission projects to develop EA Harvest reusable models from ongoing projects and other EAs June 3,

82 Chapter 2: Introduction to OPS EA Program Architecture Services Promote, provide access and distribute EAs Perform gap analyses between target and as is architectures of selected enterprises and Define and scope change initiatives needed to achieve target EA Monitor service performance measures and goal achievements. Roles in service life cycle activities Corporate roles in service life cycle activities Parties at the corporate, cluster, ministry and project levels may play prime, involved, or approver roles in the activities of the EA Development Service. Table 2-10 summarizes the roles played by corporate parties in the activities of the EA Development Service. Table 2-10: Corporate role in lifecycle activities in the EA Development Service Service Life Cycle Activity ITELC ARB T e I Corporat Planners Corporate Architects IT S tan da r d s Council MBC ners Bus Plan Architects Auditor y Agenc FOIPIP Archivist Define service goals and performance measures A P A P Define framework for EA development A I P A P Determine priorities for EA development A P I I A I I I I Commission projects to EA develop P 1 I I P 1 I I I I Harvest reusable models from ongoing projects and other EAs I P 1 I Promote, provide access & distribute components P 1 P 1 Perform gap analyses between target and as is architectures of selected enterprises and Define and scope change initiatives needed to achieve target EA Monitor performance measures & achievements A P A P P 2-16 EAPM Version 3.0

83 Enterprise Architecture Development Service Cluster roles in service life cycle activities.. Table 2-11 summarizes the roles played by cluster parties in the activities of the Enterprise Architecture Development Service. Table 2-11: Cluster role in lifecycle activities in EA Development Service Service Life Cycle Activity CIOs Cluster it ec ts Cluste r Arc h Cluster IT Planners ARB Cluster Define service goals and performance measures Define framework for EA development I I Determine priorities for EA development Commission projects to develop EAs P 1 I Harvest reusable models from ongoing projects and other EAs Promote, provide access & distribute EAs P 1 Perform gap analyses between target and as is architectures of selected enterprises and Define and scope change initiatives needed to achieve target EA Monitor performance measures & achievements I P 1 P I I 1 Cluster-specific principles, standards, guidelines, etc. Ministry roles in service life cycle activities Table 2-12 summarizes the roles played by ministry parties in the activities of the EA Development Service. Table 2-12: Ministry roles in lifecycle activities in EA Development Service. Service Life Cycle Activity ADMs Business Area Leaders Bus Planners Architects Shared Public Service Providers Define service goals and performance measures I Define framework for EA development A P Determine priorities for EA development A I I Commission projects to develop EAs Harvest reusable other EAs models from ongoing projects and Promote, provide access & distribute EAs P 1 I I I P 1 June 3,

84 Chapter 2: Introduction to OPS EA Program Architecture Services Perform gap analyses between target and as is architectures of selected enterprises and Define and scope change initiatives needed to achieve target EA? Monitor performance measures & achievements P I 1 Cluster/business specific principles, standards, guidelines, etc. Bold cells: Business-related principles, standards, guidelines, etc. Project-level roles in service life cycle activities Table 2-13 summarizes the roles played by project-level parties in the activities of the EA Development Service. Table 2-13: Project-level roles in lifecycle activities in EA Development Service Service Life Cycle Activity mmittees Co Project Steering ect nagers Proj Ma Project Architect s Business Experts s er Sy stems Develop ants External Consult Shared Risk Pa rt ne rs Define service goals and performance measures Define framework for EA development Determine priorities for EAdevelopment Commission projects to develop EAs Harvest reusable models from ongoing projects and other EAs Promote, provide access & distribute EAs I I I I I Perform gap analyses between target and as is architectures of selected enterprises and Define and scope change initiatives needed to achieve target EA? Monitor performance measures & achievements 2-18 EAPM Version 3.0

85 Change Initiative Architecture Development Service Change Initiative Architecture Development Service Develops a new change initiative architecture version. This service will comply with applicable policies and standards, and will align the architecture with the target EA. This architecture alignment will ensure the new change initiative architecture is aligned wit the intentions of the enterprise governors. This service may use outputs from the repository in the form of previous component design artifacts and/or reference model artifacts. These outputs may come from previous change initiatives and/or from the EA Development Service. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers A new change initiative architecture version. Table 2-14 defines the events that trigger delivery of this service. Table 2-14: Service delivery triggers in the Change Initiative Architecture Development Service Category Event Major Trigger Regular Trigger Routine R Response Business (budget) planning cycle IT strategic planning cycle IT project milestones IT product or service acquisition E F Routine Response Government or legislation change Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change EA Program Initial architecture development Architecture program event Technology trends. Unpredictable Events Audits FOI request Major crisis June 3,

86 Chapter 2: Introduction to OPS EA Program Architecture Services Service delivery roles Table 2-15 defines the parties that play various roles in the Change Initiative Architecture Development Service. Table 2-15: Change Initiative Architecture Development Service delivery roles Corporate Cluster Project Core business & Role level level level external level Client IT Planners Cluster Business management management team team* (MBS) Provider IT Architects IT Architects? IT Architects Business planners & designers Partner IT Architects**, Business planners** IT Architects, Business planners* Regulator (PR) ITELC*, CIPMC*, Project steering committee Regulator (BS)) Regulator (IS) Regulator (QS) Other stakeholder ARB Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Cluster initiatives only * Common or shared IT service initiatives only ** Both common or shared IT service and business initiatives (not cluster initiatives) Both cluster initiatives and common or shared business initiatives (not IT service initiatives) Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Determine design methods, disciplines and tools to use on each project Prepare business or I&IT designs Monitor service performance measures and achievement of goals EAPM Version 3.0

87 Change Initiative Architecture Development Service Roles in service life cycle activities Corporate roles in service life cycle activities Parties at the corporate, cluster, ministry and project levels may play prime, involved or approver roles in the activities of the Change Initiative Architecture Development Service. Table 2-16 summarizes the roles played by corporate parties in the activities of the Change Initiative Architecture Development Service. Table 2-16: Corporate role in lifecycle activities in the Change Initiative Architecture Development Service Service Life Cycle Activity ITELC ARB e IT at s or ner Corp Plan ate ts or ec Corp Archit IT St an dar ds Council MBC nners ts Bus Pla Archit ec Auditor Agency P FOIPI t Archivis Define service goals and performance measures Determine design methods, disciplines & tools Prepare designs Monitor performance measures & achievements A P A P I I I I I I A P A P Bold cells: Business-related principles, standards and guidelines Cluster roles in service life cycle activities Table 2-17 summarizes the roles played by cluster parties in the activities of the Change Initiative Architecture Development Service. Table 2-17: Cluster role in lifecycle activities in the Change Initiative Architecture Development Service Service Life Cycle Activity Clu st er CI O s Clu s t e r Arc hite ct s Cluster IT Planners Cluster ARB Define service goals and performance measures I June 3,

88 Chapter 2: Introduction to OPS EA Program Architecture Services Determine design methods, disciplines & tools I I Prepare designs I I Monitor performance measures & achievements I Ministry roles in service life cycle activities Table 2-18 summarizes the roles played by ministry parties in the activities of the Change Initiative Architecture Development Service Table 2-18: Ministry roles in lifecycle activities in the Change Initiative Architecture Development Service Service Life Cycle Activity ADMs Area ess rs Busin Le ade Bus Pla nners Architec t s ed Pu blic ice Prov iders Shar Serv Define service goals and performance measures Determine design methods, disciplines & tools Prepare designs Monitor performance measures & achievements I I I * I *Role depends on contractual relationships Bold cells: Business-related principles, standards, guidelines, etc EAPM Version 3.0

89 Change Initiative Architecture Development Service Project-level roles in service life cycle activities Table 2-19 summarizes the roles played by project-level parties in the activities of the Change Initiative Architecture Development Service. Table 2-19: Project-level roles in lifecycle activities in Change Initiative Architecture Development Service Service Life Cycle Activity ing eer e s ect St mitte Proj Com Proj ect Ma na ge r s Proje ct Architec ts Business Ex per t s Sy stem s Developers nsu lt ants External Co Shared Risk Part n e r s Define service goals and performance measures Determine design methods, disciplines I P I & tools Prepare designs I P P I * * Monitor performance measures & achievements * Role depends on contractual relationships June 3,

90 Chapter 2: Introduction to OPS EA Program Architecture Services Architecture Education Service Provides architecture related education and training materials. This may include information, educational materials and/or training sessions. (Architecture Education Curriculum Development) Provides architecture related education and training. This may include providing information, educational materials and/or training sessions. (Architecture Education Delivery) [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service outputs Service delivery triggers Architecture educational and training material. An architecture educational encounter. Table 2-20: Defines the events that trigger delivery of this service.ervice delivery triggers for Architecture Education Service Category Event Major Trigger Regular Trigger Routine Business (budget) planning cycle Response IT strategic planning cycle IT project milestones IT product or service acquisition Proactive Response Government or legislation change Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change EA Program Initial architecture development Architecture program event Technology trends Unpredictabl Audits e Events FOI request 2-24 EAPM Version 3.0

91 Architecture Education Service Service delivery roles Table 2-21 defines the parties that play various roles in the delivery of this service. Table 2-21: Architecture Education Service delivery roles Role Client Corporate level ITELC, ARB, CIPMC, IT Planners, ACT, PMA, ITSC, Auditor, Corporate FOI, HR Stakeholders Cluster level Cluster management team, Business planners, IT Architects, Cluster ARB Project level Project steering committee, Project managers, Architects, Project staff Core business & external level Business management team, Business planners & designers, Shared public service providers, Shared risk suppliers, Suppliers Provider IT Architects IT Architects? Partner IT Architects Regulator (PR) ITELC Regulator (BS)) Regulator (IS) Regulator (QS) ARB Other stakeholder Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Carry out general environmental scanning for emerging business and automation design techniques Prioritize research into new business and automation design innovations June 3,

92 Chapter 2: Introduction to OPS EA Program Architecture Services Conduct research into new business and automation design techniques Conduct awareness programs on emerging business and automation design techniques Prioritize architectural training needs Develop architectural training courses Promote architectural training courses Conduct architectural training courses Monitor service performance measures and achievement of goals. Roles in service life cycle activities Corporate roles in service life cycle activities Parties at the corporate, cluster and ministry levels may play prime, involved or approver roles in the activities of the Architecture Education Service. Parties at the project level are clients of this service but do not play active roles in the delivery of this service. Table 2-22 summarizes the roles played by corporate parties in the activities of the Architecture Education Service. Table 2-22: Corporate role in lifecycle activities in the Architecture Education Service cy Service Life Cycle PActivity ITELC ARB Corporate IT lan n e r s orate ects Corp Archit IT St a n d a r d s Co un cil MBC Bu s Plann e rs Archit ects r Audito Agen FOIPIP vist chi Ar Define service goals & performance A A I P A P measures Scan for emerging design techniques Prioritize research on design innovations Research new design techniques Conduct awareness programs on design Prioritize architectural training needs Develop architectural training courses I P P A A I P A P I P P I P P A A I P A P I P P 2-26 EAPM Version 3.0

93 Architecture Education Service Promote & conduct architectural courses I P P Monitor performance measures & A I P A P achievement Cluster roles in service life cycle activities Table 2-23 summarizes the roles played by cluster parties in the activities of the Architecture Education Service. Table 2-23: Cluster role in lifecycle activities in Architecture Education Service cts IOs Clu s ter C chite Cluster Ar Cluster IT Pla nn e rs B Clu s ter AR Service Life Cycle Activity Define service goals & performance measures I I Scan for emerging design techniques I I Prioritize research on design innovations Research new design techniques I I Conduct awareness programs on design I I Prioritize architectural training needs I I Develop architectural training courses I I Promote & conduct architectural courses I I Monitor performance measures & I I achievement June 3,

94 Chapter 2: Introduction to OPS EA Program Architecture Services Ministry roles in service life cycle activities Table 2-24 summarizes the roles played by ministry parties in the activities of the Architecture Education Service. Table 2-24: Ministry roles in lifecycle activities in the Architecture Education Service ea Ar Busine ss Leaders ne r s Bu Plan ers Service Life Cycle Activity ADMs c s e t s Archit lic vid Shar ed Pub Servic e Pro Define service goals & performance measures I Scan for emerging design techniques I Prioritize research on design innovations I Research new design techniques I Conduct awareness programs on design I Prioritize architectural training needs I Develop architectural training courses I Promote & conduct architectural courses I Monitor performance measures & achievement I 2-28 EAPM Version 3.0

95 Architectural Consulting Service Architectural Consulting Service Provides advice for business and I&IT design. This includes recommendations, reports, referrals of qualified designers, etc. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers An advisory encounter. Table 2-25 defines the events that trigger delivery of this service. Table 2-25: Service delivery triggers for the Architectural Consulting Service Category Event Major Trigger Regular Trigger Routine R Response R Proactive Response E EA Program Unpredictable Event Business (budget) planning cycle IT strategic planning cycle IT project milestones IT product or service acquisition Government or change legislation Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change Initial architecture development Architecture program event Technology trends Audits FOI request Major crisis June 3,

96 Chapter 2: Introduction to OPS EA Program Architecture Services Service delivery roles Table 2-26 defines the parties that play various roles in the delivery of this service. Table 2-26: Architectural Consulting Service delivery roles Role Corporate level Cluster level Project level Core business & external level Client Project managers Provider IT Architects IT Architects Partner Suppliers Regulator (PR) ITELC Cluster management team Regulator (BS)) Regulator (IS) Regulator (QS) ARB Cluster ARB Other stakeholder Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Forecast requirements for business and automation design skills Maintain roster of architects with qualified architectural skills Negotiate agreements with clients to provide architectural skills for limited periods Manage provision of services to clients and administer terms of agreement Monitor service performance measures and achievement of goals. Roles in service life cycle activities Parties at the corporate, cluster and ministry levels may play prime, involved or approver roles in the activities of the Architectural Consulting Service. Parties at the project level are clients of this service, but do not play active roles in the delivery of this service EAPM Version 3.0

97 Architectural Consulting Service Corporate roles in service life cycle activities Table 2-27 summarizes the roles played by corporate parties in the activities of the Architectural Consulting Service. Table 2-27: Corporate role in lifecycle activities in the Architectural Consulting Service Service Life Cycle Activity LC ITE B AR T Co r p o r at e I Pla nn ers Corporate Arc hitect s a d ar d s il St n nc IT Cou MBC ne s s r s Plan hitect Bu Arc r ito Aud y Agenc FOIPIP iv is t Arch Define service goals & performance measures Forecast requirements for design skills A P A P A I P A P Maintain roster of qualified architectural skills P P Negotiate agreements with clients to provide skills P P Manage service provision & terms of agreement P P Monitor performance measures & achievement A P A P June 3,

98 Chapter 2: Introduction to OPS EA Program Architecture Services Cluster roles in service life cycle activities Table 2-28 summarizes the roles played by cluster parties in the activities of the Architectural Consulting Service Table 2-28: Cluster role in lifecycle activities in the Architectural Consulting Service Service Life Cycle Activity Cluster CIOs Cluster Architects Cluster IT Planners Cluster ARB Define service goals & performance measures I Forecast requirements for design skills I I I I Maintain roster of qualified architectural skills I Negotiate agreements with clients to provide skills Manage service provision & terms of agreement Monitor performance measures & achievement I Ministry roles in service life cycle activities. Table 2-29 summarizes the roles played by core business parties in the activities of the Architectural Consulting Service. Table 2-29: Ministry roles in lifecycle activities in the Architectural Consulting Service Service Life Cycle Activity ADMs Business Area Leaders Bus Planners Architects Shared Public Service Providers Define service goals & performance measures I Forecast requirements for design skills I I I Maintain roster of qualified architectural skills I Negotiate agreements with clients to provide skills Manage service provision & terms of agreement Monitor performance measures & achievement I 2-32 EAPM Version 3.0

99 Methods and Tools Service Methods and Tools Service Provides architectural tools including guidelines, best practices and methodology guidebooks (e.g., defining programs and services in the OPS Handbook) as well as automated architectural tools such as EA modeling and CASE tools. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers An approved architecture too or method. Table 2-30 defines the events that trigger delivery of this service. Table 2-30: Service delivery triggers for the Methods and Tools Service Category Routine R Response Proactive Response EA Program Unpredictable Event Event Business (budget) planning cycle IT strategic planning cycle IT project milestones IT product or service acquisition Government or change legislation Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change Initial architecture development Major Trigger P Regular Trigger Architecture program event Technology trends P P Audits FOI request Major crisis June 3,

100 Chapter 2: Introduction to OPS EA Program Architecture Services Service delivery roles Table 2-31 defines the parties that play various roles in the delivery of this service. Table 2-31: Methods and Tools Service delivery roles Methods and Tools Service delivery roles Role Corporate level Cluster level Project level Core business & external level Client Project architects, Project staff Provider IT Architects Partner IT Architects Shared risk suppliers, Suppliers Regulator (PR) Regulator (BS)) Regulator (IS) Regulator (QS) Other stakeholder ITELC ARB Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Evaluate and select or customize government standard methods and disciplines for business and automation design Evaluate and select or customize government standard tools for business and automation design Maintain and distribute methods, disciplines and tools Provide support to users of approved methods, disciplines and tools Conduct assessments of design methods, disciplines and tools proposed for use on projects Monitor service performance measures and achievement of goals EAPM Version 3.0

101 Methods and Tools Service Roles in service life cycle activities Corporate roles in service life cycle activities Parties at the corporate, cluster and ministry levels may play prime, involved or approver roles in the activities of the Methods and Tools Service. Parties at the project level are clients of this service but do not play active roles in the delivery of this service. Table 2-32 summarizes the roles played by corporate parties in the activities of the Methods and Tools Service. Table 2-32: Corporate role in lifecycle activities of the Methods and Tools Service Service Life Cycle Activity ITELC ARB T s Corporat e I Plan ners Corporate Archite ct s IT S tandar d Counc il MBC ers Bus Plan n Archite ct s Auditor y FOIP IP Age nc Archivist Define service goals & performance measures Evaluate & select design methods & disciplines A I P P I P P Evaluate & select design tools A I P A P Maintain & distribute methods, disciplines & tools Support users of approved methods, disciplines & tools Assess methods, disciplines & tools proposed for projects Monitor performance measures & achievement I P P I P P A I P A P I P P June 3,

102 Chapter 2: Introduction to OPS EA Program Architecture Services Cluster roles in service life cycle activities Table 2-33 summarizes the roles played by cluster parties in the activities of the Methods and Tools Service. Table 2-33: Cluster role in lifecycle activities of the Methods and Tools Service Service Life Cycle Activity Cluster CIOs Cluster Architects Cluster IT Planners Cluster ARB Define service goals & performance measures I I Evaluate & select design methods & disciplines I I Evaluate & select design tools Maintain & distribute methods, disciplines & tools I I Support users of approved methods, disciplines & tools I I Assess methods, disciplines & tools proposed for projects I I Monitor performance measures & achievement I I 2-36 EAPM Version 3.0

103 Methods and Tools Service Ministry roles in service life cycle activities Table 2-34 summarizes the roles played by core business parties in the activities of the Methods and Tools Service. Table 2-34: Core business role in lifecycle activities of the Methods and Tools Service Service Life Cycle Activity ADMs Business Area Leaders Bus Planners Architects Shared Public Service Providers Define service goals & performance measures.. I.. Evaluate & select design methods & disciplines.. I.. Evaluate & select design tools.. I.. Maintain & distribute methods, disciplines & tools Support users of approved methods, disciplines & tools Assess methods, disciplines, tools proposed for projects.. I.... I.... I.. Monitor performance measures & achievement.. I.. June 3,

104 Chapter 2: Introduction to OPS EA Program Architecture Services Architecture Review Service Provide an assessment of architecture for compliance with the intentions of the governors as well as the applicable policies and standards. Ensures alignment of I&IT plans, designs and constructed components with I&IT governors strategies and standards, and with business strategies and standards. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers A compliance assessment. Table 2-35 defines the events that trigger delivery of this service. Table 2-35: Service delivery triggers for Architecture Review Service Category Routine R Response Event Business (budget) planning cycle IT strategic planning cycle Major Trigger Regular Trigger IT project milestones IT product or service acquisition Proactive R Response Government or legislation change Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change P EA R Program Initial architecture development Architecture program event Technology trends. Unpredictable Event Audits FOI request Major crisis 2-38 EAPM Version 3.0

105 Architecture Review Service Service delivery roles Table 2-36 defines the parties that play various roles in the delivery of this service. Role Table 2-36: Architecture Review Service delivery roles Corporate level Cluster level Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Project level Core business & external level Client Cluster Business management team management (MBS)* team Provider IT Architects** IT Architects Partner Regulator (PR) Regulator (BS)) IT Planners, IT Architects ITELC ITELC*, IT Planners Cluster management team Regulator (IS) ITELC**, ARB Cluster management team, Cluster management team Regulator (QS) ITELC**, ARB, Cluster ARB ACT, Auditors, Corporate FOI, HR Stakeholders Other stakeholder Cluster initiatives only * Common or shared IT service initiatives only Common or shared business initiatives only ** Both common or shared IT service and business initiatives (not cluster initiatives) Both cluster initiatives and common or shared business initiatives (not IT service initiatives) June 3,

106 Chapter 2: Introduction to OPS EA Program Architecture Services Service life cycle activities Roles in service life cycle activities Corporate roles in service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Assess business and automation plans Categorize projects (Common, Shared, Local) Commission change initiative framework for designated projects (based on the scope of business or I&IT integration required) Review business designs Review technical designs Adopt approved design elements as authoritative Audit constructed components Monitor service performance measures and achievement of goals. Parties at the corporate, cluster and ministry levels may play prime, involved or approver roles in the activities of the Architecture Review Service. Parties at the project level are clients of this service but do not play active roles in the delivery of this service. Table 2-37 summarizes the roles played by corporate parties in the activities of the Architecture Review Service. Table 2-37: Corporate roles in lifecycle activities in the Architecture Review Service Service Life Cycle Activity ITELC ARB Corporate IT Planners Corporate Architects IT Standards Council MBC Bus Planners Architects Auditor FOIPIP Agency Archivist Define service goals & performance measures A I P A P Assess business & automation plans A P I I A P I I I Categorize projects: common, shared, local I A I P A P Commission framework for designated projects A 1 I P 1 A 1 P EAPM Version 3.0

107 Architecture Review Service Review business design I I I A 1 P 1 I I I Review technical design A 1 I P 1 I I I I Adopt approved design elements as authoritative P I Audit constructed components I I P Monitor performance measures & achievement A I P A P Cluster roles in service life cycle activities Table 2-38 summarizes the roles played by cluster parties in the activities of the Architecture Review Service. Table 2-38: Cluster roles in lifecycle activities in the Architecture Review Service Service Life Cycle Activity Cluster CIOs Cluster Architects Cluster IT Planners Cluster ARB Define service goals & performance measures Assess business & automation plans Categorize projects: shared, local common, I A I P I I I I Commission framework for designated projects P 1 I A 1 Review business design I I I I Review technical design Adopt approved design elements as authoritative P 1 A 1 I Audit constructed components I I Monitor performance measures & achievement I I June 3,

108 Chapter 2: Introduction to OPS EA Program Architecture Services Ministry roles in service life cycle activities Table 2-39 summarizes the roles played by core business parties in the activities of the Architecture Review Service. Table 2-39: Ministry roles in life cycle activities for the Architecture review Service Service Life Cycle Activity ADMs Business Area Leaders Business Planners Architects Shared Public Service Define service goals & performance measures I Assess business & automation plans A P I Categorize projects: shared, local common, Commission framework for designated projects Review business design Review technical design Adopt approved design elements as authoritative Audit constructed components Monitor performance measures & achievement I I I I A 1 P 1 I I I I I 2-42 EAPM Version 3.0

109 Repository Service Repository Service Provides artifacts related to previous architecture and design efforts regarding component designs for business and I&IT. This involves collection, storage, stewardship, and access to design artifacts. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers An artifact version. Table 2-40 defines the events that trigger delivery of this service. Table 2-40: Service delivery triggers for Architecture Review Service Category Event Major Trigger Regular Trigger Routine R Response Business (budget) cycle planning IT strategic planning cycle IT project milestones IT product or service acquisition Proactive R Response Government or change legislation Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change P EA R Program Initial architecture development Architecture program event Technology trends. Unpredictable Event Audits FOI request Major crisis June 3,

110 Chapter 2: Introduction to OPS EA Program Architecture Services Service delivery roles Table 2-41 defines the parties that play various roles in the delivery of this service. Table 2-41: Quality Assurance Service delivery roles Role Client Corporate level Cluster level Cluster management team (MBS)* Provider IT Architects** IT Architects Partner Regulator (PR) Regulator (BS)) IT Planners, IT Architects ITELC ITELC*, IT Planners Cluster management team Cluster management Regulator (IS) ITELC**, ARB team, Cluster management team Regulator (QS) Other stakeholder ITELC**, ARB, ACT, Auditors, Cluster ARB Corporate FOI, HR Stakeholders Project level Core business & external level Business management team Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Cluster initiatives only * Common or shared IT service initiatives only Common or shared business initiatives only ** Both common or shared IT service and business initiatives (not cluster initiatives) Both cluster initiatives and common or shared business initiatives (not IT service initiatives) 2-44 EAPM Version 3.0

111 Repository Service Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Evaluate and select a suitable repository tool Install and operate EA repository Provide training for users and support staff Provide support to users Monitor service performance measures and achievement of goals. Roles in service life cycle activities Corporate roles in service life cycle activities Parties at the corporate, cluster, ministry and may play prime, involved or approver roles in the activities of the Repository Service. Parties at the project level are clients of this service, but do not play active roles in the delivery of this service. Table 2-42 summarizes the roles played by corporate parties in the activities of the Repository Service. Table 2-42: Corporate roles in lifecycle activities in the Repository Service Service Life Cycle Activity ITELC ARB Corporate IT Planners Corporate Architects IT Standards Council MBC Bus Planners Architects Auditor FOIPIP Agency Archivist Define service goals & performance measures A I P A P I I Evaluate and select a suitable repository tool P A P I I I Install and operate EA repository P Provide training for users and support staff P Provide support to users P Monitor performance measures & achievement A I P A P June 3,

112 Chapter 2: Introduction to OPS EA Program Architecture Services Cluster roles in service life cycle activities Table 2-43 summarizes the roles played by cluster parties in the activities of the Repository Service. Table 2-43: Cluster roles in lifecycle activities in the Repository Service Service Life Cycle Activity Cluster CIOs Cluster Architects Cluster IT Planners Cluster ARB Define service goals & performance measures Evaluate and select a suitable repository tool Install and operate EA repository Provide training for users and support staff Provide support to users Monitor performance measures & achievement I I A I P P P P P Ministry roles in service life cycle activities Table 2-44 summarizes the roles played by core business parties in the activities of the Repository Service. Table 2-44: Ministry roles in life cycle activities for the Repository Service a Service Life Cycle Activity s ADM Business Are Lead ers Busin es s Plan ners Architec t s Pu blic Shared Service Define service goals & performance measures I Evaluate and select a suitable repository tool Install and operate EA repository Provide training for users and support staff Provide support to users Monitor performance measures & achievement I 2-46 EAPM Version 3.0

113 Reference Model Service Reference Model Service Provides a reference model for re-use in change initiatives. A reference model is a generic design for an enterprise component for which there may be multiple instances throughout the enterprise. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers A new version of a reference model. Table 2-45 defines the events that trigger delivery of this service. Table 2-45: Service delivery triggers for the Reference Model Service Category Event Major Trigger Regular Trigger Routine Response Business (budget) planning cycle IT strategic planning cycle IT project milestones IT product or service acquisition Proactive Response Government or legislation change Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change EA Program Initial architecture development Architecture program event Technology trends. Unpredictable Events Audits FOI request Major crisis June 3,

114 Chapter 2: Introduction to OPS EA Program Architecture Services Service delivery roles Table 2-46 defines the parties that play various roles in the delivery of this service. Table 2-46: Reference Models Service delivery roles Role Corporate level Cluster level Project level Client Architects, IT Planners IT Planners Project staff Provider IT Architects IT Architects Architects Partner IT Architects Core business & external level Business planner & designers Regulator (PR) ITELC Regulator (BS)) Regulator (IS) Regulator (QS) ARB Cluster ARB Other stakeholder Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Identify requirement for new reference model version Design new reference model version Approve new reference model version Publish new reference model version in repository Life-cycle manage reference model Monitor service performance measures and goal achievements. Roles in service life cycle activities Parties at the corporate, cluster, ministry and project levels may play prime, involved, or approver roles in the activities of the Reference Model Service EAPM Version 3.0

115 Reference Model Service Corporate roles in service life cycle activities Table 2-47 summarizes the roles played by corporate parties in the activities of the Reference Model Service. Table 2-47: Corporate role in lifecycle activities in the Reference Model Service Service Life Cycle Activity LC ITE B AR Corporat e IT Pla nners Corporate Archite ct s an da r d s l St nci IT Cou MBC Bu s Plan ners Archite ct s itor Aud Agency FOIPIP t Arch ivis Define service goals and performance A P P measures Identify requirement for new reference P I model version Design new reference model version P I Approve new reference model A I I I version Publish new reference model version in P repository Life-cycle manage reference model P I Monitor performance measures & A P I achievements June 3,

116 Chapter 2: Introduction to OPS EA Program Architecture Services Cluster roles in service life cycle activities Table 2-48 summarizes the roles played by cluster parties in the activities of the Reference Model Service. Table 2-48: Cluster role in lifecycle activities in the Reference Model Service.. Service Life Cycle Activity CIOs Cluster s Cluster Arc hitect s Cluster IT Plann er ARB Cluster Define service goals and performance measures Identify requirement for new reference version model. P.... P. I.. Design new reference model version. P... Approve new reference model version. I.. P. Publish new reference model version in repository. P... Life-cycle manage reference model. P... Monitor performance measures & achievements. I.. P. Ministry roles in service life cycle activities Table 2-49 summarizes the roles played by ministry parties in the activities of the Reference Model Service. Table 2-49: Ministry roles in lifecycle activities in Reference Model Service. Service Life Cycle Activity ADMs Area s Busines Leaders ners s n Bus Pla Architect Shared Public Service Pr oviders Define service goals and performance measures Identify requirement for new reference model version Design new reference model version I I Approve new reference model version I I I P 2-50 EAPM Version 3.0

117 Reference Model Service Publish new reference model version in repository Life-cycle manage reference model Monitor performance measures & achievements I Project-level roles in service life cycle activities Table 2-50 summarizes the roles played by project-level parties in the activities of the Reference Model Service. Table 2-50: Project-level roles in lifecycle activities in the Reference Model Service Service Life Cycle Activity Project Steering Committees Project Managers Project Architects Business Experts Systems Developers External Consultants Shared Risk Partners Define service goals and performance measures Identify requirement for new reference model version Design new reference model version Approve new reference model version Publish new reference model version in repository Promote, provide access & distribute EAs Monitor performance measures & achievements I P I P P P June 3,

118 Chapter 2: Introduction to OPS EA Program Architecture Services Architect Certification Service Certifies an architect as competent to create architecturally compliant design models. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers A period of certification of architectural competence. Table 2-51 defines the events that trigger delivery of this service. Table 2-51: Service delivery triggers for the Architect Certification Service Category Event Major Trigger Routine Response Proactive Response Business (budget) planning cycle IT strategic planning cycle IT project milestone IT product or service acquisition Government or legislation change Vote/Item change Origination change (Program/Service) Business partner change Business policy, process or practice change EA Program Initial architecture development Unpredictable Events Architecture program event Technology trends Audits FOI request Major crisis Regular Trigger 2-52 EAPM Version 3.0

119 Architect Certification Service Service delivery roles Table 2-52 defines the parties that play various roles in the delivery of this service. Table 2-52: Architecture Certification Service delivery roles Role Corporate level Cluster level Project level Core business & external level Client ITELC, ARB, Cluster Project steering Business CIPMC, IT management team, committee, Project management team, Planners, ACT, Business planners, managers, Business planners & PMA, ITSC, Auditor, IT Architects, Architects, Project designers, Shared Corporate FOI, HR Cluster ARB staff public service Stakeholders providers, Shared risk suppliers, Suppliers Provider IT Architects IT Architects Partner IT Architects Regulator (PR) Regulator (BS)) Regulator (IS) Regulator (QS) Other stakeholder ITELC ARB Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Identify architect certification need Conduct architect assessment Issue architect certification Monitor service performance measures and achievement of goals. June 3,

120 Chapter 2: Introduction to OPS EA Program Architecture Services Roles in service life cycle activities Corporate roles in service life cycle activities Parties at the corporate, cluster and ministry levels may play prime, involved or approver roles in the activities of the Architecture Education Service. Parties at the project level are clients of this service but do not play active roles in the delivery of this service. Table 2-53 summarizes the roles played by corporate parties in the activities of the Architect Certification Service. Table 2-53: Corporate role in lifecycle activities in the Architect Certification Service cy Service Life Cycle Activity ITELC ARB Corporat e IT Planne r s Corp o r a te Architec t s IT S t a nd ards Council MBC Bus Plann ers Architec t s Auditor FOIPI P Ag en Archivist Define service goals & performance A P P measures Identify architect certification need Conduct architect assessment P P P P Issue architect certification Monitor performance measures & achievement P I I A P P 2-54 EAPM Version 3.0

121 Architect Certification Service Cluster roles in service life cycle activities Table 2-54 summarizes the roles played by cluster parties in the activities of the Architect Certification Service. Table 2-54: Cluster role in lifecycle activities in Architect Certification Service Service Life Cycle Activity Cluster CIOs Cluster Architects Cluster IT Planners Cluster ARB Define service goals & performance measures I I Identify architect certification need I I Conduct architect assessment I I Issue architect certification I I Monitor performance measures & achievement I I Ministry roles in service life cycle activities Table 2-55 summarizes the roles played by ministry parties in the activities of the Architect Certification Service. Table 2-55: Ministry roles in lifecycle activities in the Architect Certification Service Service Life Cycle Activity ADMs Business Area Leaders Bus Planners Architects Shared Public Service Providers Define service goals & performance measures I Identify architect certification need I Conduct architect assessment I Issue architect certification I Monitor performance measures & achievement I June 3,

122 Chapter 2: Introduction to OPS EA Program Architecture Services Architecture Project Planning Service Produces architectural project plans. This service assists change initiatives in planning for architecture related activities. [Note: Some changes were made to the service descriptions in Version 3 of the EAPM Handbook, based on the report of the Business Architecture for EA COE Project. Time did not permit a more thorough examination of all of the various tables to determine the additional changes that will need to be made. This has been left for a future update.] Service output Service delivery triggers An architectural project plan. Table 2-56 defines the events that trigger delivery of this service. Table 2-56: Service delivery triggers for the Architecture Project Planning Service Category Event Major Trigger Regular Trigger Routine Response Business (budget) planning cycle IT strategic planning cycle IT project milestones IT product or service acquisition Proactive Response Government or legislation change Vote/Item (Program/Service) change Organization change Business partner change Business policy, process or practice change EA Program Initial architecture development Architecture program event Technology trends. Unpredictable Events Audits FOI request Major crisis 2-56 EAPM Version 3.0

123 Architecture Project Planning Service Service delivery roles Table 2-57 defines the parties that play various roles in the delivery of this service. Table 2-57: Architecture Project Planning Service delivery roles Role Client Corporate level IT Planners Cluster level IT Planners Project level Architects, Project staff Provider IT Architects IT Architects Architects Partner IT Architects Core business & external level Business planner & designers Regulator (PR) ITELC Regulator (BS)) Regulator (IS) Regulator (QS) ARB Cluster ARB Other stakeholder Legend: PR = Priorities setting and allocating resources BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies QS = Quality assurance and standards Service life cycle activities This architectural service requires the following activities in its value chain or life cycle: Define service goals and performance measures Identify requirement for new architectural project plan Provide procedural advice Approve architectural project plan Monitor service performance measures and goal achievements. Roles in service life cycle activities Corporate roles in service life cycle activities Parties at the corporate, cluster, ministry and project levels may play prime, involved, or approver roles in the activities of the Architecture Project Planning Service. Table 2-58 summarizes the roles played by corporate parties in the activities of the Architecture Project Planning Service. June 3,

124 Chapter 2: Introduction to OPS EA Program Architecture Services Table 2-58: Corporate role in lifecycle activities in the Architecture Project Planning Service Corporate IT Plan ne r s Corpor at e Archite ct s y Service Life Cycle Activity LC ITE B AR dards l an nci IT St Cou C MB rs Bu s P lan ne Archite ct s itor Aud IPIP Agenc FO hivist Arc Define service goals and performance measures A P P Identify requirement for new architectural project P I plan Provide procedural advice P I Approve architectural project plan A I Monitor performance measures & achievements A P I Cluster roles in service life cycle activities.. Table 2-59 summarizes the roles played by cluster parties in the activities of the Architecture Project Planning Service. Table 2-59: Cluster role in lifecycle activities in the Architecture Project Planning Service Service Life Cycle Activity Define service goals and performance measures Identify requirement for new architectural project plan Provide procedural advice Approve architectural project plan Monitor performance measures & achievements I P Cluster CIOs Cluster Archite ct s P P P P Planners Cluster IT Cluster ARB 2-58 EAPM Version 3.0

125 Architecture Project Planning Service Ministry roles in service life cycle activities Table 2-60 summarizes the roles played by ministry parties in the activities of the Architecture Project Planning Service. Table 2-60: Ministry roles in lifecycle activities in Architecture Project Planning Service rs Service Life Cycle Activity AD M s a Bu siness Are Lead ers ers Bu s Plann Archit ects Shar ed Public Service Pr ov ide Define service goals and performance measures I Identify requirement for plan new architectural project P Provide procedural advice I Approve architectural project plan I Monitor performance measures & achievements I Project-level roles in service life cycle activities Table 2-61 summarizes the roles played by project-level parties in the activities of the Architecture Project Planning Service. Table 2-61: Project-level roles in lifecycle activities in the Architecture Project Planning Service Service Life Cycle Activity Project Steering Committees Project Managers Project Architects Business Experts Systems Developers External Consultants Shared Risk Partners Define service goals and performance measures Identify requirement for new architectural project plan Provide procedural advice P I I I I I Approve architectural project plan Monitor performance measures & achievements June 3,

126 Chapter 2: Introduction to OPS EA Program Architecture Governance 2.3 Architecture Governance This section presents the following topic areas: Governance Parties and Roles The architectural governance model operates at several levels within the Ontario Public Sector. These levels include corporate, cluster, project, ministry (program/service), and external stakeholders. At each level, different parties (organizations and positions) play specific roles with respect to each service offered by the architecture function EAPM Version 3.0

127 Architecture Project Planning Service Governance Parties and Roles The architectural governance model operates at several levels within the Ontario Public Sector. These levels include corporate, cluster, project, ministry (program/service), and external stakeholders. Levels of architectural governance The architectural governance model operates at several levels within the Ontario Public Sector. These levels include: Corporate level Cluster level Project level Ministry level (program/service) External stakeholder level. Role types At each level, different parties (organizations and positions) play specific roles with respect to each service offered by the architecture function. These roles can be classified into three types: Service provision roles Service activity roles Service governance roles. Service provision roles Different organizations and positions play particular roles with respect to the provision of a given architectural service. The services of the OPS EA Program are delivered to a set of clients. Client (C) A client of a given service has a need that is fulfilled by the service. As such, a client does the following: Requests a service Uses the result of the service Directly or indirectly receives the benefit of the service. Service provider (P) Service delivery business partners (BP) Other Stakeholder The service provider is the party with the major accountability for the activities in the value chain or life cycle of a given architectural service. Service delivery business partners provide resources that contribute materially to the delivery of architectural services. Other stakeholders have an accepted interest in the requirements or outcomes of the service. June 3,

128 Chapter 2: Introduction to OPS EA Program Architecture Governance Service governance roles Regulator or gatekeeper Different organizations and positions play particular roles with respect to governing the services of the OPS EA Program. These governance roles may be thought of as regulator or gatekeeper roles. Service delivery regulators or gatekeepers ensure the alignment and integration of individual initiatives with higher level or collective goals within the context of a given architectural service. Regulators may have one or more of the following focuses: PR: Priorities and resources (business-focused) BS, IS: Business or I&IT strategy QS: Quality, best practice and other standards. Service activity roles Prime (P) or lead Involved (I) Approver (A) Corporate level Different organizations and positions play particular roles with respect to the execution of the activities required to create a service, acquire the capability to deliver it, deliver the service and monitor the performance of the service. The organization or position has primary or lead responsibility for the execution of the activity. The organization or position is involved in the execution of the activity but does not have primary responsibility for the activity. For example, the party might be involved in the creation of particular architectural artifacts or delivering training courses. The organization or position approves the deliverables generated by the activity. For example, the party might approve architectural artifacts. The OPS EA Program at the corporate level has a mandate to define, review and recommend improvements to information and information technology elements that are: Common across the government Shared between several clusters This responsibility may be delegated to a lead cluster for specific elements. Corporate level organizations and positions At the corporate level, the OPS EA Program involves the following organizations and positions that may play the roles of service provider, partner, client, or regulator, depending upon the specific architectural service:. q Deputy Ministers Committee on OPS Transformation (DMCOT) Transformation Leadership Committee (TLC) Corporate Chief Technology Officer Information Technology Executive Leadership Council (ITELC) Corporate Architecture Review Board (ARB) Corporate Architecture Core Team (ACT) Information Technology Standards Council (ITSC) Corporate Head architect 2-62 EAPM Version 3.0

129 Architecture Project Planning Service Auditor Cluster level The I&IT cluster level has the mandate to define, review and recommend improvements to information and information technology elements that are specific to a given cluster. For example: The Land and Resources Cluster might be responsible for I&IT elements related to the management of natural resources The Transportation Cluster might be responsible for I&IT elements related to the management of the provincial highway network The Human Services Cluster might be responsible for I&IT elements related to the management of training and educational services related to OPS employees. Cluster level organizations and positions Project level Project level organizations and positions Ministry level At a typical cluster level, the OPS EA Program involves the following organizations and positions that may play the roles of service provider, partner, client or regulator, depending upon the specific architectural service:. Cluster Management Team Cluster Business Planner and Designer Cluster Head Architect Cluster I&IT Architects Cluster Architecture Core team Cluster Architecture Review Board At the project level, the OPS EA Program provides business and automation designs. It also is a client of the corporate and cluster level services. At the project level, the OPS EA Program involves the following organizations and positions that may play the roles of service provider, partner, client or regulator, depending upon the specific architecture service: Project Steering Committee Project Manager Project Architect Project Staff. Organizations and positions at the ministry level tend to be either clients or partners of the architecture function as it operates at the corporate, cluster and project levels. Clients or partners at the ministry level include: Strategic and Business Planning Teams Program Management Team Program Planner or Designer Shared Public Service Provider June 3,

130 Chapter 2: Introduction to OPS EA Program Architecture Governance External level Organizations and positions at the external level tend to be either clients or partners of the OPS EA Function as it operates at the corporate, cluster and project levels. Clients or partners at the external level include: Shared Risk Supplier Supplier 2-64 EAPM Version 3.0

131 Architecture Project Planning Service 2.4 Corporate Architecture Governance This section presents the following topic areas:corporate Governance Bodies Corporate A number of organizations and positions participate in the governance of the Governance OPS EA Program at the corporate level. Each subject in this section describes Bodies one of these parties and identifies its mandate and responsibilities Deputy Ministers The Deputy Ministers Committee on OPS Transformation (DMCOT) Committee on develops strategies and provides leadership for the transformation of the OPS OPS into an integrated, client-centred, efficient and effective organization. Transformation Transformation The Transformation Leadership Committee (TLC) supports the DMCOT. Leadership Committee I&IT Executive The I&IT Executive Leadership Council (ITELC) is a quality assurance body Leadership that provides leadership of the architecture process in the Ontario Council Government Information The Information Technology Standards Council (ITSC) is an inter-ministerial Technology council responsible for reviewing, approving and maintaining Government of Standards Council Ontario information technology standards (GO ITS) Corporate The Corporate Architecture Review Board (ARB) is a quality assurance body Architecture that provides leadership of the architecture process in the Ontario Review Board Government Corporate The Corporate Architecture Core Team (ACT) is an advisory body that Architecture Core provides a forum for validating the Enterprise Information Architecture (EA) Team against business priorities and directions of the Ontario Public Sector Business The Business Architecture Domain Working Group (BADWG) provides Architecture leadership in the review of the business architecture components of the OPS Domain Working EA. It also champions the development of business architecture skills. Group Information The Information Architecture Domain Working Group (IADWG) provides Architecture leadership in the review of the information architecture components of the Domain Working OPS EA. It also champions the development of information architecture Group skills Application The Application Architecture Domain Working Group (AADWG) provides Architecture leadership in the review of the application architecture components of the Domain Working OPS EA. It also champions the development of application architecture skills. Group June 3,

132 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Technology The Technology Architecture Domain Working Group (TADWG) provides Architecture leadership in the review of the Technology architecture components of the Domain Working OPS EA. It also champions the development of technology architecture skills. Group Security The Security Architecture Domain Working Group (SADWG) provides Architecture leadership in the review of the security architecture components of the OPS Domain Working EA. It also champions the development of security architecture skills. Group EA Methodology The EA Methodology Working Group (EAMWG) provides leadership in EA Working Group processes, methodology, standards and tools EAPM Version 3.0

133 Architecture Project Planning Service Corporate Governanace Bodies A number of organizations and positions participate in the governance of the OPS EA Program at the corporate level. Each subject in this section describes one of these parties and identifies its scope and mandate, its objectives, architectural role, membership, and operating procedures. Reporting relationships Figure 2-1 illustrates the reporting relationships of some of the major organizations involved in architectural governance at the corporate level, directly or indirectly. Figure 2-1: Corporate architectural governance bodies June 3,

134 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Cluster and project relationships Review of corporate IT projects Cluster governance bodies Figure 2-2 illustrates how key corporate governance bodies relate to cluster governance bodies and I&IT projects at the corporate and cluster level. Figure 2-2 also illustrates how corporate I&IT projects are reviewed by the: ACT and ARB for compliance with architectural policies and standards ITSC for compliance with general I&IT standards. Several I&IT clusters are currently commissioning Architecture Review Boards and Architecture Core Teams to review cluster level business and I&IT designs and components from cluster level I&IT projects. Other clusters are using equivalent organizations (the I&IT Planning and Architectures Office for the Transportation Cluster). Figure 2-2 also illustrates how cluster level I&IT projects are reviewed by the: Cluster ACT and ARB (or equivalent) for compliance with architectural policies and standards ITSC for compliance with general I&IT standards. Cluster I&IT projects may be referred by the cluster ARB or ACT (or equivalent) to their corporate counterparts for review. This could happen, for example, when the designs and components of the cluster I&IT project are non-compliant with corporate architectural policies and standards or if the cluster I&IT project is producing innovative designs or components that may have architectural significance beyond the cluster. Figure 2-2: Cluster & project relationships 2-68 EAPM Version 3.0

135 Deputy Ministers Committee on OPS Transformation Deputy Ministers Committee on OPS Transformation The Deputy Ministers Committee on OPS Transformation (DMCOT) develops strategies and provides leadership for the transformation of the OPS into an integrated, client-centred, efficient and effective organization. Mandate To develop strategies and provide leadership for the transformation of the OPS into an integrated, client-centred, efficient and effective organization. More specifically, the Committee s mandate is to: Provide visible and focused leadership for the development and implementations of strategies to support the transformation of the OPS for the 21 st century; Lead change management strategies including identifying and addressing both opportunities and barriers to changes that cut across ministry and functional lines; Make decisions, as appropriate, or recommendations that balance corporate and ministry perspectives on priorities for action, management policies, organizational structures and accountabilities, resource reallocation and the assignment of new initiatives to address problems or opportunities; Monitor progress towards the achievement of the vision and take corrective action, including resolving issues and disputes; Develop and implement OPS directions in the context of the directions of partners and potential partners in the broader public sector, other levels of government and the private sector, including providing leadership for transformation across the public sector in Ontario; Ensure the widespread awareness of the vision of the OPS and the action plan to implement that vision; Encourage the necessary changes in OPS culture and encourage the support, commitment and involvement of staff and partners at all levels; and Ensure that the complementary visions of electronic government, integrated service delivery, integrated inspection, investigation and enforcement activities, and shared administrative services are achieved. Roles and Responsibilities The Committee s responsibilities include: Making recommendations or decisions on issues and opportunities that cross ministries and/or functions; Making decisions or recommendations to eliminate barriers to achievement of the vision for the OPS of the future; June 3,

136 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Monitoring and enforcing of decisions that fit the above two categories; and Ensuring education, awareness and communications in support of the vision. Membership Permanent Co-Chair: Deputy Minister, Management Board Secretariat and Secretary to Management Board of Cabinet Rotating Co-Chair: Selected from body of Deputy Ministers Members are all at the Deputy Minister level EAPM Version 3.0

137 Transformation Leadership Committee Transformation Leadership Committee The Transformation Leadership Committee (TLC) supports the DMCOT. Mandate The Transformation Leadership Committee has been established by the Deputy Ministers Committee on OPS Transformation to support the Deputy Ministers in developing strategies and providing leadership for the transformation of the OPS into an integrated, client-centred, efficient and effective organization. The Transformation Leadership Committee is charged with: Acting as an incubator of new ideas related to OPS transformation; Providing a horizontal perspective and advice on transformational issues and initiatives including but not limited to: e-government, integrated service delivery, II&E, directions for enterprise management, OPS workforce, culture and change management; Making decisions on matters delegated to it by DMCOT; and Owning and steering change implementation of key initiatives. Roles and Responsibilities The Transformation Leadership Committee has been established by the Deputy Ministers Committee on OPS Transformation to support the Deputy Ministers in developing strategies and providing leadership for the transformation of the Ontario Public Service (OPS) into an integrated, clientcentred, efficient and effective organization. The Transformation Leadership Committee is charged with: Acting as an incubator of new ideas related to OPS transformation; Providing a horizontal perspective and advice on transformational issues and initiatives including but not limited to: e-government, integrated service delivery, II&E, directions for enterprise management, OPS workforce, culture and change management; Making decisions on matters delegated to it by DMCOT; and Owning and steering change implementation of key initiatives. Membership Permanent Central Agency Co-Chair: Corporate Chief Information Officer Rotating Line Ministry Co-Chair: Selected from body of Deputy Ministers Members are at the Assistant Deputy Minister level, including several Chief Administrative Officers and Cluster Chief Information Officers. June 3,

138 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance I&IT Executive Leadership Council The I&IT Executive Leadership Council is a quality assurance body that provides leadership of the architecture process in the Ontario Government. Mandate Roles and Responsibilities To ensure that the value of the government investment in I & IT, people and dollars is maximized through development and delivery of I&IT in the Ontario government in support of business directions and priorities. The Council acts as the key decision-making body for I&IT across the OPS and undertakes the following: Establishes the resource and procurement priorities for I&IT infrastructure projects and services that support the government s business objectives; Provides leadership and direction in planning, development and delivery of I&IT infrastructure projects that support the government s business objectives; Establishes priorities for I&IT human resources, including identification of emerging needs, trends and issues, and approval of plans to address those issues; Provides leadership in identifying and implementing opportunities for I&IT to add value to programs and business areas and enable business transformation; Approves enterprise I&IT standards, best practices and guidelines; Defines common infrastructure areas to be implemented across the OPS; Reports on performance measurements and outcomes achieved by the I&IT organization Provides a forum to identify and address issues of common concern in the I&IT organization and to exchange information and ideas in support of the organization; Provides leadership to support the effective integration of cross-cluster I&IT applications; and Approves and implements communication strategies and plans to support the Council s mandate and its decisions. Membership The Chair is the Corporate Chief Information Officer. Members are principally at the Cluster CIO and Corporate Chief level. There is also a CAO member who represents the CAO Forum EAPM Version 3.0

139 Information Technology Standards Council Information Technology Standards Council The Information Technology Standards Council (ITSC) is an inter-ministerial council responsible for reviewing, approving and maintaining Government of Ontario information technology standards (GO ITS). Mandate Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the standards, guidelines, technical reports and preferred practices adopted and promulgated by the IT Standards Council (ITSC) under delegated authority by the Management Board of Cabinet. These publications, available through the GO-ITS web site, support the Management Board Secretariat's responsibilities for coordinating the standardization of information and technology in the government of Ontario. Internal GO-ITS standards are internal documents and implementation guidelines that are available only to the Ontario government. More specifically, the Committee s mandate is to: recommend technical standards and related mandatory I&IT guidelines, procedures and methodologies to the Architecture Review Board and the IT Executive Leadership Council govern and provide government-wide input into the standards review, development, adoption and approvals process communicate and promote approved technical standards outward to all I&IT stakeholders adopt "open industry standards developed by recognized open standards development organizations to maximize interoperability and access to data Roles and Responsibilities The ITSC serves as an inter-ministerial council with responsibilities that include: Facilitate and encourage collaboration amongst the ministries/clusters, IT procurement, other governmental jurisdictions, the broader public sector, professional standards setting bodies, external partners and vendors; Assist major projects and initiatives in the selection, adoption and development (where necessary) of Government of Ontario Information Technology Standards (GO-ITS) or related standard processes/guideline/ procedures. Review, approve and maintain GO-ITS standards and, where appropriate, promote the need for a coordinated I&IT standards agenda for the province; Aim to minimize duplication and proliferation of conflicting standards; Develop a central source for provincial I&IT standards; and Engage the province in a more coordinated, proactive role in federal and international standards initiatives. June 3,

140 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Membership The Chair is the Manager, Technical Standards - Corporate Architecture and Standards Branch. Members are OPS/BPS management level. Link to ITSC intranet for current members located at index_.asp EAPM Version 3.0

141 Architecture Review Board Architecture Review Board Terms of reference for the Architecture Review Board. [Note: At the time of writing, these are proposed revised TOR and have not yet been approved.] Mandate The corporate Architecture Review Board (ARB) is an approval board for Government of Ontario (GO) Enterprise Architecture (EA) and Information Technology Standards (GO-ITS). The Board will: Direct the continued development of the Ontario Government s federated Enterprise Architecture Framework; Direct alignment of corporate and cluster-based architectures within this framework; Ensure that projects impacting/leveraging common services and infrastructure are in alignment with the enterprise architecture; Approve architecture of reviewed initiatives; Oversee the development of the long range plan for I&IT Standards; and Approve GO-ITS. The Board will not review the following: Projects entirely within a cluster s line of business(es); Any budgeting or resourcing requests; I&IT plan analysis; or Business strategy analysis. Scope of Responsibility Given this mandate, the corporate ARB reports to Information Technology Executive Leadership Council (ITELC) and provides the overall direction to refinements to the enterprise architecture and ensures alignment and integration of individual initiatives (fitting the definition of projects as noted above) with goals of the enterprise from these perspectives: Alignment with overall business strategies of the government. The cluster members also have the responsibility to ensure alignment/identify non-alignment with their business strategies; Alignment with corporate I&IT strategies; Compliance with quality, best practices and I&IT standards as approved in the enterprise architecture; and Elimination of duplication and promotion of reusable architectural components for business automation design and construction. The ARB is a Gatekeeper board and does not have priority or budgetary (resources) responsibilities. The ARB s primary function is to uphold quality assurance and standards with the criteria as noted within the scope of responsibility by acting as the final approval body for Government of Ontario (GO) Enterprise Architecture (EA) and Information Technology Standards June 3,

142 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance (GO-ITS). The Board s decision with regard to Enterprise Architecture compliance is final. ARB discussions and decisions will be reported to ITELC on a monthly or as required basis. Objectives Given this scope, the corporate ARB has these objectives: To agree upon and set the long-range direction for enterprise architecture; To ensure that any refinements to the enterprise architecture are in support of the business directions of government and fulfilling the objectives of the corporate I&IT strategies; To ensure that the use of architecture in the Ontario Government is relevant, practical, include appropriate tools, standards and methods, and is supported by appropriate skills/training and provide continuous business value; To incorporate I&IT trends and directions from the OPS Technology Futures into the target architecture; To ensure compliance of project/initiative architectures with the enterprise architecture in a timely manner and to approve appropriate changes to the enterprise architecture based on innovations that arise from these project architectures. As part of these reviews, the ARB members will ensure the continued alignment of cluster and corporate architectures; To agree upon and set the long-range plan for I&IT standards based on I&IT trends, revisions needed for existing standards (including the recommendation of phasing out of obsolete standards) and architecture developments. The long-range plan for I&IT standards will be presented to the ITELC on an annual basis by the chair of the ARB; To approve Government of Ontario I&IT Standards; and To communicate as members of the ARB, on an ongoing basis, board decisions and discussions to their cluster/corporate offices. Membership Members have a mandate and responsibility to review projects from an enterprise perspective. Individual members will ensure that their Cluster Architecture Review Boards, or similar functions have fully reviewed projects prior to presenting at the corporate Architecture Review Board. It is expected that projects forwarded to corporate ARB for reviews have received cluster CIO s approval. The ARB is chaired by the Corporate Chief Technology Officer.Members Head, Infrastructure Development and Deployment Branch Head, ITSM and Change Management Branch Head, E-government Branch Head, Corporate Security Branch Chairs of the Cluster ARB and/or I&IT/program head-level representative of the business cluster as appointed by the Business Cluster CIO. (Cluster members may be rotated on a yearly basis, at the discretion of a Business Cluster CIO, in consultation with the Chair.) Secretary Head Architect, Office of the Corporate Chief Technology Officer 2-76 EAPM Version 3.0

143 Architecture Review Board Supporting Team Architecture Core Team (ACT), chaired by the Head Architect and made up of Business Cluster architects, echnical review committee (proposed), members from OCCS, OCCTO and OCCSD. Administrative Support for both the corporate ARB and ACT are provided by the Corporate Architecture & Standards Branch. Reporting Relationship The corporate ARB reports to ITELC on a monthly basis and on a required basis: Exemptions (non-compliance with Enterprise Architecture and standards) Architecture developments that are of benefit across clusters Key architecture issues Long range plan for I&IT Standards EA Work Plan IT Standards Work Plan. Operating Procedures 1. The corporate ARB will meet on a monthly basis or as required. 2. The corporate ARB may request that the ACT and/or the IT Standards Council (ITSC) establish ad hoc working groups to investigate new/ changing architecture or standards issues. These working groups would be in addition to domain architecture working groups or existing ITSC working groups and would only be established if an existing body could not take on the issue within the scope of its mandate. 3. Each regular member will designate an alternate with agreement of the Business Cluster CIO and the ARB Chair in advance. If a member is unable to attend a meeting, the delegate must be fully prepared to represent his/her cluster or corporate office. 4. A meeting will be cancelled by the Chair if less than five members are able to attend. 5. The Secretary will brief the Chair one week in advance of each ARB meeting, in terms of ACT activities, results of milestone reviews of project architectures by ACT and of ITSC activities and their relation with the long range plan for I&IT Standards (the Manager, Technical Standards may present on this as required). 6. Draft minutes will be distributed to all members and projects which are reviewed by ARB prior to ARB meetings. Changes will be noted at the next meeting and will be made, upon agreement of all members in attendance. The final minutes will be then struck and will be distributed to each board member who will be responsible to transmit the minutes to their cluster/corporate office. 7. Members are to forward any agenda items to the Secretary one week ahead of the meeting. Inclusion of these items on the next agenda will be at the discretion of the Chair. 8. ACT, ITSC, and other working groups will report to the ARB on their activities on a periodic basis or as determined by the Chair. 9. The Chair will brief the ITELC members on the ARB proceedings as a standing item every month (or as required). June 3,

144 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance New Proposed: 10.Chairs of Cluster Architecture Review Board (ARB) or similar review bodies are to forward their agenda and decisions on projects reviewed to ensure alignment and co-ordination with corporate ARB. 11.Ministries that require custom designs and non-standard solutions/ configurations, need to work with iserv upfront as part of the early project review. Major Review Check Points for Corporate ARB Projects, which require ARB review and approval, by their very nature, are important contributors to the information and application architecture of the Ontario Government. There are a number of major milestones within a project life cycle that the Architecture Review Board (ARB) would like to review its intent and progress. The major checkpoints are as shown in Table 2-63: No. Check Point Purpose Table 2-62: ARB Review and Approval Checklist 0 Planning To assist projects in planning and assessment for architecture review and to fit EA into the project life cycle 1 Business Architecture To review for government context and possibilities of alignment and sharing with other similar projects. To review and advise on plans for the acquisition of information and technology goods and services and to ensure alignment with OPS standards. To certify the business architecture is internally consistent and in alignment with EA information, application, technology and security architectures, standards and methods. 2 Logical Architecture To certify the logical design is internally consistent and in alignment with EIA information, application, technology and security architectures, standards and methods. 3 Physical Architecture To certify the physical design is internally consistent and in alignment with the logical architecture and information, application, technology and security standards and methods. 4 (proposed) Solution mapping to Architecture To certify the solution is internally consistent and in alignment with the physical architecture and information, application, technology and security standards and methods 2-78 EAPM Version 3.0

145 Corporate Architecture Core Team (ACT) Corporate Architecture Core Team (ACT) Terms of reference for the Architecture Core Team. [Note: At the time of writing, these are proposed revised TOR and have not yet been approved.] Introduction Mandate The Corporate Architecture Core Team (ACT) is an integral part of the OPS Enterprise Architecture governance body responsible for ensuring compliance and assuring quality. ACT supports the Corporate Architecture Review Board (ARB) in delivering its mandate as the approval board for Government of Ontario (GO) Enterprise Architecture (EA) and Information Technology Standards (GO-ITS). The Corporate ACT guides and facilitates the OPS enterprise architecture program and services to ensure that the architecture meets the needs of business, in accordance with Ontario s Enterprise Architecture methodologies and standards. In order to fulfill this mandate, ACT will: direct the development and enhancement of the Ontario Governments Federated Enterprise Architecture Framework (FEAF); ensure proper alignment of corporate and cluster-based architectures within this framework; assure acceptable alignment of projects that leverage or impact common services and infrastructure within the enterprise architecture; recommend best practices in architecture planning, design and development; perform architecture review of projects/initiatives and made recommendations to ARB; provide a cross cluster forum for identification of architecture program management issues for resolution or for recommendations to ARB; and direct the work/ priorities of OPS Architecture Domain Working Groups (e.g. project architecture quality reviews; development/ use of architecture standards and guidelines). ACT does not: generally review of projects that are entirely within a clusters line of business(es); review any budgeting or resourcing requests; or analyze or review of I&IT plan or business strategy. June 3,

146 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Scope of Responsibility Objectives Under this mandate, ACT reports progress and outcomes to ARB, directs refinement, management and implementation of the enterprise architecture program, and ensures alignment and integration of initiatives and projects that leverage or impact goals of the enterprise architecture program including common services and infrastructure. Specifically, ACT is responsible for ensuring: alignment of Cluster/Corporate enterprise architecture goals, direction and strategies with overall business strategies of the government. Each cluster member is responsible for ensuring alignment or identifying non-alignment with their respective cluster s business strategies; alignment of architecture developments/directions with corporate I&IT strategies; project/initiative compliance with quality assurance, best practices and I&IT standards as approved in the enterprise architecture program; and optimum reuse of architectural components for business automation design and implementation. ACTs primary function is to uphold quality assurance and standards with the criteria as noted within the scope of responsibility by acting as the review body for Government of Ontario (GO) Enterprise Architecture (EA). ACT discussions and recommendations will be reported to ARB. ACT carries no budgetary responsibility. Projects falling within the scope of review by corporate ACT/ARB: all cross-cluster and enterprise-wide systems/projects all common infrastructure projects projects referred by IT controllership projects referred by the cluster CIO any project which might have an extensive or unique impact on the business or technology environment Given this scope, ACT aims at meeting the objectives of: providing and guiding the long-range directions for enterprise architecture (EA); ensuring EA refinements support the business directions of government and fulfill the objectives of the corporate I&IT strategies; assuring the relevant and practical use of architecture in the Ontario Government, including appropriate tools, standards and methods, as supported by appropriate skills/training, so as to provide continuous business value; incorporating I&IT trends and directions from the OPS Technology Futures into the target EA; 2-80 EAPM Version 3.0

147 Corporate Architecture Core Team (ACT) assuring project/initiative architecture compliance with the EA and Federated EA Framework in a timely manner; assessing and approving changes to EA harvesting innovations from project/initiative architectures while at the same time ensuring continued alignment between cluster and corporate architectures; and communicating, through its members, key decisions and significant discussions to their respective cluster/corporate offices and the EA community at large. Membership Members are responsible for project review and endorsement from an enterprise architecture perspective. Individual members will ensure that their respective cluster architecture review bodies (similar to ACT) have fully reviewed projects prior to being presented at the corporate ACT. Projects forwarded to corporate ACT for reviews, are expected to have received cluster CIO s approval. Members are also charged with contributions to fulfill the current mandate of ACT as stated above. Members attend regular ACT meetings, advice on standards and policies, review governance and professional practices, and represent their clusters in interests of architectural relevance. The Head Architect in OCCTO chairs the ACT. Members: Member, OCCSD Member, ITSM and Change Management Branch Member, E-government Branch Member, Corporate Security Branch Managers, Corporate Architecture and Standards Branch Business Cluster architects representative of the business cluster as appointed by the Business Cluster CIO. (Cluster members may be rotated on a yearly basis, at the discretion of a Business Cluster CIO, in consultation with the Chair). Supporting Team: Domain Working Groups (IADWG, BADWG, AADWG, TADWG, EAMDWG, EAFFWG and SAWG) The Corporate Architecture & Standards Branch will provide administrative Support. June 3,

148 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Reporting Relationship The Corporate ACT reports to ARB on: recommendations on projects reviewed and endorsed by ACT members; exemptions from compliance with EA, Federated EA Framework, IT Standards and relevant methods and processes (e.g., EAPM Handbook); architecture planning, designs and developments that are of benefit to OPS and across clusters; architecture issues, resolutions and approaches that are relevant and significant to EA, methods and processes;and EA Work Plan. Delegation of Authority ARB delegates authority to ACT to approve guidebooks, handbooks, and similar architectural design and implementation materials for practices in the I&IT areas including editorial, alignment and reference updates; approve templates based on approved artifacts (note: designation of artifacts on the checkpoint checklist has to receive approval from ARB); and approve detailed project/initiative artifacts. Operating Procedures 1. ACT will meet on a bi-weekly basis or as required. 2. Each regular member will designate an alternate with agreement of the I&IT Cluster CIO and the ACT Chair in advance. If a member is unable to attend a meeting, the delegate must be fully prepared to represent his/her cluster or corporate office. 3. A meeting will be cancelled by the Chair if less than five members are able to attend or an agenda is under-filled. 4. Draft minutes will be distributed to all members and projects, which are reviewed by ACT prior to ACT meetings. Changes will be noted at the next meeting and will be made upon agreement from all members in attendance. The minutes will be finalized and distributed to each core team member. They are responsible to transmit the minutes to their cluster/corporate office. 5. Members will forward any agenda items and support materials such as presentations to the Chair one week prior to the meeting. Inclusion of these items on the next agenda will be at the discretion of the Chair. 6. Domain working groups will report to the ACT on their activities on a periodic basis or as determined by the Chair. 7. The Chair will brief the ARB members on the ACT proceedings as a standing item monthly (or as required). 8. ACT reviews and summarizes activities of member Clusters and domain working groups in a Work Plan that is produced and reported to ARB quarterly EAPM Version 3.0

149 Corporate Architecture Core Team (ACT) 9. ACT organizes the OPS Architecture Open House that is normally held annually. Major Check Points for Architecture Review of Corporate Projects Projects requiring ACT review and ARB approval may contribute significantly to the enterprise architecture at the Government of Ontario. ACT is responsible for reviewing, recommending and endorsing these cross-cluster projects throughout the architecture development lifecycle at separate stages of architectural decisions and designs known as checkpoints. In general, they correspond to the various levels of architecture development as specified in the EAPM Handbook and the Federated EA Framework. The major checkpoints are shown in the following table: No. Check Point Purpose Table 2-63: ACT/ARB Review and Approval Checklist 0 Planning To assist projects in strategic planning and feasibility assessment for architecture review and to fit EA into the project life cycle 1 Business Architecture To review for government context and possibilities of alignment and sharing with other similar projects. To review and advise on plans for the acquisition of information and technology goods and services and to ensure alignment with OPS standards. To endorse the business architecture is conceptually acceptable, internally consistent and methodologically complete for considerations by EA information, application, technology and security architectures, standards and methods. 2 Logical Architecture To endorse the logical design is consistently aligned with EA business architecture, systematically integrated among information, application, technology and security architectures, and is compliant with published standards, processes and methods. 3 Physical Architecture To endorse the physical design is consistently aligned with the business architecture and the overall logical architecture (that entails integrated information, application, technology and security architectures, and is compliant with published standards, processes and methods). 4 (propos ed) Operational Architecture and Implementation To certify the operational architecture for implementing the solution is consistently aligned with the physical architecture that entails the realization of information, application, technology and security architectures in the operational environments, and is compliant with published standards, processes and methods June 3,

150 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Business Architecture Domain WG The Business Architecture Domain Working Group (BADWG) provides leadership in the review of the business architecture components of the OPS EA. It also champions the development of business architecture skills. Definition of Enterprise Architecture is a representation of the enterprise's key business, Business information, application and technology strategies and their impact on Architecture business services and processes. The Business Architecture Domain Working Domain Group is primarily concerned with the Zachman Framework Rows 1 and 2, recognizing the shared responsibilities with and the appropriate handoffs to the other domain working groups. Mandate Membership The mandate of the (BADWG) is to support the development of the Corporate and Cluster architecture program by: Developing new tools, methodologies and best practices Bridging the gap between business and I&IT (e.g. by developing a common lexicon, creating awareness etc.) Promoting business artefacts as authoritative, to be placed in the appropriate library Supporting business architecture training and education Providing a forum for sharing experiences Working with specific projects as directed by the Architecture Core Team. Recommended membership: Business architects proposed by each Cluster Business representative or business architect from Shared Services Bureau, iserve, ESD, other corporate service organizations Member(s) from Corporate Architecture Branch Business representation (e.g. PMED, other) Members would be appointed and/or recruited by the Head Architect(s) or equivalent in their home positions EAPM Version 3.0

151 Business Architecture Domain WG Governance The BADWG takes direction from ACT and is accountable for the activities it undertakes, to ACT. The BADWG operates in a partnership with other Domain Working Groups on issues of mutual interest. Chair - 1 year, rotating across membership Each member responsible for bringing issues, ideas and/or proposals to the Working Group and reporting back to their home organization. June 3,

152 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Information Architecture Domain WG The Information Architecture Domain Working Group (IADWG) provides leadership in the review of the information architecture components of the OPS EA. It also champions the development of information architecture skills. Definition of Information Architecture Domain Mandate Scope of Responsibility The Information Architecture (IA) Domain encompasses all matters related to the information architecture components of the OPS EA. The IADWG is primarily concerned with Column 1 of the Zachman Framework, recognizing the shared responsibilities with appropriate handoffs to the other domain working groups. To support the mandate of corporate ACT and corporate ARB decision making processes and operations by validating, investigating, researching and developing appropriate method, techniques, best practices, guidelines, technology directions, relevant standards in the IA Domain; specifically: validating and reviewing information architecture of corporate and cluster projects which have OPS wide impacts or as directed by ACT; developing and refining standard design templates, methods, guidelines for the design and implementation of information architecture components of corporate or cluster initiatives; serving as the focal point for consulting and resolving cross clustering policy issues, technology trends and directions in the IA domain; facilitating the sharing and re-use of solutions, and promote a common information architectural culture; developing and promoting the information architecture knowledge base and skills of the clusters and corporate staff; and serving as a working level communication channel between corporate domain working group and cluster architecture structure. The IADWG may include the following major areas within the domain of Information Architecture and Information Management: Information Architecture Information Management Policies and Standards Data Technologies Data Warehouse Strategy and implementation: Information Privacy and Data Security Cluster Projects Metadata 2-86 EAPM Version 3.0

153 Information Architecture Domain WG Membership The Chair of the IADWG is an information architect selected from one of the I&IT clusters for a year at a time. The other members include at least one information architect from each I&IT cluster and the information architects in the Corporate Architecture and Standards Branch. Governance Formal Reporting Relationship: the Chair will report to ACT on regularly basis, to ARB and ITSC as requested. Project Reporting Relationship: the appropriate cluster representative will bring IADWG research/recommendations back to the project in the respective cluster. Support: administrative support to be provided by CAB, other project/event specific support can be provide by various cluster representatives and ACT team, external consultants as required. Task planning: Tasks can be delegated to the IADWG by ACT or ITSC. The working level of cluster & corporate architecture may also suggest tasks. June 3,

154 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Application Architecture Domain WG The Application Architecture Domain Working Group (AADWG) provides leadership in the review of the application architecture components of the OPS EA. It also champions the development of application architecture skills. Definition of Application Architecture Domain Mandate Membership Governance Enterprise Application Architecture provides a means to maintain adaptive and technologically sound application development and deployment environments, drives the introduction of new technologies, and focuses on rapid and standards-based implementation. It achieves this through a logically consistent set of principles, standards and architectural models. These models are derived from the business requirements. The AADWG is primarily concerned with Column 2 of the Zachman Framework, recognizing the shared responsibilities with and the appropriate handoffs to the other domain working groups. As a working subcommittee of the Corporate Architecture Core Team (ACT), the mandate of the AADWG is to support the corporate ACT and Architecture Review Board (ARB) by: acting as a consulting body to the OPS in regards to application architecture; recommending standards, such as naming conventions, deployment methods etc.; serving as a forum where experiences and information can be shared amongst Cluster representatives; and investigating, researching and prototyping application architecture techniques, trends and technologies. (The results of the research will ensure the alignment of architecture and I&IT strategy.) The Federated Frameworks Model will be used for all architectural models. The results will be shared with the other clusters/ministries in order to re-use the results of the research for common requirements, thus leveraging and supplying common solutions. The AADWG is comprised of the following representatives: Domain architecture lead/chair (one year, rotating across membership) Participation from all clusters Participants may vary depending on the specific research that is being conducted. The Domain architecture lead is that of a one-year term. The AADWG takes direction from ACT and is accountable for the activities it undertakes, to ACT EAPM Version 3.0

155 Technology Architecture Domain WG Technology Architecture Domain WG The Technology Architecture Domain Working Group (TADWG) provides leadership in the review of the Technology architecture components of the OPS EA. It also champions the development of technology architecture skills. Definition of Technology Architecture Domain Mandate Scope of Responsibility The Technology Architecture Domain encompasses all technology infrastructure matters pertaining to the OPS EA. The SADWG is primarily concerned with Column 3 of the Zachman Framework, recognizing the shared responsibilities with and the appropriate handoffs to the other domain working groups. As a working subcommittee of the Corporate Architecture Core Team (ACT), the mandate of the TADWG is to support the corporate ACT and Architecture Review Board (ARB) by: researching and recommending principles, standards, guidelines and best practices for technology architecture; reviewing and validating the technology architecture of corporate and cluster initiatives that come before the corporate ACT, and ensuring the alignment of those initiatives to OPS principles and standards; providing advice on matters of technology architecture as requested by ACT; researching and reporting on emerging trends in information technology; and promoting a common technology architecture culture. The TADWG works under the direction of the Corporate ACT, and provides direction and guidance on matters of technology architecture to corporate initiatives, and to cluster initiatives on request. Membership Technology architects and analysts from the Clusters; Representatives from technical infrastructure within the Corporate Architecture Branch; Representatives from iserv Ontario, particularly from its Solutions organization One member of the group is selected by the group to act as Chair for a period of one year. Governance The TADWG takes direction from ACT and is accountable for the activities it undertakes, to ACT. June 3,

156 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance Security Architecture Domain WG The Security Architecture Domain Working Group (SADWG) provides leadership in the review of the security architecture components of the OPS EA. It also champions the development of security architecture skills. Definition of Security Architecture Domain Mandate Scope of Responsibility The Security Architecture Domain encompasses all security matters pertaining to the OPS EA. The SADWG is concerned with all cells of the Zachman Framework, recognizing the shared responsibilities with and the appropriate handoffs to the other domain working groups. As a working subcommittee of the Corporate Architecture Core Team (ACT), the mandate of the SADWG is to support the corporate ACT and Architecture Review Board (ARB) by: researching and recommending principles, standards, guidelines and best practices for security architecture; reviewing and validating the security architecture of corporate and cluster initiatives that come before the corporate ACT, and ensuring the alignment of those initiatives to OPS principles and standards; providing advice on matters of security architecture as requested by ACT; researching and reporting on emerging trends in security; and promoting a common security architecture culture. The SADWG works under the direction of the Corporate ACT, and provides direction and guidance on matters of security architecture to corporate initiatives, and to cluster initiatives on request. In particular, the SADWG focuses on: Security Architecture Privacy Architecture (where it crosses over with Security Architecture) The SADWG will work as necessary with the Cluster Security Officers and with other Domain Working Groups on matters of joint interest and scope EAPM Version 3.0

157 Security Architecture Domain WG Membership Governance Membership consists of one representative from each Cluster, one representative from Corporate Security Branch (iserv), and one representative from the MBS Corporate Architecture Branch. All representatives are security architects or are performing that role within their own organizations. One member of the group is selected by the group to act as Chair for a period of one year. The SADWG takes direction from ACT and is accountable for the activities it undertakes, to ACT. June 3,

158 Chapter 2: Introduction to OPS EA Program Corporate Architecture Governance EA Methodology WG The EA Methodology Working Group (EAMWG) provides leadership in EA processes, methodology, standards and tools. Definition of EA Methodology Mandate Scope of Responsibility Membership Governance EA methodology is a body of procedures, techniques, tools and documentation aids that aid in the design of enterprises. The EAMWG is concerned with all cells of the Zachman Framework, recognizing the shared responsibilities with the other domain working groups. As a working subcommittee of the Corporate Architecture Core Team (ACT), the mandate of the EAMWG is to support and advance the EA methodology capabilities of the OPS by: evaluating and selecting or customizing government standard methods and disciplines for architecture; evaluating and selecting or customizing government standard tools for architecture; conducting assessments of enterprise architecture methods, disciplines and tools across architectural domains; facilitating the identification and resolution of enterprise architecture issues that span domains; and sharing individual skills and experiences. The scope of the EAMWG is the architecture processes, methodology and related standards and tools. It also works with other domain teams to facilitate integration across the domains. The EAMWG is an inter-cluster working group. The chair is the corporate Methodology Specialist. Membership principally consists of senior architecture and methodology representatives from Corporate Architecture Branch and from the Clusters. The EAMWG takes direction from ACT and is accountable for the activities it undertakes, to ACT EAPM Version 3.0

159 EA Methodology WG 2.5 Cluster Architecture Governance This section presents the following topic areas: Cluster Governance Bodies Cluster Architecture Review Board (ARB) A number of organizations and positions participate in the governance of the OPS EA Program at the cluster level. Each subject in this section describes one of these parties and identifies its scope and mandate, its objectives, architectural role, membership, and operating procedures. The Cluster Architecture Review Board (ARB) is a decision-making body that can be constituted by a cluster to provide leadership for the architecture function within the cluster. It is equivalent to the corporate-level ARB Cluster The Cluster Architecture Core Team (ACT) is an advisory body that can be Architecture constituted by a cluster to provide a forum for validating EA against business Core Team priorities and directions of the core businesses of the cluster. It is equivalent to (ACT) the corporate-level ACT Roles and Position Descriptions A number of business and technical positions are involved in the creation and approval of the artifacts in the various services frameworks produced by OPS organizations. June 3,

160 Chapter 2: Introduction to OPS EA Program Cluster Architecture Governance Cluster Governance Bodies A number of organizations and positions participate in the governance of the OPS EA Program at the cluster level. Each subject in this section describes one of these parties and identifies its scope and mandate, its objectives, architectural role, membership, and operating procedures. Reporting relationships Figure 2-3 illustrates the reporting relationships of some of the major organizations that may be involved in architectural governance at the cluster level. (Clusters are at different stages in the implementation of the architectural function and its governance). Figure 2-3: Cluster architectural governance bodies Review of cluster I&IT projects Cluster I&IT projects may be reviewed by the:. Cluster ACT and ARB for compliance with architectural policies and standards ITSC for compliance with general IT standards EAPM Version 3.0

161 EA Methodology WG Corporate and project relationships Cluster I&IT projects may be referred by the cluster ARB or ACT (or equivalent) to their corporate counterparts for review. This could happen, for example, when:. The designs and components of the cluster I&IT project are noncompliant with corporate architectural policies and standards The cluster I&IT project is producing innovative designs or components that may have architectural significance beyond the cluster. Figure 2-4 illustrates how key cluster governance bodies relate to other governance parties at the corporate and project level. Figure 2-4: Corporate & project relationships to cluster architectural governance bodies June 3,

162 Chapter 2: Introduction to OPS EA Program Cluster Architecture Governance Cluster Architecture Review Board (ARB) The Cluster Architecture Review Board (ARB) is a decision-making body that can be constituted by a cluster to provide leadership for the OPS EA Program within the cluster. It is equivalent to the corporatelevel ARB. Scope Mandate Objectives The Cluster ARB provides overall architecture direction for the cluster by: Ensuring the alignment and integration of cluster initiatives with cluster goals and business strategies Ensuring compliance of cluster initiatives with quality, best practices and standards in enterprise architecture Promoting reusable architecture components for systems design and construction Approving major changes to cluster-level architectural elements. The Cluster ARB mandate may include the following components: Ensure alignment of cluster-based architectures with the OPS EA and its component architectural frameworks Monitor the compliance of cluster-level architectures with OPS-defined goals and measures Ensure that projects affecting or leveraging common services and infrastructure are in alignment with the cluster architecture Act as the approval body for deliverables from the Cluster Architecture Core Team (or equivalent) and resolve any issues referred to it by the Cluster ACT Act as a liaison with the Corporate ARB. Refer to the Joint Executive Management Committee (EMC) or Senior Management Committee (SMC) all matters that require approval. The objectives of the Cluster ARB are to: Provide leadership for the development of cluster-level architectural components Ensure that refinements to cluster-level components of EA support planned directions of the ministry programs supported by the cluster Ensure that the use of architectural services is relevant and practical and that it provides continuous business value Determine which new I&IT trends should be examined to meet the requirements of the programs supported by the cluster Ensure compliance of project architectures with the OPS EA Communicate ARB decisions to the core businesses supported by the cluster EAPM Version 3.0

163 Cluster Architecture Review Board (ARB) Membership The Cluster ARB may include the following members: Chair of the Information and Information Technology Subcommittee Assistant Deputy Ministers or Directors from each division Cluster Chief Information Officer (CIO) Lead Architect or Senior Manager, Planning & Architecture, (or equivalent) for the cluster Head Architect, Management Board Secretariat Other cluster representatives as required. The Cluster ARB may be chaired by the Chair of the I&IT Subcommittee or the Cluster CIO. Architectural role Table 2-64 summarizes the architectural role of the Cluster ARB with respect to the eight services of the architecture function. [Note: If this table is retained, it must be changed to reflect the 12 services of the OPS EA Program.] Table 2-64: Architectural roles of the Cluster ARB Service Client Provider Partner Regulator Other Stakeholder Architectural Policies & Standards EA Development QS*, IS* QS* Change Initiative Architecture Development Architecture Education Architect Certification QS Tools & Methods Architecture Review Repository QS*, IS* QS Architectural Consulting Reference Model Architecture Project Planning * Cluster-level components or initiatives PR Setting priorities and allocating resources QS = Quality assurance and standards BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies in support og government & cluster business initiatives June 3,

164 Chapter 2: Introduction to OPS EA Program Cluster Architecture Governance Operating procedures The following operating procedures are suggested for the operation of a Cluster ARB: The Cluster ARB (or equivalent) will meet monthly or as required. For example, a Cluster ARB session could be the last agenda item of a monthly meeting of the I&IT Subcommittee for a cluster. If a member is unable to attend a meeting, the nomination of a substitute will require the approval of the Chair in advance. The Cluster ARB will periodically review activity reports from the Cluster ACT EAPM Version 3.0

165 Cluster Architecture Core Team (ACT) Cluster Architecture Core Team (ACT) The Cluster Architecture Core Team (ACT) is an advisory body that can be constituted by a cluster to provide a forum for validating EA against business priorities and directions of the ministry programs supported by the cluster. It is equivalent to the corporate-level ACT. Scope The Cluster ACT fulfills OPS EA Program responsibilities at the cluster level by: Creating and maintaining authoritative architecture artifacts (descriptions) at the cluster level Guiding the work of the domain and project architecture teams, Providing a forum for the resolution of architectural issues Reviewing projects for architectural compliance Making appropriate recommendations to the Cluster ARB for final approval. ACT provides advice to the Cluster ARB and the Cluster Head Architect concerning Enterprise Information Architecture including: All major changes to enterprise architecture at the cluster level Business architecture, privacy and security, information architecture, application architecture and technology architecture The effectiveness of the architecture functions in delivering the expected benefits and opportunities for improvements Emerging business directions that should guide architectural directions. Mandate The Cluster ACT mandate may include the following components: Review proposed changes to the cluster-level enterprise architecture for expected impacts on current and planned business activities Provide input to the plans of the Lead Architect concerning orientation, training and promotion of architecture in the cluster Advise the Head Architect, Management Board Secretariat, of emerging business initiatives and priorities Lead all architectural processes where the cluster has responsibility Represent the interests of the cluster for all architectural processes where the corporate level (MBS) has responsibility Implement enterprise architectural governance at the cluster level, including the effective initiation, operation and maintenance of cluster level architectural services. June 3,

166 Chapter 2: Introduction to OPS EA Program Cluster Architecture Governance Objectives The objectives of the Cluster ACT may include: Assure the quality of architectural components developed in cluster initiatives Implement, lead and support appropriate domain architecture working groups Collaborate with the standards setting and governance process of the Information Technology Standards Committee through the cluster s representative on the committee Work as a team with domain and ministry architecture functions, setting clear roles to ensure architectural value to ministry programs supported by the cluster Conduct efficient, pertinent and timely project reviews and make appropriate recommendations Help set skill requirements for the development and evolution of the enterprise architecture Provide a forum where business experts can ensure that the work of the cluster architects: Support the direction of ministry programs supported by the cluster Achieves the expected benefits of EA Provide a body of business experts who are sufficiently familiar with architectural issues to identify impacts and provide guidance Enable identification of common business and technology issues and opportunities and provide strategies for addressing unique business and technology requirements effectively Strengthen communication between line divisions and IT planners and designers through the participation of business staff who are recognized by their home divisions as having this liaison role. Membership The Cluster ACT may include the following members Head Architect for the Cluster (Chair) Business representative from each Division The following positions may be members of, or play supporting roles for, the ACT: Cluster architects (business, information, application, technology and security domains) Business analysts I&IT projects representatives EAPM Version 3.0

167 Cluster Architecture Core Team (ACT) Architectural role Table 2-65 summarizes the architectural role of the Cluster ACT with respect to the eight services of the architecture function. [Note: If this table is retained, it must be changed to reflect the 12 services of the OPS EA Program.] Table 2-65: Architectural role of the Cluster ACT Service Client Provider Partner Regulator Other Stakeholder Architectural Policies & Standards QS* EA Development QS Change Initiative Architecture Development Architecture Education Architect Certification Tools & Methods QS Architecture Review QS* Repository QS* Architectural Consulting Reference Model Architecture Project Planning * Cluster-level components or initiatives PR Setting priorities and allocating resources QS = Quality assurance and standards BS = Alignment with corporate business strategies IS = Alignment with corporate I&IT strategies in support og government & cluster business initiatives Operating procedures The following procedures are suggested for the operation of a cluster ACT: The ACT will meet monthly or as required If a member is unable to attend a meeting, an alternate may attend (a regular alternate is preferred) ACT will report to the ARB on its activities on a periodic basis Line division management committees will receive a report from their representatives following each ACT meeting. June 3,

168 Chapter 2: Introduction to OPS EA Program Artifact Creation and Approval Roles 2.6 Artifact Creation and Approval Roles [Note: This section has been left unchanged for Version 3.0 pending experience with new and changed roles stemming from the planned acquisition of EA modeling tools and repository. This section will be updated in late 2005 or early 2006 and included in the HR section.] This section presents the following topic areas: Scope Artifact Roles (Row 1) Conceptual Model Artifact Roles (Row 2) Logical Model Artifact Roles (Row 3) Physical Model Artifact Roles (Row 4) Component Artifact Model Roles (Row 5) A number of business and technical positions are involved in the creation and approval of artifacts in row 1 of the services framework of the enterprise information architecture. These artifacts define the context and scope of a given framework. A number of business and technical positions are involved in the creation and approval of artifacts in row 2 of the services framework of the enterprise information architecture. These artifacts define the conceptual business model required to deliver the services in defined by a given framework. A number of business and technical positions are involved in the creation and approval of artifacts in row 3 of the services framework of the enterprise information architecture. These artifacts define the logical systems model required to automate elements of the management and delivery the services in defined by a given framework. Row 4 artifacts describe the physical designs of the components of the enterprise. Definitions for these artifacts are notional as of the publication of Version 1 of the EAPM Handbook. A number of technical positions are involved in the creation and approval of artifacts in row 5 of the services framework of the enterprise information architecture. These artifacts constitute the most detailed representation required to build or transform the functioning enterprise EAPM Version 3.0

169 Cluster Architecture Core Team (ACT) Scope Artifact Roles (Row 1) A number of business and technical positions are involved in the creation and approval of artifacts in row 1 of the services framework of the enterprise information architecture. These artifacts define the context and scope of a given framework. Table 2-66 lists the artifacts of Row 1 of the Patterns, Template and Reusable Components library and indicates the role played by a given position in artifact creation and approval. Table 2-66: Row 1 artifact creation roles Cell Service Frameworks Artifacts Program Manager Policy Analy s t / Program Executive Management Business Analyst Business Architect Technica l w riter 1,1 Resource Type A I I L 1,2 Core Business I L A I I Program I L A I I Service I L A I I Program Service Cross-Reference I L A I I 1,3 Location Type A I I L Geographical Area Type A I I L Service/Location Type Cross-Reference A I I L Location Type/Geographic -Area Type Cross Reference 1,4 Party Type A I I L Role Type Target Group Type Service By Role Type Cross-Reference A L I I 1,5 Event Type A L I I Cycle Type I L A I I Service-by Event Type and Cycle Type Cross Reference A L I I 1,6 Goal L I A I I Need Type L I A I I Mandate Type L I A I I L Lead, I Involved, A Approves June 3,

170 Chapter 2: Introduction to OPS EA Program Artifact Creation and Approval Roles Conceptual Model Artifact Roles (Row 2) A number of business and technical positions are involved in the creation and approval of artifacts in row 2 of the services framework of the enterprise information architecture. These artifacts define the conceptual business model required to deliver the services in defined by a given framework. Table 2-67 lists the artifacts of Row 2 of the services framework and indicates the role played by a given position in artifact creation and approval. Table 2-67: Row 2 artifact creation roles Cell Service Frameworks Artifacts Project Manager Policy Analyst / Program Specialist Executive Management Business Analyst Business Architect Applications architect Information architect 2,1 Conceptual Data Model I I I A L 2,2 Semantic Model Service Model Value Chain Process Service Life Cycle A I L I I Business Function Model A I L I I 2,3 Business Network Model A I L I I 2,4 Workflow Model A I L I I 2,5 State Transition Model Business Scenarios 2,6 Service Objectives L I A I I Performance Matrix L I A I I L Lead, I Involved, A Approves EAPM Version 3.0

171 Logical Model Artifact Roles (Row 3) Logical Model Artifact Roles (Row 3) A number of business and technical positions are involved in the creation and approval of artifacts in row 3 of the services framework of the enterprise information architecture. These artifacts define the logical systems model required to automate elements of the management and delivery of the services as defined by a given framework. Table 2-68 lists the artifacts of Row 3 of the services framework and indicates the role played by a given position in artifact creation and approval. Table 2-68: Row 3 artifact creation roles Cell Service Frameworks Artifacts Program Ma n ag er Policy Analys t / Program Sp e c ialist Executive Management ss Ana yst Busine l hitect Business Arc ations a rc hitect Applic chitect Technology ar chitect Information ar ecialist Security Sp / Project Manager Leader 3,1 Business View LDM Design View LDM Analysis Class Model Design Class Model I I I L, A I 3,2 Functional Requirements Logical Application - Architecture Application I I I L, A I I Logical Application Workflow Step X-Ref L, A I Application Component Patterns L, A I I I Logical Application Application Building Block Cross Reference Logical Classes and Interactions Use Case Realization L, A I I I 3,3 Infrastructure Component Placement Diagram A I I I L I I A Infrastructure Pattern Match I I I L I I A Logical Application Deployment Model I I I L I I A June 3,

172 Chapter 2: Introduction to OPS EA Program Artifact Creation and Approval Roles 3,4 Functional Group Application Component Cross Reference A I L I I Detailed Workflow Specification A I L I I I 3,5 Logical Operating Schedule A I L I I 3,6 L Lead, I Involved, A Approves EAPM Version 3.0

173 Physical Model Artifact Roles (Row 4) Physical Model Artifact Roles (Row 4) Row 4 artifacts describe the physical designs of the components of the enterprise. Definitions for these artifacts are notional as of the publication of Version 1 of the EAPM Handbook. Table 2-69 lists the artifacts of row 4 of the services framework and indicates the role played by a given position in artifact creation and approval.. Table 2-69: Table 2-70: Row 4 artifact creation roles Cell Service Frameworks Artifacts Program Manager Database Analyst DBA Administrator Executive Management Business Analyst Business Architect Applications architect System Analyst Information architect Security Specialist Project Manager/ Leader 4,1 Physical Data Model L,A I I I I Database Design Model L I Database Inventory 4,2 Application Design Model L,A I I Application Inventory I I L,A Physical Design Constraints I L,A I,A I 4,3 Physical Deployment Model 4,4 User Interface Design A L I I 4,5 4,6 N/A Calenderized Schedule and States L Lead, I Involved, A Approves L I I,A I June 3,

174 Chapter 2: Introduction to OPS EA Program Artifact Creation and Approval Roles Component Artifact Model Roles (Row 5) A number of technical positions are involved in the creation and approval of artifacts in row 5 of the services framework of the enterprise information architecture. These artifacts constitute the most detailed representation required to build or transform the functioning enterprise. Table 2-70 lists the artifacts of row 5 of the services framework and indicates the role played by a given position in artifact creation and approval Table 2-70: Row 5 artifact creation roles Cell Service Frameworks Artifacts Project Manager/Leader Database Administrator Applications Architect Programmer/Analyst Information Architect Program Manager Policy Analyst or Program Specialist Executive Management Business Architect Security Specialist System Analyst Business Analyst 5,1 DDL Script L A 5,2 Trigger Code L I A Stored Procedure Code I A L I L Lead, I Involved, A Approves EAPM Version 3.0

175 Chapter 3: Architecture Roles, Responsibilities and Skills

176 3.1. Architecture Roles, Responsibilities and Skills Provides guidelines for developing the knowledge and skills required of staff assigned to EA roles. Synopsis This section describes in generic terms, applicable to all clusters and projects, the typical job descriptions, duties and skill requirements for staff working in architecture roles at the corporate, cluster and project levels. The following roles are described in detail in the following sub-sections: 3.1.1: Enterprise Architect 3.1.2: Business Architect 3.1.3: Information Architect 3.1.4: Application Architect 3.1.5: Technology Architect 3.1.6: Security Architect 3.1.7: EA Methodologist 3.1.8: EA Repository Librarian Each role is described in terms of purpose, major responsibilities (for both entry and senior levels where appropriate), judgement requirements, contact requirements, and competency requirements. Competency requirements are described in three categories: Business, Technical and Behavioural. The four point scale used in the tables of competencies for each role is defined as follows Skill Level 1: Basic Understanding Skill Level 2: Working Experience Skill Level 3: Extensive Experience Skill Level 4: Subject Matter Depth and Breadth 3-2 EAPM Version 3.0

177 Enterprise Architect Enterprise Architect Describes the role of Enterprise Architect. Purpose of Role To establish and maintain enterprise architecture, current and target, for defined enterprises within assigned spheres of responsibility. To assist in high-level planning for initiatives needed to enable target enterprise architecture. Major Responsibilities General knowledge is same for senior enterprise architect and enterprise architect (difference in skill-level/experience). Senior Enterprise Architect Analyzes business plans to aid in defining enterprises and to assess transformation requirements. Analyzes the trends in the delivery of government services in general to detect critical deficiencies in OPS programs. Monitors advancements in information technology and assesses potential impacts upon government services and processes. Leads architecture teams to establish target architectures for the enterprises within an assigned sphere of responsibility. Designs and participates in the governance activities associated with ensuring compliance with enterprise architecture. Consults with project managers to ensure implemented I&IT solutions contribute to increasingly integrated government service and I&IT environments. Enterprise Architect Assists in the analysis of business plans to aid in defining enterprises and to assess transformation requirements. Assists in the analysis of trends in the delivery of government services in general to detect critical deficiencies in OPS programs. Carries out research in advancements in information technology and suggests potential impacts upon government services and processes. Participates as a member of architecture teams to establish target architectures for the enterprises within an assigned sphere of responsibility. Participates in the governance activities associated with ensuring compliance with enterprise architecture. Assists system design teams on projects to ensure system designs conform with the approved target architecture for the sponsoring enterprise/program and with GO IT standards. June 3,

178 Judgement The Enterprise Architect works within an Architect Unit s mandate, within current and accepted systems development standards, and in accordance with OPS policies and directives. The Enterprise Architect exercises considerable latitude for judgement and decision-making in: Contacts assessing business needs; determining the breadth and depth of factors to be considered; identifying and evaluating enterprise architecture problems and issues; anticipating and addressing client concerns; deciding on tools, techniques and methods to use in enterprise architecture development; developing viable solutions and courses of action which achieve an Architect Unit s mandate, goals and objectives; recommending and implementing enterprise architecture models; managing and coordinating enterprise architecture implementation activities; assessing enterprise architecture implementation progress; providing credible and timely authoritative expertise and advice to client ministry management; working effectively with client officials whose interests and priorities may conflict with those of the Architect Unit; maintaining current knowledge of client business needs, client corporate culture and relevant IT technology; and undertaking policy review and development activities pertaining to enterprise architecture. Frequent contact with client program managers to solicit input, exchange information; enhance the flow of ideas; maintain on-going liaison; provide expertise, analysis and recommendations; discuss issues of mutual concern, and resolve problems. Regular contact with senior Ministry and client Ministry officials to provide briefings and updates and to provide expertise, advice and recommendations with regard to emerging issues and concerns. Regular and ongoing contact with the Architect Unit and other Ministry peers to coordinate operational activities and discuss issues of mutual concern. Regular contact with peers in other jurisdictions and external stakeholder organizations to discuss issues of common interest and concern; identify best practices; learn from experiences; share information; coordinate joint initiatives and resolve problems. 3-4 EAPM Version 3.0

179 Enterprise Architect Regular contact with IT industry professionals to maintain up-to-date knowledge of emerging trends/issues and current technology/software. Competencies [Note: The competencies will need to be profiled in the same way that the domain architect positions have been.] June 3,

180 3.1.2 Business Architect Describes the role of Business Architect. Purpose of Role To plan, manage and coordinate the effective translation of client business requirements into systems models through analysis information pertinent to business architecture and stakeholder consultation. To develop and revise business architecture artifacts of Enterprise Information and Information Technology (EIA) and ensure that these are vertically integrated. To provide advice to client business on key business strategies and their impact on business functions and processes. Major Responsibilities General knowledge is same for senior business architect and business architect (difference in skill-level/experience). Senior Business Architect Lead the development/establishment of principles, policies and standards for enterprise business architecture program. Develop business architecture concepts, tools and methods to be used across the OPS. Participate in governance of OPS Enterprise Architecture program by providing QA and professional advice to ensure business architecture is aligned with the EAPM Handbook. Provide leadership in championing and promoting awareness of appropriate business architecture concepts, methods, tools and best practices. Develop and maintain reusable business architecture. Develop and sustain an effective network of credible and authoritative contacts by participating on intra- and inter-ministerial committees (BADWG, Tools group, joint DWGs) Provide senior applied level business architecture advice and support/ facilitation to business and I&IT program and project managers. Develop and deliver business architecture models and methodology for clients. Plan, co-ordinate and manage the effective translation of client business requirements into systems models and system requirements. Lead and contribute to the design, development and delivery of business architecture training and curriculum. Manage the process of contract management and procurement services. Ensure the quality of business architecture work done by consultants on behalf of clients. 3-6 EAPM Version 3.0

181 Business Architect Business Architect Participate in the development/establishment of principles, policies and standards for enterprise business architecture program. Participate in development of concepts, tools and methods to be used across the OPS. Support leadership team in championing and promoting awareness of appropriate business architecture concepts, methods, tools and best practices. Develop and maintain reusable business architecture. Provide applied level business architecture advice and support/ facilitation to business and IT program and project managers. Develop and deliver business architecture models and methodology for clients. Plan, co-ordinate and manage the effective translation of client business requirements into systems models and system requirements. Contribute to the design, development and delivery of business architecture training and curriculum. Participate in the process of contract management and procurement services. Review the quality of business architecture work done by on behalf of clients. Judgement The Business Architect works within an Architect Unit s mandate, within current and accepted systems development standards, and in accordance with OPS policies and directives. The Business Architect exercises considerable latitude for judgement and decision-making in: assessing business application needs; determining the breadth and depth of factors to be considered; identifying and evaluating business architecture problems and issues; anticipating and addressing client concerns; deciding on tools, techniques and methods to use in application development; developing viable solutions and courses of action which achieve an Architect Unit s mandate, goals and objectives; recommending and implementing systems models; managing and coordinating application implementation activities; assessing project progress; providing credible and timely authoritative expertise and advice to client ministry management; working effectively with client officials whose interests and priorities may conflict with those of the Architect Unit; June 3,

182 Contacts maintaining current knowledge of client business needs, client corporate culture and relevant IT technology; and undertaking policy review and development activities pertaining to business architecture. Frequent contact with client program managers to solicit input, exchange information; enhance the flow of ideas; maintain on-going liaison; provide expertise, analysis and recommendations; discuss issues of mutual concern, and resolve problems. Regular contact with senior Ministry and client Ministry officials to provide briefings and updates and to provide expertise, advice and recommendations with regard to emerging issues and concerns. Regular and ongoing contact with the Architect Unit and other Ministry peers to coordinate operational activities and discuss issues of mutual concern. Regular contact with peers in other jurisdictions and external stakeholder organizations to discuss issues of common interest and concern; identify best practices; learn from experiences; share information; coordinate joint initiatives and resolve problems. Regular contact with IT industry professionals to maintain up-to-date knowledge of emerging trends/issues and current technology/software. Competencies The following competencies are required for the Business Architect Role: Table 3-1: Business Architecture Role competency requirements Business Technical Behavioural Competency Proficiency Level Competency Proficiency Level Competency Proficiency Level Sr. Arch Arch Sr. Arch Arch Sr. Arch Arch Service 3 3 Enterprise 3 2 Commitment to 3 3 Excellence Architecture Organizational Learning Knowledge Management 3 2 Business Architecture 4 3 Impact and Influence Business Process 3 2 Business 2 2 Initiative 2 Design Architecture Effectiveness Measurement Knowledge of 4 2 Enterprise 4 2 Innovation 5 Organization Business Architecture Process and Methods Organizational 4 3 System 3 2 Networking 4 Savvy and Development Politics Life Cycle for Business Architecture EAPM Version 3.0

183 Business Architect Business 3 2 Product and 3 2 Planning, 4 2 Functions Vendor Organizing and Evaluation Coordination E-Business 2 1 Project 3 2 Problem Solving 4 3 Management ERP (Enterprise 1 1 Strategic 4 3 Resource Thinking Planning) Written Communications 4 3 June 3,

184 3.1.3 Information Architect Describes the role of Information Architect. Purpose of Role To analyze, define, develop and implement the information architecture for application development, including determining the flow and distribution of data, the integration of databases and data access methods. To ensure the provision of timely and authoritative advice and support to OPS client ministries and organizations in the use and management of integrated information and information architecture. To develop and revise information architecture artifacts related to EA and ensure that these are vertically integrated. Major Responsibilities General knowledge is same for senior information architect and business architect (difference in skill-level/experience). Senior Information Architect Information Architect Provides strategic information architecture direction in projects and enterprise architecture; consults with senior management and advises on information architecture solutions, trends, directions, and strategies; develop synergies across programs and the enterprise. Reviews and ensures alignment of cluster with corporate information architecture, including models, best practices, standards, directions, strategies and key industry trends. Leads development/adaptation of information architecture methodologies, standards and best practices, and lead the selection of tools. Leads the development of enterprise information models and the addition or revision of information architecture artifacts. Promotes information architecture in the OPS. Promotes best practices for information management. Manages the process of designing, developing and implementing information architecture. Liaises and participates in the governance of the OPS Enterprise Architecture program. Ensures information architecture alignment with business and collaborate with other architecture domains. Supports projects by reviewing deliverables and ensuring alignment with cluster and corporate information architecture, including models, best practices, standards, directions and strategies. Develops project and enterprise information models and recommend the addition or revision of information architecture artifacts. Promotes best practices for information management and information architecture in the OPS EAPM Version 3.0

185 Information Architect Participates in the development/adaptation of information architecture methodologies, standards, best practices and the selection of tools. Participates in strategizing on project and enterprise information architecture; develop synergies across programs and enterprise. Ensures alignment with business and collaborate with other architecture domains. Judgement The Information Architect works within an Architect Unit s mandate, and related or project directives, policies and standards; statutory requirements, OPS administrative policies, procedures, directives; and accepted systems development practices. The Information Architect works on assigned projects and may lead them as required. Judgement is exercised in: identifying and assessing information architecture problems and issues; determining appropriate tools and methods for data modeling and systems analysis and design; devising project parameters, designing, developing, implementing and assessing applications; providing credible and timely advice to client ministry management; undertaking related policy review and development activities; staying current with related I&IT technology and systems, tools, data modeling methods and other assessment and application mechanisms; and maintaining good working knowledge of client business needs and client corporate environments, and information management legislative obligations. Contacts Ongoing contact with client program managers to share information, provide authoritative guidance on information architecture and related requirements, develop recommendations, identify concerns and resolve problems. Regular contact with peers in other jurisdictions to share information, identify needs, learn from experiences, identify best practices, co-ordinate joint projects, and resolve problems. Regular contact with IT industry professionals to stay current with developments and trends, and obtain specific information pertinent to current data architecture projects. June 3,

186 Competencies The following competencies are required for the Information Architect Role: Table 3-2: Information Architect Role competency requirements Business Technical Behavioural Competency Proficiency Level Competency Proficiency Level Competency Proficiency Level Sr. Arch Arch Sr. Arch Arch Sr. Arch Arch Service 3 2 Information 4 2 Problem 4 3 Excellence Management Solving Knowledge of Organization 3 2 IT Architecture 3 2 Business 3 2 IT Standards, 4 3 Commitment to 3 2 Functions Procedures, Organizational Learning Industry Knowledge Knowledge Management Business Case Justification Organizational Savvy Policies 4 2 Modeling: Data, Process, Events, Objects 2 1 Data Administration 2 1 IT Project Management 3 2 Database Structures Database 3 2 Warehousing IT Industry: 2 N/A Trends & Directions Emerging 2 N/A Technologies Relational N/A 2 Databases CASE Tools N/A Networking Concern for Quality and Standards 2 1 Strategic Thinking EAPM Version 3.0

187 Application Architect Application Architect Describes the role of Application Architect. Purpose of Role Major Responsibilities Senior Application Architect Application Architect To assess, define and recommend on the structure and relationship between suites of applications, including the identification of re-usable components, the organization and layering of software and the determination of interfaces. To implement architectures to be used for a range of applications. To ensure the provision of timely and authoritative advice and support to OPS client ministries and organizations. Leads the assessment, design and development of application architecture. Ensures application architecture alignment with business objectives, requirements, and collaborates and ensures alignment with other architecture domains. Provides strategic application architecture direction in projects and enterprise architecture; consults and advises senior management and clients on application architecture solutions, trends, directions, and strategies. Manages the process of establishing application architecture for clients (for example, but not limited to: the structure and relationship between suites of applications, including the identification and assessment of reusable components, the organization and layering of software and the determination of interfaces). Develops and promotes best practices for application architecture in the organization. Develops and implements a strategy for the use of application architecture activities (e.g. common components/services, standards-setting processes, service-oriented architecture). Supports projects by developing and reviewing architecture and design deliverables and by ensuring alignment with cluster and corporate application architecture, including best practices, standards, directions and strategies. In collaboration with project team, provides interpretation of application architecture methodologies, standards, and best practices to be applied in the context of a project. Promotes best practices for application architecture in the organization. Provides advice and guidance to clients in their application development to ensure adherence to application architecture standards. June 3,

188 Participates in the refinement of application architecture standards. Contributes to the development of a business case analysis for a new technology; participates in the evaluation, selection, and piloting of new technologies. Judgement The Application Architect works within an Architect Unit s mandate and related directives, policies and standards; statutory requirements (e.g. FIPPA), OPS administrative policies, procedures, directives; and accepted systems development practices. The Application Architect on assigned projects and may lead them as required. Judgment is exercised in: Contacts identifying and assessing application architecture problems and issues, including identification and assessment of re-usable components, the organization and layering of software and the determination of interfaces; determining appropriate tools and methods for systems analysis and design; devising project parameters, designing, developing, implementing and assessing applications and their linkages; providing credible and timely advice to client managers and Ministry senior management; undertaking related policy review and development activities; staying current with related I&IT technology and systems, tools, modeling methods and other assessment and application mechanisms; and maintaining good working knowledge of different ministry and corporate business environments, and information management legislative obligations. Ongoing contact with peers in unit, Architect community, planners and managers in client ministries to share information, provide authoritative guidance on application architecture, related issues and requirements and develop recommendations, identify concerns and resolve problems. Regular contact with peers in other jurisdictions to share information, identify needs, learn from experiences, identify best practices, co-ordinate joint projects, and resolve problems. Frequent contact with I&IT industry to stay current with developments and trends, and obtain specific information pertinent to current projects EAPM Version 3.0

189 Application Architect Competencies The following competencies are required for the Application Architect Role: Table 3-3: Application Architecture Role competency requirements Business Technical Behavioural Competency Proficiency Level Competency Proficiency Level Competency Proficiency Level Sr. Arch Arch Sr. Arch Arch Sr. Arch Arch Core Application 4 3 Enterprise 3 3 Problem 4 3 Systems Architecture Solving Business 1 1 IT Standards, 4 3 Commitment to 3 2 Functions Policies, Organizational Procedures Learning Service Excellence Knowledge of Organization Organizational Savvy and Politics Planning: Tactical and Strategic 2 3 Application Architecture, Design 4 3 Innovation (Impact of) 4 3 Networking 3 2 Emerging Technologies 4 2 IT Environment 4 3 Strategic 3 3 Thinking 4 n/a Application Delivery Process System Development Life Cycle Application Development Tools Systems Software Infrastructure 2 2 Planning, Organizing, and Coordinating 3 3 Written Communicatio n June 3,

190 3.1.5 Technology Architect Describes the role of Technology Architect. Purpose of Role To assess, develop, recommend and implement the technology* to be used for a range of applications. To ensure the provision of timely and authoritative advice and support to OPS client ministries and organizations. * Where the term technology encompasses technology framework, patterns and models, technical architecture, and broad knowledge of technology lifecycle considerations. Major Responsibilities Senior Technology Architect Promotes best practices for technology architecture in the OPS in order to demonstrate to business how I&IT can help them leverage the transformation agenda and their business agenda. Collaborates with other architecture domains and I&IT stakeholders in cluster and corporate organizations to achieve a common and consistent architecture vision to meet organization needs. Leads the research, assessment, design, development and integration of technology architecture and standards in order to capitalize on technology to provide optimal solutions throughout the organization. Monitors the technology environment, business needs, and evolving technologies and trends in order to provide strategic advice to senior management on technology architecture changes and solutions (e.g., technology procurement). Contributes to the development of the cluster I&IT strategic plans regarding recommended technology architectures and infrastructure within the context of ensuring technology alignment between enterprise, cluster and program area levels. Defines/maintains/interprets technology integration models and processes (and their associated elements such as technology infrastructure components, patterns, and services) to optimally: deploy infrastructure that meets the systems needs of the business assimilate infrastructure change as a result of technology innovation Ensures successful technology (new and existing) evaluation and transfer that aligns I&IT with the business EAPM Version 3.0

191 Technology Architect Technology Architect Promotes best practices for technology architecture in the OPS in order to educate the business community in how I&IT can help them leverage the transformation agenda and their business agenda. Collaborates with other architecture domains and I&IT stakeholders in cluster and corporate to achieve a common and consistent architecture vision to meet organization needs. Contributes to research, assessment, design, development and integration of technology architecture and standards in order to capitalize on technology to provide optimal solutions throughout the organization. Monitors the technology environment, business needs, and evolving technologies and trends in order to provide tactical advice on technology architecture changes and solutions (e.g., technology procurement). Contributes to technology integration models (and their associated elements such as technology infrastructure components, patterns, and services) to optimally: deploy infrastructure that meets the systems needs of the business assimilate infrastructure change as a result of technology innovation Ensures successful technology (new and existing) evaluation and transfer that aligns I&IT with the business. Judgement The Technology Architect works within the Architect Unit s mandate and related directives, policies and standards; statutory requirements (e.g. FIPPA), OPS administrative policies, procedures, directives; and accepted systems development practices. The Technology Architect on assigned projects and may lead them as required. Judgement is exercised in: identifying and assessing technical architecture problems and issues; determining appropriate tools and methods for systems analysis and design; devising project parameters, designing, developing, implementing and assessing applications; providing credible and timely advice to client ministry management; undertaking related policy review and development activities; staying current with related I&IT technology and systems, tools, modeling methods and other assessment and application mechanisms; and maintaining good working knowledge of different ministry and corporate business environments, and information management legislative obligations. June 3,

192 Contacts Ongoing contact with client program managers to share information, provide authoritative guidance on technology architecture and related requirements and develop recommendations, identify concerns and resolve problems. Regular contact with peers in other jurisdictions to share information, identify needs, learn from experiences, identify best practices, co-ordinate joint projects, and resolve problems. Frequent contact with the IT industry to stay current with developments and trends, and obtain specific information pertinent to current technical architecture projects. Competencies The following competencies are required for the Technology Architect Role: Table 3-4: Technology Architecture Role competency requirements Business Technical Behavioural Competency Proficiency Level Competency Proficiency Level Competency Proficiency Level Sr. Arch Arch Sr. Arch Arch Sr. Arch Arch Enterprise Communicating Architecture 4 3 Effectively 3 3 Planning: Tactical and Strategic 4 2 Service Excellence 4 2 Organizational Savvy and Politics 4 2 Industry Knowledge 4 3 Business Case Justification 4 2 Business Functions 3 1 Knowledge of Organization 4 2 IT Standards Policies and Procedures 4 3 Technology Architecture 4 3 System & Technology Integration IT Environment Emerging Technologies Infrastructure Development Tools Infrastructure Development Life Cycle Infrastructure Delivery Process Infrastructure (Desktop/Server/ Network) Innovation Networking Problem Solving Strategic Thinking Written Communications EAPM Version 3.0

193 Security Architect Security Architect Describes the role of Security Architect. Purpose of Role To analyze, define, develop, recommend, implement and oversee effective security and privacy architectures, and related policies, procedures and technologies for computing environments within the provincial government. To ensure the provision of timely and authoritative advice and support to cluster architects, OPS client ministries and organizations in the identification, assessment and resolution of I&IT security and privacy architecture issues. To develop and refine security architecture artifacts of the OPS EA and ensure that they are vertically integrated. Major Responsibilities General knowledge is same for security architect and senior security architect. Senior security architect does more enterprise-wide work; security architect tends to work in more local context. Senior Security Architect Lead development of security architecture policies, standards, principles, methods, processes and structures, including developing patterns, common models and reusable architecture. In consultation with business partners and architectural domains, ensure the alignment of security architecture with best practices, industry standards and the OPA EA Program. Consult and ensure the identification, analysis and resolution of specific security factors, service delivery concerns, protection of personal privacy issues. Provide advice and expertise as it relates to industry and international standards, legislative and policy matters, and best practices. Provide senior strategic and tactical advice, options and recommendations to senior managers, planners and architects regarding complex security issues. Provide senior security risk mitigation advice by identifying, analyzing and evaluating key areas of risks and potential impacts, and reviewing and developing risk mitigation strategies and plans. Security Architect Support the leadership team in the development of security architecture policies, standards, principles, methods, processes and structures, including developing patterns, common models and reusable architecture. In consultation with business partners and architectural domains, support the alignment of security architecture with best practices, industry standards and the OPS EA Program. June 3,

194 Consult and ensure the identification, analysis and resolution of specific security factors, service delivery concerns, protection of personal privacy issues. Provide advice and expertise as it relates to industry and international standards, legislative and policy matters, and best practices. Provide advice and recommendations to managers, planners and architects regarding security issues. Provide security risk mitigation advice by identifying, analyzing and evaluating key areas of risks and potential impacts, and reviewing and developing risk mitigation strategies and plans. Judgement The Security Architect works within the Architect Unit s mandate, and within current and accepted systems parameters and security standards. The Security Architect exercises considerable latitude for judgement and decision-making in: determining, implementing and evaluating the security architecture and underlying policies, and developing related strategies and plans to provide for a secure systems environment in order to minimize security risks and impacts; conducting risk, business impact and cost-benefit analyses; Contacts providing credible, timely and authoritative expertise and advice to client ministry management with regard to complex and sensitive security and privacy issues, developing viable solutions and courses of action which achieve the Architect Unit s mandate, goals and objectives; coordinating security and contingency initiatives; and undertaking policy review and development activities. Regular contact with Ministry and client ministry senior management to present and discuss the security architecture, disaster preparedness and contingency issues and analyses, as well as related plans and strategies, and to brief, update and provide expertise, advice and recommendations with regard to emerging issues and impacts. Regular and ongoing contact with colleagues and companion security function in iserv Ontario, to coordinate development of the security architecture and related policies. Regular and ongoing contact with OPS client ministries to provide security architecture and disaster preparedness and recovery expertise, consultation, training, and advice. Regular contact with IT industry professionals to maintain up-to-date knowledge of emerging security trends/issues and technology/software standards and best practices. Regular contact with vendors to research and assess security technology/ software acquisitions EAPM Version 3.0

195 Security Architect Competencies The following competencies are required for the Security Architect Role: Table 3-5: Security Architect Role compency requirements Business Technical Behavioural Competency Proficiency Level Competency Proficiency Level Competency Proficiency Level Sr. Arch Arch Sr. Arch Arch Sr. Arch Arch Knowledge of Security Commitment to Organization 3 2 Architecture 4 3 Organizational 3 3 Learning Risk Management 4 3 Business Functions 3 2 Writing/ Documentation 4 2 Organizational Savvy and Politics 3 2 Ethics and Integrity 3 3 Professional Judgment 4 3 Enterprise Architecture Process and Methods 3 2 Enterprise Architecture IT Standards, Procedures, Policies Security Management 4 3 Legal Regulatory Environment I&IT IT Industry: Trends, Directions and Emerging Technologies Network Architecture Product and Vendor Evaluation Concern for Image Impact 4 N/A 3 2 Integrity N/A Networking 3 2 Planning, Organizing and Coordination 2 N/A 3 2 Problem Solving Self-Confidence N/A Strategic Thinking Written Communications June 3,

196 3.1.7 EA Methodologist Describes the role of EA Methodologist. Purpose of Role Major Responsibilities To serve in the role of custodian of the Federated Enterprise Architecture Framework, its use/refinement and the architecture strategies, methods, techniques, tools and standards included in the EA libraries of the OPS body of EA knowledge. To plan, manage and conduct projects to develop new/refine content in the EA libraries of the OPS body of EA knowledge. To act as an expert in support of architecture development in the OPS and to lead the development, implementation and evaluation of architecture strategies, methods, techniques, tools and standards. To provide authoritative advice and guidance to Ministry and client ministries (working with the cluster architects). To develop and implement training initiatives concerning enterprise architecture. Leads the development, implementation, alignment and integration of enterprise and domain-specific architecture and project methodologies, including their definition (syntax, semantics, pragmatics), processes, techniques and metamodels. Provides awareness and expert consultation, advice, recommendations and practical support to senior management levels (both business and I&IT), architecture teams, business improvement and application solution project teams, governance bodies, and public and private sector stakeholders. This is in the selection, use and applicability of required tools and methodologies. Reviews and conducts research and analysis pertaining to the refinement, development and implementation of enterprise architecture strategies, methods, techniques, tools, standards, policies, guidelines and best practices. Manages the development, implementation, use and maintenance of an EA repository/library of knowledge-based metamodels, models and designs and other artifacts in support of EA work and system development work, including business, information, technology, application and security architectures (the five architecture domains) and associated patterns and components. This responsibility includes the custodianship of corporate documents that define the practice of architecture in each of the five architecture domains. Develops and sustains an effective network of credible and authoritative contacts with senior management levels (both business and I&IT), architecture teams, governance bodies, public and private sector stakeholders, subject matter experts and academia to facilitate the exchange of ideas, the flow of information and to keep abreast of issues, 3-22 EAPM Version 3.0

197 EA Methodologist trends, concerns and potential problems, especially as they relate to enterprise architecture methodologies. Judgement The EA Methodologist works within an Architect Unit s mandate, within the I&IT Strategy and related directives, policies, and administrative and I&IT standards. The EA Methodologist has with broad latitude for independent decision-making in the areas of accountability. Judgement and initiative are exercised in: Contacts planning, managing and conducting of research and analysis activities, that ensure the identification and resolution of critical factors; recommending changes to architecture strategies, methods, techniques, tools and standards included in the EA libraries of the OPS body of EA knowledge and advisory guidelines; developing and providing effective training materials; identifying potential or contentious issues/concerns; evaluating the environment and determining new areas for research and analysis; managing stakeholder relations; developing and making recommendations to senior officials within Ministry and client ministries on technical policy and program matters as well as emerging issues; staying current with OPS programs and I&IT technology and service developments. exercising tact and good interpersonal judgement, especially where effective matrix management is required across ministries and working closely with the Architecture Core Team, to establish credibility and maintaining effective rapport with officials at all levels within the provincial government, vendors, officials of other jurisdictions, the broader public sector and other stakeholders. Frequent contact with senior level officials within Ministry and client ministries to provide authoritative guidance, information, analysis and recommendations, enhance information flow, exchange information, discuss issues of mutual concern and resolve problems. Regular contact with peers in Ministry to provide information, analysis and recommendations, resolve problems, and to discuss issues of mutual concern. Regular contact with middle level officials in client Ministries to provide information, analysis and recommendations, enhance information flow, exchange information on IT policy and development matters, and resolve problems. Regular contact with peers in other jurisdictions and the broader public sector to share information, identify best practices, learn from experiences, develop and coordinate joint initiatives, and resolve problems. June 3,

198 Regular contact with service and product vendors, IT partners, software, hardware and service providers to share information, assess impacts of proposed or potential changes, develop training materials, identify and resolve problems, and stay current with developments and trends. Competencies The following competencies are required for the EA Methodologist Role: Table 3-6: EA Methodologist Architect Role compency requirements Business Technical Behavioural Competency Proficiency Level Competency Proficiency Level Proficiency Level Proficiency Level Knowledge Management 3 Enterprise Architecture 4 Problem Solving 4 Methodology Organizational Savvy and 3 Metadata Management 4 Coaching 2 Politics Knowledge of Organization 4 Enterprise Architecture Effectiveness 3 Impact and Influence 4 Measurement Service Excellence 3 IT Standards, Procedures, Policies 4 Commitment to Organizational Learning 3 4 Initiative 4 Business Process Design 2 Modeling: Data, Process, Events, Objects Business Case 3 CASE Tools 3 Innovation 4 Justification Application Delivery 2 Networking 4/5 Process Information Management 3 Strategic Thinking 4 IT Project Management EAPM Version 3.0

199 EA Repository Librarian EA Repository Librarian Describes the role of Enterprise Architect. Purpose of Role Major Responsibilities To implement and manage a repository for the OPS body of EA knowledge. To provide guidance aimed at ensuring all EA artifacts conform to the standards for naming and format. To act as custodian of EA artifacts. Advises and provides expertise to programs/teams and managers in the development of OPS EA knowledge repository(s), and it s content, for principles, methods, processes, standards, and practices. Manages and administers the OPS or Cluster EA knowledge/repository(s) using current electronic framework/artifact/repository management lifecycles, standards, methods, tools and procedures. Validates architecture designs to ensure that they are correctly classified, organized, stored, shared and searchable. Creates, requests, receives, analyses, classifies, organizes, validates, stores, retrieves and reports EA frameworks, business and &IT designs/ artifacts including their architecture metadata. Generates reports from repository(s) for clients and senior management. Conducts and validates metadata and data to ensure alignment between the OPS and Cluster repositories and ensure access and compliance with standards, policies, and practices. Establishes, develops, manages, and enhances a shared work environment to enable EA projects/teams to work collaboratively and effectively. Assists in the specification of repository and ancillary software requirements and upgrades. Designs, develops, and delivers awareness sessions and education training courses on repositories, frameworks, methods and tools through various channels to ensure project teams acquire and maintain required EA knowledge and skills. Develops and maintains effective customer working relationships with project(s)/teams, counterparts in other Ontario Government jurisdictions, external project consultants, as well as private sector IT peers, to share ideas and experiences. Judgement The EA Repository Librarian works within the Architect Unit s mandate and related directives, policies and standards; statutory requirements concerning privacy, security and information access (e.g. FIPPA), OPS administrative policies, procedures, directives; accepted electronic document management and architecture management practices and IT library and classification standards. Judgement is exercised in: June 3,

200 Contacts identifying and assessing artifact architecture management issues; determining appropriate methods for document classification; developing, recommending and implementing architecture knowledge processes for the unit; providing credible and timely advice to client managers and ministry senior management; undertaking related policy review and program assessment; and staying current with related I&IT technology and systems, tools, data modeling methods and other assessment and application mechanisms, information and privacy legislation, privacy impact assessments and information security requirements. Ongoing contact with peers in ministry and client ministries to provide authoritative information on electronic document management, architecture artifacts and current architecture, to consult on needs, to identify concerns, and to resolve problems. Regular contact with peers in other jurisdictions to share information, learn from experiences, identify best practices, and resolve problems. Regular contact with IT industry peers to stay current with developments and trends, and resolve problems concerning electronic document management. Competencies The following competencies are required for the EA Repository Librarian Role: Table 3-7: EA Repository Lrarian Role compency requirements Business Technical Behavioural Competency Proficiency Level Competency Proficiency Level Competency Proficiency Level Knowledge of Enterprise Commitment to Organization 2 Architecture 3 Organizational 3 Learning Service Excellence 3 Repository Metadata Management 4 Concern for Quality and Standards 4 Knowledge Management 3 Internet, Intranet Literacy Org Savvy and Politics Business Functions IT Standards, Procedures, Policies Information Management Document Management Data Movement Tools Drive to Results Integrity Deliver Problem Solving Teamwork EAPM Version 3.0

201 EA Repository Librarian Business Process Modeling: Data, Written Design 2 Process, Events, 2 Communications 3 Objects System 2 Development Life Cycle Training Delivery 3 IT Environment 2 June 3,

202 3-28 EAPM Version 3.0

203 Chapter 4: Architecture Methods

204 Chapter 4: Architecture Methods Starting the Project 4.1 Starting the Project This section presents the following topics: Project Initiation How does architecture fit into the typical project initiation process? This section describes in generic terms the different approaches to: developing a project charter in the context of an architecture; making use of existing architectural content to scope the project establishing roles and responsibilities for the architecture team vis-à-vis the development team Checkpoint Zero Project Compliance Review Process Standards Development Reusable Components Development I&IT projects contribute to the development of corporate and cluster-level components of the OPS EA. To assure the quality of these components, the corporate and cluster Architecture Review Boards review the progress of individual projects at key checkpoints. A checklist has been developed to guide projects subject to architectural review by corporate ACT and ARB. This checklist identifies all authoritative artifact types by row and column position, and indicates whether they are optional or mandatory. An accompanying Guidebook informs projects of the potential benefits to be accrued by producing each artifact, and the risks undertaken for each artifact not produced. Describes the typical categorization, selection/identification criteria, processes, approval forums and deliverable forms expected from projects which are creating business and/or automation design standards either as the main focus, or as an ancillary requirement of a business or technical change initiative. Describes the typical categorization, selection/identification criteria, processes, approval forums and deliverable forms expected from projects or functions that are creating business and/or automation design patterns, templates, and re-usable components. 4-2 EAPM Version 3.0

205 Project Initiation Project Initiation How does architecture fit into the typical project initiation process? Synopsis This section describes in generic terms the different approaches to: developing a project charter in the context of an architecture making use of existing architectural content to scope the project establishing roles and responsibilities for the architecture team vis-à-vis the development team Checkpoint Zero Developing Project Charters In the Context of EA The Ideal Situation Ideally, in enterprises that have EA programs, projects should be defined and scoped according to what analysis determines is needed to enable target architectures. The main steps in the process, for any given enterprise, are as follows: A current ( as is ) architecture is completed to a desired level of detail. It is especially important to capture at least some high-level information identifying the existing processes that support the enterprise s mission and goals, the information sources supporting the processes, the organizations that have any responsibility for the processes, and the information systems used in the processes. It s also useful to assess the quality, both technical and degree of client satisfaction, of the existing systems. A target ( to be ) architecture is completed to a desired level of detail. The target architecture is based on the enterprise s strategic and business plan. Starting with the new, envisioned goals for the enterprise, the architecture process consists of identifying the processes, information, organizations, etc., needed to enable the enterprise s envisioned future state. A gap analysis is conducted to determine how much of the current architecture can satisfy the requirements of the target architecture. If all of it can, then, in theory, there is no need to charter any projects because no changes are required. In most cases, however, especially with the pressures to migrate to online processes, integrate processes, etc., there will be a considerable gap between the capabilities of the existing enterprise and what it is intended to become. This gap is the basis for identifying and establishing the boundaries or scope of the initiatives needed to bring about the necessary changes. The projects and whatever they implement are said to be EA compliant because they will have been defined and scoped according to what has been determined to be needed to implement a target architecture. Such projects are considered to be implementing an architecture (and not just satisfying individual business June 3,

206 Chapter 4: Architecture Methods Starting the Project requirements). The implementations that result from such projects are aligned with the goals of some target architecture because they have been defined and scoped to align with a target architecture in the first place. The Reality Today The OPS EA Program is not yet at a level of maturity where target architectures are being developed to the degree needed to identify and scope the initiatives needed to implement them. There are not sufficient numbers of staff in both the business and I&IT communities who are trained in this methodology. In the meantime, however, it is still important to align projects when they are initiated with the evolving body of OPS EA. Aligning a project with EA in the OPS means to follow the following principles: Project and enterprise architectures are defined within their own separate frameworks but are all based on the Zachman Framework. The types of information (called artifacts) defined for enterprise frameworks are also defined for project frameworks for example, a data model. Project frameworks typically contain: Less or different scope than the enterprise for example some but not all data elements or new data elements Additional types of information for example a cross reference between processes and data relevant to the project Additional levels of detail or greater granularity for example more detailed process definitions than exist in the enterprise framework Architectural alignment is achieved by ensuring that the information in an enterprise framework and related project frameworks is consistent within, and equivalent between, frameworks. This means amending information within frameworks and copying appropriate information between enterprise and project frameworks after analysis and due consideration of the implications. Analysis amounts to detecting alignment issues gaps uncovered in project and/or enterprise architectures, and overlaps between several projects from the perspective of the enterprise. Due consideration means addressing these issues and amending information in the appropriate framework(s). The contents of the enterprise framework are normally considered authoritative, meaning that information can be copied from it to a project framework with regard only to relevance (scope), but information copied from a project framework to an enterprise framework must undergo an acceptance process. Alignment of enterprise and project architectures is an on-going process, normally proceeding one row at a time. Each project architecture adds more detail to the enterprise architecture. 4-4 EAPM Version 3.0

207 Project Initiation Implications The reality today and for the foreseeable future is that architecturally significant projects must plan for and be prepared to produce four categories of deliverables. 1. Project Management Deliverables - i.e., Project Charter, Project Plan, procurement documents (e.g., RFP), Threat/Risk Assessment, Privacy Impact Assessment, etc. 2. EA Deliverables i.e., the mandatory and optional EA artifacts specified in the Checklist for Initiatives that are Subject to Corporate ACT/ARB Review 3. Software Development Methodology (SDM) Deliverables i.e., designs required by the chosen SDM (e.g., Rational Unified Process) 4. New or Changed I&IT Capabilities i.e., the physical implementations satisfying the business requirements that projects are established to achieve In many cases EA deliverable requirements will coincide with the chosen SDM deliverable requirements, lessening the total related workload. Making Use of Existing EA Content to Scope a Project Architecture Teams versus Development Teams Projects are sponsored by their enterprises ministry programs that formed following the approval of Votes/Items in ministry business plans. If any architecture has already been developed for the sponsoring programs, then it must be reviewed to determine what if any of it can be reused in projects. It is particularly important for a project to draw first upon the sponsoring enterprise s Row 1 artifacts to help define the scope of the project and to begin the process of architectural alignment. Enterprise architects design the enterprises that are envisioned by the enterprise executives. Development teams build the enterprises designed by the architects. In the OPS context, if the OPS EA Program were at a more advance stage of maturity, enterprise architects would design the enterprises needed to implement the Votes/Items (Programs/Services) in ministry business plans. They would carry out the activities described at the beginning of this section under The Ideal Situation. For the previously mentioned reasons, the OPS is not yet ready to implement architecture in this way. In the meantime, development teams are required to combine EA activities with their system design and implementation activities. When an I&IT project is deemed to be architecturally significant, it is required to comply with architectural direction as provided by this Handbook and its companion documents and domain architecture handbooks. In addition to the design products required of the Software Development Methodology selected for the project, development teams assigned to architecturally significant projects must also produce EA artifacts per the Checklist for Change Initiatives that are Subject to Corporate ACT/ARB Review. June 3,

208 Chapter 4: Architecture Methods Starting the Project Checkpoint Zero Note: The following information was derived from the white paper Enterprise Architecture Checkpoint Zero, January 28, 2004 The architecture review process associated with I&IT projects that are subject to corporate ACT/ARB review involves three formal checkpoints for presenting project deliverables, defined as follows: Table 4-1: Checkpoints Checkpoint Description 1 Also known as the Business Architecture of the project. The artifacts involved in this checkpoint involve the Scope/Contextual/Planner and the Owner/Conceptual artifacts that are related to Rows 1 and 2 of the Zachman Framework. 2 Also known as the Logical Architecture of the project. Artifacts for this checkpoint are developed with a System/Logical/Designer perspective and are based on further elaborations of the artifacts produced during the Checkpoint 1 development phase. 3 The final physical description, through detailed artifacts and representation, of the technology implementation of the project - presented from the Builder/Subcontractor perspective. Due to the number of available system development methodologies, potential customizations and expectations on both sides of the review process, it has been determined by experience that it would be of great value to hold an informal information session in advance of a project s Checkpoint 1 review. Accordingly, a checklist for a Checkpoint 0 review has been established (see Enterprise Architecture Checkpoint 0 Checklist, January 25, 2005). Checkpoint 0 is not a formal review; rather, it provides an opportunity for everyone associated with a project that is subject to architecture review to become familiar with all of the requirements of the three formal checkpoints. 4-6 EAPM Version 3.0

209 Project Compliance Review Process Project Compliance Review Process I&IT projects contribute to the development of corporate and cluster-level components of the OPS EA. To ensure the quality of these components, the corporate and cluster Architecture Review Boards review the progress of individual projects at key checkpoints. A checklist has been developed to guide projects subject to architectural review by corporate ACT and ARB. This checklist identifies all authoritative artifact types by row and column position, and indicates them as optional or mandatory. An accompanying Guidebook informs projects of the potential benefits to be accrued by producing each artifact, of the risks undertaken for each artifact not produced, and provides examples. Review parameters Criteria for architecture review The following parameters are required for architecture review to provide standards and guidelines and assessments of compliance: Criteria for compliance reviews (why) Clear roles and responsibilities (who) Triggering events for standards and compliance reviews (when) Requirements for form and content at each stage in the review process including both architecture and privacy concerns (what) Defined checkpoints for architecture review (how). Table 4-2 summarizes the criteria for determining the responsibility for architectural review based on the scope of a given initiative. Table 4-2: Criteria for architectural review Initiative Scope Corporate Architecture Review Corporate e-government Review Common Common data definitions & Infrastructure elements Common components Base infrastructure Enterprise New architecture developments Architecture EA refinements Government-wide Common applications (e.g. ERPS) Any aspect of architecture initiatives Common technology components applying to online initiatives (e.g., ccpay) that are meant to be applied government wide. Cross-cluster Shared components Shared services & patterns infrastructure Shared applications Shared infrastructure Shared services & patterns Cluster Architecture Review June 3,

210 Chapter 4: Architecture Methods Starting the Project Program Architectural non-compliance Program Opportunities for leverage applications CIO-requested review Program infrastructure Program data arch. Review checkpoints Table 4-3 summarizes the checkpoints for architectural review by the corporate or cluster ACT and ARB. For each checkpoint, it identifies the components to be reviewed and the purpose of the review. The Corporate or Cluster ARB will review the development of the Privacy Impact Assessment (PIA) at each checkpoint. Table 4-3: Architectural review checkpoints Check Point* Components Purpose 0. Pre-incep- Project overview issues To identify aspects of the project dealing with tion Policy impacts on architecture intent, scope and planning. work To ensure awareness of policies impacting archi- Privacy and security tecture Standards Architecture arti- To ensure awareness of need for Privacy Impact facts management Assessments and Threat Risk Assessments Business-specific architecture To relate relevant standards requirements to the work project Information-specific architec- To identify the mandatory and optional EA artifacts ture work required of the project Security-specific architecture To review importance of creating a business archiwork tecture for the project that will ensure a good fit with the sponsoring business area Technology-specific architecture work To assess potential for sharing information with other organizations within and external to the OPS Application-specific architecture work To ensure awareness of importance of security Architecture reviews To identify any intentions to use new technology or to use existing technology To ensure the project is aware of work done so far in development common component strategies To identify the requirement for projects to plan for the formal checkpoint reviews and to be prepared to deal with both cluster and corporate review groups 4-8 EAPM Version 3.0

211 Project Compliance Review Process 1. Project plan Project Proposal or Plan Project Procurement Plan (RFPs for Services or Goods) Row 1 scope artifacts, particularly program and service context To review for cluster, ministry and government context and possibilities of alignment and sharing with other similar projects. To review and advise on plans for the acquisition of information and technology goods and services To ensure alignment with OPS standards. 2. Conceptual design 3. Logical design 4. Physical Design** 5. Implementation** Row 2 conceptual business design artifacts Row 3 logical system design artifacts Row 4 physical system design artifacts Row 5 implementation artifacts Deployment plans To certify the conceptual design is internally consistent and aligns with information, application, technology and security design principles, standards and methods. To certify the logical design is internally consistent and aligns with information, application, technology and security design principles, standards, and methods. To certify the physical design is internally consistent and aligns with logical information, application, technology and security standards and methods. To review and approve implementation To ensure there are no unplanned circumstances that would adversely affect other corporate projects. ** Stages at which projects meeting the criteria for IITELC review would be presented, following ARB review. Checkpoint 0 is usually performed during the development of a project charter. If the project charter is completed relatively quickly, then the Checkpoint 0 process may continue. In fact, any aspect of Checkpoint 0 may be revisited at any time throughout the life of a project. Checkpoint Reviews and Iterative SDLC Methodologies The original checkpoint review process was based on a waterfall Systems Development Life Cycle (SDLC) methodology. When an iterative SDLC methodology is followed, software is developed incrementally, as iterations, starting small and benefiting from enlightened trial and error along the way to full implementation. Accordingly, with iterative SDLC, it is likely that the system and technology models (artifacts in Rows 3 and 4) will need to be changed after testing actual software (Row 5). Such cases may require multiple Checkpoint 2 and 3 reviews, as illustrated by Figure 4-1. June 3,

212 Chapter 4: Architecture Methods Starting the Project Figure 4-1: Checkpoint reviews 4-10 EAPM Version 3.0

213 Standards Development Standards Development Discusses the application of standards and control functions This section describes the typical categorization, selection/identification criteria, processes, approval forums and deliverable forms expected from projects which are creating business and/or automation design standards either as the main focus, or as an ancillary requirement of a business or technical change initiative. Standards Development Establishing corporate technical standards, assisting projects with applying standards and assessing conformance is a large focus of the overall I&IT strategy. The IT Standards Council (ITSC), supported by the Technical Standards Unit, CASB, OCCTO, ensures that government standards are aligned with industry and serve as a basis for reducing costs and risks associated with the implementation of major I&IT initiatives and projects. Approved I&IT standards will require all I&IT development to go forward in a manner that ensures: interoperability and coherence privacy and security reliability and scalability reduce the risks associated with sole-sourcing Adherence to the government s I&IT standards is mandatory. The I&IT standards play a major role in establishing an underlying infrastructure based on sound principles. Main thrust of the I&IT standards initiative To adopt industry-wide, accepted, and available standards for all government systems that provide the following seven capabilities: 1. Reliability (minimize unplanned downtime) 2. Interoperability (enable disparate systems to interact) 3. Scalability (ability to increase number of simultaneous users) 4. Portability (enable platform independence) 5. Availability (minimized planned downtime) 6. Security and Privacy (auditing, tracking, encryption and protection against attacks) 7. Flexibility (positioned for migration to future technology opportunities) I&IT standards include Technical standards such as protocols, API s, specifications and data formats Functional standards for product/technology selection to make available the seven capabilities (reliability, interoperability, scalability, portability, availability, security/privacy and flexibility) June 3,

214 Chapter 4: Architecture Methods Starting the Project Development standards with respect to methods (best practices) for application development and implementing code using specific protocols, API and data formats Architecture standards or standard models for designs that meet specific business requirements All approved standards are reviewed regularly to be kept current and ensure relevant and timely standards are approved in a pro-active manner. A comprehensive list of industry standards has been adopted as mandatory by the Ontario Public Service. Mandatory technical, functional, development and architecture standards will feed into the RFP process as mandatory RFP requirements. Existing products and technology are assigned a status as per the following: Emerging Standards (monitor/ potential for adoption/ ongoing research) Approved Standards (approved/ adopted/ best practice) Transitional Standards (use when no suitable approved standards available) Obsolete Standards (sustain installed/ no new/ phase out) Transitional and obsolete standards are phased out over time on a case-bycase basis. Standards compliance is mandated through procedures based on a technical reference model (see Technical Standards Operational Policy). Technical Standards Operational Policy The Technical Standards Operational Policy describes a process for incorporating GO-ITS into the development life-cycle of an I&IT project/ initiative and stipulates that the evaluation and documentation of the technical standards implemented within a project/initiative must become part of the key deliverables reviewed throughout (as part of) the project governance. The Policy also provides guidance and direction to Government of Ontario ministries on compliance with GO-ITS. It has been developed by the Technical Standards Section, Corporate Architecture and Standards Branch, Management Board Secretariat. To access the policy, link to the ITSC intranet at - Standards Management Process/IT Standards Council Policy. All OPS I&IT projects/initiatives must incorporate and reflect the development of the Technical Standards Profile in the project plans, timelines and checkpoints for approval as part of the key project/initiative deliverables. The Technical Standards Section, Office of the Corporate Chief Technology Officer, provides a web-based tool for developing a Technical Standards Profile. It is called the Technical Standards Knowledge Management System (TSKM) see Reusable Components Development section for advice on the TSKM implementation tool EAPM Version 3.0

215 Standards Development IT Standards Council (ITSC) Mandate Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the standards, guidelines, technical reports and preferred practices adopted and promulgated by the IT Standards Council (ITSC) under delegated authority by the Management Board of Cabinet. These publications, available through the GO-ITS web site, support the Management Board Secretariat's responsibilities for coordinating the standardization of information and technology in the government of Ontario. Internal GO-ITS standards are internal documents and implementation guidelines that are available only to the Ontario government. More specifically, the Council s mandate is to: Recommend technical standards and related mandatory I&IT guidelines, procedures and methodologies to the Architecture Review Board and the IT Executive Leadership Council Govern and provide government-wide input into the standards review, development, adoption and approvals process Communicate and promote approved technical standards outward to all I&IT stakeholders Adopt open industry standards developed by recognized open standards development organizations to maximize interoperability and access to data Roles and Responsibilities The ITSC serves as an inter-ministerial council with responsibilities that include: Facilitate and encourage collaboration amongst the ministries/clusters, IT procurement, other governmental jurisdictions, the broader public sector, professional standards setting bodies, external partners and vendors; Assist major projects and initiatives in the selection, adoption and development (where necessary) of Government of Ontario Information Technology Standards (GO-ITS) or related standard processes/guideline/ procedures; Review, approve and maintain GO-ITS standards and, where appropriate, promote the need for a coordinated I&IT standards agenda for the province; Aim to minimize duplication and proliferation of conflicting standards; Develop a central source for provincial I&IT standards; and Engage the province in a more coordinated, proactive role in federal and international standards initiatives. Chair Susan Hess - Manager, Technical Standards Membership Members are OPS/BPS management level. Link to the ITSC intranet for a list of current members located at June 3,

216 Chapter 4: Architecture Methods Starting the Project Model Standards Approved definitions of the primitives and other artifacts associated with the EA frameworks that comprise the Federated Frameworks Model (FFM), along with reference models and patterns used in modeling, comprise another important body of standards. These standards are developed by subject matter experts associated with the particular model types and are incorporated into modeling tools and made available through the EA Meta-framework and the Patterns, Templates and Reusable Components Library EAPM Version 3.0

217 Reusable Components Development Reusable Components Development This section describes the typical categorization, selection/identification criteria, processes, approval forums and deliverable forms expected from projects or functions that are creating business and/or automation design patterns, templates, and reusable components. Synopsis Reusable components can be created as by-products of project work, or can be developed in projects specifically intended to create patterns, or can be discovered through analysis of multiple projects artifacts by the corporate or cluster architecture function. Presented here are the component parts of the template for the business case for the development of a Common Application Component. This document is to be used by I&IT clusters to present all the information required to get approval to develop a new common component or to use an existing application as a common component. Common Application Component Development Business Case Guidelines Executive Summary: Give a summary of the proposal. Highlight the objective of the project, funding requirements, key benefits/costs and recommendations. Purpose & Scope: This is more like a Mission Statement, and should state clearly what the project aims to achieve, how it is going to be executed, and the measures for success. Background: Provide information on business requirements, project issues, and external/internal factors that influence, contribute or affect the proposal in any way. Assumptions: On what premise is the project founded on, and why? Common Application Component Information: In this section detailed information should be provided to support the request to develop a Common Application Component. The items in this section represent key requirements that an application should possess in order to become a Common Application Component. It is therefore strongly recommended that all pertinent information be provided. Definition/Functionality: Define the application in detail making sure all of its functionalities and constraints are outlined. Reusability: Explain how well the application can be re-used across the OPS. Identify the current and potential users. Technical Standards: A Common Application Component should work with open standards (e.g. TCPIP, XML, etc.). Use the Technical Standards Profile to explain what GO-ITS and technical specifications standards are used by the application. Explain how the application conforms to the GO- ITS Information Technology Standards Framework. The Technical Standards Knowledge Management System (TSKM) will assist users to generate a profile by referencing The Open Group Architecture Framework (TOGAF) and selecting the application functions and services that describe the functionality of their project/initiative. For information on the Government of Ontario Information & Technology Standards (GO- June 3,

218 Chapter 4: Architecture Methods Starting the Project ITS) and the TSKM, please go to the following URL: or Architecture Standards: Explain how the application architecture conforms to OPS endorsed architecture best practices the architects utilize in developing the enterprise architecture for all initiatives. For information about Architecture Best Practices Library Framework please go to the following URL: structurenet2001-msaccess/index.asp?db=ops_ff. Architecture Reviews at ACT/ARB: Explain if the application architecture was reviewed by ACT/ARB. Include in the Appendix, if available, the architecture business, logical and physical models, TRA and PIA. The Checkpoints Checklist for architecture reviews is outlined by the OCCTO at the following URL: eia/frame00.nsf/items/ 9CCC8FD389D045FC85256CB10075DA86?OpenDocument Documentation: Provide details on the existing documentation on the application. Documentation may include user manuals, technical manuals, run books, training guides, etc. Common Application Component Shared Infrastructure: The figure below outlines the current Common Application Component Shared Infrastructure. The information within this section of the business case should address the following questions: Will the application work within the current Common Application Components Shared Infrastructure? What needs to be done in order for your application to work within the Common Application Component Shared Infrastructure. For example: changes to the application in the form of enhancements, etc EAPM Version 3.0

219 Reusable Components Development Figure 4-2: Common application component shared infrastructure COMMON APPLICATION COMPONENT SHARED INFRASTRUCTURE Firewall GONET INTERNET Firewall Firewall iserv Internet DMZ iserv Intranet DMZ Intranet Web Server Internet Web Server iserv Application Oracle Database Server WebSphere Application Server Service Levels: Explain the service levels contained in delivering this application, and any service level agreements that may currently exist. Release Management: Explain your proposed approach to defining the scope of releases and the frequency. Funding: Provide information on budget projections and funding model. Estimate resources required for developing, maintaining, and supporting the Common Application Component, and estimate resources required for training as well. Benefits: A detailed cost/benefit analysis is required in this section. Explain the pros and cons of building the application versus buying it. Recommendations: Outline any actions that are required to ensure the project is successful. June 3,

220 Chapter 4: Architecture Methods Starting the Project Figure 4-3: Common application component development workflow I&IT Clusters Common Component Advisory Team Impact Assessment and Prioritization Common Component Acceptance Approve Go-Live Plan Applied Technology Solution Branch - Log Request - Evaluate and Prepare Proposal for ITELC Get Aproval from ITELC Approve Project Charter Plan and Design Service Prepare: - Service catalogue - SLAs Final Approval to Proceed Obtain Authoprization from CCAB I&IT Cluster Application Development Branch Submit Business Case (Is it a common component?) Prepare Project Charter Complete: - Development Plan - Logical Models - Physical Models - PIA & TRA Build & Test Documentation: - Manuals - Run Books - iserv Manuals Knowledge Transfer Training to CC-COE Common Component Centre of Excellence Pre-production Quality Assurance Update SLA with iserv Prepare Go-Live Plan Arrange with iserv to Go Live iserv Certification Promote to Production Corporate ACT/ARB Pre-development Architectural Assessment EA Repository Librarian Check copy into Reusable Components Library EA Repository It is intended for Common Application Components to be indexed appropriately and stored in the EA Repository. Access procedures will be developed in the near future. [Note: It is not intended for the EA Repository to store executable code.] 4-18 EAPM Version 3.0

221 Reusable Components Development 4.2 The Architecture Process This section presents the following topics: Definition of the Architecture Process Analysis in Zachman This section presents the basic elements of the OPS Enterprise Architecture approach adopted from the META Group process. Although the general META Group process has been accepted in the OPS, a greater emphasis has been placed on the importance of business architecture, due to the much greater diversity of business activities carried out by any large government in comparison to a private sector organization. Data gathering, analysis, and synthesis in the context of a Zachman Framework Starting Points What are the starting points for architecture? This section identifies key starting points for each of the first five rows of the Zachman Framework. These are the tasks that must be done effectively to gain value from the investment in enterprise architecture at all levels project, cluster and corporate. While all architectural specifications are important (or they should not be part of the OPS specifications), some architectural elements are seminal in terms of setting the stage, helping to communicate, ensuring control of scope Architecture and Project Lifecycles How does architecture fit into a project lifecycle? One of the challenging aspects of enterprise architecture is that, in any given situation project, change initiative the view and mandate of enterprise architecture is always larger by definition than the view and mandate of the project, and the designers on the project. Once architecture and the distinctions between architecture and design are properly understood, there are several choices for fitting architectural work into project work. June 3,

222 Chapter 4: Architecture Methods The Architecture Process Definition of Architecture Process Enterprise architecture is a repeating, cyclical process, not a one-time event. This section presents the basic elements of the OPS Enterprise Architecture approach adopted from the META Group process. Although the general META Group process has been accepted in the OPS, a greater emphasis has been placed on the importance of business architecture, due to the much greater diversity of business activities carried out by any large government in comparison to a private sector organization. Enterprise Architecture Bridges Strategy and Implementation Business Strategy includes the definition of: Business drivers Business goals Business policies Trends analysis Implementation includes the definition of: Business processes Application systems Technical infrastructure Organizational structure Enterprise architecture bridges between these two realms by specifying: Business architecture Information architecture Application architecture Technology architecture Security architecture Positioning Enterprise Architecture A new or changed enterprise is a manifestation of business and I&IT strategy. Business strategy is manifested in such things as business processes, information requirements and organization. I&IT strategy is an articulation of how I&IT will enable business strategy. Enterprise architecture is a disciplined approach for creating and aligning I&IT architecture with business architecture to design an envisioned enterprise.just as there are many disciplines employed in the construction of large buildings, so are there many disciplines involved in building enterprises. And just as blueprints provide a common picture for how a building is envisioned to be for all of the disciplines involved, enterprise architecture provides a common picture for senior management, program and policy management, and IT management. This common vision includes: key environmental trends and business strategies I&IT requirements derived from those business drivers technology, market and public trends to be accounted for 4-20 EAPM Version 3.0

223 Definition of Architecture Process the role of IT and enterprise-wide IT infrastructure. The Enterprise Architecture Process Model The following diagram illustrates the Enterprise Architecture Process. It is a simplified version of the Adaptive EA Strategy process advocated by META Group Inc. Figure 4-4: Enterprise Architecture Process The preceding diagram highlights the cyclical nature of the EA process. Enterprises are under continuous pressure to adapt to changing circumstances. Business and technology drivers for change influence business planning and choices for the capabilities that enterprises must implement in order to meet expectations. Commercial enterprises that do not adapt to changing circumstances go out of business. Government enterprises, while not in danger of going out of business, are under the same pressures to change in order to meet the expectations of citizens. Pressures to offer online alternatives for transactional services, to improve accountability through results-based planning, to reduce or eliminate inefficacies wherever possible, to provide one-stop-shopping for related interjurisdictional services, and others, are driving governments to take a greater interest in the purposeful design of their enterprises. Governments, like all enterprises, deliver their services by means of their people and infrastructures. Knowing exactly what needs to be changed in the enterprise to respond to business direction requires an in-depth analysis, which is impossible to carry out definitively unless information about the June 3,

224 Chapter 4: Architecture Methods The Architecture Process intended future state of the enterprise can be made explicit in sufficient detail to be able to compare it with explicit information about the enterprise s current state. Being able to compare the two states visually is essential to identifying the change initiatives that are required to enable the target enterprise architecture. The EA process should be repeated every time there is a significant change in an enterprise s business direction. The need for the process to be repeatable implies the need for a high degree of consistency in how various aspects of the enterprise are modeled, both current and future states. Consistency in modeling is important even for enterprises that have only one business line. It is all the more critical in enterprises that have multiple and diverse business lines, such as the Ontario Government, for these kinds of enterprise benefit the most from sharing models. The ability to share models, saves time and effort, and helps to integrate business not only horizontally across the enterprise but also with partners and suppliers. The ability to create models consistently in a repeatable EA process, particularly in large organizations with several geographically dispersed modeling and design teams, requires the adoption of a standard EA framework and rules for creating models of all kinds. In this the Ontario Government has joined many other government and commercial organizations in adopting the Zachman Framework as its standard for modeling its enterprises EAPM Version 3.0

225 Enterprise Architecture Starting Points Enterprise Architecture Starting Points What are the important starting points for enterprise architecture? The OPS EA is a federated architecture, meaning that it is based on the concept that the Enterprise of the Ontario Government is in reality comprised of many sub-enterprises the various ministry programs and services, which stem from the Votes and Items approved by the Legislative Assembly. Although there is a continuing need to implement measures wherever possible to integrate the Ontario Government as a whole, the highest-level single enterprise that is purposefully designed is a ministry program. In the OPS, when we refer to current and target enterprise architectures, we mean current and target architectures of ministry programs. Because of the emphasis on government transformation, of the two states of architecture, current and target, target architectures are the more important. Resources should be expended on creating current architecture only to the degree needed to conduct a gap analysis with a more detailed and comprehensive target architecture. Target architecture once implemented, becomes the new current architecture and will serve as the basis for comparison in a future gap analysis with new target architecture. The Zachman Framework approach to EA is based on the logic of describing enterprises as sets of models that reflect the perspectives of key stakeholders in the enterprise. Each row or perspective of the Zachman Framework is comprised of six primitive cell models, and the sequence in which they are created is important. While all architectural specifications are important, some architectural elements are seminal in terms of setting the stage, helping to communicate, and ensuring control of scope. This section provides an example of a sequence to follow for creating the Zachman Framework models/artifacts for any program s EA. (See the Checklist for Change Initiatives that are Subject to Corporate ACT/ARB Review and Checklist Guidelines publications for details concerning the artifacts identified in the following paragraphs.) Column 6 Artifacts (Rows 1 and 2,) Why does the Program exist? Column 2 Artifacts (Rows 1 and 2) How will goals be achieved? The Column 6 artifacts provide the rationale and justification for initiating the program, and for any I&IT projects that are chartered to implement any part of the program. This is a key starting point. Starting with any other cell in the framework risks justifying the contents of that cell for its own sake rather than to support the achievement of program goals. The Column 2 artifacts define and describe the activities (e.g., services) required achieve the program s goals. This an important focal point because the content of the other cells will be based on what is needed to support the activities that the program needs to be engaged in. If an activity (or service) is defined that cannot be tied to any specific goal, then it becomes open to question as to the actual need for the activity. June 3,

226 Chapter 4: Architecture Methods The Architecture Process Column 1 Artifacts (Rows 1 and 2) Column 4 Artifacts (Rows 1 and 2) Column 3 Artifacts (Rows 1 and 2) Column 5 Artifacts (Rows 1 and 2) What information is needed to support Program activibties? The contents of these artifacts should be derived from determining the information needed to support the previously identified activities. One of the benefits of tying information to activities in this way is that it may be found that different activities require the same information, thereby identifying potential areas for information integration. Who is responsible for Program activities? Most activities need people to carry out various tasks, and even self-service services require someone to be responsible for service performance. Tying the Row 1 Column 4 artifacts to the previously identified activities is the start of establishing accountability for program and service outcomes and also helps to identity organizations engaged in the same or similar activities. Where do Program activities take place? Program locations generally are linked to organizations, so it is best to wait until the Column 4 artifacts are completed before starting Column 3. When do Program activities take place? The only dependency this cell has is on the previously identified activities. The following figure illustrates a sequence of developing the enterprise models down to Row 2. For ease of illustration, all of the models are depicted as simple decomposition diagrams, with decomposed elements relating to other appropriate decomposed elements. Figure 4-5: Modeling Sequence for Rows 1 and EAPM Version 3.0

227 Enterprise Architecture Starting Points Other Rows From the perspective of EA, the sequence of development of the various cell models in the remaining rows is not as important as Rows 1 and 2. Once the scope has been set, founded on Program goals and what is needed to support the activities (services) that are required to achieve those goals, the rest may be developed by transforming the Row 2 models into their corresponding Rows 3 and 4 models in the sequence prescribed by the systems development methodology being nemployed. June 3,

228 Chapter 4: Architecture Methods The Architecture Process Enterprise Analysis and Planning Data gathering, analysis and synthesis in the context of the Zachman Framework Note: This section is a draft currently under review. Enterprise Analysis vs. Systems Analysis Analyzing Models Systems analysis, one of the functions of systems development, is a wellknown and mature process. By contrast, enterprise analysis is a relatively unknown and immature process. In describing what enterprise analysis is, it is perhaps helpful to contrast it with systems analysis. Systems analysis is the application of analytical methods in the planning, design, and implementation of new and improved information systems. It involves the analysis of a proposed system and the identification of the requirements it should meet. It is the starting point for system design. (Programmers implement the designs systems analysts produce.) Enterprise analysis is the application of analytical methods in the planning, design, and implementation of new and improved enterprises. It involves the analysis of a proposed enterprise and the identification of the requirements it should meet. It is the starting point for identifying, scoping, and defining the change initiatives needed to build the enterprise that is needed to fulfill its planned mission and goals. If the modeling described in the previous section has been carried out for any OPS program, a great deal of useful knowledge will have been made explicit - the program s goals, the activities (however they are expressed as services, functions, processes, etc.) needed to achieve the goals, the information needed to support the activities, the organizations responsible for the various services, etc. These models alone can be of benefit to the enterprise as documented knowledge. Organizations that do not do much more than this with their models, however, are sometimes accused of doing architecture for architecture s sake, and their EA programs fail to live up to expectations. The maximum benefit is derived when models are analyzed with a view to determining and validating the relationships among them. Only when this is done can it be confirmed that, for example, all functions needed to achieve the intended goals have been properly identified, or that the organizational structure has been designed appropriately (i.e., is sufficient to carry out the intended range of activities and has no redundancy), or which information systems should be retired and replaced with ones that are needed to enable a target architecture, etc. Analyzing models consists of a set of associations whereby certain high-level models are combined to form matrices used to compare one set of enterprise information with another. To be precise, each matrix is actually an association of two lists, where each list consists of the names of the models in question. The following steps are undertaken to create the most important matrices needed for analysis: 4-26 EAPM Version 3.0

229 Enterprise Analysis and Planning Associate Goals with Processes In this activity, a matrix is formed by listing the enterprise goals and along one side and all processes down the other. Taking each process in turn and asking if it is required to achieve each goal, with a checkmark to indicate if it does, allows the architect to know if all of the programs/services are in fact needed to achieve the enterprise s goals or if any goal has been identified for which no process has been planned to be established to support it. The following figure illustrates. Figure 4-6: Goals ~ Processes Matrix Program A Service A1 Service A2 Service A3 Goal A Objective A1 x x x Objective A2 x Objective A3 Objective A4 x x x x Objective A5 x x x x Goal B Objective B1 x x x x Service A4 Associate Processes with Information Areas Associate Processes with Organizations Associate Processes with Locations Associate Processes with Existing Systems In this activity, a matrix is created with the information areas down one side, and programs/services along the other. Taking each programs/services in turn, and by asking if the programs/services involves each information subject area in turn, with a checkmark to indicate if it does, allows the architect to know which information could be shared among particular programs/services, thereby reducing redundancy and cost, and contributing to increased integration. In this activity a matrix is created to associate enterprise programs/services with the organizations in the enterprise s target architecture. Among other things, this matrix aids in determining organizational impacts when processes are changed or eliminated. In this activity a matrix is created to associate enterprise programs/services with the locations in the enterprise s target architecture. Among other things, this matrix aids in determining the impacts on locations when processes are changed or eliminated. In this activity, a matrix is created to associate programs/services required in the target architecture with the systems identified in the enterprise s as-is architecture. Among other things, this is used to identify the systems that should be retired and to assess the relative priorities of the initiatives needed to develop new ones. It should be noted that, although the foundation for the analysis is the set of enterprise goals, i.e., what the enterprise is intended to become, the common June 3,

230 Chapter 4: Architecture Methods The Architecture Process pivot for all of the analyses is programs/services. It is possible to select another variable to serve as the common anchor in the associations, but programs/services tend to be more stable than other possibilities, especially organizations, and usually are what the business community focuses on when redesigning enterprises for increased commonality. Planning In an enterprise whose EA program has reached an advanced stage of maturity, I&IT projects are justified according to their need in enabling the enterprise s target architecture and are defined and scoped according to the kind of analysis described previously. In such EA programs, the Target Architecture Implementation Plan, which is a plan that lists and sequences all of the change initiatives needed to create the envisioned enterprise within the business planning time frame, is an important EA deliverable. The OPS EA Program is not yet at the stage where I&IT projects are identified in this way, and target architecture implementation plans are not yet being developed. However, It is worthwhile documenting the concept at this time in order to improve understanding of the direction the OPS EA Program is taking. When I&IT projects are defined in regards to a target architecture and after an analysis has been performed, an initiative first appears in a list of all possible change initiatives as an entry that resembles the following table: Table 4-4: Change Initiative Definition and Scope [Change Initiative Name] [Change Initiative Description] Includes Processes Involves Information Areas Goals Supported Organizations Impacted Locations Impacted Systems Impacted [List of business processes involved in the change initiative.] [List of information areas involved in the change initiative.] [List of goals to be supported enabled by the change initiative.] [List of organizations affected by the change initiative.] [List of locations affected by the change initiative.] [List of existing systems affected by the change initiative.] Once a group of possible initiatives has been established, the next step is to prioritize them based on the degree to which each supports achieving the enterprise s goals. This is done using affinity analysis, a statistical technique that determines the degree of commonality between associations. It is beyond the scope of Version 3 of the EAPM Handbook to describe affinity analysis in detail at this time, but the result of the affinity analysis is a rank ordering of the possible initiatives, elimination of some that may not prove to have been as important as first thought, and perhaps a merging of some that have a high degree of commonality. The revised list of initiatives will now be ready to be sequenced and documented in the Target Architecture Implementation Plan EAPM Version 3.0

231 Architecture & Project Lifecycles Architecture & Project Lifecycles How does architecture fit into a project lifecycle? One of the challenging aspects of enterprise architecture is that, in any given situation project, change initiative the view and mandate of enterprise architecture is always larger by definition than the view and mandate of the project, and the designers on the project. Once architecture and the distinctions between architecture and design are properly understood, there are several choices for fitting architectural work into project work. Separate Architecture Project or Subproject One of the safest approaches, usually involving fewer challenges, is to establish a separate project or subproject for enterprise architecture, working separately from business and IT infrastructure change initiatives and projects. The architecture project aims at completing a broad cut at enterprise architecture in advance of the implementation projects, so that they can base their designs on enterprise-wide standards. Although this is a good concept, in practice the approach has several challenges of its own to overcome: know wherbto stop in terms of level of detail difficult to test or validate the architectural elements developed by the team since they are developed in isolation from real projects This approach does work well, however, up to a point. The best separate architecture projects are focused on developing education, communication, and limited common standards often in the form of principles. After a point, the architecture project or subproject transitions into an operating architecture function. Architecture After-the-Fact Architecture is often introduced while many projects are underway, and the question that arises is how to achieve some degree of architectural control over the project without creating unreasonable cost and scheduling issues for the project. This situation usually gives rise to two types of problems: major problems in the event the project is developing components or using standards which could turn out to be big departures for the organization minor problems in the event the project is using mainstream or compatible standards, but is not being documented according to the architecture guidelines in other words it is a black box to the architecture function. In both situations, it is usually advisable for the architecture function to invest time and effort in negotiating some role or interface to the project, to determine how to provide assistance and value. June 3,

232 Chapter 4: Architecture Methods The Architecture Process Architecture and the PMO Architecture Just-in-Time Architecture Approached from Two Directions Perhaps the best situation overall is one in which a Project Management Office, providing oversight to multiple significant projects, works closely with the architecture function. The architecture function and the PMO function, could be considered adjunct elements of each other. The projects within the realm of the PMO are typically important, and, therefore critical, to the long-term success and value of architecture. Architecture can typically offer considerable value to the projects since it, in effect, assumes some or all of the integration design work across multiple projects. A key question in planning for architecture work is how far in advance the architecture work needs to precede the design work that will take place during the project. Can architecture be delivered just-in-time? The answer should be a qualified yes by definition, the architecture work should be focused so as to provide value to the project or projects basing their designs on it, and the architecture work should not get too far out ahead of the projects, or they will encounter the problems mentioned in the point above. From experience, the best architecture groups adopt the strategy that they must stay close to the projects, in terms of knowing what the project priorities are, and helping to meet these by ensuring that architecture work is focused on those priorities. At the same time, the architecture function is responsible for overall standards and ensuring that goals beyond the immediate objectives of the project will be met. Once again, good architecture functions serve a purpose in communicating the importance and value of these higher goals to the project, resulting in better project results. The Zachman Framework seems to invite the question of approaching architecture from the top down and bottom up at the same time, meeting in the middle at logical design. This is a fallacy. There is no substitute for top-down architecture defining the business context, and the business vision and conceptual model, before beginning the development of logical and physical models (some overlap is possible in these tasks). What is sometimes called bottom up architecture gathering information about existing assets such as databases, applications, technology, etc. is really only that: data gathering. As such it is a legitimate activity, but should be conducted in the context of some specific purpose or project that needs the information EAPM Version 3.0

233 Architecture & Project Lifecycles 4.3 Planning and Architecture This section presents the following topics: Role of Architectural Planning Examines the role of architectural planning within the overall planning of a medium or large scale I&IT project, beginning with determining the scope of the architecture required to support the project Determining Architectural Scope Architectural planning begins with the delineation of the scope of the enterprise architecture required to support the I&IT initiative. The architect assumes that the products of the I&IT initiative are intended to support a business vision for the improvement of service delivery. This business vision must be clarified and detailed in a change initiative framework Business Case Effective architectural design can make the difference between an I&IT for Architectural project that succeeds in its business and technical objectives and one that Support fails. To ensure that medium and large-scale projects are supported by good enterprise architectural design, the I&IT planner should develop a business case for the design and implementation of the architecture required by a given project Statement of Architectural Work The statement of architectural work defines the major activities required to provide a medium or large scale I&IT project with the enterprise architectural design required to ensure the success of the project. June 3,

234 Chapter 4: Architecture Methods Planning and Architecture Role of Project Architectural Planning This section examines the role of architectural planning within the overall planning of a medium or large scale I&IT project beginning with determining the scope of the architecture required to support the project. Need for architectural planning Objectives Medium and large scale I&IT projects require millions of dollars of investment. The architectural design of these projects can make a significant difference in whether the technology, as implemented, not only meets individual business requirements but also the requirement to contribute to increasingly integrated business and I&IT environments for the programs they support. Effective architectural design can also significantly reduce the overall cost of system design and development by making effective use of reusable components. Significant effort should therefore be put into planning the required architecture as a part of the planning of a medium or large scale I&IT project. The objectives of a planning activity for architectural support for an I&IT project will normally include: Defining the architectural scope of the I&IT project including business, information, application, technology and security architecture. Identifying and analyzing the impact of the required architecture on the project and any associated business or I&IT initiatives. Analyzing the benefits and justifying the costs of the architectural design work required to support the project. Identifying the work required to design and implement the architecture required of an I&IT project. Deliverables Figure 4-7 illustrates the deliverables from an architectural planning exercise: Business vision enabled by the products of the I&T project. The vision will characterize the target business conceptual model, which, in turn, sets the architectural scope required by the project (see subsection 4.3.2). Change initiative framework to guide the development of the EA products of the I&IT project in the context of the Federated Frameworks Model. Business case for the required investment to support the EA contributions of the project (see subsection 4.3.3). Statement of scope of work required for the architectural work to support the project (see subsection 4.3.4) EAPM Version 3.0

235 Role of Project Architectural Planning Figure 4-7: Architectural planning deliverables for I&IT project Resources The following resources are required for an architectural planning initiative: Project sponsor to help determine the business scope of the architecture. The project sponsor will normally be a business organization within the OPS. If the I&IT initiative is focused purely on IT infrastructure, the project sponsor may be an I&IT organization. A business architect to determine the scope of the change initiative framework and to assist in the impact analysis, business case development, and statement of the scope of architectural work for the I&IT project. Business domain experts to help analyze the impact of the required architecture on the I&IT project and to develop the business case. Domain architects (in addition to the business architect) assist in the impact analysis, business case development and statement of the scope of work to design and implement the required architecture. Domain architects include information, application, technology and security domains. EA Repository administrator to set up the change initiative framework, including checking out any artifacts from authoritative frameworks and populating the change initiative framework with new artifacts. June 3,

236 Chapter 4: Architecture Methods Planning and Architecture Governance Activities Identify architectural scope Artifacts developed for the change initiative framework will be reviewed by the Cluster Architecture Review Board (ARB) or the Corporate ARB depending upon the scope of the I&IT project. The Cluster Architecture Core Team (ACT) or Corporate ACT or both may be involved in supporting the development of the framework. An architectural scoping initiative may involve the following activities. This activity determines the overall scope of the architecture required to support the I&IT project and any related initiatives. It ensures the creation and review of the: Business vision to be enabled by the products of the I&IT project. Change initiative framework(s) and scope level artifacts (Row 1) for the architecture required to support the I&IT project. Create the business case Define the statement of architectural work Schedule This activity is defined in subsection This activities cost justifies the investment in the design and development of target enterprise architecture to support the I&IT initiatives (see subsection 4.3.3). This activity defines the work required to design and develop the target enterprise architecture and to migrate from the legacy architecture (see subsection 4.3.4). Depending upon the size of the I&IT project and the availability of business and architectural resources, allow the following approximate durations for the scoping activities: Identify architectural scope: 2 to 4 weeks Business case development (see subsection 4.3.2): 2 to 4 weeks Statement of architectural work (see subsection 4.3.3): 2 to 4 weeks EAPM Version 3.0

237 Determining Architectural Scope Determining Architectural Scope Architectural planning begins with the delineation of the scope of the enterprise architecture required to support the I&IT initiative. The architect assumes that the products of the I&IT initiative are intended to support a business vision for the sponsoring program. This business vision must be clarified and detailed in a change initiative framework if it has not already been defined in the sponsoring program s EA. Objectives The objectives of a scoping exercise for architectural support for an I&IT project will normally include: Defining the architectural scope of the I&IT project including business, information, application, technology and security architecture. Identifying and analyzing the impact of the required architecture on the project and any associated business or I&IT initiatives. Deliverables The deliverables from an architectural scoping initiative include: Business vision enabled by the products of the I&T project. The vision will characterize the target business conceptual model, which in turn sets the architectural scope required by the project. Change initiative framework populated with Row 1 artifacts to describe the scope of the target architecture required to support the business vision. Impact analysis to identify the impact of the required architecture on the I&IT project and any related business and IT initiatives. Change initiative framework In determining the scope of the initiative, the I&IT planner should identify the sponsoring program s goals supported by the I&IT project. Where authoritative knowledge already exists for the sponsoring program, the planner should check-out the appropriate artifacts from an authoritative framework to populate Row 1of the change initiative framework. Scope artifacts (Row 1) Especially in the initial years of implementing enterprise architecture, a given set artifacts/models may not have been created and be available in an authoritative framework. In this case, the planner should engage the services of a business analyst or architect to lead an activity aimed at creating the appropriate business architecture artifacts/models. The business architect will generate a number of mandatory and optional artifacts relating to the sponsoring program needed to help scope the I&IT project per the Checklist for Change Initiatives that are Subject to Corporate ACT/ARB Review. Analytic intention of the framework The planner should also define the analytic intention (i.e., purpose) of the change initiative framework. The general analytic intention of a given services framework is to ensure a high degree of alignment and integration among the designs of the following architectural components: Programs and services Conceptual business model for service delivery June 3,

238 Chapter 4: Architecture Methods Planning and Architecture Logical models of the required information technology components. Business vision for proposed conceptual model (Row 2) Impact analysis of architecture on project Activities Develop business vision & change initiative framework Analyze impact The business planner or architect will develop a vision of the proposed conceptual business model. The vision will initially be a diagram that characterizes the target conceptual model for service delivery. It will include supporting diagrams and textual descriptions. The vision diagram will generally show clients, services, service providers, business partners and the business network for service delivery. As the architecture of the project develops, this vision will be used to generate detailed Row 2 artifacts such as the business network model, service delivery value chain, conceptual information model, performance model, and workflow model. The business vision will also guide the thinking of information technology architects in developing logical models of the target architecture (Row 3). The analysis will identify the impact of the required architectural design on the proposed I&IT project and any related business or IT initiatives. For each initiative, the following information will be included: Brief description of project or initiative Timing and major deliverables of project or initiative Linkages and dependencies between target architecture and project or initiatives Preliminary analysis of the target architecture for the project and the current I&IT architecture Preliminary analysis of the risks to the project and related initiatives if the architecture is not available Benefits derived by the project and related initiatives from the availability of an enterprise architecture. An architectural scoping initiative may involve the following activities. This activity ensures the creation and review of the change initiative framework(s) and scope level artifacts (Row 1) for the architecture required to support the I&IT project. This activity will include the following tasks: Conduct framework workshops with key business domain experts to identify the scope artifacts (Row 1) for the change initiative framework and to generate the business vision. Initiate a change initiative framework using currently available modeling and repository tools. Review the business vision, framework and artifacts with the appropriate ACT, ARB, and business sponsors. This activity identifies the impact of the proposed architecture on the I&IT project. This activity will include the following tasks: Conduct impact analysis workshop with key business and technical domain experts to characterize the architecture required to support the business vision and to analyze the impact of the proposed architecture on the I&IT project and related change initiatives EAPM Version 3.0

239 Determining Architectural Scope Document potential impact of the proposed architecture on the I&IT project and related change initiatives including: Salient features of current architecture ( as built components) Salient features of target architecture ( to be components) Potential impact of target architecture on I&IT project and related initiatives The risks associated with implementing or not implementing the proposed architecture The benefits of the proposed architecture for all architectural domains Review the impact analysis with the project sponsor and the appropriate governance bodies. June 3,

240 Chapter 4: Architecture Methods Planning and Architecture Business Case for Architectural Support Effective architectural design can make the difference between an I&IT project that succeeds in its business and technical objectives and one that fails. To ensure that medium and large-scale projects are supported by good enterprise architectural design, the I&IT planner should develop a business case for the design and implementation of the architecture required by a given project. Need for a business case A business case for I&IT investment is a long accepted practice. A business case for architectural support is a relatively new practice. This newer form of business case is required for a number of reasons: Enterprise architecture is a relatively new field. Many business and I&IT professionals are not clear on the benefits to be derived from good architectural design. Architectural resources are scarce and expensive. Business and I&IT planners may be tempted to cut corners on architectural support. The business case helps them to quantify the costs and benefits of architectural support. Migration from legacy architectures is complex and risky. The business case helps to map out a cost effective migration from the design of legacy systems to the target enterprise architecture in a way that maximizes benefits and mitigates against the risks. Objectives The objectives of a business case for architectural design support for an I&IT project include: Understanding the deficiencies, and opportunities for improvement, in the current business and technical environment Understanding the gap between the current business and technical environment and the possible future architecture Identifying potential migration strategies between the current business and technical environment and one based on the potential future architecture Determining the potential for a positive return on investment for the proposed architectural work. Deliverables The deliverables from a business case for architectural design support for an I&IT project include: Further clarification of the business vision: context and objectives Extensions to the change initiative framework to define the current (legacy) architecture and the proposed (target) architecture Gap analysis between current and proposed architectures Cost benefit analysis Recommended migration strategies Program management approach EAPM Version 3.0

241 Business Case for Architectural Support Business vision: context and objectives Change initiative framework extensions This deliverable will clarify the business vision developed at the beginning of the scoping exercise. It includes a review of the relevant features of the business context and objectives that will be supported by the architecture required by the proposed I&IT project. Business objectives will be identified at the government, cluster, ministry program, and project level as appropriate. This deliverable includes representative artifacts to characterize salient features of the as built legacy architecture and the to be target architecture required to support the business vision. Domain architects may add some of the following artifacts to the change initiative framework: Prototypical conceptual business model artifacts (Row 2) to contrast the business vision with the current business context. These artifacts might include as is and to be business scenarios illustrating the change in business vision (2,5), service life cycle activities (2,2), business network models (2,3), conceptual data models (2,1), work flow models (2,4), and business rules models (2,6) Prototypical logical model artifacts to characterize the target IT architecture including logical data models (3,1), logical applications and application building blocks (3,2), and infrastructure pattern matching (3,3) Existing physical data models (4,1), applications (4,2) and network topologies (4,3) to characterize the legacy architecture. Gap analysis between current and proposed architectures This deliverable requires an analysis of the as is and to be business model and information technology architecture of the business and technical domains within the scope of the proposed I&IT architecture. As such, the gap analysis deliverable will include: Key elements of the architectural scope of the project ( inclusions and exclusions based on the change initiative framework developed in the scoping initiative see subsection 4.3.1) Identification of salient design features of the current program and service model, service delivery model(s) and architecture of existing legacy systems Identification of salient design features of the target program and service model, service delivery model(s) and proposed I&IT architecture Analysis of the gap between the design of the current business and technical environment and the target enterprise architecture. Recommended migration strategies This deliverable identifies the recommended strategy for migrating from the current business and technical environment to the target enterprise architecture. It will include: Key migration challenges Critical linkages and dependencies in the business and technical domains, other considerations (e.g. privacy and security) Critical success factors associated with migration Risks associated with migration and actions to mitigate the risks June 3,

242 Chapter 4: Architecture Methods Planning and Architecture Migration strategy options Preferred migration strategy. Cost benefit analysis This deliverable determines whether there is a significant return on the investment required to design and implement the target architecture for the proposed I&IT project. It will include: A summary of the costs incurred in designing and implementing the target architecture A summary of the tangible and intangible benefits (business and technical) to be derived from the target architecture) Performance measurements to use to determine whether tangible benefits are obtained as the target architecture is deployed Recommendations on how to actively manage the achievement of potential benefits as the target architecture is deployed. Activities Program management approach Extend change initiative framework This deliverable describes the recommended approach to managing the design and implementation of the target architecture to ensure a successful migration that achieves the potential benefits. It will include: Collaboration and governance strategies to ensure that the I&IT project complies with relevant design standards and is able to share reusable design patterns and components from other enterprise architecture initiatives throughout the OPS and BPS Procurement strategy to ensure that the I&IT initiative is able to acquire the required architectural resources for all domains (business, information, application, technology and security) whenever there is a gap between available and required resources HR strategy to ensure that expensive and scarce architectural resources have the required skills, are focused on the right tasks and are managed to provide the most cost effective solution Communications strategy to ensure that architectural resources understand the emerging standards and design patterns of the enterprise architecture (EA) in general, and the target architecture of the proposed project in particular. The business case component of an architectural scoping initiative may involve the following activities. This activity involves domain architects in extending the change initiative framework to include elements of the as built legacy architecture and the to be target architecture. This activity will include the following tasks: Conduct design workshops with key business domain experts and domain architects to identify salient features of the as built architecture and the target architecture required to support the business vision. Document as built and to be artifacts emerging from the workshops EAPM Version 3.0

243 Business Case for Architectural Support Review the artifacts with the appropriate ACT, ARB and business sponsors. Analyze gap between legacy and target architectures Create migration strategy This activity identifies the gap between target architecture for the proposed I&IT project and the architecture(s) of the legacy systems. This activity will include the following tasks: Domain architects will document the salient design features of the legacy architecture(s) and the target architecture Domain architects will analyze the gaps between the legacy and target architectures Domain architects will review the gap analysis with the project sponsor and the appropriate governance bodies. This activity involves the development of a migration plan to mitigate the risks of moving from the legacy architecture(s) to the target architecture. It will include the following tasks: Conduct migration strategy workshop with domain experts and domain architects to identify business and technical migration challenges, critical linkages and dependencies in the business and technical domains, critical success factors for migration, risks associated with migration, actions to mitigate risks and migration strategy options. Document the migration strategy considerations and options, including the recommended strategy. Review the migration strategy with the project sponsor and the appropriate governance bodies. Analyze costs and benefits This activity involves the analysis of costs and benefits associated with moving from the legacy architecture(s) to the target architecture. It will include the following tasks: Conduct cost-benefit analysis workshop to identify the costs incurred in designing and implementing the target architecture, the costs associated with maintaining the legacy architecture, the tangible and intangible benefits (business and technical) to be derived from moving to the target architecture), performance indicators to measure the benefits, active benefit management techniques to ensure that benefits are secured Document the costs and benefits and calculate potential return on architectural investment Review the cost benefit analysis with the project sponsor and the appropriate governance bodies. Create architectural management program recommendations This activity involves the creation of a set of recommended strategies to manage the architecture program or function required to support the I&IT project and to migrate from the legacy to the target architecture. It will include the following tasks: June 3,

244 Chapter 4: Architecture Methods Planning and Architecture Conduct program management workshop to identify recommended collaboration and governance strategies, procurement strategies, HR strategies and communications strategies Document the recommended strategies for the architecture management function. Review the program management recommendations with the project sponsor and the appropriate governance bodies. Useful Business Case Inputs The Business Case for Architectural Support is one of several overhead documents that are prepared at the onset of an I&IT project. The Project Charter and Project Plan are well known requirements. For projects that are subject to corporate ACT/ARB reviews, another early deliverable is the result of going through the Enterprise Architecture Checkpoint 0 Checklist. All of these additional documents can provide very useful inputs when preparing the Business Case for Architectural Support EAPM Version 3.0

245 Statement of Architectural Work Statement of Architectural Work The statement of architectural work defines the major activities required to provide a medium or large scale I&IT project with the enterprise architectural design required to ensure the success of the project. Need for a statement of work Objectives A statement of architectural work is required for an I&IT project to: Define the scope of the business and I&IT design required to support the project Ensure that design deliverables are available on a timely basis for the success of the project Provide the terms of reference in requests for proposals or resources for architectural design services Guide the migration of the legacy architecture to the target enterprise architecture. The objectives of a statement of work for architectural design support for an I&IT project include the management of: Scope: determining the scope of business and IT design activities required ( inclusions and exclusions ) to support the I&IT project and to guide migration to the target architecture [Note: This should have already been identified in the Project Charter.] Time: Determining when design resources are required and what activities they must perform to provide timely support to the I&IT project [Note: This will have to be factored into the Project Plan.] Money: Quantifying the design resources required to support the project. Deliverables The deliverables from a statement of work for architectural design support for an I&IT project include: Statement of scope Work breakdown structure Resource roles and responsibilities Work schedule. Statement of scope Work breakdown structure Resource roles and responsibilities Work schedule This deliverable defines deliverables, activities and responsibilities that are included or excluded from the scope of the architectural design work. This deliverable breaks down the architectural design work into a set of activities and deliverables. This deliverable defines the resources required for architectural design support and specifies the responsibility of each role for provision of design deliverables. This deliverable schedules the activities in the work breakdown structure. June 3,

246 Chapter 4: Architecture Methods Planning and Architecture Typical WBS, roles and schedule Activity: Understand current architecture The balance of this subject describes the scope of each activity in a typical work breakdown structure and identifies resource roles and responsibilities. Using Enterprise Architecture (EA) standards, create a set of as built design artifacts in the business, data, applications, technology and security domains that describe the current business and I&IT environment. The question that always arises pertains to the degree, i.e., breadth and depth, to which the current enterprise (program) needs to be architected. In general, this will depend on the scope of any particular change initiative. With regards to breadth of architecture (i.e., number of components), if a change initiative has a narrow focus, affecting relatively little of its sponsoring program, then little of its current architecture will likely be required. On the other hand, if an I&IT project is expected to affect a relatively large segment of a program, then a correspondingly large part of its current architecture will be needed. With regards to depth (i.e., detail) that is required, all that is needed to be known is just enough to serve as a basis for comparing future requirements identified in the target architecture with current capabilities in order to define the additional capabilities, or changes to existing ones, that are needed to meet the program s goals. In many cases, it may be sufficient simply to name the components in the sponsoring program, e.g., functions (or services), information areas, organization units, systems, etc, and whether any need to be changed or retired in migrating to the target architecture. In other cases it may be necessary to model some components, especially if they are going to be directly affected by the I&IT project that is underway. Roles Subject matter experts (from the program under review) Enterprise Architect Business Architect Application Architect Information Architect Technology Architect Security Architect 4-44 EAPM Version 3.0

247 Statement of Architectural Work Activities Deliverables Analysis of as-is information, business processes, applications, and technology architectures. What are the deficiencies that need to be addressed in order for the program to be able to achieve its goals? For business architecture, scope artifacts (Row 1) and conceptual business model (Row 2) For information and applications architectures: Appropriate Column 1 and 2 artifacts For technology architecture: Appropriate Column 3 artifacts Activity: Design target architecture Using EA standards, create a target enterprise architecture as a blueprint for future business and systems environments. Specific deliverables will be clustered around business, information, applications, technology, and security domains. For this activity, the typical roles, activities and deliverables are described by architectural domain. Business architecture domain roles Business architecture domain activities Business architecture domain deliverables Data architecture domain roles Data architecture domain activities Data architecture domain deliverables Subject matter experts (from the program under review) Business Architect Identify and review relevant business documents. Identify and interview business subject matter experts (possibly in concert with the Data Architect). Identify business reviews, draft deliverables, gain acceptance from reviewers. A list of business problems and root causes. Per the Checklist for Change Initiatives that are Subject to Corporate ACT/ARB Review for Rows 1 and 2 Information Architect Identify and review relevant business documents. Identify and interview business subject matter experts. Identify and review relevant existing physical, logical, and conceptual data architecture documents. Prepare information architecture deliverables according to EA guidelines. Per the Checklist for Change Initiatives that are Subject to Corporate ACT/ARB Review for Column 1 June 3,

248 Chapter 4: Architecture Methods Planning and Architecture Applications architecture domain roles Applications architecture domain activities Applications architecture domain deliverables Technology architecture domain roles Technology architecture domain activities Technology architecture domain deliverables Security architecture domain roles Security architecture domain activities Security architecture domain deliverables Applications Architect Cross-reference logical business processes against logical data. Conduct affinity analysis to determine the logical applications (applications portfolio). Cross-reference logical applications to the logical data group. Determine the Application Building Blocks (ABB) underlying the logical applications. Document the ABBs Define the fundamental types and inheritance in the Class Hierarchy Per the Checklist for Change Initiatives that are Subject to Corporate ACT/ARB Review for Column 2 Technology Architect Develop Application Function and Data Placement Model Identify Domains Identify Nodes Identify base Logical Operational Model Validate Logical Operational Models with Business Scenarios Define Technical Selection Criteria and Process Per the Checklist for Change Initiatives that are Subject to Corporate ACT/ARB Review for Column 3 Security Architect Review each domain architecture (business, information, applications and technology) to identify potential security threats within each domain. Document and share the findings with each domain architect. Review the updated domain architecture based on updates from findings Provide guidance with the creation of the security layer for each domain architecture. Assist with the creation of a security layer for each domain architecture: Provide technical security patterns, security data classification, application groupings and separation of functions, security policies. Security principles 4-46 EAPM Version 3.0

249 Statement of Architectural Work Potential security threats within each domain architecture. Guidance on creation of security layer for each domain architecture. Miscellaneous support for other business initiatives. Security requirements from business initiatives that affect the I&IT project. Activity: Identify business & technology alternatives Identify potential business and technology alternatives that satisfy business objectives, I&IT project objectives and the intent of the target architecture. (Business alternatives could include various alternative service delivery options.) Roles Technology Architect Activities Identify feasible technology alternatives that will satisfy the intent of the target architecture and I&IT project objectives. Deliverables Technology alternatives: Set of alternatives needed to align technology design decisions (within individual initiatives) with the target architecture. Activity: Perform detailed gap analysis Specify differences between legacy and target architectures, including missing or redundant functionality, and less than optimal divisions of labour. Identify missing or inadequate components required by the target architecture and related business and technical initiatives. Provide input to migration plans and business cases for later phases. For applications architecture, ensure that target architecture includes components to meet legacy functional requirements still required in future. Roles Business Architect Application Architect Information Architect Activities Deliverables Activity: Monitor I&IT projects Analyze as-is artifacts against the target artifacts and document the differences. Legacy versus target environment gap analysis. While design work is continuing, portions of the design may be constructed or deployed or related components may be constructed and deployed in other initiatives. The design team must monitor and consult with the I&IT project team and related project teams to support a common architecture approach. Roles Business Architect Information Architect Application Architect Technology Architect Security Architect June 3,

250 Chapter 4: Architecture Methods Planning and Architecture Activities Meet periodically with the team in each project that is likely to change the business processes within scope. Modify target architecture deliverables as required to reflect the business process changes. Repeat cross referencing and acceptance activities as required.deliverables Deliverables Activity: Confirm or modify I&IT project components Modified target architecture artifacts The design team should formally review all existing or related business or I&IT initiatives to confirm their scope, objectives, timelines, priority and sequencing against the target architecture and architecture migration strategy and plans Roles Activities Business Architect Information Architect Application Architect Technology Architect Security Architect Review project proposals and evaluate in terms of appropriate business case, scope, approach, deliverables and timing. Make recommendations for the modification of these. As appropriate with project s nature and timing, negotiate an agreement as to the nature and extent of architectural activity. Perform quality assurance on the resulting deliverables and integrate them into the cluster architecture. Deliverables Activity: Define and implement architecture support function Possible modifications to target architecture based on new constraints on technology options. Some large-scale I&IT projects are complex enough as to require a dedicated architecture functional support team. This group integrates conceptual and logical architectures with architectural patterns and standards established at corporate, cluster or Ministry levels. It provides education, advice and quality assurance reviews to the project team. It specifies terms for an architecture function support team, including: organization, staffing, roles and responsibilities, procedures, tools, relationships and accountabilities. If an architecture support function has been defined, this activity will implement the function, with governance, accountabilities, mandate, reporting relationships, logistics, staffing, procedures, and relationships. Finally, it will also execute the architecture function's mandate to support continuing business and I&IT projects. Roles Architecture Functional Support Team Manager Architecture Planner 4-48 EAPM Version 3.0

251 Statement of Architectural Work Activities Deliverables Cluster Information Architect Cluster Business/Applications Architect Cluster Technology/Security Architect Methods & Tools Specialist Repository Administrator/Librarian Negotiate service level agreement (SLA) and Centre of Excellence (COE) agreement Write RFP or RFR for project architects Evaluate and award architecture contracts Perform architecture planning for the project Perform vertical integration for information, business, applications, technology and security architectures Define and support policies, standards, guidelines for creation and management of ministry architecture artifacts and tools Support artifact creation and management tools Perform artifact management including change control, versioning, check-in/check-out Provide education and training in methods, tools, standards to project architects SLA agreement for project architecture work COE agreement for project architecture work Selected and awarded project architects Project architecture plans Horizontal integration of architectures between project, cluster, corporate Artifact creation and management standards, policies, guidelines Artifact creation and management tools Vertically integrated domain architectures (information, business, application, technology, security) for the project and for the cluster Activity: Define components The target architecture identifies logical building blocks that are combined to carry out business services. This stage defines these building blocks. Roles Activities Deliverables Information Architect Application Architect Migrate the Use Case diagrams to Sequence Collaboration diagrams. Examine the process steps to determine Object components. Create an inventory of objects that can be refined to common class model. Identify the object components. Class Model List of Components. June 3,

252 Chapter 4: Architecture Methods Planning and Architecture Activity: Design standard reusable components Based on the migration strategy, the design team and development project staff will design chosen components or application building blocks (ABBs) to begin the migration process. Roles Information Architect Application Architect Security Architect Applications Architect I&IT Staff (subject matter experts) Activities Deliverables Define Implementation Classes Implementation classes EAPM Version 3.0

253 Statement of Architectural Work 4.4 Architecture and Special Initiatives This section presents the following topics: Introduction to Data Warehouse Design and Architecture This section clarifies the differences between operational systems and analytic systems; and lists alternative architectures for the data warehouse design. This overall picture of data warehouse will help in the selection of information models to use for individual projects Portal This subsection will be available in a future release of this publication Commercial off-the-shelf software This subsection will be available in a future release of this publication. June 3,

254 Chapter 4: Architecture Methods Architecture and Special Initiatives Introduction to Data Warehouse Design and Architecture This section clarifies the differences between operational systems and analytic systems; and lists alternative architectures for the data warehouse design. This overall picture of data warehouse will help in the selection of information models to use for individual projects. Overview What is a Data Warehouse? Data Warehouse Types and Design Data Warehouse Architecture According to W. H. Inmon (1992), a data warehouse is a subject-oriented, integrated, time-variant, and nonvolatile collection of data in support of management s decision making process. This definition provides four key features. Data warehouses could be classified into two classes in terms of their usage scopes: the enterprise data warehouse and the data mart. Their features are summarized here. The data warehouse architecture is made up of a number of layers. At a high level view, data moves from the source systems to the staging area using functions provided as part of the data staging services layer. This flow is controlled by metadata maintained in the metadata repository: data that describes the locations and definitions of the sources and targets, data transformations, timing and dependencies. Once the data is combined and aligned in the staging area, the same data staging services are used to select, aggregate, and restructure the data into a data warehouse EAPM Version 3.0

255 What is a Data Warehouse? What is a Data Warehouse? According to W. H. Inmon (1992), a data warehouse is a subject-oriented, integrated, time-variant, and nonvolatile collection of data in support of management s decision-making process. This definition provides four key features. Subject-oriented Integrated Time-variant Nonvolatile The data warehouse is designed for analysis of business and answers the questions from decision makers and information analysis. It is organized around major subjects, such as market and product. Data in the data warehouse normally integrates from multiple, heterogeneous data sources. During the transformation, data cleaning and data integration techniques are applied to ensure consistency such as naming conventions. Data warehouse contains historical data. Data warehouse is always separated from operational databases. It only has two operations loading and access (read only) of data. The benefits of data warehousing can be summarized as below. Make decision-making possible. Enhance customer service. It is easier to handle large amounts of data. Make execution of complex queries easier and faster. Make unknown or hidden knowledge discovery in data mountain possible. Provide better data integrity and quality. Provide easier integration and process automation along with cost effectiveness and higher productivity. Online Analytical Processing (OLAP) and Data Mining A Data warehouse supports business decisions by collecting, consolidating and organizing data for reporting and analysis with tools such as OLAP and data mining. In other words, a data warehouse provides a prerequisite for OLAP and data mining. OLAP is a technology providing superior performance for ad hoc business intelligence queries. It is designed neither to store large volumes of text or binary data, nor to support high volume update transaction. Its design enable efficient operation with data organized in accordance with the dimensional model, which has been discussed in Chapter 3. It provides remarkable performance in rapidly summarizing information for analytical queries. Rollup, drill down, slice, dice and pivot are the common operations provided in OLAP. Data mining is a technology that analyzes data by applying sophisticated and complex algorithms and then exposes interesting information for analysis by decision makers. Whereas OLAP organizes data in a model suited for exploration by analysts, data mining performs analysis on these organized June 3,

256 Chapter 4: Architecture Methods Architecture and Special Initiatives data and provides the results to decision makers. Therefore, OLAP supports model-driven analysis and data mining supports data-driven analysis. OLAP is similar to traditional statistic methods, the only difference is that OLAP is working on organized data so it can provide much better performance. However, both OLAP and traditional statistical methods can only list statistical results. Data mining is able to answer decision-making types of questions, which can never be done by OLAP and traditional statistical methods. Below are some sample questions to be answered by OLTP (online transaction processing), OLAP and data mining respectively. OLTP questions: OLAP questions: Who bought which product on what date? View sales data according to various levels of time, item and location. What is the average turnover in a certain sales region in July? Data mining questions: What are the most important trends in customer behavior? Which items are likely to be purchased together for a customer on a given trip to the store? 4-54 EAPM Version 3.0

257 What is a Data Warehouse? OLAP versus OLTP As discussed in the previous section, OLAP is an analysis environment, while OLTP is an example of operational environment. Table 4-5: OLAP versus OLTP Features OLTP OLAP Characteristic Operational processing Informational processing Orientation Transaction/Operation Analysis User Clerk, DBA, database professional Knowledge worker (e.g. Manager, executive, analyst) Function Day-to-day operation Long term information requirements, decision support Data Current; guaranteed up-to-date Historical; accuracy maintained over time Summarization Primitive, highly detailed Summarized, consolidated View Detailed, flat relational Summarized, multidimensional Unit of work Short, simple transaction Complex query Access Read/write Mostly read Focus Data in Information out Operations Index/hash on primary key Lots of scanning # of records accessed Tens Millions # of users Thousands Hundreds DB size 100 MB to GB 100 GB to TB Priority High performance, high availability High flexibility; end-user autonomy Metric Transaction throughput Query throughput, response time Data model ER based, application-oriented Star/snowflake, subject-oriented June 3,

258 Chapter 4: Architecture Methods Architecture and Special Initiatives Data Warehouse Types and Design Scope Data warehouse could be classified into two classes in terms of their usage scopes: the enterprise data warehouse and the data mart. Their features are summarized in the Enterprise data warehouse versus data mart below. Table 4-4: Enterprise data warehouse versus data mar Enterprise Data Warehouse Corporate-wide data integration Subjects spanning the entire organization Cross-functional and cross-subject Data Mart A subset of corporate-wide data Specific and selected subjects only User Whole enterprise Value to a specific group of users Data Detailed data and summarized data Typically summarized data only Data source Typically from one or more operational systems or external information provider DB size GB to TB and over GB From multiple sources, or From an enterprise data warehouse Data model ER model and/or dimensional model Dimensional model The implementation of a data mart is much easier than an enterprise data warehouse; its cycle is more likely to be measured in weeks. However, it may involve complex integration if the designers did not keep the enterprise-wide planning in mind from the start. Meanwhile, development of an enterprise data warehouse is much more expensive; it requires a proper design. Some alternatives for the enterprise data warehouse design are discussed below. Top-down Bottom-up Top-down development of an enterprise warehouse is a systematic solution. It minimizes integration problems. However, it is expensive and could take a long time to finish. In a top-down approach, one big enterprise data warehouse containing historical detail data is created first from the operational systems. Later, the subject specific data marts are built. Because of its larger scope, the danger in this approach is that building from the top may not go deep enough to serve each department s specific needs. The enduser applications are created with what is available rather than what should be there. One of the most difficult tasks is getting all the key people from different departments to agree on the same interpretation of the data before building any applications. The never ending requests from the users to expand the design built with this approach make on-time delivery rather difficult and costly. Bottom-up development starts with independent data marts and then integrates all produced data marts into an enterprise data warehouse. Its advantages are flexibility, low cost, and rapid return. But multiple data marts built this way become isolated systems. Since each of them requires an extraction of operational data from different sources, they begin to cause redundancy. As their number grows larger, the total time spent managing them 4-56 EAPM Version 3.0

259 What is a Data Warehouse? becomes longer than expected. The biggest drawback for this approach is the lack of data integration for the organization as a whole. The migration to a common enterprise data warehouse model will be nearly impossible. The effort to create an enterprise data warehouse model brings to light the need to plan for more scalability from the start, where the data from multiple sources can be cleansed and refreshed centrally. Hybrid It has been accepted that when many independent data marts exist without a common architecture, it later becomes very difficult to create a single enterprise data warehouse. It is also known that building a full-blown, easy to use enterprise data warehouse is more risky and costly than a data mart. To increase the chances of putting a data warehouse in production within a reasonable time while minimizing efforts needed to have an enterprise data warehouse use a hybrid approach. Hybrid development is to develop independent data marts with a high-level enterprise data model in mind. In this approach, we inclusively design for the enterprise data warehouse and department data mart. The data mart is built first and the enterprise data warehouse follows. June 3,

260 Chapter 4: Architecture Methods Architecture and Special Initiatives Data Warehouse Architecture Data warehouse is not standalone; Data Warehouse Architecture describes a framework on how the data warehousing work and the components fit together. The data warehouse architecture is made up of a number of layers. At a high level view, data moves from the source systems to the staging area using functions provided as part of the data staging services layer. This flow is controlled by metadata maintained in the metadata repository: data that describes the locations and definitions of the sources and targets, data transformations, timing and dependencies. Once the data is combined and aligned in the staging area, the same data staging services are used to select, aggregate, and restructure the data into data warehouse, which is represented by the dotted frame in Figure Data Warehouse Architecture. Figure 4-8: Data Warehouse Architecture Figure Data Warehouse Architecture, Data Warehouse Architecture, where DM(SD) denotes data mart with summarized data and the dotted frame represents a single logical view of the data warehouse. The atomic data store could be modeled by using dimensional models or data models, while a data mart must use dimensional modeling. Data modeling will result in a 3NF relational database. If a bottom-up or hybrid design approach is adopted for Data Warehouse design, dimensional modeling is recommended, because it is almost impossible to integrate several 3NF relational databases into one. For a top-down approach, both model types will work. The reason is that a data model is data-oriented, as soon as all data are properly stored, the number and content of data marts could then be changed easily 4-58 EAPM Version 3.0