enterprise architecture process and methods handbook

Government of Ontario

Enterprise ArchitectureProcess & Methods Handbook

Version 3.0

June 3, 2005

Copyright Information: © Queen’s Printer for Ontario, 2005

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 4.4.1.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 best-practice processes, methods and tools used in the development of enterprise architecture.

ii EAPM Version 3.0

Contributors

Name Role Coordinates

L. C. (Skip) Lumley Principal author and editor Chartwell IRM Inc.

[email protected]

Ian Gilmour Contributing author Chartwell IRM Inc.

[email protected]

Estell MacKinnon Editor Chartwell IRM Inc.

[email protected]

Architecture Core Team Review

(ACT)Corporate Architecture Review

BranchCorporate Architecture Contributing author [email protected]

Peter ChurchardMike Knowles Contributing Author

IBM

Andrew Dudas Senior Technical Writer TAMBI Corporation

[email protected]

[email protected] Smart Standards and Architecture

[email protected]

Anthony (Tony) Brown Contributing Author Allstream IT Services

[email protected]@allstream.com

June 3, 2005 iii

mailto:[email protected]





Introduction to the EAPM HandbookOverview 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 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.

Knowledge Some knowledge is assumed as a pre-requisite for reading the Handbook. prerequisites 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

TABLE OF CONTENTS

CHAPTER 1: EA ARCHITECTURE FRAMEWORK ................................................... 1-1

1.1 Introduction to EA Frameworks ............................................................................1-21.1.1 Principles of Framework Definition .............................................................1-51.1.2 Overview of Framework Artifacts ................................................................1-6

1.2 EA Federated Frameworks ..................................................................................1-101.2.1 Vote and Item Architecture Frameworks.................................................... 1-211.2.2 The EA Meta-framework and Libraries ......................................................1-23

1.3 Managing Architectural Knowledge ....................................................................1-271.3.1 General Concepts of EA Development and Management ..........................1-291.3.2 Authoritative vs. Project Frameworks ........................................................1-341.3.3 Architecture Framework Maintenance .......................................................1-38

1.4 Access to Architecture Knowledge ......................................................................1-491.4.1 What Is Relevant Architecture Knowledge ................................................1-501.4.2 Use of Modeling Tools and Repositories ...................................................1-521.4.3 Architecture Maintenance ...........................................................................1-58

CHAPTER 2: INTRODUCTION TO OPS EA PROGRAM........................................... 2-1

2.1 The OPS EA Program Profile ................................................................................2-2

2.2 Architecture Services .............................................................................................2-52.2.1 Client Needs for Architecture Services ........................................................2-72.2.2 Architectural Policies & Standards Service ..................................................2-92.2.3 Enterprise Architecture Development Service .....................................2-142.2.4 Change Initiative Architecture Development Service ................................2-192.2.5 Architecture Education Service ..................................................................2-242.2.6 Architectural Consulting Service ................................................................2-292.2.7 Methods and Tools Service .........................................................................2-332.2.8 Architecture Review Service ......................................................................2-382.2.9 Repository Service ......................................................................................2-432.2.10 Reference Model Service ............................................................................2-472.2.11 Architect Certification Service ...................................................................2-522.2.12 Architecture Project Planning Service ........................................................2-56

2.3 Architecture Governance .....................................................................................2-602.3.1 Governance Parties and Roles ................................................................. 2-61

June 3, 2005 v

2.4 Corporate Architecture Governance ....................................................................2-652.4.1 Corporate Governanace Bodies ...................................................................2-672.4.2 Deputy Ministers’ Committee on OPS Transformation .............................2-692.4.3 Transformation Leadership Committee ......................................................2-712.4.4 I&IT Executive Leadership Council ...........................................................2-722.4.5 Information Technology Standards Council ...............................................2-732.4.6 Architecture Review Board ........................................................................2-752.4.7 Corporate Architecture Core Team (ACT) .................................................2-792.4.8 Business Architecture Domain WG ............................................................2-842.4.9 Information Architecture Domain WG .......................................................2-862.4.10 Application Architecture Domain WG .......................................................2-882.4.11 Technology Architecture Domain WG .......................................................2-892.4.12 Security Architecture Domain WG .............................................................2-902.4.13 EA Methodology WG .................................................................................2-92

2.5 Cluster Architecture Governance .........................................................................2-932.5.1 Cluster Governance Bodies .........................................................................2-942.5.2 Cluster Architecture Review Board (ARB) ................................................2-962.5.3 Cluster Architecture Core Team (ACT) .....................................................2-99

2.6 Artifact Creation and Approval Roles ...............................................................2-1022.6.1 Scope Artifact Roles (Row 1) ...................................................................2-1032.6.2 Conceptual Model Artifact Roles (Row 2) ...............................................2-1042.6.3 Logical Model Artifact Roles (Row 3) .....................................................2-1052.6.4 Physical Model Artifact Roles (Row 4) ....................................................2-1072.6.5 Component Artifact Model Roles (Row 5) ...............................................2-108

CHAPTER 3: ARCHITECTURE ROLES, RESPONSIBILITIES AND SKILLS .................. 3-1

3.1 Architecture Roles, Responsibilities and Skills ......................................................3-23.1.1 Enterprise Architect ......................................................................................3-33.1.2 Business Architect ........................................................................................3-63.1.3 Information Architect .................................................................................3-103.1.4 Application Architect ..................................................................................3-133.1.5 Technology Architect .................................................................................3-163.1.6 Security Architect .......................................................................................3-193.1.7 EA Methodologist .......................................................................................3-223.1.8 EA Repository Librarian .............................................................................3-25

CHAPTER 4: ARCHITECTURE METHODS .............................................................. 4-1

vi EAPM Version 3.0

4.1 Starting the Project ..................................................................................................4-24.1.1 Project Initiation ...........................................................................................4-34.1.2 Project Compliance Review Process ............................................................4-74.1.3 Standards Development ..............................................................................4-114.1.4 Reusable Components Development ..........................................................4-15

4.2 The Architecture Process ......................................................................................4-194.2.1 Definition of Architecture Process .............................................................4-204.2.2 Enterprise Architecture Starting Points ......................................................4-234.2.3 Enterprise Analysis and Planning ...............................................................4-264.2.4 Architecture & Project Lifecycles ..............................................................4-29

4.3 Planning and Architecture ....................................................................................4-314.3.1 Role of Project Architectural Planning .......................................................4-324.3.2 Determining Architectural Scope ...............................................................4-354.3.3 Business Case for Architectural Support ....................................................4-384.3.4 Statement of Architectural Work ................................................................4-43

4.4 Architecture and Special Initiatives ......................................................................4-514.4.1 Introduction to Data Warehouse Design and Architecture .........................4-524.4.2 What is a Data Warehouse? ........................................................................4-534.4.3 Data Warehouse Architecture .....................................................................4-58

CHAPTER 5: ARCHITECTURE PRINCIPLES ........................................................... 5-1

5.1 General Concepts ....................................................................................................5-25.1.1 General Concepts of Principles-Driven Architectures ..................................5-35.1.2 Object-oriented Models ................................................................................5-55.1.3 Templates and Patterns .................................................................................5-7

5.2 EA Principles ........................................................................................................5-125.2.1 Global Architecture Principles.................................................................... 5-145.2.2 Business Architecture Principles ................................................................5-165.2.3 Information Architecture Principles ...........................................................5-175.2.4 Application Architecture Principles ............................................................5-205.2.5 Technology Architecture Principles ...........................................................5-23

5.3 Security Architecture Principles ...........................................................................5-34

APPENDIX A: OPS EA GLOSSARY.........................................................APPENDIX-AAPPENDIX B: EAPM ACRONYMS ...........................................................APPENDIX-B

June 3, 2005 vii

viii EAPM Version 3.0

Chapter 1: EA Architecture Framework

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 (www.zifa.com).

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

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 semi-autonomous 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 meta-framework” 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, 2005 1-3


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.

❑

❑

❑


Principles of Framework Definition

1.1.1 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, 2005 1-5


1.1.2 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 pro-vided 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

❑

❑

❑

❑

❑

❑


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: ScopeThe 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-of-province 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, 2005 1-7


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.



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 tool-specific 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 EnterpriseThis 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, 2005 1-9

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 componentFederated architectures use common standards for design knowledge and have processes to integrate designs. Architecture frameworks are schema

❑

❑

❑

❑

❑



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 architectureFederated frameworks are multiple framework implementations to manage federated architectures.

OPS Enterprise The following figure identifies all categories of OPS EA knowledge and Architecture illustrates how it is classified and organized.Knowledge

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 FrameworkThe 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, 2005 1-11


“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 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.]

OPS Federated Framework

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.

OPS Corporate 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.

Vote Frameworks 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 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

Corporate Frameork

Cluster Frameworks



detailed explanation of public and internal programs, refer to the document Defining Programs and Services in the Ontario Public Service.

Change Initiative Frameworks

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.

Standards and Guide-lines Library

This library is a repository for publications such as GO IT Standards, EA best practices, etc.

Topics Library 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.]

Patterns, Templates and Reusable

Components Library

This library is a repository for elements of designs that may be reused as required, e.g., a client-server pattern.

Authoritative Artifacts 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, 2005 1-13


Explanation of Icons Used in the FFM Diagram

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.

Implications of the Federated Frameworks Approach

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).

Federated Frameworks Model Conventions

There are several conventions that explain the basic function and inter-relationship of the different types of frameworks in the Federated Framework Model.

First Convention - Accountability

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.



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, 2005 1-15


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.



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, 2005 1-17


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



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 GuidebookBusiness Architecture Domain Defining Programs and Services in the OPSInformation Architecture Domain Information Modeling Handbook for the OPSApplication Architecture Domain Application Architecture GuidebookTechnology Architecture Domain [Not yet available.]Security Architecture Domain [Not yet available.]

June 3, 2005 1-19


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.


Vote and Item Architecture Frameworks

1.2.1 Vote and Item Architecture Frameworks

Describes the concepts and use of Vote and Item Frameworks

Votes and Items 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.

Vote and Item Frameworks

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.

Programs 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.

EA Ownership and Custodianship

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, 2005 1-21


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.


The EA Meta-framework and Libraries

1.2.2 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 Meta-framework. 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, 2005 1-23


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.



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 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.

Patterns, Templates and Reusable Components Library

This library contains special forms of artifacts—patterns, templates and re-usable 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 re-occurring 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, 2005 1-25


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.

❑

❑

❑



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 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.

Artifacts 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, 2005 1-27

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 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 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 long-term 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.

Other 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.


General Concepts of EA Development and Management

1.3.1 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.

This section outlines the principles to be used in the operation of the Federated Frameworks Model.

Principle of Alignment

What is 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.

Alignment with Tar-get Architecture

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.

Design Alignment 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, 2005 1-29


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.

Principle of Integration

What is integration? 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.

How is integration achieved?

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.

Architectural Product Lifecycles

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.



Figure 1-9: Generic Architecture Product Lifecycle

States in the diagram

The following observations apply to the states in the diagram:

Created ❑

❑

❑

❑

❑

❑

❑

Architectural product construction has been commissioned by some party and designed by some partyIn 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.

Proposed The architecture product has been put forward for certification by at least one party, not necessarily the commissioning or creating partyThe 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’.

Generic Architectural Product Lifecycle

ReviseCommission (Next version)

Develop / Refine Approved

Created Endorse for

ReviseApproval De-

commissionSubmit for ReviseApproval Endorsed

Proposed

Propose forRetireApproval

Retired

Retire Retire

June 3, 2005 1-31


Endorsed ❑

❑

❑

❑

Agreement to the proposal for certification has been given by at least one party in addition to the proposing partyIn 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 partiesThis states reflects the intended final state of the product and documents its provenance and history.

Approved

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

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

Artifact Evolution

Created

Endorsed

Approved (‘Project Approved’)

Commission

Proposed

Retired

Develop / Refine

Revise

Revise (Next

version)

Revise

De-commission

Submit for Approval

Propose for Approval

Endorse forApproval

Retire

Retire

Created

Endorsed

Approved (“Authoritative’)

Commissioning

Proposed

Develop / Refine

Revise

Revise (Next

version)

Revise De-commissioningSubmit

forApproval

Propose for Approval

Endorse for Approval

Retire Retire

Project

Authoritative

Submit forAuthorization

Retire

Retire



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, 2005 1-33


1.3.2 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.

❑

❑


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, 2005 1-35


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.


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 Meta-framework) 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, 2005 1-37


1.3.3 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. CommissionF2. Submit for ApprovalF3. Propose for ApprovalF4. Endorse for ApprovalF5. Submit for AuthorizationF6. DecommissionF7. Retire

Artifact Management Processes:A1. CommissionA2. Submit for ApprovalA3. Propose for ApprovalA4. Endorse for ApprovalA5. Submit for AuthorizationA6. DecommissionA7. 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.


Architecture Framework Maintenance

Project Team Individual designers and architects developing artifacts in the project context.

Librarian Generic repository librarian role whose scope depends on the context of the scenario: project, cluster or corporate (enterprise).

Architecture Generic role that, depending on the Team context, applies project, cluster and/or

enterprise perspectives to evaluate an artifact’s architectural fit.

Endorser Generic role that represents a party endorsing the approval of an artifact, in a project, cluster or corporate context.

Approver 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, 2005 1-39


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



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

Artifact Creation Tool 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 OS File System (Currently Windows NT)

The file management tools supported by the Windows OS (including the security administration tool)

FSI Structure The repository tool selected by the OPS

June 3, 2005 1-41


Figure 1-19: Framework Lifecycle Management Scenario F2 – Submit Framework for Approval



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, 2005 1-43


Figure 1-22: Framework Lifecycle Management Scenario F5 – Endorse Framework for Approval



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, 2005 1-45


Figure 1-24: Artifact Lifecycle Management Scenario A2 – Submit Artifact for Approval

Figure 1-25: Artifact Lifecycle Management Scenario A3 – Propose Artifact for Approval



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, 2005 1-47


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.



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, 2005 1-49

Chapter 1: EA Architecture Framework—Access to Architecture Knowledge

1.4.1 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 reviewsShare 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

❑

❑

❑


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, 2005 1-51


1.4.2 Use of Modeling Tools and Repositories

Discusses the uses of and relationships between modeling tools and repositories

Synopsis 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.

Enterprise Architecture and Systems Development

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 Methodology

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:


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

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.

The Importance of Standard Elements in Design Artifacts

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.

The Importance of Standard Elements when Storing Designs

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, 2005 1-53


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

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).

The Multi-project Environment

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.

What the Modeling Tools Create

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.



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, 2005 1-55


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

EA Metamodeler EA Modeler

Designer

Meta-models

EnterpriseModels

Createenterprise

model

Createmetamodel

DesignData

DesignArtifacts

Create design

EnterpriseArchitectureRepository

Managerepository

EAR Librarian/Administrator

Design instance

EA Methodologist

Develop EAmethodology

Builder

Develop solution

"As built"Artifacts

ImplementedSolution

Subject Matter Expert

Provide subjectmatter advice

Standards Setter

Set standard



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 1-28.

June 3, 2005 1-57


1.4.3 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.]


Chapter 2: Introduction to OPS EA Program

Chapter 2: Introduction to OPS EA Program—The OPS EA Program Profile

2.1 The OPS EA Program ProfileCentre 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 The Enterprise Architecture Program (EAP) was conceived as part of the Information and Information Technology (I&IT) strategy for the Ontario Government in 1998. 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.

Program Outcomes

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.

Increased Alignment of Business and I&IT

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


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 Stake-holder of Assurance

of Success

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).

Increased Alignment of Change Initiative

Participants with Government Strate-

gies

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).

Greater Enterprise Design Knowledge

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.

Increased Change Design Competence

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.

Program Impacts The outcomes of the EAP have the following impacts on the function of the OPS as an enterprise.

June 3, 2005 2-3

Chapter 2: Introduction to OPS EA Program—The OPS EA Program Profile

Increased Enterprise Change Success

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.

Increased Enterprise Effectiveness, Effi-

ciency and Adaptive-ness

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.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 Service Description

Architectural Provide policies and standards that govern I&IT design and construction, Policies & and support business planning and design, jurisdictional scope, Standards conformance to Threat Risk Assessments and Privacy Impact Assessments,

and compliance with I&IT directives.

Tools & Methods 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.

Reference Model 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.

Architecture Education Curriculum Development

Provides architecture related education and training materials. This may include information, educational materials and/or training sessions.

Architecture Education Delivery

Provides architecture related education and training. This may include providing information, educational materials and/or training sessions.

Repository 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.

Architecture Review

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.

Change Initiative Architecture Development

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, 2005 2-5

Chapter 2: Introduction to OPS EA Program—Architecture Services

Enterprise Develops a target EA version that reflects the intended future state of the Architecture enterprise. This future state represents the intentions of the enterprise Development 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.

Architectural Provides advice for business and I&IT design. This includes Consulting recommendations, reports, referrals of qualified designers, etc.

Architecture Produces architectural project plans. This service assists change initiatives Project Planning in planning for architecture related activities.

Architect Certifies an architect as competent to create architecturally compliant design Certification models.


Client Needs for Architecture Services

2.2.1 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 The following table identifies and describes the groups of individuals within Population 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

A person accountable for conceiving an implementable change to a business component and documentating that change ina form that facilitates development.

Architect Includes enterprise architect and any domain architect, e.g., business architect, security architect, etc.

Designer Includes business designer and designer).

I&IT designer (system

Change Manager A manager accountable for an aspect of Initiative.

a Change

Change Initiative Manager

The manager accountable for Initiative.

the outcome of the Change

I&IT Planner/Policy Manager

The manager accountable for I&IT plans and policy (through the Change Initiative Manager).

Business Planner/Policy Manager

The manager accountable for business plans and policy (through the Change Initiative Manager).

Enterprise Component 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.

Program Manager A role within an organization outcomes of a program.

accountable for the

I&IT Service Manager A role within an organization accountable for outcomes of an I&IT Service.

the

Business Service Manager

A role within an organization accountable for outcomes of a Business Service.

the

Governor 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, 2005 2-7


Client Needs The EAP recognizes the following needs:

Enterprise Governor A person or institution to which an enterprise is accountable for its performance.

Business Governor A person or institution to which a business component an enterprise is accountable for its performance.

of

I&IT Governor A person to which an I&IT business component is accountable for its performance.

Change Initiative Governor

A person or institution to which a change initiative is accountable for its performance.

Architectural Educator Architectural Educator An individual who delivers an architectural education encounter.

Productivity: The need for outcomes

change designers to use minimal resources to achieve intended

Skill: The need for functions.

change designers to be able to perform particular tasks or

Knowledge: The need for change designers to understand their roles in the grater context of EA and OPS transformation.

Assurance:

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.

Alignment: The need for enterprise.

coordination of components to meet the outcomes of the

Adaptiveness: The need for readiness for change.

Integration The need to combine into a whole.

Accountability: The need to be able to measure performance on intended outcomes to meet the obligations of accountability.

Quality: The need for improved program and service quality.

Effectiveness: The need to achieve the intended outcomes of the enterprise.

Efficiency: The need to use minimal resources to achieve intended goals.


Architectural Policies & Standards Service

2.2.2 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 An authoritative standard or policy.

Service delivery Table 2-3 defines the events that trigger delivery of this service TService triggers 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

ProactiveResponse

Government or legislation change

Vote/Item (Program/Service) change

Organization change

Business partner change

Business policy, process or practice change

EAProgram

Initial architecture development

Architecture program event

Technology trends

Unpredictable Events

Audits

FOI request

Major crisis

June 3, 2005 2-9


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

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 measuresEstablish a structure for defining and publishing policies and standards Determine priorities for policies or standards development Commission projects to develop a proposed policy or standardEvaluate and approve a proposed policy or standardApprove or reject exceptions to a policy or standard Promulgate policy or standardIncorporate a new policy or standard into planning and project reviews Monitor compliance with policies and standardsReview policies and standards periodically for effectiveness Monitor service performance measures and achievement of goals.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

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, suppliersCorporate FOI, HR Stakeholders

Other stakeholder



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.

Corporate roles in service life cycle

activities

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

1 Common and shared principles, standards, guidelines, etc. Bold cells: Business-related principles, standards, guidelines, etc.

y

T

Age

nc

e I rd ners

at ate

etsc

Plan e

tsc st

Service Life Cycle C

rsne

das

tan ci

Cou

nl r

ito

FOIP

IP hivi

Activity

ITEL

AR

B

Crp

oro

Plan

Crp

oro

Arc

hit

IT S C

MB

Bus

A

rchi

t

Aud

Arc

Define service goals & performance measures A P A P

Establish a structure for defining and publishing A I P I A Ppolicies and standards

Determine priorities for policies and standards A P I I I A I I I Idevelopment

Commission projects develop policies and

to P1 I I I P1 I I I I

standard

Evaluate proposed policies and standards & approve A1 I P1 I A1 P1 I I I

Approve/reject exceptions to a policy or standard A P I I A I

Publicize policy and standard and incorporate P1 P1into reviews

Monitor compliance with policies and standards P1 P1 I

Review periodically effectiveness

for P1 P1 I

Monitor performance measures & achievement A P A P

June 3, 2005 2-11


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

Clu

ser

Ct

Os

I

Clu

ser

At

chite

cts

r

ster

Clu

IT P

lan

rsne

Clu

ser

At

BR

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 standardP1 I

Evaluate proposed policies and standards & approveP1 I A1

Approve/reject exceptions to a policy or standard I I

Publicize policy and standard and incorporate into reviewsP1

Monitor compliance with policies and standardsI P1

Review periodically for effectivenessI P1

Monitor performance measures & achievement I

1 Cluster-specific principles, standards, guidelines, etc.



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


AD

Ms

Bus

ines

s A

rea

Lead

ers

Bus

Pla

nner

s A

rchi

tect

s

Shar

ed P

ublic

Ser

vice

Pr

ovid

ers


Establish a structure for defining policies and standards

and publishing A P

Determine priorities for development

policies and standards A I I

Commission projects standard

to develop policies and P1 I I

Evaluate proposed policies and standards & approve A1 P1 I

Approve/reject exceptions to a policy or standard A I I

Publicize reviews

policy and standard and incorporate into P1

Monitor compliance with policies and standards P1 I

Review periodically for effectiveness P1 I


1 Cluster/business specific principles, standards, guidelines, etc. Bold cells: Business-related principles, standards, guidelines, etc.

June 3, 2005 2-13


2.2.3 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 A new target EA version. [Note: The ability to perform this service anywhere in the OPS is very limited at present.]

Service delivery triggers

Table 2-8 defines the events that trigger delivery of this service.

Table 2-8: Service delivery triggers for EA Development Service

Category EventMajor Trigger

Regular Trigger

Business (budget) planning cycleRoutine Response




Proactive Response



Organization change



EA ProgramInitial architecture development

Architecture program event.

Technology trends. .


Audits . FOI request . Major crisis .


Enterprise Architecture Development Service


Table 2-9 defines the parties that play various roles in the delivery of this service.

Table 2-9: A Development Service delivery roles

Legend:







❑

❑

❑

❑

❑

Define service goals and performance measuresDefine framework for EA development (i.e., EA Meta-framework) Determine priorities for EA development Commission projects to develop EAHarvest reusable models from ongoing projects and other EAs

Role

Corporate level

Cluster level

Project level

Vote/Item & external level

Client Architects Planners

Business planner & designers


Partner IT Planners IT Architects IT Planners


Regulator (BS))

Regulator (IS)

Regulator (QS) ARB, ACT, ITSC, Auditors, Corporate FOI, HR Stakeholders

Shared risk suppliers

Other stakeholder

June 3, 2005 2-15


Promote, provide access and distribute EAsPerform gap analyses between target and “as is” architectures of selected enterprises and Define and scope change initiatives needed to achieve target EAMonitor service performance measures and goal achievements.

❑

❑

❑


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


activities

y

T

Age

nc

e I d

das

ners


ITE

LC

AR

B

Cor

pora

tP

lann

ers

Cor

pora

te s

Arc

hite

ct

SIT

ta

nr

Cou

ncil

MB

C

Bus

Pla

n sA

rchi

tect

Aud

itor

FOIP

IP

Arc

hivi

st

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 P1 I I P1 I I I I

Harvest reusable models from ongoing projects and other EAs I P1 I

Promote, provide access & distribute components P1 P1

Perform gap analyses between target and “as is” architectures of selected enterprises and Define Pand scope change initiatives needed to achieve target EAMonitor performance achievements

measures & A P A P


Enterprise Architecture Development Service


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

. .

itts

ec

CIO

s

Clu

ster

IT

AR

B


Clu

ster

Clu

ste

hr A

rc sP

lann

er

Clu

ster

Define service goals and performance measures I

Define framework for EA development I I

Determine priorities for EA development I

Commission projects to develop EAs P1 I

Harvest reusable models from ongoing projects and other EAs P1

Promote, provide access & distribute EAs P1

Perform gap analyses between target and “as is” architectures of selected enterprises and Define and Pscope change initiatives needed to achieve target EA

Monitor performance measures & achievements I

1 Cluster-specific principles, standards, guidelines, etc.

Ministry roles in ser-vice life cycle activi-

ties

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.


AD

Ms

Bus

ines

s A

rea

Lead

ers

Bus

Pla

nner

s A

rchi

tect

s

Sha

red

Pub

lic

Ser

vice

Pro

vide

rs


Define framework for EA development A P

Determine priorities for EA development A I I

Commission projects to develop EAs P1 I I

Harvest reusable other EAs

models from ongoing projects and I

Promote, provide access & distribute EAs P1

June 3, 2005 2-17


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

Perform gap analyses between target and “as is” architectures of selected enterprises and Define and scope change initiatives needed to achieve target EA?

P


s

mitt

ee

m s

Co er ants

rtrs


Pro

ject

Ste

erin

g

ect

nage

rsP

roj

Ma

Pro

ject

s

Arc

hite

ct

Bus

ines

s E

xper

ts

stem

s S

yD

evel

op

Ext

erna

l Con

sult

Sha

red

Ris

k P

ane

Define service goals and performance measures

Define framework for EA development

Determine priorities for EAdevelopment

Commission projects to develop EAs

Harvest reusable models from projects and other EAs

ongoing I I I I I

Promote, provide access & 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 performance measures & achievements


Change Initiative Architecture Development Service

2.2.4 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.


Service output A new change initiative architecture version.



Table 2-14: Service delivery triggers in the Change Initiative Architecture Development Service

Category

Event

Major Trigger

Regular Trigger

Routine R Response





E F

Routine Response



Organization change



EA Program



Technology trends.

UnpredictableEvents

Audits

FOI request

Major crisis

June 3, 2005 2-19



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

Legend:



IS = Alignment with corporate I&IT strategiesQS = 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)



Define service goals and performance measuresDetermine design methods, disciplines and tools to use on each projectPrepare business or I&IT designsMonitor service performance measures and achievement of goals.

❑

❑

❑

❑

Corporate Cluster Project Core business & Role level level level external levelClient 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) ARB

Other stakeholder




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.


activities

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

Bold cells: Business-related principles, standards and guidelines


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

e IT

ds

Age

ncy

at s e at

st dar

nner

s st t

orr

ne or ec an Pla ec P

ITE

LCService Life Cycle A

RB

Cor

pP

lan

Cor

pA

rchi

t tSC

ounc

il

MB

C

Bus

A

rchi

t

Aud

itor

IPI

FO Arc

hivi

s

Activity IT

Define service goals and performance A P A Pmeasures

Determine design methods, disciplines & tools

I I I

Prepare designs I I I


A P A P

ct

s hite

O

Clu

ster

IT

Clu

ster

AR

B

er C

I

r Arc

Pla

nner

s

ts se

st


Clu

Clu

Define service goals and performance Imeasures

June 3, 2005 2-21


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

Determine design methods, disciplines & tools I I

Prepare designs I I


blic

s

ider

Are

a

vic

e P

ro

rs

nner

s

Pu

s es

ade Pla

Arc

hite

cst

ed

AD

Ms

Bus

in

Bus

Sha

r vS

erService Life Cycle Activity Le


Determine design methods, disciplines & tools I

Prepare designs I *


*Role depends on contractual relationships Bold cells: Business-related principles, standards, guidelines, etc.




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

* Role depends on contractual relationships

r st t oper

s

nsu

ants

lt

ing ge

s

tec

per

eer s na

Arc

hi

Dev

el

Sha

red

Ris

k

tSe

Ma

Bus

ines

s E

xs

s

Ext

erna

l Co

s

ect

mitt

e

ect ct

stem

r


Pro

jC

om

Pro

j

Pro

je

Sy

nP

art

e


Determine design methods, disciplines I P I& tools

Prepare designs I P P I * *


June 3, 2005 2-23


2.2.5 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)


Service outputs 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

Major Regular Category Event Trigger Trigger

Routine Business (budget) planning cycle Response




Proactive Government or legislation Response change


Organization change



EA Initial architecture development Program


Technology trends

Unpredictabl Audits e Events

FOI request


Architecture Education Service



Table 2-21: Architecture Education Service delivery roles

Legend:





Service life cycleactivities


Define service goals and performance measuresCarry out general environmental scanning for emerging business and automation design techniquesPrioritize research into new business and automation design innovations

❑

❑

❑

Role

Corporate level

Cluster level

Project level

Core business & external level

Client ITELC, ARB, CIPMC, IT Planners, ACT, PMA, ITSC, Auditor, Corporate FOI, HR Stakeholders

Cluster management team, Business planners, IT Architects, Cluster ARB

Project steering committee, Project managers, Architects, Project staff

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

June 3, 2005 2-25


Conduct research into new business and automation design techniquesConduct awareness programs on emerging business and automation design techniquesPrioritize architectural training needsDevelop architectural training coursesPromote architectural training courses Conduct architectural training coursesMonitor 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 Education Service. Parties at the project level are clients of this service but do not play active roles in the delivery of this service.


activities

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

Cor

pora

te IT

rs e

Age

n

dd

aa

rn

s

orat

e ec

ts nnrs

B

uP

la ects

r vist

Service Life Cycle CIT

EL

AR

B

lan

e

Cor

pt

Arc

hi Stn

unC

oci

l

MB

C s t

Arc

hi

Aud

ito IPIP

FO

chi

Activity P IT

Ar

Define service goals & performance A A I P A Pmeasures

Scan for emerging design techniques I P P

Prioritize research design innovations

on A A I P A P

Research new design techniques I P P

Conduct awareness programs on design I P P

Prioritize architectural training needs A A I P A P

Develop architectural training courses I P P


Architecture Education Service


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

Promote & conduct architectural courses I P P

Monitor performance measures & A I P A Pachievement

sct

IOs

chite

B

Clu

ster

Ar

Clu

ster

IT

nnrse

Service Life Cycle Activity C

lute

r Cs

Pla

Clu

ter A

Rs

Define service goals & performance measures I IScan for emerging design techniques I IPrioritize research on design innovationsResearch new design techniques I IConduct awareness programs on design I IPrioritize architectural training needs I IDevelop architectural training courses I IPromote & conduct architectural courses I IMonitor performance measures & achievement

I I

June 3, 2005 2-27



ties

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

ers

ea

lic idv

Ar r

nes

Sha

rP

ub

ss

Bu

Pla

n cs

et

ed e P

ro


AD

Ms

sine

Bu

ders

Lea s

Arc

hit

Ser

vic

Define service goals & performance measures IScan for emerging design techniques IPrioritize research on design innovations IResearch new design techniques IConduct awareness programs on design IPrioritize architectural training needs IDevelop architectural training courses IPromote & conduct architectural courses IMonitor performance measures & achievement

I


Architectural Consulting Service

2.2.6 Architectural Consulting Service

Provides advice for business and I&IT design. This includes recommendations, reports, referrals of qualified designers, etc.


Service output An advisory encounter.



Table 2-25: Service delivery triggers for the Architectural Consulting Service

Category

Event

Major Trigger

Regular Trigger

Routine R Response





R Proactive Response

Government or change

legislation


Organization change



E EA Program



Technology trends

UnpredictableEvent

Audits

FOI request

Major crisis

June 3, 2005 2-29




Table 2-26: Architectural Consulting Service delivery roles

Legend:







Define service goals and performance measuresForecast requirements for business and automation design skillsMaintain roster of architects with qualified architectural skillsNegotiate agreements with clients to provide architectural skills for limited periodsManage provision of services to clients and administer terms of agreement 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 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.

Role

Corporate level

Cluster level

Project 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


Architectural Consulting Service


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

y

T r

Age

nc

e I

Cor

pora

te s

dd

s a

ar nes

s

oatr rse il

Pla

n r

ivt

is

LC B nn

ect

hit

Stn

nc

MB

C s ec

thi

t ito

Service Life Cycle Activity ITE

AR r

Co

pP

la

Arc

IT

Cou

Bu

Arc

Aud

FOIP

IP

Arc

h

Define service goals & performance measures A P A P

Forecast requirements for design skills 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, 2005 2-31



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

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 C

lust

er C

IOs

Clu

ster

Arc

hite

cts

Clu

ster

IT

Pla

nner

s

Clu

ster

AR

B


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


Service Life Cycle Activity A

DM

s

Bus

ines

s A

rea

Lead

ers

Bus

Pla

nner

s A

rchi

tect

s

Sha

red

Pub

lic

Ser

vice

Pro

vide

rs


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



Methods and Tools Service

2.2.7 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.


Service output An approved architecture too or method.



Table 2-30: Service delivery triggers for the Methods and Tools Service

Category

Event

Major Trigger

Regular Trigger

Routine R Response





ProactiveResponse


legislation


Organization change


Business policy, process or practice change P

EA Program



Technology trends P P

UnpredictableEvent

Audits

FOI request

Major crisis

June 3, 2005 2-33




Table 2-31: Methods and Tools Service delivery roles Methods and Tools Service delivery roles

Legend:





Service life cycle activities This architectural service requires the following activities in its value chain or

life cycle:

Define service goals and performance measuresEvaluate 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 toolsProvide support to users of approved methods, disciplines and toolsConduct assessments of design methods, disciplines and tools proposed for use on projectsMonitor service performance measures and achievement of goals.

❑

❑

❑

❑

❑

❑

❑


Cluster level

Project level


Client Project architects, Project staff


Partner IT Architects Shared risk suppliers, Suppliers

Regulator (PR)

ITELC

Regulator (BS))Regulator (IS)Regulator (QS)

ARB

Other stakeholder




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.


activities

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

y

T s ers nc

e I

Cor

pora

te d n

Cor

pora

tne

rs ct il

Pla

n ct

IP A

ge

Arc

hivi

st

Service Life Cycle ActivityIT

ELC

AR

B

Pla

n

Arc

hite

s

IT

tand

arS

Cou

nc

MB

C

Bus

A

rchi

tes

Aud

itor

FOIP

Define service goals & performance measures A I P P

Evaluate & select design methods & disciplines I P P

Evaluate & select design tools A I P A P

Maintain & distribute methods, disciplines & tools I P P

Support users of approved methods, disciplines & tools I P P

Assess methods, disciplines & tools proposed for projects A I P A P

Monitor performance measures & achievement I P P

June 3, 2005 2-35



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


Clu

ster

CIO

s

Clu

ster

Arc

hite

cts

Clu

ster

IT P

lann

ers

Clu

ster

AR

B

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




ties

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


AD

Ms

Bus

ines

s A

rea

Lead

ers

Bus

Pla

nner

s A

rchi

tect

s

Sha

red

Pub

lic

Ser

vice

Pro

vide

rs

Define service goals & performance measures . . I. .

Evaluate & select design methods & disciplines . . I. .

Evaluate & select design tools . . I. .

Maintain & distribute methods, disciplines & tools

. . I. .

Support users of approved methods, disciplines & tools

. . I. .

Assess methods, disciplines, tools proposed for projects

. . I. .

Monitor performance measures & achievement . . I. .

June 3, 2005 2-37


2.2.8 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.


Service output A compliance assessment.



Table 2-35: Service delivery triggers for Architecture Review Service

Category EventMajor

TriggerRegular Trigger

Routine R Response





ProactiveR Response



Organization change



EAR Program



Technology trends.

Unpredictable Event

Audits

FOI request

Major crisis


Architecture Review Service

Service delivery roles Table 2-36 defines the parties that play various roles in the delivery of this service.

Table 2-36: Architecture Review Service delivery roles

Legend:





† 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)

Role

Corporate level

Cluster level

Project level


Client Cluster Business management team management (MBS)* team°

Provider IT Architects** IT Architects†

Partner IT Planners, IT Architects†

IT Planners†


Regulator (BS))

ITELC*, 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

June 3, 2005 2-39




Define service goals and performance measuresAssess business and automation plansCategorize projects (Common, Shared, Local)Commission change initiative framework for designated projects (based on the scope of business or I&IT integration required)Review business designsReview technical designsAdopt approved design elements as authoritativeAudit constructed componentsMonitor 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 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.


activities

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


ITE

LC

AR

B

Cor

pora

te IT

P

lann

ers

Cor

pora

te

Arc

hite

cts

IT S

tand

ards

C

ounc

il

MB

C

Bus

Pla

nner

s A

rchi

tect

s

Aud

itor

FOIP

IP A

genc

y

Arc

hivi

stDefine service goals & performance A I P A Pmeasures

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 A1 I P1 A1 P1


Architecture Review Service


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

Review business design I I I A1 P1 I I I

Review technical design A1 I P1 I I I I

Adopt approved design elements authoritative

as P I

Audit constructed components I I P

Monitor performance measures & achievement

A I P A P


Clu

ster

CIO

s

Clu

ster

A

rchi

tect

s

Clu

ster

IT

Pla

nner

s

Clu

ster

AR

B


Assess business & automation plans A I P

Categorize projects: shared, local

common, I I I I

Commission framework for designated projects P1 I A1

Review business design I I I

Review technical design P1 A1

Adopt approved design elements as authoritative I

Audit constructed components I I


June 3, 2005 2-41



ties

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


AD

Ms

Bus

ines

s A

rea

Lead

ers

Bus

ines

s P

lann

ers

Arc

hite

cts

Sha

red

Pub

licS

ervi

ce


Assess business & automation plans A P I

Categorize projects: shared, local

common, I I

Commission framework for designated projects

I I

Review business design A1 P1 I

Review technical design I

Adopt approved design elements as authoritative I

Audit constructed components I



Repository Service

2.2.9 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.


Service output An artifact version.



Table 2-40: Service delivery triggers for Architecture Review Service

Category EventMajor


Routine R Response

Business (budget) cycle

planning




ProactiveR Response


legislation


Organization change



EAR Program



Technology trends.

Unpredictable Event

Audits

FOI request

Major crisis

June 3, 2005 2-43


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

Legend:





† 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)

Role

Corporate level

Cluster level

Project level


ClientCluster management team (MBS)*

Business management team°

Provider IT Architects** IT Architects†

Partner IT Planners, IT Architects† IT Planners†


Regulator (BS)) ITELC*,

Cluster management team†

Cluster management

Regulator (IS) ITELC**, ARB team†, Cluster management team†

ITELC**, ARB,

Regulator (QS) ACT, Auditors, Corporate FOI, HR Cluster ARB†

Stakeholders

Other stakeholder


Repository Service



Define service goals and performance measuresEvaluate and select a suitable repository toolInstall and operate EA repositoryProvide training for users and support staffProvide support to usersMonitor service performance measures and achievement of goals.

❑

❑

❑

❑

❑

❑


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.


activities

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


ITE

LC

AR

B

Cor

pora

te IT

P

lann

ers

Cor

pora

te

Arc

hite

cts

IT S

tand

ards

C

ounc

il

MB

C

Bus

Pla

nner

s A

rchi

tect

s

Aud

itor

FOIP

IP A

genc

y

Arc

hivi

st

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, 2005 2-45



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


ties

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


Clu

ster

C

IOs

Clu

ster

A

rchi

tect

s

Clu

ster

IT

Pla

nner

s

Clu

ster

A

RB


Evaluate and select a suitable repository tool A I P

Install and operate EA repository P

Provide training for users and support staff P

Provide support to users P

Monitor performance measures & achievement P

a

bli

Pu

c

Bus

ines

s A

re

t s rse es ne

rsA

rchi

tec

s

ce


AD

M adLe B

usin

sP

lan

Sha

red

Ser

viDefine 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



Reference Model Service

2.2.10 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.


Service output A new version of a reference model.



Table 2-45: Service delivery triggers for the Reference Model Service

Category EventMajor


Routine Response





ProactiveResponse



Organization change



EAProgram



Technology trends.

UnpredictableEvents

Audits

FOI request

Major crisis

June 3, 2005 2-47




Table 2-46: Reference Models Service delivery roles

Legend:







Define service goals and performance measuresIdentify requirement for new reference model versionDesign new reference model versionApprove new reference model versionPublish new reference model version in repositoryLife-cycle manage reference modelMonitor service performance measures and goal achievements.

❑

❑

❑

❑

❑

❑

❑


Parties at the corporate, cluster, ministry and project levels may play prime, involved, or approver roles in the activities of the Reference Model Service.


Cluster level

Project level


Client IT Planners IT Planners Architects,Project staff


Provider IT Architects IT Architects ArchitectsPartner

IT Architects

Regulator (PR) ITELCRegulator (BS))Regulator (IS)Regulator (QS) ARB Cluster ARBOther stakeholder




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

y

Age

nc

e IT

Cor

pora

te d

das

anr ne

rs

ct l

Bu

Pla

n ct t

Service Life Cycle LC B

orat

Cor

p nner

s

Arc

hite

s

Stnc

i

MB

C s A

rchi

tes

itor

FOIP

IP

Arc

hs

ivi

Activity

ITE

AR

Pla

IT

Cou

Aud

Define service goals and performance A P PmeasuresIdentify requirement for new reference P Imodel versionDesign new reference model version P I

Approve new reference model A I I IversionPublish new reference model version in PrepositoryLife-cycle manage reference model P I

Monitor performance measures & A P Iachievements

June 3, 2005 2-49



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


ties

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.

. .

s

s

C

IOs

Clu

ster

hite

ct A

rc

Clu

ster

er IT

Pla

nn

AR

B


Clu

ster

Clu

ster

Define service goals and performance measures . P. . .

Identify requirement for new reference version

model . 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.

rs

ovid

e

Are

a s ne

rs Pub

lic

s n

Ser

vice

Pr


AD

Ms

Bus

ines

Lead

ers

Bus

Pla

tA

rchi

tec

Sha

red

Define service goals and performance Imeasures

Identify requirement for new reference version

model P

Design new reference model version I I

Approve new reference model version I I




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

Publish new reference model version in repository

Life-cycle manage reference model


Service Life Cycle Activity P

roje

ct S

teer

ing

Com

mitt

ees

Pro

ject

Man

ager

s

Pro

ject

Arc

hite

cts

Bus

ines

s E

xper

ts

Sys

tem

s D

evel

oper

s

Ext

erna

l C

onsu

ltant

s

Sha

red

Ris

k P

artn

ers


Identify requirement for new reference model version

Design new reference model version I P I P P P

Approve new reference model version

Publish new reference model version in repository

Promote, provide access & distribute EAs


June 3, 2005 2-51


2.2.11 Architect Certification Service

Certifies an architect as competent to create architecturally compliant design models.


Service output A period of certification of architectural competence.



Table 2-51: Service delivery triggers for the Architect Certification Service

Category Event Major Trigger

Regular Trigger

Routine Response Business (budget) planning cycle


IT project milestone


Proactive Response


Vote/Item change

(Program/Service)

Origination change



EA Program Initial architecture development


Technology trends


Audits

FOI request

Major crisis


Architect Certification Service



Table 2-52: Architecture Certification Service delivery roles

Legend:







Define service goals and performance measuresIdentify architect certification needConduct architect assessmentIssue architect certificationMonitor service performance measures and achievement of goals.

❑

❑

❑

❑

❑

Role

Corporate level

Cluster level

Project 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 (BS))

Regulator (IS)

Regulator (QS) ARB

Other stakeholder

June 3, 2005 2-53



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.


activities

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

yc

ers

en

e te

t

aar

ds

tnd

t

P A

g

Arc

hivi

st

Cor

pora

tIT

rP

lann

es

oar

Arc

hite

cs

Pla

nnA

rchi

tec

s

Service Life Cycle

ITE

LC

AR

B SC

ounc

il

MB

C

Bus

Aud

itor

FOIP

I

Activity Cor

p

IT

Define service goals & performance A P Pmeasures

Identify architect certification need P P

Conduct architect assessment P P

Issue architect certification P I I

Monitor performance measures & achievement

A P P


Architect Certification Service


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


ties

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


Clu

ster

CIO

s

Clu

ster

Arc

hite

cts

Clu

ster

IT P

lann

ers

Clu

ster

AR

B


Identify architect certification need I I

Conduct architect assessment I I

Issue architect certification I I


Service Life Cycle Activity A

DM

s

Bus

ines

s A

rea

Lead

ers

Bus

Pla

nner

s A

rchi

tect

s

Sha

red

Pub

lic

Ser

vice

Pro

vide

rs


Identify architect certification need I

Conduct architect assessment I

Issue architect certification I


June 3, 2005 2-55


2.2.12 Architecture Project Planning Service

Produces architectural project plans. This service assists change initiatives in planning for architecture related activities.


Service output An architectural project plan.



Table 2-56: Service delivery triggers for the Architecture Project Planning Service

Category EventMajor


Routine Response





ProactiveResponse



Organization change



EAProgram



Technology trends.

UnpredictableEvents

Audits

FOI request

Major crisis


Architecture Project Planning Service



Table 2-57: Architecture Project Planning Service delivery roles

Legend:






This architectural service requires the following activities in its value chain orlife cycle:

Define service goals and performance measuresIdentify requirement for new architectural project planProvide procedural adviceApprove architectural project planMonitor service performance measures and goal achievements.

❑

❑

❑

❑

❑


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.


activities

Table 2-58 summarizes the roles played by corporate parties in the activities of the Architecture Project Planning Service.


Cluster level

Project level


Client IT Planners IT Planners Architects,Project staff


Provider IT Architects IT Architects ArchitectsPartner

IT Architects

Regulator (PR) ITELCRegulator (BS))Regulator (IS)Regulator (QS) ARB Cluster ARBOther stakeholder

June 3, 2005 2-57


Table 2-58: Corporate role in lifecycle activities in the Architecture Project Planning Service


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

y

Cor

pora

te IT

rs

IPIP

Age

nc

dard

s

ne

r atC

orpo

re

ct l ct

Service Life Cycle LC B nes

Arc

hite

s

an cin C sla

nB

u P

Arc

hite

s

itor st

hivi

Activity

ITE

AR

Pla

n

IT S

tC

ou

MB

Aud

FO Arc

Define service goals and performance measures A P P

Identify requirement for new architectural project P Iplan

Provide procedural advice P I

Approve architectural project plan A I

Monitor performance measures & achievements A P I

. . ct

Pla

nner

s


Clu

ster

CIO

s

Clu

ster

Arc

hite

s

Clu

ster

IT

Clu

ster

AR

B

Define service goals and performance measures P

Identify requirement for new architectural project plan P

Provide procedural advice PApprove architectural project plan P

Monitor performance measures & achievements I P




ties

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


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

rs

a ide

sine

ss A

re rs

e

lic

Sha

rP

ub ov

nB

uP

lan P

r

ser ec

ts

ed

ce

Service Life Cycle Activity MA

Ds

Bu

dLe

a s t

Arc

hi rvi

Se


Identify requirement for plan

new architectural project P

Provide procedural advice I

Approve architectural project plan I



Pro

ject

Ste

erin

g C

omm

ittee

s

Pro

ject

Man

ager

s

Pro

ject

Arc

hite

cts

Bus

ines

s E

xper

ts

Sys

tem

s D

evel

oper

s

Ext

erna

l C

onsu

ltant

s

Sha

red

Ris

k P

artn

ers


Identify requirement for new architectural project plan P I I I I

Provide procedural advice

Approve architectural project plan


I

June 3, 2005 2-59

Chapter 2: Introduction to OPS EA Program—Architecture Governance

2.3 Architecture Governance

This section presents the following topic areas:

2.3.1 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.



2.3.1 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 levelCluster levelProject levelMinistry 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 rolesService 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 serviceUses the result of the serviceDirectly or indirectly receives the benefit of the service.

Service provider (P) 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 busi-ness partners (BP)

Service delivery business partners provide resources that contribute materially to the delivery of architectural services.

Other Stakeholder Other stakeholders have an accepted interest in the requirements or outcomes of the service.

June 3, 2005 2-61


Service governance roles

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.

Regulator or “gatekeeper”

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 strategyQS: Quality, best practice and other standards.

Service activity roles

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.

❑

❑

❑

Prime (P) or lead The organization or position has primary or lead responsibility for the execution of the activity.

Involved (I) 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.

Approver (A) The organization or position approves the deliverables generated by the activity. For example, the party might approve architectural artifacts.

Corporate level 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 organiza-tions 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 OfficerInformation Technology Executive Leadership Council (ITELC)Corporate Architecture Review Board (ARB)Corporate Architecture Core Team (ACT)Information Technology Standards Council (ITSC)Corporate Head architect

❑

❑

❑

❑

❑

❑

❑

❑



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 resourcesThe Transportation Cluster might be responsible for I&IT elements related to the management of the provincial highway networkThe 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

❑

❑

❑

❑

At a typical cluster level, the OPS EA Program involves the following organi-zations and positions that may play the roles of service provider, partner, cli-ent or regulator, depending upon the specific architectural service:.

Cluster Management TeamCluster Business Planner and DesignerCluster Head ArchitectCluster I&IT ArchitectsCluster Architecture Core teamCluster Architecture Review Board

❑

❑

❑

❑

❑

❑

Project level 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.

Project level organizations and

positions

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 CommitteeProject ManagerProject ArchitectProject Staff.

Ministry level 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 TeamsProgram Management TeamProgram Planner or DesignerShared Public Service Provider

❑

❑

❑

❑

❑

❑

❑

❑

June 3, 2005 2-63


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 SupplierSupplier

❑

❑



2.4 Corporate Architecture GovernanceThis section presents the following topic areas:Corporate Governance Bodies

2.4.1 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.

2.4.2 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

2.4.3 Transformation The Transformation Leadership Committee (TLC) supports the DMCOT.Leadership Committee

2.4.4 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.

2.4.5 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).

2.4.6 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.

2.4.7 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.

2.4.8 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

2.4.9 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.

2.4.10 Application The Application Architecture Domain Working Group (AADWG) provides

Domain Working OPS EA. It also champions the development of application architecture skills.Group

Architecture leadership in the review of the application architecture components of the

June 3, 2005 2-65

Chapter 2: Introduction to OPS EA Program—Corporate Architecture Governance

2.4.11 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

2.4.12 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

2.4.13 EA Methodology The EA Methodology Working Group (EAMWG) provides leadership in EA Working Group processes, methodology, standards and tools.



2.4.1 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, 2005 2-67


Cluster and project relationships

Review of corporate IT projects

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 standardsITSC for compliance with general I&IT standards.

❑

❑

Cluster governance bodies

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 standardsITSC 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

❑

❑


Deputy Ministers’ Committee on OPS Transformation

Jun

2.4.2 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 21st 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; andEnsure 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;

❑

❑

❑

❑

❑

❑

❑

❑

❑

e 3, 2005 2-69


Monitoring and enforcing of decisions that fit the above two categories; andEnsuring 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.

❑

❑


Transformation Leadership Committee

2.4.3 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; andOwning and steering change implementation of key initiatives.


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, 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; andOwning 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, 2005 2-71


2.4.4 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 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 organizationProvides 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; andApproves 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.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑


Information Technology Standards Council

2.4.5 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 Councilgovern and provide government-wide input into the standards review, development, adoption and approvals processcommunicate and promote approved technical standards outward to all I&IT stakeholdersadopt "open industry standards” developed by recognized open standards development organizations to maximize interoperability and access to data


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; andEngage the province in a more coordinated, proactive role in federal and international standards initiatives.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

June 3, 2005 2-73


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 http://intra.itsc.gov.on.ca/scripts/index_.asp.


Architecture Review Board

2.4.6 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; andApprove 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; orBusiness 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; andElimination 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, 2005 2-75


(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; andTo 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 BranchHead, ITSM and Change Management BranchHead, E-government BranchHead, Corporate Security BranchChairs 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

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑


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 clustersKey architecture issues Long range plan for I&IT StandardsEA Work PlanIT 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 exist-ing 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 mem-ber 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 dis-tributed 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, 2005 2-77


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:

Table 2-62: ARB Review and Approval Checklist

No. Check Point Purpose

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


Corporate Architecture Core Team (ACT)

2.4.7 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 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).

Mandate 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 Government�s 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; anddirect 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 cluster�s line of business(es);review any budgeting or resourcing requests; oranalyze or review of I&IT plan or business strategy.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

June 3, 2005 2-79



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.

ACT�s 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

Objectives 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;



● 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, 2005 2-81


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 rep-resent 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 mem-bers 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.



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:

Table 2-63: ACT/ARB Review and Approval Checklist

No. Check Point Purpose

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(proposed)

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, 2005 2-83


2.4.8 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 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.

Membership 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.


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, 2005 2-85


2.4.9 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

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.

Mandate 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


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, 2005 2-87


2.4.10 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

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.

Mandate 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.

Membership 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.

Governance The AADWG takes direction from ACT and is accountable for the activities it undertakes, to ACT.


Technology Architecture Domain WG

2.4.11 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

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.

Mandate 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, 2005 2-89


2.4.12 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

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.

Mandate 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.


Security Architecture Domain WG

Membership 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.

Governance The SADWG takes direction from ACT and is accountable for the activities it undertakes, to ACT.

June 3, 2005 2-91


2.4.13 EA Methodology WG

The EA Methodology Working Group (EAMWG) provides leadership in EA processes, methodology, standards and tools.

Definition of EA Methodology

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.

Mandate 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.

Membership 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.

Governance The EAMWG takes direction from ACT and is accountable for the activities it undertakes, to ACT.


EA Methodology WG

2.5 Cluster Architecture Governance


2.5.1 ClusterGovernance

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.

2.5.2 ClusterArchitecture

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 architecture function within the cluster. It is equivalent to the corporate-level ARB.

2.5.3 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 core businesses of the cluster. It is equivalent to the corporate-level ACT.

2.5.4 Roles andPosition

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, 2005 2-93

Chapter 2: Introduction to OPS EA Program—Cluster Architecture Governance

2.5.1 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 standardsITSC for compliance with general IT standards.


EA Methodology WG

Corporate and project relationships

Cluster I&IT projects may be referred by the cluster ARB or ACT (or equiva-lent) to their corporate counterparts for review. This could happen, for exam-ple, when:.

❑

❑

The designs and components of the cluster I&IT project are non-compliant with corporate architectural policies and standardsThe 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, 2005 2-95


2.5.2 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 corporate-level ARB.

Scope The Cluster ARB provides overall architecture direction for the cluster by:

Ensuring the alignment and integration of cluster initiatives with cluster goals and business strategiesEnsuring compliance of cluster initiatives with quality, best practices and standards in enterprise architecturePromoting reusable architecture components for systems design and constructionApproving major changes to cluster-level architectural elements.

Mandate The Cluster ARB mandate may include the following components:

Ensure alignment of cluster-based architectures with the OPS EA and its component architectural frameworksMonitor the compliance of cluster-level architectures with OPS-defined goals and measuresEnsure that projects affecting or leveraging common services and infrastructure are in alignment with the cluster architectureAct as the approval body for deliverables from the Cluster Architecture Core Team (or equivalent) and resolve any issues referred to it by the Cluster ACTAct 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.

Objectives The objectives of the Cluster ARB are to:

Provide leadership for the development of cluster-level architectural

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 valueDetermine which new I&IT trends should be examined to meet the requirements of the programs supported by the clusterEnsure compliance of project architectures with the OPS EACommunicate ARB decisions to the core businesses supported by the cluster.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

components


Cluster Architecture Review Board (ARB)

Membership The Cluster ARB may include the following members:Chair of the Information and Information Technology SubcommitteeAssistant Deputy Ministers or Directors from each divisionCluster Chief Information Officer (CIO)Lead Architect or Senior Manager, Planning & Architecture, (or equivalent) for the clusterHead Architect, Management Board SecretariatOther 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 QS*, IS*

EA Development QS*

Change Initiative Architecture Development

Architecture Education

Architect Certification QS

Tools & Methods

Architecture Review QS*, IS*

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

June 3, 2005 2-97


Operating procedures The following operating procedures are suggested for the operation of a Clus-ter 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.


Cluster Architecture Core Team (ACT)

2.5.3 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 levelGuiding the work of the domain and project architecture teams,Providing a forum for the resolution of architectural issuesReviewing projects for architectural complianceMaking 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 levelBusiness architecture, privacy and security, information architecture, application architecture and technology architectureThe effectiveness of the architecture functions in delivering the expected benefits and opportunities for improvementsEmerging 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 activitiesProvide input to the plans of the Lead Architect concerning orientation, training and promotion of architecture in the clusterAdvise the Head Architect, Management Board Secretariat, of emerging business initiatives and prioritiesLead all architectural processes where the cluster has responsibilityRepresent the interests of the cluster for all architectural processes where the corporate level (MBS) has responsibilityImplement enterprise architectural governance at the cluster level, including the effective initiation, operation and maintenance of cluster level architectural services.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

June 3, 2005 2-99


Objectives The objectives of the Cluster ACT may include:

Assure the quality of architectural components developed in cluster initiativesImplement, lead and support appropriate domain architecture working groupsCollaborate with the standards setting and governance process of the Information Technology Standards Committee through the cluster’s representative on the committeeWork 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 recommendationsHelp set skill requirements for the development and evolution of the enterprise architectureProvide a forum where business experts can ensure that the work of the cluster architects:Support the direction of ministry programs supported by the clusterAchieves the expected benefits of EAProvide a body of business experts who are sufficiently familiar with architectural issues to identify impacts and provide guidanceEnable identification of common business and technology issues and opportunities and provide strategies for addressing unique business and technology requirements effectivelyStrengthen 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

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.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

Head Architect for the Cluster (Chair)❑

❑

❑

❑

❑



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

Operating procedures The following procedures are suggested for the operation of a cluster ACT:

The ACT will meet monthly or as requiredIf 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.

❑

❑

❑

❑

Service Client Provider Partner Regulator Other Stakeholder

Architectural Policies & Standards QS*

EA Development QSChange Initiative Architecture DevelopmentArchitecture Education

Architect Certification Tools & Methods QSArchitecture Review QS*Repository QS*Architectural ConsultingReference ModelArchitecture 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, 2005 2-101

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.]

2.6.1 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.

2.6.2 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.

2.6.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 the services in defined by a given framework.

2.6.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.

2.6.5 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.



2.6.1 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

s

Bus

ines

s A

naly

st

Cell Service Frameworks Artifacts

Pro

gram

M

anag

er

Pol

icy

Ana

lyt /

P

rogr

am

Exe

cutiv

e M

anag

emen

t

Bus

ines

s A

rchi

tect

l wTe

chni

carit

er

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 ACross Reference I I L

1,4 Party Type

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 Cross Reference

and Cycle Type 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, 2005 2-103


2.6.2 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.


Cell

Service Frameworks Artifacts P

roje

ct M

anag

er

Pol

icy

Ana

lyst

/ P

rogr

am S

peci

alis

t

Exe

cutiv

e M

anag

emen

t

Bus

ines

s A

naly

st

Bus

ines

s A

rchi

tect

App

licat

ions

arc

hite

ct

Info

rmat

ion

arch

itect

2,1 Conceptual Data Model I I I A L

Semantic Model

2,2 Service Model

Value Chain Process A I L I I

Service Life Cycle

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



Logical Model Artifact Roles (Row 3)

2.6.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.


ner

t /

eia

list

hite

ct

atio

ns a

hite

ctrc ch

itect

chite

ct

ecia

list /

Cell


rogr

am M

aag

Pol

icy

Ana

lys

Pro

gram

Sp

c

Exe

cutiv

e M

anag

emen

t

ss A

nays

tB

usin

el

Bus

ines

s A

rc

App

lic

Tech

nolo

gy a

r

Info

rmat

ion

ar

Sec

urity

Sp

Pro

ject

Man

ager

Lead

er

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, 2005 2-105


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



Physical Model Artifact Roles (Row 4)

2.6.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


rogr

am M

anag

er

Dat

abas

e A

naly

st

DB

A A

dmin

istra

tor

Exe

cutiv

e M

anag

emen

t

Bus

ines

s A

naly

st

Bus

ines

s A

rchi

tect

App

licat

ions

arc

hite

ct

Sys

tem

Ana

lyst

Info

rmat

ion

arch

itect

Sec

urity

Spe

cial

ist

Pro

ject

Man

ager

/ Le

ader

4,1 Physical Data Model L,A I I I I

Database Design Model L I

Database Inventory I

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 Calenderized Schedule and States L I I,A

4,6 N/A


June 3, 2005 2-107


2.6.5 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


Pro

ject

Man

ager

/Lea

der

Dat

abas

e Ad

min

istra

tor

App

licat

ions

Arc

hite

ct

Service Frameworks

Pro

gram

mer

/Ana

lyst

Cell Artifacts

Info

rmat

ion

Arch

itect

Pro

gram

Man

age r

5,1 DDL Script L A

Pol

icy

Anal

yst o

r

Pro

gram

Spe

cial

ist

5,2 Trigger Code L I A E

xecu

tive

Man

agem

ent

Stored B

usin

ess

Arch

itect

Procedure I A L I Code

Sec

urity

Spe

cial

ist

S

yste

m A

naly

st

L – Lead, I – Involved, A – Approves B

usin

ess

Ana

lyst


Chapter 3:

Architecture Roles, Responsibilities and Skills

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 Architect3.1.2: Business Architect3.1.3: Information Architect3.1.4: Application Architect3.1.5: Technology Architect3.1.6: Security Architect3.1.7: EA Methodologist3.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

❑

❑

❑

❑

❑

❑

❑

❑


Enterprise Architect

3.1.1 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 General knowledge is same for senior enterprise architect and enterprise Responsibilities 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.


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, 2005 3-3

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:

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.

Contacts 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 [Note: The competencies will need to be profiled in the same way that the domain architect positions have been.]

❑

June 3, 2005 3-5

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 General knowledge is same for senior business architect and business Responsibilities architect (difference in skill-level/experience).

Senior Business Lead the development/establishment of principles, policies and standards Architect 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.


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, 2005 3-7

C

SE

KMBD

KO

OSP

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.

Contacts 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 Behaviouralompetency Proficiency Level Competency Proficiency Level Competency Proficiency Level

Sr. Arch Arch Sr. Arch Arch Sr. Arch Archervice xcellence

3 3 Enterprise Architecture

3 2 Commitment to Organizational Learning

3

nowledge anagement

3 2 Business Architecture

4 3 Impact and Influence

4

usiness Process 3 2 Business 2 2 Initiative 2esign Architecture

Effectiveness Measurement

nowledge of 4 2 Enterprise 4 2 Innovation 5rganization Business

Architecture Process and Methods

rganizational 4 3 System 3 2 Networking 4avvy and Development olitics Life Cycle for

Business Architecture

❑

❑

❑

❑

❑

■

■

3

3

2

3

2


Business Architect

BF

E

usiness 3 2 Product and 3 2 Planning, 4 2unctions Vendor Organizing and

Evaluation Coordination

-Business 2 1 Project 3 2 Problem Solving 4 3ManagementERP (Enterprise Resource

1 1 Strategic Thinking

4 3

Planning)Written Communications

4 3

June 3, 2005 3-9

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 General knowledge is same for senior information architect and business Responsibilities architect (difference in skill-level/experience).

Senior Information Provides strategic information architecture direction in projects and Architect 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.

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.

Information Architect 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.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

Manages the process of designing, developing and implementing


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

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.

requirements, develop recommendations, identify concerns and resolve problems.

❑

❑

❑

■

■

■

■

■

■

■

❑

❑

❑

June 3, 2005 3-11

C

SEKOBF

IK

KM

BJOS

Competencies The following competencies are required for the Information Architect Role:

Table 3-2: Information Architect Role competency requirements


Sr. Arch Arch Sr. Arch Arch Sr. Arch Archervice xcellence

3 2 Information Management

4 2 Problem Solving

4 3

nowledge of rganization

3 2 IT Architecture 3 2

usiness unctions

3 2 IT Standards, Procedures, Policies


3 2

ndustry nowledge

4 2 Modeling: Data, Process, Events, Objects

4 3 Networking 3 2

nowledge anagement

2 1 Data Administration

3 3 Concern for Quality and Standards

4 3

usiness Case ustification

2 1 IT Project Management

2 1 Strategic Thinking

3+ 3-

rganizational avvy

3 2 Database Structures

3 2

Database Warehousing

3 2

IT Industry: Trends & Directions

2 N/A

Emerging Technologies

2 N/A

Relational Databases

N/A 2

CASE Tools N/A 2


Application Architect

3.1.4 Application Architect

Describes the role of Application Architect.

Purpose of Role 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.

Major Responsibilities

Senior Application Leads the assessment, design and development of application Architect 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 re-usable 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,

Application Architect 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.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

service-oriented architecture).

June 3, 2005 3-13

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:

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;


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.

Contacts 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.

❑

❑

■

■

■

■

■

■

■

❑

❑

❑


Application Architect

C

CSBF

SE

KO

OSPPTS

Competencies The following competencies are required for the Application Architect Role:

Table 3-3: Application Architecture Role competency requirements


Sr. Arch Arch Sr. Arch Arch Sr. Arch Archore Application ystems


3 3 Problem Solving

4 3

usiness unctions

1 1 IT Standards, Policies, Procedures


3 2

ervice xcellence

2 3 Application Architecture, Design

4 3 Innovation 4 2

nowledge of rganization

2 1 (Impact of) Emerging Technologies

4 3 Networking 3 2

rganizational avvy and olitics

4 2 IT Environment 4 3 Strategic Thinking

3 3

lanning: actical and trategic

4 n/a Application Delivery Process

2 2 Planning, Organizing, and Coordinating

2 2

System Development Life Cycle

3 3 Written Communication

4 2

Application Development Tools

3 4

Systems Software Infrastructure

4 3

June 3, 2005 3-15

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 life-cycle considerations.


Senior Technology Promotes best practices for technology architecture in the OPS in order to Architect 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.

❑

❑

❑

❑

❑

❑

❑

❑

■

■

❑


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;


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, 2005 3-17

Co l

PlTaStSeEx

OSaPoInK

BuJuBuFuKO

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 Behaviouralmpetency Proficiency Level Competency Proficiency Level Competency Proficiency Leve

Sr. Arch Arch Sr. Arch Arch Sr. Arch Archanning: ctical and rategic

4 2Enterprise Architecture 4 3

Communicating Effectively 3 3

rvice cellence 4 2

IT Standards Policies and Procedures

4 3Innovation

4 2

rganizational vvy and litics

4 2Technology Architecture 4 3

Networking3 2

dustry nowledge 4 3

System & Technology Integration

4 2Problem Solving

4 3

siness Case stification

4 2 IT Environment 3 3 Strategic Thinking

3 3

siness nctions

3 1 Emerging Technologies

4 3Written Communications 4 2

nowledge of rganization 4 2

Infrastructure Development Tools

2 4

Infrastructure Development Life Cycle

3 3

Infrastructure Delivery Process

3 2

Infrastructure (Desktop/Server/Network)

4 3

❑

❑

❑


Security Architect

3.1.6 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 General knowledge is same for security architect and senior security architect. Responsibilities 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

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.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

issues.

June 3, 2005 3-19

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;

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.

Contacts 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.

❑

❑

❑

❑

■

■

■

■

■

❑

❑

❑

❑

❑


Security Architect

C

KO

RM

BFWD

OSPEIn

PJu

Competencies The following competencies are required for the Security Architect Role:

Table 3-5: Security Architect Role compency requirements


Sr. Arch Arch Sr. Arch Arch Sr. Arch Archnowledge of rganization 3 2

Security Architecture 4 3

Commitment to Organizational Learning

3 3

isk anagement 4 3

Enterprise Architecture Process and Methods

3 2 Concern for Image Impact 4 N/A

usiness unctions


3 2 Integrity N/A 2

riting/ ocumentation 4 2

IT Standards, Procedures, Policies

4 2 Networking 3 2

rganizational avvy and olitics

3 2Security Management 4 3

Planning, Organizing and Coordination

2 N/A

thics and tegrity 3 3

Legal Regulatory Environment – I&IT

3 2 Problem Solving 4 3

rofessional dgment

4 3

IT Industry: Trends, Directions and Emerging Technologies

4 2 Self-Confidence N/A 2

Network Architecture

2 2 Strategic Thinking 3 3

Product and Vendor Evaluation

4 3 Written Communications 4 3

June 3, 2005 3-21

3.1.7 EA Methodologist

Describes the role of EA Methodologist.

Purpose of Role 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,


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:

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

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.

Contacts 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, 2005 3-23

Co

Kn

OrPoKnOr

Se

Bu

BuJus

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

mpetency Proficiency Level

Competency Proficiency Level

Proficiency Level ProficiencyLevel

owledge Management 3 Enterprise Architecture Methodology

4 Problem Solving 4

ganizational Savvy and litics

3 Metadata Management 4 Coaching 2

owledge of ganization

4 Enterprise Architecture Effectiveness Measurement

3 Impact and Influence 4

rvice Excellence 3 IT Standards, Procedures, Policies

4 Commitment to Organizational Learning

3

siness Process Design 2 Modeling: Data, Process, Events, Objects

4 Initiative 4

siness Case tification

3 CASE Tools 3 Innovation 4

Application Delivery Process

2 Networking 4/5

Information Management 3 Strategic Thinking 4

IT Project Management 3

❑


EA Repository Librarian

3.1.8 EA Repository Librarian

Describes the role of Enterprise Architect.

Purpose of Role 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.

udgement 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:

J

June 3, 2005 3-25

C lKO

SeEx

KM

InLiOPoBFu

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.

Contacts 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 Behaviouralompetency Proficiency Level Competency Proficiency Level Competency Proficiency Levenowledge of Enterprise Commitment to rganization 2 Architecture 3 Organizational 3

Learningrvice cellence 3

Repository Metadata Management

4Concern for Quality and Standards

4

nowledge anagement 3

IT Standards, Procedures, Policies

3Drive to Results

Deliver 1

ternet, Intranet teracy

3 Information Management

2 Integrity 2

rg Savvy and litics

2 Document Management

2 Problem Solving 3

usiness nctions

2 Data Movement Tools

3 Teamwork 3

■

■

■

■

■

■

❑

❑

❑


EA Repository Librarian

BD

usiness Process Modeling: Data, Written esign 2 Process, Events, 2 Communications 3

ObjectsSystem 2Development Life CycleTraining Delivery 3

IT Environment 2

June 3, 2005 3-27

Chapter 4: Architecture Methods

Chapter 4: Architecture Methods—Starting the Project

4.1 Starting the Project This section presents the following topics:

4.1.1 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 projectestablishing roles and responsibilities for the architecture team vis-à-vis the development teamCheckpoint Zero

4.1.2 Project Compliance

Review Process

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.

4.1.3 Standards Development

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.

4.1.4 Reusable Components Development

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.

❑

❑

❑

❑


Project Initiation

4.1.1 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 architecturemaking use of existing architectural content to scope the projectestablishing roles and responsibilities for the architecture team vis-à-vis the development teamCheckpoint Zero

Developing The Ideal SituationProject Charters Ideally, in enterprises that have EA programs, projects should be defined and In the Context of scoped according to what analysis determines is needed to enable target EA 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, 2005 4-3


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

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.

the implications.

❑

❑

❑

❑

❑

❑

❑


Project Initiation

ImplicationsThe 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, Pri-vacy Impact Assessment, etc.

2. EA Deliverables – i.e., the mandatory and optional EA artifacts spec-ified 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 implementa-tions 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

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.

Architecture Teams versus Development Teams

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, 2005 4-5


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/Sub-contractor 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.


Project Compliance Review Process

4.1.2 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 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).

Criteria for architecture review

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

Cluster Architecture

ReviewCommon • Common data definitions & Infrastructure elements

• Common components• Base infrastructure

Enterprise Architecture

• New architecture developments• 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 & patternsinfrastructure • Shared applications

• Shared infrastructure• Shared services & patterns

June 3, 2005 4-7


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 archi-work tecture for the project that will ensure a good fit

with the sponsoring business area• Technology-specific architec-ture work • To assess potential for sharing information with

other organizations within and external to the OPS• Application-specific architec-ture 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

Program • Architectural non-compliance • Program • Opportunities for leverage applications

• CIO-requested review • Program infrastruc-ture

• Program data arch.


Project Compliance Review Process

** 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.

1. Project plan ••

•

Project Proposal or PlanProject Procurement Plan (RFPs for Services or Goods)Row 1 scope artifacts, particularly program and ser-vice 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

• Row 2 conceptual business design artifacts

• To certify the conceptual design is internally con-sistent and aligns with information, application, technology and security design principles, standards and methods.

3. Logical design

• Row 3 logical system design artifacts

• To certify the logical design is internally consistent and aligns with information, application, technol-ogy and security design principles, standards, and methods.

4. Physical Design**

• Row 4 physical system design artifacts

• To certify the physical design is internally consis-tent and aligns with logical information, applica-tion, technology and security standards and methods.

5. Implementa-tion**

•

•

Row 5 implementation artifactsDeployment plans

••

To review and approve implementation To ensure there are no unplanned circumstances that would adversely affect other corporate projects.

June 3, 2005 4-9


Figure 4-1: Checkpoint reviews


Standards Development

4.1.3 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.

❑

❑

❑

❑

❑

❑


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 coherenceprivacy and securityreliability and scalabilityreduce 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 formatsFunctional standards for product/technology selection to make available the seven capabilities (reliability, interoperability, scalability, portability, availability, security/privacy and flexibility)

June 3, 2005 4-11


Development standards with respect to methods (best practices) for application development and implementing code using specific protocols, API and data formatsArchitecture 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-by-case 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 http://intra.itsc.gov.on.ca/scripts/index_.asp - 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.

❑

❑

❑

❑

❑

❑



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 CouncilGovern and provide government-wide input into the standards review, development, adoption and approvals processCommunicate and promote approved technical standards outward to all I&IT stakeholdersAdopt “open industry standards” developed by recognized open standards development organizations to maximize interoperability and access to data

❑

❑

❑

❑


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; andEngage 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 http://intra.itsc.gov.on.ca/scripts/index_.asp

❑

❑

❑

❑

❑

❑

June 3, 2005 4-13


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.


Reusable Components Development

4.1.4 Reusable Components DevelopmentThis 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, 2005 4-15


ITS) and the TSKM, please go to the following URL: http://www.gov.on.ca/MBS/techstan or http://intra.itsc.gov.on.caArchitecture 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: http://cabdev.mbs.gov.on.ca/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: http://intra.eia.cio.gov.on.ca/MBS/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.

❑

❑

❑

❑


http://www.gov.on.ca/MBS/techstan/

http://www.gov.on.ca/MBS/techstan/

http://intra.itsc.gov.on.ca

http://cabdev.mbs.gov.on.ca/structurenet2001-msaccess/index.asp?DB=OPS_FF

http://cabdev.mbs.gov.on.ca/structurenet2001-msaccess/index.asp?DB=OPS_FF

http://intra.eia.cio.gov.on.ca/MBS/eia/frame00.nsf/Items/9CCC8FD389D045FC85256CB10075DA86?OpenDocument




Figure 4-2: Common application component shared infrastructure

INTERNET

GONET

iSER

V A

pplic

atio

n

iSE

RV

Inte

rnet

DM

ZiS

ER

V In

trane

t DM

ZFirewall

Firewall

Firewall

OracleDatabase

Server

WebSphereApplication

Server

Intranet WebServer

Internet WebServer

COMMON APPLICATION COMPONENT SHARED INFRASTRUCTURE

❑

❑

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, 2005 4-17


Figure 4-3: Common application component development workflow

I&IT ClustersCommon

ComponentAdvisory Team

AppliedTechnology

SolutionBranch

I&IT ClusterApplication

DevelopmentBranch

CommonComponent

Centre ofExcellence

iServ

CorporateACT/ARB

EA RepositoryLibrarian

ImpactAssessment

andPrioritization

- Log Request- Evaluate and Prepare Proposal for ITELC

Submit BusinessCase

(Is it a commoncomponent?)

Get Aprovalfrom ITELC

PrepareProjectCharter

ApproveProjectCharter

Complete:- Development Plan- Logical Models- Physical Models- PIA & TRA

Plan andDesignService

CommonComponentAcceptance

Approve Go-LivePlan

Prepare:- Servicecatalogue- SLAs

Final Approvalto Proceed

ObtainAuthoprization

from CCAB

KnowledgeTransferTraining

to CC-COE

Pre-production QualityAssurance

Update SLA with iServPrepare Go-Live Plan

Certification

Build & TestDocumentation:- Manuals- Run Books- iServ Manuals

Arrangewith iServto Go Live

Promote toProduction

Pre-developmentArchitecturalAssessment

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.2 The Architecture Process

This section presents the following topics:

4.2.1 Definition of the Architecture

Process

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.

4.2.2 Analysis in Zachman

Data gathering, analysis, and synthesis in the context of a Zachman Framework.

4.2.3 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.

4.2.4 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, 2005 4-19

Chapter 4: Architecture Methods—The Architecture Process

4.2.1 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 driversBusiness goalsBusiness policiesTrends analysis

Implementation includes the definition of:

Business processesApplication systemsTechnical infrastructureOrganizational structure

Enterprise architecture bridges between these two realms by specifying:

Business architectureInformation architectureApplication architectureTechnology architectureSecurity 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 strategiesI&IT requirements derived from those business driverstechnology, market and public trends to be accounted for

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑


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, 2005 4-21


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.


Enterprise Architecture Starting Points

4.2.2 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?

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.

Column 2 Artifacts (Rows 1 and 2) How will goals be achieved?

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, 2005 4-23


Column 1 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 2


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, 2005 4-25


4.2.3 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

Systems analysis, one of the functions of systems development, is a well-known 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.

Analyzing Models 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:


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

Service

A4

Goal A Objective A1 x x x Objective A2 x Objective A3 Objective A4 x x x x Objective A5 x x x xGoal B Objective B1 x x x x

Associate Processes with Information

Areas

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.

Associate Processes with Organizations

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.

Associate Processes with Locations

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.

Associate Processes with Existing Systems

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, 2005 4-27


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

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.

[Change Initiative Name]

[Change Initiative Description]

Includes Processes

[List of business processes involved in the change initiative.]

Involves Information

Areas

[List of information areas involved in the change initiative.]

Goals Supported

[List of goals to be supported enabled by the change initiative.]

Organizations Impacted

[List of organizations affected by the change initiative.]

Locations Impacted

[List of locations affected by the change initiative.]

Systems Impacted

[List of existing systems affected by the change initiative.]


Architecture & Project Lifecycles

4.2.4 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 detaildifficult 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 organizationminor 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, 2005 4-29


Architecture and the PMO

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.

Architecture “Just-in-Time”

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.

Architecture Approached from Two Directions

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.


Architecture & Project Lifecycles

4.3 Planning and ArchitectureThis section presents the following topics:

4.3.1 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.

4.3.2 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.

4.3.3 Business Case 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.

for ArchitecturalSupport

4.3.4 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, 2005 4-31

Chapter 4: Architecture Methods—Planning and Architecture

4.3.1 Role of Project Architectural PlanningThis 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

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.

Objectives 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).

❑

❑

❑

❑

❑

❑

❑

❑


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, 2005 4-33


Governance 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.

Activities An architectural scoping initiative may involve the following activities.

Identify architectural scope

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

This activity is defined in subsection 4.3.2.

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).

Define the statement of architectural work

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).

Schedule 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 weeksBusiness case development (see subsection 4.3.2): 2 to 4 weeksStatement of architectural work (see subsection 4.3.3): 2 to 4 weeks.

❑

❑

❑


Determining Architectural Scope

4.3.2 Determining Architectural ScopeArchitectural 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 servicesConceptual business model for service delivery

June 3, 2005 4-35


Logical models of the required information technology components.❑

Business vision for proposed conceptual

model (Row 2)

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).

Impact analysis of architecture on

project

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 initiativeTiming and major deliverables of project or initiativeLinkages and dependencies between target architecture and project or initiativesPreliminary analysis of the target architecture for the project and the current I&IT architecturePreliminary analysis of the risks to the project and related initiatives if the architecture is not availableBenefits derived by the project and related initiatives from the availability of an enterprise architecture.

Activities An architectural scoping initiative may involve the following activities.

❑

❑

❑

❑

❑

❑

Develop business vision & change

initiative framework

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.

❑

Analyze impact 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.


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, 2005 4-37


4.3.3 Business Case for Architectural SupportEffective 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 architectureIdentifying 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) architectureGap analysis between current and proposed architecturesCost benefit analysisRecommended migration strategiesProgram management approach.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑


Business Case for Architectural Support

Business vision: context and objectives

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.

Change initiative framework extensions

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 challengesCritical 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, 2005 4-39


Migration strategy optionsPreferred 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 architectureA 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 deployedRecommendations on how to actively manage the achievement of potential benefits as the target architecture is deployed.

Program management

approach

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 BPSProcurement 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 resourcesHR 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.

Activities The business case component of an architectural scoping initiative may involve the following activities.

Extend change initiative framework

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.


Business Case for Architectural Support

❑ Review the artifacts with the appropriate ACT, ARB and business sponsors.

Analyze gap between legacy and target

architectures

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 legacyarchitecture(s) and the target architecture Domain architects will analyze the gaps between the legacy and target architecturesDomain architects will review the gap analysis with the project sponsor and the appropriate governance bodies.

Create migration strategy

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 securedDocument the costs and benefits and calculate potential return on architectural investmentReview 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, 2005 4-41


Conduct program management workshop to identify recommended collaboration and governance strategies, procurement strategies, HR strategies and communications strategiesDocument 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.

❑

❑

❑


Statement of Architectural Work

4.3.4 Statement of Architectural WorkThe 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

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 projectEnsure that design deliverables are available on a timely basis for the success of the projectProvide the terms of reference in requests for proposals or resources for architectural design servicesGuide the migration of the legacy architecture to the target enterprise architecture.

Objectives 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 scopeWork breakdown structureResource roles and responsibilitiesWork schedule.

Statement of scope This deliverable defines deliverables, activities and responsibilities that are included or excluded from the scope of the architectural design work.

Work breakdown structure

This deliverable breaks down the architectural design work into a set of activities and deliverables.

Resource roles and responsibilities

This deliverable defines the resources required for architectural design support and specifies the responsibility of each role for provision of design deliverables.

Work schedule This deliverable schedules the activities in the work breakdown structure.

June 3, 2005 4-43


Typical WBS, roles and schedule

The balance of this subject describes the scope of each activity in a typical work breakdown structure and identifies resource roles and responsibilities.

Activity: Understand current architecture

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 ArchitectBusiness ArchitectApplication ArchitectInformation ArchitectTechnology ArchitectSecurity Architect



Activities ❑

❑

❑

❑

❑

❑

❑

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?

Deliverables For business architecture, scope artifacts (Row 1) and conceptual business model (Row 2)For information and applications architectures:Appropriate Column 1 and 2 artifactsFor 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

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

Subject matter experts (from the program under review)Business Architect

Business architecture domain activities

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.

Business architecture domain deliverables

Per the Checklist for Change Initiatives that are Subject to Corporate ACT/ARB Review for Rows 1 and 2

Data architecture domain roles

Information Architect

Data architecture domain activities

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.

Data architecture domain deliverables

Per the Checklist for Change Initiatives that are Subject to Corporate ACT/ARB Review for Column 1

June 3, 2005 4-45


Applications architecture domain

roles

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

Applications Architect


activities

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 ABBsDefine the fundamental types and inheritance in the Class Hierarchy


deliverables


Technology architecture domain

roles



activities

Develop Application Function and Data Placement ModelIdentify DomainsIdentify NodesIdentify base Logical Operational ModelValidate Logical Operational Models with Business ScenariosDefine Technical Selection Criteria and Process


deliverables


Security architecture domain roles

❑ Security Architect

Security architecture domain activities

❑ 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

Security architecture domain deliverables

❑ 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 ❑



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 ❑

❑


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 ArchitectInformation Architect

Activities Analyze “as-is” artifacts against the target artifacts and document the differences.

Deliverables Legacy versus target environment gap analysis.

Activity: Monitor I&IT projects

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 ArchitectInformation ArchitectApplication ArchitectTechnology ArchitectSecurity Architect

June 3, 2005 4-47


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 Modified target architecture artifacts

Activity: Confirm or modify I&IT project components

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 ❑

❑

❑

❑

❑

❑

❑

❑

❑

Business ArchitectInformation ArchitectApplication ArchitectTechnology ArchitectSecurity Architect

Activities 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 Possible modifications to target architecture based on new constraints on technology options.

Activity: Define and implement architecture support function

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 ManagerArchitecture Planner



Cluster Information ArchitectCluster Business/Applications ArchitectCluster Technology/Security Architect Methods & Tools SpecialistRepository Administrator/Librarian

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

Activities Negotiate service level agreement (SLA) and Centre of Excellence (COE) agreementWrite RFP or RFR for project architectsEvaluate and award architecture contractsPerform architecture planning for the projectPerform vertical integration for information, business, applications, technology and security architecturesDefine and support policies, standards, guidelines for creation and management of ministry architecture artifacts and toolsSupport artifact creation and management toolsPerform artifact management including change control, versioning, check-in/check-outProvide education and training in methods, tools, standards to project architects

Deliverables SLA agreement for project architecture workCOE agreement for project architecture workSelected and awarded project architects Project architecture plansHorizontal integration of architectures between project, cluster, corporateArtifact creation and management standards, policies, guidelinesArtifact creation and management toolsVertically 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 Information Architect Application Architect

Activities 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.

Deliverables Class ModelList of Components.

June 3, 2005 4-49


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 ArchitectApplication ArchitectSecurity Architect Applications ArchitectI&IT Staff (subject matter experts)

Activities Define Implementation Classes

Deliverables Implementation classes.



4.4 Architecture and Special InitiativesThis section presents the following topics:

4.4.1 Introduction toData Warehouse

Design andArchitecture

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.

4.4.2 Portal This subsection will be available in a future release of this publication.

4.4.3 Commercial off-the-shelf

software

This subsection will be available in a future release of this publication.

June 3, 2005 4-51

Chapter 4: Architecture Methods—Architecture and Special Initiatives

4.4.1 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?

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 Warehouse Types and Design

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.

Data Warehouse Architecture

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.



4.4.2 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 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.

Integrated 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.

Time-variant Data warehouse contains historical data.

Nonvolatile 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. Roll-up, 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, 2005 4-53


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: “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?”❑ “

OLAP questions:

❑

❑

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?”



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 OLAPCharacteristic Operational processing Informational processingOrientation Transaction/Operation AnalysisUser Clerk, DBA, database professional Knowledge worker

executive, analyst)(e.g. Manager,

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, consolidatedView Detailed, flat relational Summarized, multidimensionalUnit of work Short, simple transaction Complex queryAccess Read/write Mostly readFocus Data in Information outOperations Index/hash on primary key Lots of scanning# of records accessed Tens Millions# of users Thousands HundredsDB size 100 MB to GB 100 GB to TBPriority High performance, high availability High flexibility; end-user autonomyMetric Transaction throughput Query throughput, response timeData model ER based, application-oriented Star/snowflake, subject-oriented

June 3, 2005 4-55


Data Warehouse Types and DesignData 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 Data Mart

Scope Corporate-wide data integrationSubjects spanning the entire organizationCross-functional and cross-subject

A subset of corporate-wide dataSpecific 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

From multiple sources, orFrom an enterprise data warehouse

DB size GB to TB and over GB

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 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 end-user 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 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



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, 2005 4-57


4.4.3 Data Warehouse ArchitectureData 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


Chapter 5: Architecture Principles

Chapter 5: Architecture Principles—General Concepts

5.1 General ConceptsThis section presents the following topic areas:

5.1.1 General Concepts of Principles-

Driven Architectures

General concepts for developing and using principles-driven architectures.

5.1.2 Artifacts vs Primitives

What is the difference between artifacts and primitives and why is it important? Much of this subsection is taken from a paper by John Zachman written in 2000. In it he distinguishes “architectural” knowledge (or artifacts) from application development knowledge or artifacts.

5.1.3 Relational vs Object

What is the impact of choosing the relational or the object-oriented paradigms in the context of the Zachman Framework?

In simple terms, the fundamental concepts used to represent or model the world (at least of I&IT purposes) fall into two broad camps or paradigms—relational and object-oriented. The issues raised by this distinction are important to the practice of enterprise architecture, since it is the function that concerns itself most with how to represent or model aspects of the enterprise.

5.1.4 Templates and patterns

Definitions of the contents of the Templates, Patterns and Reusable Components Library.


General Concepts of Principles-Driven Architectures

5.1.1 General Concepts of Principles-Driven Architectures

General concepts for developing and using principles-driven architectures.

In the implementation of an enterprise architecture program, initially there are only principles to declare. Eventually there is architectural knowledge, consistent with the initial principles, consisting of components that are used by designers to construct solutions, point-in-time implementations, etc.

Many principles have been developed and recorded in the course of the implementation of the OPS EA Program. This section describes the elements of a general architecture principle. The specific principles can be found in the EA repository.

A Good Architecture Principle

States a fundamental belief of the enterprise in one or two clearly written sentencesRecommends an action against which some arguments could be madeHas relevance to an architecture domain – business, information, application, technology, securityIs worded directly and simply in terms understandable by both business and I&IT managersHas business-wide applicabilityIs durable; will not be outdated quickly by advancing technologyHas objective reasons for advancing it instead of the alternatives that were consideredHas impacts that need to be documented

A Poor Architecture Principle

Makes a statement which no one would dispute Is a general business or financial statementHas little or no general applicability. It may actually select a standard or a technologyIs stated at too low a level of detail and may not endureMay be included “because I say so”

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

June 3, 2005 5-3


When Is An Architecture Principle Not?

When it is a general business principle or company policy with no architecture implications.

Categories of Principles

Guiding PrinciplesManagement and Organization PrinciplesData Management PrinciplesApplication Delivery PrinciplesUser Interface PrinciplesSecurity PrinciplesSystems Management Principles

❑

❑

❑

❑

❑

❑

❑


Object-oriented Models

5.1.2 Object-oriented Models

What is the impact of choosing an object-oriented software development methodology in the context of the Zachman Framework?

Concern has been expressed in the past that object-oriented (OO) modeling may be incompatible with the Zachman Framework. One of the reasons is perhaps related to the examples of models that John Zachman offers in the poster that illustrates the Framework. The examples of models that appear in the poster are primitive models, in keeping with the logic behind this particular framework, while OO models tend to be composites. This does not mean, however, that organizations that have selected an OO methodology for software development cannot benefit from taking a Zachman Framework approach to EA.

The Zachman Framework is not an SDM

The Zachman Framework is a classification schema for the information that, in total, describes an enterprise. The logic behind the Zachman Framework requires enterprise information to be in the form of primitive models to aid in analysis, and to facilitate the sharing, reuse, and maintenance of models. It is not a software development methodology (SDM), nor does it recommend which models to use for any SDM.

Some confusion may arise when information that is contained in the primitive models that comprise an enterprise’s architecture is meant to be used in the models of a selected SDM, or when models that are produced in the course of developing software are used to provide information for an enterprise architecture.

Using EA Information in SDM Models

The use of information contained in EA models, i.e., the primitive models of an EA that has been developed per the Zachman Framework approach, is a key strategy for engineering commonality across an enterprise through the various I&IT implementations that are carried out over time. Regardless of the SDM that is selected for an I&IT project, OO or otherwise, it is important for the elements of the designs that are created in arriving at the solutions to be implemented to be based on a set or subset of authorized models that have been created for the enterprise in general. In many cases this will require system designers on project teams to access an EA repository of models, select the desired elements from the models that are available, and use them in their designs.

June 3, 2005 5-5


Using SDM Models to Create EA

In the early stages of an EA program, there will not be many EA models for system designers to draw upon, and this is the case with the OPS EA Program at present. Accordingly, a great deal of effort has gone into defining and standardizing the formats for the models and other artifacts that are created by I&IT project design teams so that information may be abstracted from them and used to create reusable primitive models, at least for their sponsoring enterprises, and also possibly across clusters and the OPS.


Templates and Patterns

5.1.3 Templates and Patterns

Definitions of the some of the contents of the Templates, Patterns, and Reusable Components Library

The Reuse Goal One of the most significant objectives for architecture is the construction of reusable assets.

In a technical context, this could range from an analytic technique that produces a superior answer, to a physical device or package of logic, which can be reconfigured quickly accurately, and inexpensively to perform multiple tasks, or to take on new tasks when the business no longer requires the performance of the old tasks.

In a business context a reusable asset would range similarly—from multi-purpose techniques and tools to business systems that are so sophisticated they make it possible for the same employee to perform a wider range of services without significant skill upgrades. The concept of reuse is infinitely malleable and powerful.

Reuse is intimately tied to the “alignment and integration” goals of architecture as illustrated by the following exhibit:

Table 5-1: Alignment and integration goals of architecture

Architecture Goals Alignment Goals Integration Goals

For Automation Design Aligns technical capabilities with business needs

Creates multi-purpose and reusable components, e.g. “integrated financial system,” “work scheduling module,” etc.

For Work Design Aligns accountabilities, pro-cesses and motivations (per-formance measures) with business goals

Creates multi-purpose and reusable processes, resources, roles, e.g., “one-stop, one window service”

For Policy Design Aligns program with public needs and mandates

Creates multi-service con-cepts, e.g., “treat the person, not the disease” Creates reusable processes, e.g., collect different types of waste products using same service delivery mechanisms

June 3, 2005 5-7


Reuse strategies from successful practitioners have several common factors:

Very high level of quality and documentation of the components. Reusable components must be organized in a Library, but only good quality items should be in that Library.Introduction of reuse as a part of a quality improvement program. If the motivation for a reuse program is only productivity improvement, without any regard to quality, success will be difficult to get.Do improvements based on an evolutionary, step-by-step approach, rather than a “revolutionary” approach.Use of domain analysis to identify and specify reusable components in the development of new systems.“White-box” reuse: components can be modified when reused, if necessary. This decreases the cost of development of reusable components.Identify generic problems that can be addressed with generic components.Careful revision of the specification of the reusable components, in order to avoid too complex or unnecessary generic specifications.Narrow the definition of reuse to avoid overworking it; for example, a standard is not “reusable” just because everyone can adopt it. There should be some sense in which the reusable component is “used”. (This last point is good in principle, but the OPS is large enough that standards developed in one area could be “reused” in other areas.)

The Templates, Patterns, and Reusable Components Library and the FFM

This library is designed to classify and organize reusable design elements and other components. The Federated Framework model, along with the services of a librarian, will ensure that its contents can be located, shared and used.

Components may be as elementary as instances of primitives—the definition of a citizen, for example. Components may appear in the form of one artifact, or a whole group or related artifacts—perhaps an entire framework of artifacts to represent a generic program or service.

Components will find their way into the Services Library following the same process as all other artifacts—originating in project frameworks, approved in a project context, then promoted to the Templates, Patterns, and Reusable Components Library. As part of the promotion process, the component will be classified in terms of its intended use.

Preliminary Usage Classifications

The following is a very preliminary list of proposed usage classifications for components in the Templates, Patterns, and Reusable Components Library.

Mandatory—The component must be used assuming it meets relevant criteria; an example would be basic information which must kept about any government facility, or certain actions such as security checking procedures which must be performed in a certain way to comply with regulations.

Recommended—The component has demonstrated its usefulness under appropriate conditions, such as an algorithm.

Available—The component is available for use.

❑

❑

❑

❑

❑

❑

❑

❑

❑



Special Purpose—Use of the component is limited in some way; and example might be a model of crisis response suited to only certain types of crisis.

Preliminary Type Classifications

The following is a very preliminary list of proposed type classifications for components in the Templates, Patterns, and Reusable Components Library. The purpose of type classification is to provide additional information to those searching for reusable components.

Pattern—the component is intended to be used as a guide, or model; it may be followed exactly, or closely, or not at all; a simple example would be checklist of features for a computer workstation; another example might be

Template—the component is intended to be used to construct a close facsimile of the desired result, by copying and modifying for example

Clone—the component is intended to be used without change

Reference—the “reusable component” is a reference to something that can be used; an example would be a reference to an industry-sponsored device specification, but not the specification itself.

Every Artifact Reuse Behavior is Unique

Experience suggests that every type of artifact will have its own reuse signature. A model of a particular process will never be reusable in the same way that a package of source code, or executable code, is reusable.

The following guidelines are recommended: [Note: The following guidelines are likely to change as experienced is gained with the EA Repository and modeling tools.]

Context Artifacts Reuse

Business Resource Types—actual instances should be a consolidated list in the form of a template maintained at the corporate level, detailed to a standard degree of granularity, assembled by aggregating artifacts; each cluster could also have a subset version of the corporate template.Programs and Services—actual instances are unique; standard methodology and patterns should be used to define instances; patterns should be developed as a service of the OPS EA ProgramBusiness Locations Types—actual instances should be a consolidated list in the form of a template maintained at the corporate level, detailed out to a standard degree of granularity, assembled by aggregating artifacts; also a cluster-level version could be produced with each cluster having a subset of the corporate template.Types of Individuals and Organizations—actual instances should be in the form of a consolidated indented list or class hierarchy (allowing multiple inheritance) maintained as a template at the corporate level, detailed out to a standard degree of granularity; also a cluster-level version could be produced with each cluster having a subset of the corporate template. This is an important “reusable component” because the fact that different ministries, programs, projects, etc. are targeting the same types of clients has business importance in terms of alignment and integration across government.

❑

❑

❑

❑

June 3, 2005 5-9


Role Types—actual instances should be in the form of a consolidated indented list maintained as a template at the corporate level, detailed out to a standard degree of granularity; also a cluster-level version could be produced with each cluster having a subset of the corporate template.Business Cycle Types—actual instances should be in the form of a consolidated indented list maintained as a template at the corporate level, detailed out to a standard degree of granularity; also a cluster-level version could be produced with each cluster having a subset of the corporate template.Client Needs—actual instances should be in the form of a consolidated indented list or class hierarchy (allowing multiple inheritance) maintained as a template at the corporate level, detailed out to a standard degree of granularity; also a cluster-level version could be produced with each cluster having a subset of the corporate template. This is an important “reusable component” because the fact that different ministries, programs, projects, etc. are targeting the same types of needs has business importance in terms of alignment and integration across government.Goals—actual instances are unique; standard methodology and patterns should be used to define instances; patterns should be developed as a service of the corporate architecture function

Conceptual Model Artifacts Reuse

❑

❑

❑

❑

❑

❑

❑

❑

Conceptual Information Model (sometimes called the Semantic Model)—initial pattern has been created alreadyService Delivery (Value Chain) Process Model—patterns have been created already (service archetypes, service classes, etc.)Business Functional Models—patterns have been created already (internal services archetypes)Business Logistics Network Model—actual instances should be in the form of a consolidated model maintained as a template at the corporate level, detailed out to a standard degree of granularity; also a cluster-level version could be produced with each cluster having a subset of the corporate templateWork Flow Model—many, many instances should be analyzed and patterns extracted on the basis of “best practices” or other criteria such as commonality; patterns could be maintained on a consolidated basis at the corporate level, and/or at the cluster levelBusiness Scenarios—instances are generalized into use cases, not into patterns.Objectives—actual instances are unique; standard methodology and patterns should be used to define instances; patterns should be developed as a service of the corporate architecture functionPerformance Matrix—special case similar to clients and needs, where the corporate architecture function has a role to play in helping to integrate performance information from different areas of government, using common components. Templates or references to performance matrixes should be maintained corporately and analyzed for overall integration

❑

❑

❑

❑



potential. Eventually could lead to consolidate “performance matrix” for government, where interactions among all programs can be understood.

Logical Model Artifacts Reuse

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

Logical Data Model—two approaches to this: templates of data models for common and shared information subjects (e.g. human resources, geographic referencing, etc.) or one consolidated data model maintained at the corporate level (similar to approach for performance model artifacts).Logical Data Groups (Subject Area Databases)—same options as logical integrated data modelClass Hierarchy—same options as logical integrated data modelData Flow Models—many instances should be collected and evaluated for common patterns using best practices or other criteria.Logical Applications—same options as logical integrated data modelInfrastructure Components—selected from the Infrastructure Component Catalogue for the OPS.Infrastructure Pattern Matching—selecting the appropriate pattern or chain of patterns to be used along with the corresponding service level matchesInfrastructure Pattern Chains—illustrating the patterns, links, etc.Use Cases—many instances should be collected and evaluated for common patterns using best practices or other criteria.Business Policies (business rules)—many instances should be collected and evaluated for common patterns using best practices or other criteria

June 3, 2005 5-11

Chapter 5: Architecture Principles—EA Principles

5.2 EA Principles


5.2.1 Global Architecture

Principles

The overarching vision for the EA is that it will be iterative and evolving, and will guide the development of an integrated information environment that will enable cost effective solutions to meet new business requirements. The architectural principles presented here have been adopted and act as a “road map” to guide further architecture development and to confirm that the architecture continues to fulfill its intended purpose.

5.2.2 Business Architecture

Principles

Business architecture principles provide guidance for the development and use of business architecture. At the time of writing, business architecture principles have not yet been formalized. This section is a “placeholder” for the time being.

5.2.3 Information Architecture

Principles

The Information Architecture design principles were developed by studying the principles that have been considered by other large organizations, and by determining information-related capabilities needed to implement the architecture requirements that support the Government’s business needs.

5.2.4 Application Architecture

Principles

The Government of Ontario’s application architecture design principles provide the foundation for all of the enterprise application development initiatives. This section provides an overview of the design principles that are relevant to the Government of Ontario and should be implemented as a core component of all enterprise application development projects.

5.2.5 Technology Architecture

Principles

The following Technology Architecture design principles are described in this subsection:

Integrated Network Data Warehouse & Database System Management Internet/Electronic Commerce Platform Workflow Directory/Message Transport Middleware

❑

❑

❑

❑

❑

❑

❑

❑



5.2.6 Security Architecture

Principles

This section presents security architecture principles grouped under the following categories:

Administration

Availability

Accountability

Authorization

Awareness and Training

■

■

■

■

■

June 3, 2005 5-13


5.2.1Global Architecture PrinciplesThe overarching vision for the EA is that it will be iterative and evolving, and will guide the development of an integrated information environment that will enable cost effective solutions to meet new business requirements. The following architectural principles have been adopted and will act as a “road map” to guide further architecture development and to confirm that the architecture continues to fulfill its intended purpose. The EA must:

Facilitate the reduction in the complexity of I&IT integration. This is done by setting standards aimed at unifying the technology base that will comprise the I&IT infrastructure. Enable access to information subject to privacy protection pursuant to the Freedom of Information and Protection of Privacy Act (FIPPA). Although the overall aim of the EA is to facilitate access to and sharing of information, statutory requirements pertaining to privacy will be adhered to. Enable information to be treated as a corporate resource (recognizing the stewardship of program areas over their information), ensuring that non-personal products are known, available, secure and useful. The sharing of information, which is key to the Government’s vision for business integration, recognizes that personal information shall be treated differently from non-personal information in order to comply with FIPPA privacy requirements. Ensure that privacy impact assessments are undertaken to evaluate the full range of privacy issues arising from new technologies, information systems, and proposed changes to programs or policies before seeking approval to issue an RFP or proceeding with development or implementation. Point out opportunities to re-engineer business processes to meet client expectations of government services. The EA should stimulate thinking of the potential use of the capabilities of integrated information technology in ways that can render business processes more effective and efficient. Be flexible and promote an adaptable I&IT infrastructure that will be organizationally independent. The architecture must be flexible and “organizationally independent” in the sense that it serves the Government as a whole. Enable timeliness of services to clients. This will be done primarily though greater visibility of available information, increased

Ensure currency of technology. This can only be assured if the EA itself remains current, which itself is dependent on the EA governance structure that has been put in place. Ensure that security is part of the initial design, implementation and post-implementation of application developments and in the modification of software. This is

speed of access, and increasingly automated processes.

❑

❑

❑

❑

❑

❑

❑

❑

❑



essential in order to ensure integration of the security measures and mechanisms that are needed for all EA components. Make security uncomplicated and as transparent as possible to the user, and integrate security seamlessly into I&IT applications, repositories, and infrastructure. This is essential if security mechanisms are to be properly employed by everyone. Ensure that I&IT infrastructure is robust, reliable and with the appropriate redundancy of components where required by the business. Essential for reliability. Facilitate comparison of investment over long-term total cost of ownership. By compiling a comprehensive inventory of the components that comprise elements of the I&IT infrastructure, it will be possible to conduct business case analyses to compare the ongoing total cost of ownership associated with legacy technologies with the capital investment and total cost of ownership associated with potential replacement technologies. Move to an electronic work environment, including electronic commerce. A key enabler of the Government's business vision. Lead and enable a culture of reuse to be established (authorized reuse of information, application components and infrastructure). This is accomplished by promoting the principles of reuse in component architecture design. Promote consideration of buying and integrating “off-the-shelf” solutions versus developing them “in house” wherever possible. A key measure to reduce the total cost of ownership of I&IT capabilities. Contains standard interfaces to or encapsulates legacy systems in a practical, secure, and efficient manner. A legacy system, re-engineered to reflect EA design principles, may be considered integrated within the architecture or it will remain as a legacy system. Must be documented comprehensively. The EA serves as corporate memory and fulfills its purpose despite changes in staff. Consequently, it is important that all aspects of the EA be recorded and incorporated into the OPS EA Knowledge Base. Facilitate decision making through the availability of higher quality information.

❑

❑

❑

❑

❑

❑

❑

❑

❑

June 3, 2005 5-15


5.2.2 Business Architecture PrinciplesBusiness architecture principles provide guidance for the development and use of business architecture. At the time of writing, business architecture principles have not yet been formalized. This section is a “placeholder” for the time being.


Information Architecture Principles

5.2.3 Information Architecture PrinciplesIntroduction The Information Architecture design principles (IDP) that are described in the

following paragraphs were derived from discussions held in the EA Information Architecture Workshop, which was held 15-18 June 1998, by studying the principles that have been considered by other large organizations, and by determining information-related capabilities needed to implement the architecture requirements that support the Government’s business needs.

IDP#1: Information must be life-cycle managed as a strategic resource of exceptional value, in order to ensure reliable, authoritative evidence of action where needed and the longevity of information access as required. Information is of value to Government, to citizens, and to public and commercial organizations served who receive government services. Information is the Government’s primary product and is used in the planning, evaluation and management of every program.

IDP#2: The Information Architecture must be business driven and based on technology implemented for both operational and decision support requirements. The information architecture must reflect subject areas that have been derived from the enterprise business mandate and not from the attributes of existing or planned technologies. This ensures continuity of information structures despite changes in technology.

IDP#3: Privacy must be protected (and shall have priority over general information sharing objectives). General information sharing and objectives can only be achieved where privacy can be protected. The Freedom of Information and Protection of Privacy Act and the Ontario Government Privacy Standard that is under development serve to ensure the protection of personal information provided by individuals and impose legal restraints on its use, even with the confines of the Government. This will have a direct bearing on database linkages and on the need to ensure personal identifiers are removed from other related information when consolidating information for program evaluation purposes. The objective of establishing an enhanced information-sharing environment shall not take priority over the protection of privacy.

IDP#4: Security must be incorporated into the Information Architecture. The features and mechanisms needed to implement security requirements will be included in the initial design of the Information Architecture rather than being considered later. This is true for all of the EA component architectures, ensuring the best opportunity to establish a uniform security environment throughout Government.

June 3, 2005 5-17


IDP#5: Information must be designed to be sharable (but shall not imply the sharing of private information beyond the limits imposed by legislation). Where possible and subject to privacy legislation, information systems within the government should be designed to allow the sharing of information among ministries regardless of organizational structures and geographic barriers. In effect, clients (including citizens as well as OPS employees) and organizations should view government information as the resource of a single enterprise.

IDP#6: Information management policy development will be a framework documented and applied consistently across the enterprise. Information is to be considered a “corporate resource”, therefore direction for the quality, integrity, access and security of information must emanate from the corporate or enterprise level. This does not mean, however, that all information is directly managed at the corporate level. Management responsibilities should be delegated to appropriate business organizations within the enterprise. This means that the authoritative sources, accountability, ownership and custody of all information must be clearly defined so that it is an integral part of overall program management.

IDP#7: Operational data and decision-support data must be held on separate "platforms" so that performance is not impacted by decision support processing. A layer should exist between the requesters of information and the actual systems from which the information is derived in order not to impact on the performance of the operational system.

IDP#8: Information must be managed so as to guarantee its quality. The information provided to clients should be accurate, timely, understandable, and at the right level of detail. Decision-makers should not be overwhelmed with unnecessary information.

IDP#9: Information must be defined consistently across the enterprise.

IDP#10: Information Architecture is to ensure that appropriate Recorded Information Management policies, standards and processes can be incorporated into information systems. Despite the heterogeneous nature of the various sources and systems providing and holding information, a common standard must be defined and managed that enables clients and organizations the ability to view data elements in a consistent manner. This is key to the integration of information across Government. Discussions will take place with the Ontario Archivist on this matter.


Information Architecture Principles

IDP#11: The Information Architecture must facilitate decision making. This will be accomplished through the availability of higher quality information.

June 3, 2005 5-19


5.2.4 Application Architecture PrinciplesIntroduction The Government of Ontario’s application architecture design principles

provide the foundation for all the enterprise application development initiatives. It defines how applications should be designed and how they can cooperate to gain maximum interoperability for the application. This section provides an overview of the design principles that are relevant to the Government of Ontario and should be implemented as a core component of all enterprise application development projects.

Benefits of well-documented

application architecture design

principles

❑

❑

❑

❑

Ease of integration of applications and application services. Efficient reuse of existing application assets. Faster deployment of new applications. Better responsiveness to changing business needs.

The application design principles (ADPs) listed below provide guidelines for the design or purchase of applications and application components across the Government of Ontario. They will ultimately form the foundation of the next application architecture project that will expand these ideas into an application architecture guidance document.

ADP#1: The application architecture must facilitate the reduction in integration complexity.The integration and streamlining of business processes will require as homogeneous an application environment as possible.

ADP#2: Application architecture must facilitate change in business processes. Government programs are carried out through the delivery of services, which in turn are delivered through the exercise of business functions and processes. These business processes must be completely understood and each associated business event should also be identified. The application architects must understand how business processes cooperate to supply value when business events occur. The logical boundaries for applications should be drawn around business processes and the business process should be implemented using a collection of related business rules. Applications will therefore respond to business events by invoking business rules in the most flexible way possible.

ADP#3: Application architecture must be highly modular and flexible.The Government of Ontario application architecture should allow for the possibility of re-partitioning an application in the future. Being highly modular will provide flexibility in physical implementation (i.e., in the deployment of application components on different platforms) and will also provide the ability to easily evolve the application as business requirements change.


Application Architecture Principles

ADP#4: Applications should be designed to permit reuse of components.The ability to share application functionality across ministry boundaries will be accomplished using application components. As an increasing number of enterprise applications are deployed, there will also be an increasing number of application components available for use by other new applications. Therefore all new enterprise applications should be built by assembling and integrating existing components, rather than by creating custom code. This approach will help to reduce cycle times and will minimize artisan programming.

ADP#5: Application Architecture must drive the selection of development tools.Traditionally, project teams selected tools (e.g., PowerBuilder, Visual Basic, ORACLE, SQL Server) first, and then had to live with the architecture those tools supported. That approach leads to the problem of the tools driving the architecture (and thus the business) rather than the business requirements mandating the architecture and thence the tools. It is therefore very important for the Ontario Government’s application architects to focus first on the design of the application and then select the best-of-breed tools to support the selected architecture.

ADP#6: Programmer roles must be defined according to application tiers (not technology).Each of the following classes of programmers can specialize and use the tools best suited to their roles:

User function programmers Business function programmers Data access programmers

ADP#7: The Application Architecture must be documented comprehensively.As mentioned in ADP#2, the application architecture must facilitate change in business processes. It is therefore very important to document the architecture and how it supports the business processes. Since changes occur more frequently in business processes than in the data, it will be important for the developers to be as familiar with the processes as with the data. This can only be achieved with comprehensive and up to date documentation. Although all component architecture must be documented to some degree, the greatest care must be taken with the application architecture as it more than any other component most closely matches the actual workflows and their automated processes.

❑

❑

❑

June 3, 2005 5-21


ADP#8: Applications must meet the requirements of the security architecture.The reason that a security architecture has been included in the conceptual stage of the development of the EA is to provide maximum opportunity for particular software solutions to operate as seamlessly as possible within an integrated security environment.

ADP#9: The Application Architecture must recognize legacy system transition strategies .An infrastructure as large as the Ontario Government’s will always be in transition to some degree and will inevitably have a significant percentage of systems in operations that span one or more generations of technology. Co-existence between new generation and legacy systems will always be necessary. The application architecture must take this into consideration and must identify the legacy systems and their transition strategies.

ADP#10: The Application Architecture must incorporate the principle of "buy vs. build” and promote the consideration for bought versus developed solutions wherever possible. “Off-the-shelf” software should be considered as large objects to be reused if possible. A strategy for maintaining off-the-shelf applications must be developed.


Technology Architecture Principles

5.2.5 Technology Architecture PrinciplesIntroduction The Technology Architecture design principles that are described in the

following paragraphs were derived from discussions held in the EA Technology Architecture Workshop, which was held 6-9 July 1998, by studying the principles that have been considered by other large organizations, and by determining technology-related capabilities needed to implement the architecture requirements that support the Government’s business needs. A common thread appears throughout the components—the need to adopt standards, ensure adaptability, reuse of infrastructure, and configuration discipline. The principles of each technology component are presented in turn.

Integrated Network Data Warehouse & Database System Management Internet/Electronic Commerce Platform Workflow Directory/Message Transport Middleware

Integrated Network

The integrated network is a client driven, universally accessible capability that is media independent for the delivery of services such as voice, data, and video over a variety of different means of transport. The LAN architectures will use the integrated network to provide an identically configured environment, which includes the desktop, server and network environment. The Integrated Network Design Principles (INDPs) have been identified as follows:

INDP#1: The integrated network must be capable of supporting configuration and version control at both the backbone network level and the LAN level for all network components. This is necessary to ensure interoperability among all infrastructure components.

INDP#2: The integrated network must have common naming standards for all network devices and components. Essential for system management.

INDP#3: The integrated network must have a 24/7 orientation and be responsive and reliable. Networks provide an increasingly important and necessary role in the execution of business functions and processes. The availability of the network seven days a week and twenty-four hours a day must be maintained in a consistent and complete manner.

❑

❑

❑

❑

❑

❑

❑

❑

June 3, 2005 5-23


INDP#4: The integrated network must employ a single network medium standard at the LAN level.The industry de facto standard is Ethernet. This is best achieved by a phased approach (as opposed to trying to do it in "one fell swoop.") As legacy LANs are replaced, they should be replaced by the selected standard.

INDP#5: A common model for security policies must be implemented for the integrated network.Essential for interoperability, this includes the lower level telecommunications and the LAN-level network operating systems.

INDP#6: The integrated network must be viewed as both a communications infrastructure and an application platform.The network provides a universal interface to all enterprise communications, information systems and applications.

INDP#7: The integrated network must be scalable and extensible and driven by client requirements and needs.The network must facilitate changes in business processes and not be an obstacle.

INDP#8: The integrated network must support seamless access to information from the user’s point of view.The network must not be difficult to access and there must not be any decrease in the functionality of client's software as a result of operating through the network. The network must be integrated with the other architectures, especially with the application and middleware architectures.

INDP#9: The integrated network must be capable of providing accessibility from remote regions that may not have a fully developed telecommunications infrastructure. This implies the need for radio/satellite gateways. User access should be a function of authentication and authorization, not of location.

INDP#10: The integrated network will primarily serve the OPS but must provide interface to the trusted extended environment. The trusted extended environment includes the Broader Public Sector and as well as elements of the private sector with which the Government conducts business and will be an essential supporting mechanism for electronic commerce (automated financial transactions).

INDP#11: The integrated network must consider use of existing infrastructure as delivery mechanisms in local areas.This is both to avoid unnecessary duplication as well as to facilitate interoperability.



INDP#12: The integrated network must have a system management capability. The system management capability must be able to measure performance in ways that could be used in service level agreements.

INDP#13: The integrated network must incorporate high bandwidth technologies where cost-effective and feasible.This is essential to support the principle of scalability for the network in order to be able to accommodate more applications, new data types and more users.

INDP#14: The integrated network must be based on "off-the-shelf" solutions versus in-house development.This is essential to reduce the total cost of ownership and to ensure integration with external networks, which will also likely be based on “off-the-shelf” technology.

June 3, 2005 5-25


Data Warehouse & Database

A data warehouse accumulates snapshots of corporate information which is locally managed, organized and authorized by Metadata (key fields to access authoritative sources) that can be deployed in a distributed, centralized or hybrid configuration. A database is a collection of programs that enables data to be entered, organized, and selected in a database. The Data Warehouse & Database Design Principles (DW/DDPs) have been identified as follows:

DW/DDP#1: Business requirements rather than technological capabilities must drive the design of data warehouses. The business management community must be fully engaged in the defining their information requirements.

DW/DDP#2: Decision support data used in data warehouses and operational sources of data must be on separate platforms. This is necessary so as not to degrade the performance of operational systems.

DW/DDP#3: There must be a clear accountability/ownership of data, with appropriate policies to control access to data warehouses and protection of personal privacy.Business user organizations are responsible for establishing and maintaining the accuracy of data collected and entered into data warehouses.

DW/DDP#4: Data warehouses must be designed to leverage the capabilities of the network. The network should be used to increase the sharing of data warehouse products.

DW/DDP#5: Data warehouses will require authoritative sources of data, which are defined by the metadata; common metadata standards also apply to data marts.Managers and executives will be using data warehouse capabilities to make important and critical decisions in planning for the future. It is essential that data contained in the data warehouse be trusted and as accurate as possible.

DW/DDP#6: Data warehouses must support forecasting, decision making, and "what-if" scenarios.The very purpose of a data warehouse is to support decision making.

DW/DDP#7: Data marts must be based on a single or few well defined subject areas.This reflects the definition of a data mart.



DW/DDP#8: Data warehouses must be able to change specific data within “snapshots” without impacting the integrity of the snapshots.A “snapshot” of data reflects the values of a selected body of data that is captured at a specific point in time. If later is determined that some of the date that was captured was inaccurate, then the trust of the entire snapshot will be jeopardized. It will be important, therefore, to be able to make any necessary adjustments to previously captured snapshots.

DW/DDP#9: The overall design of the enterprise data warehouse will follow a federated approach.A federated approach, linking relatively small data marts, mitigates the risk that is associated with monolithic approaches.

System Management

System Management is a single means for reporting problems and managing the resolution of all technology related problems. System Management is incident-driven and client initiated. System management includes help desk, operations management, storage management, performance monitoring and tuning, security services and disaster recovery. The System Management Design Principles (SMDPs) have been identified as follows:

SMDP#1: System management must be as available and reliable as the I&IT infrastructure it serves. It must be available 24 hours a day 7 days a week matching the availability of the systems that it supports.

SMDP#2: System management must provide multiple levels of support , from data collection in the initial call through to problem resolution.There are generally considered to be three levels or tiers of support:

❑ Tier 1 - help desk/call centre ❑ Tier 2 - advanced technical expertise ❑ Tier 3 - highly specialized technical experts

SMDP#3: A common help desk will be used as the main entry point for all support calls. A single point of contact minimizes user inconvenience and confusion. The common help desk(s) must be able to hand off calls to specialized support desks for specific business applications in addition to resolving general I&IT infrastructure related support calls. The enterprise-wide help desk must be integrated with the overall system management capability.

June 3, 2005 5-27


SMDP#4: Since system management will be a point of contact in the case of failure the system management's I&IT infrastructure must be able to operate independently of other systems. This is essential for disaster recovery.

SMDP#5: The system management service must be redundant and not have a single point of failure.This is a contributing factor to ensuring the overall robustness of the I&IT infrastructure.

SMDP#6: System management must have the ability to perform remote control of user workstations to assist in problem resolution. This is an essential technical support staff economizing measure as well as a measure that will accelerate the time needed to resolve user problems.

SMDP#7: System management will require a comprehensive knowledge base.A knowledge base is a combination of vendor provided database and information that is specific to the I&IT infrastructure such as inventory information.

SMDP#8: System management must be capable of receiving a variety of incident reports via the queuing of IVR/voice/e-mail.This reflects the variety of user access capabilities that will be in use.

SMDP#9: System management must have escalation procedures in addition to call scheduling capabilities. Lengthy outages should be brought to the attention of appropriate levels of management so that additional resources may be applied to the resolution of specific problems if necessary.

SMDP#10: System management must have rigorous version control of supported software. This is necessary to ensure an integrated I&IT environment.

SMDP#11: System management must have the ability to assign problems to local resources and to track end-to-end implications.Necessary to guarantee cross-enterprise functionality and high quality of service.

SMDP#12: System management must enable a formal change management process.This applies to all components across all technologies.



Internet/Electronic Commerce

Internet/Electronic Commerce enables transactions (both financial and non-financial) between the government and business clients (trusted partners) using I&IT infrastructure. E-commerce automates transactions so that fewer people are involved in processes. Internet/Electronic Commerce applications are designed to be legally binding and can occur 24 hours a day from any client that has access to the service (which could be global in nature). Internet/Electronic Commerce Design Principles (I/ECDPs) have been identified as follows:

I/ECDP#1: Internet/Electronic Commerce applications must leverage infrastructure already in place.The application delivery should be via a web browser and should take advantage of the workflow, directory and message transport infrastructures.

I/ECDP#2: Internet/Electronic Commerce solutions must be applicable to different business applications throughout the enterprise and therefore must be developed generically. If this approach is not taken, the result will be several uniquely designed electronic commerce applications, which will be relatively costly to support and will not in all likelihood be interoperable.

I/ECDP#3: Internet/Electronic Commerce applications must be able to support cross-certification with other partners such as banks, credit card companies and suppliers. This is required in order to extend electronic commerce functionality to trusted partners.

I/ECDP#4: Internet/Electronic Commerce must take into account communications across entire processes and provide the proper level of security between clients, the banking industry and suppliers. This should be evaluated within the context of risk. The Internet does not guarantee delivery or security. Transaction reliability must be engineered in until reliable Internet transaction management tools mature.

I/ECDP#5: Internet/Electronic Commerce applications must be robust and reliable.Since they will often be used outside of regular operating hours they must be capable of 24/7 operation.

I/ECDP#6: Internet/Electronic Commerce applications must leverage the use of Electronic Data Interchange (EDI) applications that are currently in use. Many different environments will be connected via electronic commerce with multiple protocols and transports employed by different participants. Although TCP/IP is the prevailing protocol for the Internet, other transports that now exist may require the use of other protocols.

June 3, 2005 5-29


I/ECDP#7: Internet/Electronic Commerce must provide a seamless interface to the user. The electronic commerce architecture must be integrated with the other architectures, especially the application, network and middleware architectures.

Platform The platform architecture defines vendor-independent desktop and server components (hardware and operating systems). The platform ranges from a departmental system that will serve multiple purpose business requirements to mid-range application servers whose breadth may include the extended (i.e., to trusted partners) and external (e.g., Internet) environments. There may be one or more classes of platform used depending on the business requirements. Platform Design principles have been identified as follows:

PDP#1: The platform(s) must be scalable to support both ministry and enterprise requirements.Rapid changes in business processes are enabled in part by implementing a platform infrastructure that exceeds the capacity requirements of existing applications.

PDP#2: The platform must support legacy applications and systems, where required.Although information systems will increasingly be designed as three or more tiers, monolithic (host based) and two-tier (client-server) applications will remain in operation for some time to come.

PDP#3: The platform must be extensible such that it can support multiple business applications simultaneously. This applies mainly to application servers that should be designed for multi-tasking (for better CPU utilization) and multi-threading (to respond to multiple user requests efficiently).

PDP#4: The platform must be highly interoperable to support the standard DBMS and multi-tier application systems.This helps reduce the complexity of integration.

PDP#5: The platform must integrate with the security architecture and be capable of integrating with public key cryptography. Public key cryptography will be one of the primary security mechanisms employed throughout the enterprise and with the external environment.

PDP#6: The platform must be highly manageable and support standards-based management tools - including the applications running on the platform.The platform architecture must be integrated with the systems management architecture.



PDP#7: Depending on the business requirement, the platform must be highly reliable and fault-tolerant.Mission critical systems should not have a single point of failure.

PDP#8: A variety of client access methods must be supported according to business requirements (personal computers, thin and fat clients, voice services and Internet). This reflects the diversity of the Ontario Government’s clientele.

PDP#9: Client access must be ubiquitous and not dependent upon location, given the proper security rights. Client access should only be dependent on authentication and authorization, not on location.

PDP#10: Thin clients must be utilized where possible, but only where security requirements allow.

This reflects the n-tier approach of the application architecture.

PDP#11: Components of the Public Key Infrastructure (PKI), such as the certificate authority, must be secure.PKI components will reside on server platforms that will require exceptionally strong security in order to guarantee the integrity of the systems. Adequate security must also be placed on the less sensitive areas of the PKI such as the Directory.

WorkflowWorkflow is a set of activity based rules that manage the flow of documents through processes or workgroups. Workflow is often built-into custom developed applications, implemented in messaging systems, or implemented in messaging objects. Workflow Design Principles (WFDPs) have been identified as follows:

WFDP#1: Workflow tools and objects must be extensible and scalable.

They must be extensible to support many different applications and they must be scalable to be able to grow to support a greater number of workgroups or a higher information processing load.

WFDP#2: Workflow tools and objects must use activity-based rules that are derived from business functions. By definition, workflow automates activity-focused behavior and must be derived from work architecture, which in turn stems from business functions.

WFDP#3: Workflow applications must be PKI-enabled. Many workflow objects, such as electronic forms, will require digital signatures, and sensitive information will need to be encrypted.

June 3, 2005 5-31


WFDP#4: Workflow tools and objects must work with n-tier architectures.The workflow architecture will have to be integrated with the application, network and middleware architectures.

WFDP#5: Workflow must integrate with the Directory and Messaging to leverage on enterprise-wide message routing capabilities.The workflow architecture must be integrated with the directory/message transport architecture.

Directory/MessageTransport

Directory service provides the means to identify all objects within a networked environment. Messaging provides a transport and routing capability between objects in the network. Directory/Message Transport Design Principles (D/MDPs) have been identified as follows:

D/MDP#1: The Directory and Message Transport technologies must be scalable and extensible. Flexibility and unlimited addressing is needed to facilitate changes in business processes.

D/MDP#2: A standard e-mail address schema must be employed so that they may be logically and consistently found.This is needed not only for human users, but also to aid in the transmission of automated workflow documents.

D/MDP#3: The Directory must be accessible internally within the OPS and in the extended environment (BPS and other trusted partners). This is necessary for applications such as electronic commerce.

D/MDP#4: The Directory must be capable of storing certificates needed for PKI. The Directory architecture must be integrated with the PKI architecture.

D/MDP#5: The Directory will be used for core services such as message routing and certificate lookups, and therefore must be highly reliable and fault-tolerant.The platforms in which the Directory will reside must be robust with no single point of failure.

D/MDP#6: The Directory must be highly manageable and maintainable. Maintaining a directory can be labour-intensive. Automated tools should be used as much as possible.



D/MDP#7: Messaging must be integrated with office automation applications and business specific applications where necessary.The messaging architecture must be integrated with the application architecture.

D/MDP#8: The Directory and Message Routing component must support international and de facto protocols.The most prevalent protocols are X.400, X.500, SMTP and LDAP.

Middleware Middleware is a standard application layer interface that provides a basic functionality that can be used by many different applications. Middleware is commonly found as standard interfaces to messaging infrastructures, transaction-processing systems, and systems management interfaces; it is not limited to providing these capabilities, however. Middleware Design Principles (MWDPs) have been identified as follows:

MWDP#1: Minimize the number of object model standards and manage via the common directory . This will be necessary to ensure interoperability.

MWDP#2: Applications must interface with standardized middleware objects where possible to leverage infrastructure-wide services such as messaging, system management, database access, security services and gateways.Middleware must be used where possible to reduce the cost of recreating and customizing applications to provide the same functionality as other shared services such as e-mail or user authentication.

June 3, 2005 5-33

Chapter 5: Architecture Principles—Security Architecture Principles

5.3 Security Architecture PrinciplesThis section presents security architecture principles grouped under the following categories:

● Administration

● Availability

● Accountability

● Authorization

● Awareness and Training

Administration

Administration Principle 1

I&IT assets and resources will be protected from loss, destruction or unauthorized disclosure in accordance with its value and sensitivity

Motivations Ensure cost-effective (risk-appropriate) investments in I/T security technology.

Implications OPS must define and publish:

Data Classification Standards

Security Standards and Guidelines.Security Processes.

Relates to

Information, Application, Technology, Organization.

❑

❑


The design and implementation of the security infrastructure (e.g., identification, authentication and authorization mechanisms) will be as simple, efficient, common and transparent to the user as possible.

Motivations Minimize impact of security mechanisms on business productivity; encourage compliance.

Implications Need to develop security mechanisms and infrastructure that are not intrusive to the user, e.g.,

Single System Sign-OnPassive Techniques—Smart cards, biometrics

❑

❑

Relates to Information, Application, Technology, Organization


The security of I&IT systems will be audited as required for compliance with statutory, contractual, and policy requirements as well as de facto standards of care that may apply across jurisdictional boundaries.



Motivations

Ensure ongoing security compliance.Ensure jurisdictional boundaries with standards of care when present.

ImplicationsOPS must define and publish:

Security Standards and Guidelines.Data Classification. Criteria for determining appropriate level.E-Commerce framework.Security Processes.Communications.Compliance.Monitoring and Auditing.Life Cycle.Legal Ramifications for non-compliance.

Relates toApplications, Technology, Organization.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑


All systems will be designed and built to incorporate the level of security, privacy, and audibility and control functions which are appropriate to the sensitivity and value of information assets which it uses, controls or manages.

MotivationsEnsure compliance of new systems.

ImplicationsOPS must define and publish

Security Standards and Guidelines.

● Data Classification.

● Criteria for determining appropriate le

● Access Control.

● Audit Trails.

Security Processes.

● Communications.

● Compliance.

● Review and Approval.

● Exceptions and Appeals.

Relates toApplications, Technology.

vel.

❑

❑

June 3, 2005 5-35



An I&IT Architecture will include an Enterprise Security Architecture. The Security Architecture will address IM/IT Security Policies, Standards and Guidelines, and Processes. Security Practices and Standards developed at the cluster, ministry or business unit levels must be aligned with, and conform to, Enterprise Strategies and Directions.

MotivationsEnsure compliance with Security Standards and Guidelines.Ensure compliance of new systems, and on-going compliance.

ImplicationsThe Security Communications Process for the OPS Policies, Standards and Guidelines will demonstrate the support and commitment of senior management.

OPS must define and publish:

Security Policies.Security Standards and Guidelines.

● Data Classification.

● Criteria for determining appropriate level.

● Security Processes.

● Communications.

● Compliance.

● Review and Approval.

● Exceptions and Appeals.

● Monitoring and Auditing.

The OPS Security Policies, Standards and Guidelines will be distributed to the entire organization.

Relates toInformation, Application, Technology, Organization.

❑

❑

❑

❑


The Enterprise Security Architecture, Security Standards and Guidelines will enable implementation of Privacy and Confidentiality Legislative requirements, e.g., the Freedom of Information and Protection of Privacy Act and the Ontario Government Privacy Design Principles.

Motivations

Ensure compliance with FIPPA.

ImplicationsThe OPS Security Architecture and OPS I/T Security Standards and Guidelines must be designed to enable implementation of the privacy and confidentiality requirements of the Freedom of Information and Protection of Privacy Act and the Ontario Government Privacy Design Principles.




Availability

Availability Principle 1

The Enterprise Security Architecture will support key business processes such as Incident Response, Business Continuity and Contingency Planning (Business Impact Analysis), “Survivability” Planning, Security Capacity Planning, and Security “Housekeeping” measures.

MotivationsEnsure that the Enterprise IM/IT Security Architecture addresses availability of Security Resources.

ImplicationsThe OPS Security Standards and Guidelines and Processes must address:

❑ Incident Reporting.❑ Business Continuity.❑ Contingency Planning.❑ Security Capacity Planning.❑ Security Housekeeping (e.g. User ID management).

Relates toTechnology, Organization.

Availability Principle 2

Active counter measures against breaches of security will be implemented to protect I&IT assets, resources and services. The counter measures and level of response to threats will be consistent with the value and sensitivity of protected assets/services.

MotivationsEnsure appropriate active counter measures and responses to threats.

ImplicationsThe OPS Policies must include:

A statement defining what constitutes a breach of security (e.g. rattling the door knob to see if locked.Versus trying to pick the lock).

The OPS Standards and Guidelines must define requirements for

Data Classification.Active Counter Measures.A comprehensive set of tools to assist with the detection and response to security breaches.

❑

❑

❑

❑

❑

June 3, 2005 5-37


The OPS Security Processes must define:

Responses to threats which are consistent with the value and sensitivity of I/T assets, resources and services.

Relates toTechnology, Organization.

Assurance

❑

Assurance Principle 1

The OPS will adopt and comply with industry-standard approaches and standards of care to ensure the secure electronic delivery of services and seamless information exchange with clients (other jurisdictions, vendors, suppliers, and end users).

MotivationsEnsure security complies with industry standards.Ensure jurisdictional boundaries with standards of care when present.Ensure security is upheld when interacting with third parties.

ImplicationsOPS must define and publish:

Security Processes. Communications. Compliance. Monitoring and Auditing.Legal ramifications for non-compliance.

OPS Security Standards and Guidelines must include control requirements for third parties.


❑

❑

❑

❑

❑

❑

❑

❑


As per Management Board Acts and Directives, ministries and agencies will comply with Corporate Policy and Standards as a minimum, but may compliment them with their own IT Standards and Guidelines where and when appropriate.

MotivationsEnsure viability of I&IT assets and resources necessary to support programs and operations through confidentiality, integrity, availability, reliability, and auditability.

ImplicationsTo Be Determined.

Relates toOrganization.




I&IT systems which do not comply with published Security Directives, Policies, Standards or Processes must be formally reviewed and Risk Accepted with the Program Director and Corporate Security Officer.

MotivationsEnsure appropriate level of management visibility and decision-making regarding non-compliant situations.

Implications

Need to design:

Risk Management Process consistent with value and sensitivity of I&IT assets and resources.

Need to ensure that Security Processes include:

Compliance Reviews and Approval. Periodic Reviews of Risk Accepted Systems.


Accountability

❑

❑

❑

Accountability Principle 1

All Government I&IT assets and resources must be accounted for and have a manager designated to be accountable for these assets. The accountable manager will be responsible for determining the value and sensitivity of the information assets in accordance to Security Policy and Legislation.

MotivationsAccountability for appropriate protection of all I&IT assets and resources.

Implications❑

❑

❑

❑

❑

❑

Need to inventory and designate person(s) accountable for all Government I&IT assets and resources.Need to determine responsibilities and rules for designating accountability to people.Need to design process for designating accountability of new assets.Need Classification System.Need to define Roles and Responsibilities for person(s) designated as accountable for I&IT assets and resources.Need to define a chain of accountability and authority.

Relates toInformation, Organization.

June 3, 2005 5-39



Users are accountable for the appropriate and responsible use of I&IT assets and resources in support of the goals and objectives of the overall Security Architecture.

MotivationsEnsure systems are used appropriately, and to ensure remedies are available to the Government in the event of misuse.

Implications Training. Job Descriptions. Conditions of Employment.


❑

❑

❑


Adherence to Enterprise Security Policies and Standards is essential to achieve and maintain proper levels of security. Managers and users who do not adhere to Security Policies and Standards may be subject to disciplinary actions.

MotivationsEnsure consistent execution of security practices.

Implications Training. Job Descriptions. Conditions of Employment.Monitoring and Auditing.

Relates toInformation, Organization.

❑

❑

❑

❑

Authorization

Authorization Principle 1

Access to Information and Information Technology (I&IT) must be controlled on the basis of business need and policies, and have a demonstrated auditability.

MotivationsEnable privacy and confidentiality by limiting access to information on a need to know’ basis.

ImplicationsNeed Classification System to define the protection required for valuable or sensitive information versus published or generally available information.



Relates toInformation, Applications, Technology, Organization

Authorization Principle 2

Access to secure areas will be restricted to those with legitimate requirements and must be physically protected from security threats and environmental hazards consistent with the value and sensitivity of the data contained within the infrastructure.

MotivationsEnsure I/T infrastructure is not physically vulnerable to security threats or hazards.

ImplicationsNeed to define standards.

Relates toInformation, Technology, Organization.

Awareness and Training

Awareness and Training Principle 1

Awareness of Information Security is the responsibility of every OPS employee and agent.

MotivationsEnsure consistent execution across OPS.

ImplicationsSecurity and privacy responsibilities must be included in job descriptions and contracts.All employees and agents must be trained in security procedures and incident reporting processes.Compliance (and being monitored for compliance) must be included in Conditions of Employment.


❑

❑

❑

Awareness and Train-ing Principle 2

Awareness and training programs will be an integral and on-going component of the Government’s Security Architecture and it is the manager’s responsibility to ensure staff are adequately trained.

MotivationsDevelop a culture of security conscious staff within the Ontario Government.Reduce overall threat of security breaches through human error or negligence.

❑

❑

June 3, 2005 5-41


ImplicationsAll employees must be trained in security procedures and incident reporting processes.Compliance (and being monitored for compliance) must be included in Conditions of Employment.


References Management Board of Cabinet Directive: Information and Information Technology Security —March 3, 1998Information and Information Technology Security: Operating Procedure on Usage of I.T. Resources (Draft)—January 28, 2000Information and Information Technology Security: Operating Procedure on Internet, Intranets and Extranets (Draft)—January 28, 2000British Standard 7799NIS

❑

❑

❑

❑

❑

❑

❑


Appendix A: OPS EA GlossaryTerm Definition Source

Accreditation Accreditation - official authorization and approval that is granted to a computer system or network, to process sensitive date is a particular operation environment. Specific technical personnel perform accreditation after a security evaluation of the system’s hardware, software, configuration, and security controls.

EA Phase 1

Activity An activity is an action carried out by an employee, or other authorized agents, in the execution of a business process.

ChartwellUpdated in V 3.0

Alignment The arrangement of enterprise components to meet the outcomes of the enterprise.

BA for EA Report

Application Automated processes that are designed and created to meet business needs.

EA Phase 1Updated in V 3.0

Architect Person responsible for creating architecture for an enterprise or in a particular domain.

Adapted from BA for EA Report

Architecture 1. The design of anything that has been or is intended to be built.2. “The architecture of an IT system is the structure or structures of

the system, which comprise software and hardware components, the externally visible properties of those components, and the rela-tionships amongst them”.

1. Allstream2. Adapted from

[Bass, Clements and Kazman, 1998].

Artifact In the context of enterprise architecture, an artifact is an architecture work product such as a model or a list.

Allstream

Assurance A measure of confidence that the security features and architecture of an information system accurately mediate and enforce the system’s security policy. If the security features of an information system are relied on to protect sensitive information and restrict user access, the features must be tested to ensure that the security policy is enforced and may not be circumvented during information system operation.

EA Phase 1

Authentication The security mechanism or process of proving that a subject (e.g., user or a system) is what the subject claims to be. Authentication is a measure to verify the eligibility of a subject and the ability of that subject to access certain information. It protects against the fraudulent use of a system or the fraudulent transmission of information. There are three traditional ways to authenticate to a system: something you have, something you know, and something you are.

EA Phase 1

Authoritative Framework

Contains architectural information that has been approved in the architecture review process. Approved information can describe existing business and IT practices, systems, technology, etc, and can also describe intended changes to existing components.

Chartwell

Availability A security policy requirement that is aimed ensuring the ability of a system to keep working efficiently and to keep information accessible.

EA Phase 1

Biometrics In computer security, the use of unique, quantifiable physiological, behavioral, and morphological characteristics to provide positive personal identification. Examples of such characteristics are fingerprints, retina patters, and signatures.

EA Phase 1

BPS Broader Public Sector (e.g., schools and hospitals) EA Phase 1

Appendix A: Glossary

Term Definition Source

Business Architecture

The design, structure and behaviour of an enterprise’s business components.


Business Component

A constituent element of a business model. Adapted from BA for EA Report

Business Drivers Defined business requirements for the target information and information technology environment. In this context, business requirements determine the level of information sharing, processing, security, etc., needed to meet the mandates of the programs across Government and with its partners.

EA Phase 1

Business Process A sequence of related activities designed to produce a specific output. AllstreamBusiness-to-business (B2B)

Business-to-business (B2B) e-commerce requires a two-way interaction between two businesses (businesses serve each other through B2B) and needs that the two organizations know each other and work on setting up the B2B system together. The B2B e-commerce is often implemented through extranets.

Chartwell

Business-to-consumer (B2C)

In business-to-consumer (B2C) e-commerce no prior relationship between the business and the consumer (who can represent a business) needs to be established. The business serves the consumer (the business attracts, interacts, informs, offers and sells products and offers customer service to consumer), whereas the consumer requests information, service and buys products and services from the business.

Chartwell

CA An acronym for Client Access or Certificate Authority (an organization that issues "certificates" of authenticity in a Public Key Infrastructure).

EA Phase 1

Cell (of a Zachman Framework)

In the context of the Zachman Framework, a cell is the intersection between one of the six rows of the Framework, representing a stakeholder perspective, and one of six columns, each representing an aspect of an enterprise in response to one of six possible interrogatives (What, How, Where, Who, When, and Why).

Allstream

Certification The technical evaluation performed as part of, and in support of, the accreditation process that established the extent to which a particular computer system or network design and implementation meet a pre-specified set of security requirements.

EA Phase 1

Change Initiative Framework

In the context of the Federated Frameworks Model, a Change Initiative Framework is a temporary framework used to guide the development of models and other artifacts that are created during the life cycle of an I&IT project.

Allstream

Channel A service delivery method, e.g., kiosk or over the counter. EA Phase 1Client An individual or organization who uses, or applies to use, or is

required to use via statute or regulation products or services of the Ontario Government. Clients may be citizens, businesses and partners (e.g. other governments, employees, judicial/legal enforcement, media, ad hoc groups) of the Ontario Government.

EA Phase 1

Chartwell

Client Access A device that grants access into an organizations information and information technology environment. The degree of access is determined and managed by the security component of the environment. Examples are personal computers (PCs), network PCs, output devices such as printers and interactive devices such as kiosks.

EA Phase 1

A-2 EAPM Version 3.0



Client Server A computing model defined as an application operating on one computer (a Client), which then calls for services residing on another computer (a Server) in a network.

EA Phase 1

Column (of a Zachman framework)

The columns of a Zachman Framework represent aspects of the enterprise responding to the six classical interrogatives - What, How, Where, Who, When and Why. In the case of enterprise architecture, the six interrogatives correspond to Data, Function, Network, people, Time, and Motivation.

Allstream

Common I&IT Infrastructure

The basic information and information technology components that are required to meet the needs of the business across ministry or program boundaries. The infrastructure will maximize the integration and sharing of information and processes across the Ontario Public Service and other partner organizations.

EA Phase 1

Component A constituent element of a system. BA for EA ReportConfidentiality A security policy requirement that aims at preventing unauthorized

access to information. Synonymous with secrecy.EA Phase 1

Core Businesses The primary responsibilities of a ministry - what it must achieve to be effective. The core businesses are described in the annual Ontario Government Business Plans.

EA Phase 1

Corporate Initiative Internal projects or initiatives that shape the way in which the government organization operates.

Chartwell

Criteria Trusted computer system evaluation criteria provide a basis for the evaluation of the effectiveness of security controls built into automated data processing products. Criteria are used in the determination of levels of assurance (trust). Examples are (1) the Department of Defense Trusted Computer System Evaluation Criteria and (2) the Common Criteria.

EA Phase 1

Customize To alter an original design to meet specific individual requirements. This should be avoided if possible with regards to software as it incurs additional costs not only for the customized development but also for ongoing support.

EA Phase 1

Data Representation of facts, concepts, or instructions in a formalized manner, suitable for communication, interpretation, or processing by humans or by automated means. Any representations such as characters or analog quantities to which meaning is or might be assigned.

OPS IMH

Database A database is a collection of data that is organized so that its contents can easily be accessed, managed, and updated. The most prevalent type of database is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.

OPS IMH

Database Management System (DBMS)

A program that lets one or more computer users create and access data in a database. The DBMS manages requests from users and other programs.

OPS IMH

June 3, 2005 A-3



Digital Signature A digital code that can be attached to an electronically transmitted message that uniquely identifies the sender. Like a written signature, the purpose of a digital signature is to guarantee that the individual sending the message really is who he or she claims to be. Digital signatures are especially important for electronic commerce and are a key component of most authentication schemes. To be effective, digital signatures must be unforgeable. There are a number of different encryption techniques to guarantee this level of security.

EA Phase 1

Due Diligence The process of systematically obtaining and assessing information in order to identify and contain the risks associated with a transaction (e.g., buying a business) to an acceptable level.

EA Phase 1

Directory A lookup facility containing information such as description and location of a person or thing.

EA Phase 1

Document The units of information for sharing or exchange.Documents hold information, have many formats, and reside in electronic folders (assuming an electronic work environment). Documents are the products that are processed by the workgroups and workflows and are effectively the unit of information exchange. It should be recognized that the notion of document includes text, images, sound tapes, multi-media or "compound" documents, as well as structured data, which, when presented in human-usable form, are contained within traditional looking documents such as spreadsheets, tables and graphs. In addition, it is important to keep in mind that the concept of document is more than a container of information; rather, in the modern sense "intelligent" documents point to other sources of information, other documents and databases, and can guide readers through their subject content and present their information in an interactive manner.

EA Phase 1

Domain A domain is a subject area, which defines a context for analysis and description of some aspect of an IT system.

META Adaptive Infrastructure Strategies Infusion Workshop

EDI EDI (Electronic Data Interchange) - data sharing using standard record formats.

EA Phase 1

E-Government E-Government (Electronic Government) - the electronic delivery of government services.

EA Phase 1

Electronic Business (e-business)

Application of Internet technology to business problems or transforming key business processes through the use of Internet technologies.

Chartwell, IBM

Electronic Commerce (e-commerce)

Refers to automated financial transactions. Chartwell

Enterprise 1. Any purposeful endeavour. The concept of enterprise includes everything that is required to fulfill the purpose of the endeavour.

2. Synonym for business.

Allstream


An individual skilled in the discipline of planning, designing, building, and maintaining enterprises.

Allstream




Enterprise Architecture

1. A set of models representing an enterprise in its current or intended future state.

2. The process of creating the models representing an enterprise.3. The discipline of planning, designing, building, and maintaining

enterprises.

Allstream

Enterprise Architecture Framework

A structure for identifying and organizing the models comprising enterprise architecture.

Allstream

Enterprise Architecture Repository

A database for storing models and other information related to enterprise architecture.

Allstream

Event An occurrence that causes the need for a response of service. EA Phase 1Extensibility The ability to change the functionality of an application without

changing its programmed code (e.g., user-defined functions by means of a drop-down menu).

EA Phase 1

Extranet An intranet that is partially accessible to authorized outsiders. Whereas an intranet resides behind a firewall and is accessible only to people who are members of the same company or organization, an extranet provides various levels of accessibility to outsiders.

EA Phase 1

Federated Enterprise Architecture

A collection of architectures of the sub-enterprises of a larger enterprise. This approach is often taken when an enterprise is too large and complex to architect as a single entity.

Allstream

Federated Frameworks Model

A model representing the structure established by the OPS for creating and maintaining the federated architecture of the Ontario Government enterprise.

Allstream

Firewall A system designed to prevent unauthorized access to or from a private network. Firewalls can be implemented in both hardware and software, or a combination of both. Firewalls are frequently used to prevent unauthorized Internet users from accessing private networks connected to the Internet, especially intranets. All messages entering or leaving the intranet pass through the firewall, which examines each message and blocks those that do not meet the specified security criteria.

EA Phase 1

Business Function A group of business processes that together completely support accomplishing a major subdivision of the total body of work needed to achieve the goals of an enterprise.

Allstream

Gateway A server that provides access between networks; may perform conversion from one protocol to another, e.g., to convert from ESMTP to X.400.

EA Phase 1

HTML HTML - Short for HyperText Markup Language, the authoring language used to create documents meant to be viewed via intranets, extranets and the World Wide Web.

EA Phase 1

I&IT Infrastructure Encompasses data, applications, technology, networks, security and includes all related policies and standards, and planning and design processes. Corporate I&IT architecture function is mandated to define and recommend improvements to I&IT infrastructure which is common across the government or shared between several clusters. Cluster I&IT architecture function is mandated to define and recommend improvements to in-cluster infrastructure.

Governance Workshop Services Summary.ppt

Information Meaning derived from facts or data, within a specified context. EA Phase 1

June 3, 2005 A-5



Information Management

The planning, budgeting, manipulating, and controlling of information throughout its life cycle.

EA Phase 1

Information System A discrete set of information resources organized for the collection, processing, maintenance, transmission, and dissemination of information, in accordance with defined procedures, whether automated or manual.

EA Phase 1

Integrated Using common means to achieve common goals. AllstreamIntegrity A security policy requirement that aims at preventing information

from being modified or otherwise corrupted either maliciously or accidentally. Mechanisms that assure integrity protect against forgery or tampering. Synonymous with accuracy.

EA Phase 1

Internet The Internet (also known as the Net) is comprised of a series of interconnected computer networks using the same technology, leading to the World Wide Web (WWW), which is the abstract space where people connect through documents, pictures, sound, or video.

Chartwell

Interoperability In the field of information technology, the ability of computers to provide information to and receive information from other computers, and to use the information so exchanged to enable them to work effectively together.

EA Phase 1

Intranet A network based on TCP/IP protocols (an internet) belonging to an organization, usually a corporation, accessible only by the organization's members, employees, or others with authorization. An intranet's Web sites look and act just like any other Web sites, but the firewall surrounding an intranet fends off unauthorized access. Like the Internet itself, intranets are used to share information.

EA Phase 1

ISO ISO - International Standards Organization. EA Phase 1Item A subdivision of a VOTE, representing an enterprise established to

deliver programs and services.Allstream

IT System A combination of hardware, software and documentation that implements and describes a business solution.

META Adaptive Infrastructure Strategies Infusion Workshop

IVR IVR - (Interactive Voice Response), automated telephone response systems. The generation of voice output by computer. It provides pre-recorded information either with or without selection by the caller. Interactive voice response allows interactive manipulation of a database.

EA Phase 1

Knowledge Contextual information that is learned. There are two categories of knowledge: explicit and tacit knowledge. Examples of explicit knowledge include information that is normally found in documents (e.g., text, graphs, tables, etc). Tacit knowledge includes techniques for doing things and knowledge gained through training and experience.

EA Phase 1

Legacy Existing information or information technology, often containing important data and functionality that may need to be migrated to or accessed by other, more modern IT solutions.

EA Phase 1

Mandate Can be stewardship, social, or economic. Nodes.docMessaging Messaging - the sending and receiving of electronic information. EA Phase 1




Metadata Data used to aid the identification, description and location of information resources. May include information such as the author of a work, the date of creation, links to any related works, etc.

EA Phase 1

Meta-framework A framework used to define the form and content requirements of the models in an enterprise architecture framework.

Allstream

Metalevel A metalevel is a level of knowledge about some other level of knowledge. The Object Management Group has defined four metalevels as follows:❑ Metalevel M0 – a data record or specific instance of a data

element, e.g., someone’s date of birth.❑ Metalevel M1 – a particular data element definition, e.g.,

definition of a date of birth data element.❑ Metalevel M2 – a specification for the means of defining data

elements, i.e., a metamodel describing the structure and metadata requirements of data elements.

❑ Metalevel M3 – the language in which the M2 things are specified, e.g., UML.

Allstream

Metamodel A model that describes the structure and content requirements of a model.

Allstream

Model A representation or abstraction of something, actual or proposed. AllstreamObject-oriented A software development methodology wherein software is designed

and created as objects that contain data and the procedures for operating on that data.

Allstream

Organizational Unit One person or a group of people and resources with a specific business goal, and related to other such groups via the organizational structure of a company. An organizational unit is a point of actual or delegated accountability, responsibility and/or authority.

EA Modeling Rules.ppt

Owner of an artifact's primitive (standard column name in most Excel artifacts)

Owner of primitive - individual or organization permitted to change the primitive (any of its attributes).

Chartwell

Patterns, Templates and Reusable Components Library

Contains abstract or generic patterns and templates expressing best practices and/or standards for architectural information. The patterns and templates are intended to be copied into service frameworks and customized as needed.

Chartwell, Allstream

Performance Metric A Performance Metric is the name of a calculation that:- measures the quality, efficiency and/or effectiveness of a program, a

service, a resource, and/or an activity;- specifies what you are going to measure;- names and classifies the metric (quality, efficiency and/or

effectiveness);- specifies the formula for the metric;- sets a target value for performance level.

Chartwell

Platform The hardware and operating system software operated by an organization to accomplish a function.

EA Phase 1

June 3, 2005 A-7



Primitive model In the context of the Zachman Framework, the Business Model (Row 2), the System Model (Row 3), and the Technology Model (Row 4) are each comprised of primitive models corresponding to the six cells in their particular rows. These models are said to be primitive in that they do not overlap (i.e., are mutually exclusive) and completely describe the models that they comprise.

Allstream

Principle Enduring and fundamental beliefs of the enterprise, in one or two clearly written sentences, which recommend an action or approach against which some arguments could be made. Principles must be relevant to the security architecture and worded directly and simply in terms understandable by both business and IT managers. A principle is supported by documentation of the reasons (Motivations) for it being stated and the effect (Implications) it will have on future privacy decisions.

Examples of Artifacts.ppt

Privacy The right of an individual to self-determination as to the degree to which personal information will be shared among other individuals or organizations. This includes the right of individuals and organizations to control the collection, storage, and dissemination of personal information.

EA Phase 1

Program In the context of the OPS, a mandate conferred upon a Ministry to achieve goals and outcomes that address the identified needs of a target group.


Program Manager A role within an organization accountable for the outcomes of a program.

BA for EA report

Protocol A protocol extends the concept of an interface to include the allowable sequences of requests, possibly across many interfaces. Defined in terms of Interactions.

EA Phase 1

Public Key Encryption

A type of encryption that uses two mathematically related keys. The public key is known within a group of users or posted to a directory. The private key is known only to its owner. The infrastructure that supports public key encryption is known as Public Key Infrastructure (PKI).

EA Phase 1

Public Key Infrastructure (PKI)

See Public Key Encryption. EA Phase 1

Reference Model A generic design of an enterprise component, of which the enterprise may have multiple instances.

BA for EA Report

Resource Something owned or managed by the enterprise that is employed directly in the delivery of services and the execution of activities:

● can be supplied directly by external Suppliers or can be created through “internal” services;

● is prime indicator for information requirements.Different categories of resources include:

● Infrastructure (e.g. sanitary sewer network)Vehicle (e.g. snow plow)Equipment (e.g. leaf blower)Human Resource (e.g. fire fighter)Facility (e.g. water treatment plant)Fund (e.g. tax account).

●

●

●

●

●

Chartwell




Reuse The concept of reapplying existing information, software and infrastructure to meet new requirements, without having to start from scratch.

EA Phase 1

Row (of a Zachman framework)

Each row of the Zachman Framework for Enterprise Architecture represents the perspective of a key stakeholder interest. Each row serves to establish the boundaries of the rows below them. There are six rows, and they correspond to the perspectives of the Planner, Owner, Designer, Builder, Subcontractor, and User.

Allstream

Scalable A popular buzzword that refers to how well a hardware or software system can adapt to increased demands. For example, a scalable network system would be one that can start with just a few infrastructure components but can easily expand. Scalability can be a very important feature because it means that you can invest in a system with confidence you won't outgrow it. Refers to anything whose size can be changed. For example, a font is said to be scalable if it can be represented in different sizes.

EA Phase 1

Security Mechanisms

Devices and measures used to implement rules stated in security policies and standards. Security mechanisms can be divided into three categories: prevention, detection and recovery mechanisms. Within each group, there are many security mechanisms available, where each mechanism focuses on a specific kind of threat and deals with a specific form and aspect of security.

EA Phase 1

Security Policy The set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive information.

An information Security Policy is necessary to provide management direction and support for information security. Top management should set a clear direction and demonstrate their support for and commitment to information security by establishing a Company-wide information security policy.

EA Phase 1

Conceptual Security Architecture.doc

Service A Service provides specific results (deliverables) that satisfy the needs of a target group and contribute to the achievement of program goals.

BA for EA Report

Service Manager A role within an organization accountable for the outputs of a service. BA for EA ReportTarget Group The population or segment of the population that is the intended

beneficiary of a Program or the intended recipient of a Service.BA for EA Report

Topics Library A topic index containing pointers to artifacts in other libraries and frameworks based on defined areas of interest, e.g., water management. This library serves the role of a “thread” through all the frameworks/libraries artifacts.

Allstream

Standards and Guidelines Library

The Standards and Guidelines Library contains the consolidated principles, guidelines, standards which govern the design of (business and) systems and technology.

Chartwell, Allstream

State of a primitive State of a primitive - review and acceptance status of a primitiveApproved - reviewed and accepted by the framework ownerProposed - reviewed but not yet accepted by the framework owner Notional - identified but requires review and acceptance by the framework owner.

Chartwell

Vote A relatively broad segregation of spending authority for some intended purpose, such as expenditures for a group of programs or for capital investments.

Allstream

June 3, 2005 A-9



Workflow A workflow is a set of one or more manual or automated processes that are integrated to support and deliver any output of the Ontario Government. It includes a series of tasks and routings that control how documents move from person to person, from workgroup to workgroup, or from one automated process to another.

Workflow - the "flow" of enterprise-wide and core business processes, workgroup activities or information, which together complete a service.

Workflow is the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step in a business process. Workflow management focuses on processes.

EA Phase 1,

Chartwell

Zachman Framework

A generic framework used to identify, classify and organize descriptive information about any complex object. The Framework as it applies to enterprises is a logical structure for classifying and organizing the descriptive representations of an enterprise that are significant to the management of the enterprise as well as to the development of the enterprise’s systems.

“The Framework for Enterprise Architecture: Background, Description and Utility,” John Zachman, 1996.


Appendix B: EAPM Acronyms

Acronym Description

AADWG Application Architecture Domain Working GroupABBs Application Building BlocksACID Atomicity, Consistency, Isolation and DurabilityACTs Architecture Core Teams (Corporate or Cluster ??)ADMs Assistant Deputy MinisterADPs Application Design PrinciplesAPI Application Program InterfaceARBs Architecture Review BoardsASD Alternative Service DeliveryBADWG Business Architecture Domain Working GroupBCP Business Continuity PlansBPS Broader Public SectorCAD Computer Aided DesignCARB Cluster Architectural Review BoardCFL Centre for LeadershipCIFs Change Initiative frameworks.CIO Cluster Chief Information OfficerCIPMC Section 2.2.4, Page 2-20COE Centre of ExcellenceCOM Component Object Model COMSOC Community & Social ServicesCORBA Common Object Request Broker ArchitectureCRUD Create, Read, Update and DeleteCSB Communication Services BranchCTI Computer Telephone IntegrationD/MDPs Directory/Message Transport Design PrinciplesDBMS Data Base Management System DCOM Distributed Component Object ModelDDLs Data Definition LanguageDDPs Database Design PrinciplesDM Data MartDMCOT Deputy Ministers’ Committee on OPS TransformationDRP Disaster Recovery PlansDWA Data Warehouse ArchitectureECDPs Electronic Commerce Design Principles

Appendix B: Glossary

Acronym DescriptionEA Enterprise Architecture EMC Executive Management CommitteeEAMWG Enterprise Architecture Domain Working groupERPS Enterprise Resource Planning SystemESD Electronic Service DeliveryFIPPA Freedom of Information and Protection of Privacy ActFIS Financial Information SystemFOI Freedom of InformationGIS Geographic Information SystemsI & IT Information & Information TechnologyICC Infrastructure Component CatalogueIITDC Information and Information Technology Deputies CommitteeIITMC Information and Information Technology Management CommitteeIMH Information Modeling HandbookINDPs Integrated Network Design PrinciplesIADWG Information Architecture Domain Working GroupIRP Interjurisdictional Registration PlanISD Integrated Service DeliveryISO International Standards OrganizationITELC Information Technology Executive Leadership CouncilITSC Information Technology Standards Committee LOB Line of business LRC Land & Resources ClusterLUWs Logical Unit of WorkMBC Management Board of CabinetMBS Management Board SecretariatMCBS Ministry of Consumer & Business ServicesMCzCR Ministry of Citizenship, RecreationMMA&H Ministry of Municipal Affairs and HousingMNR Ministry of Natural ResourcesMOE Ministry of the EnvironmentMOHLTC Ministry of Health and Long-Term CareMTO Ministry of TransportationMWDPs Middleware Design PrinciplesOCCIO Corporate Chief Information OfficerODBC Open Database Connectivity DriversOLAP Online Analytical ProcessingOLTP Online Transaction ProcessingOMG Object Management Group

B-5 EAPM Version 3.0


AcronymOPS ORBs OSC PIA PKI PMA PMO RDBMS RDBMS RFPs SADWGSD SDLCSDMSLA SMC SMDPs SQL TADWGTCP/IP TLCTPS

DescriptionOntario Public SectorObject Request BrokerOntario Science CentrePrivacy Impact AssessmentPublic Key Infrastructure Policy Management AuthorityProject Management OfficeRelational Database Management SystemRelational Database Management System Request for ProposalSecurity Architecture Domain Working GroupSummarized DataSystems Development Life CycleSoftware Development MethodologyService Level AgreementSenior Management CommitteeSystem Management Design PrinciplesStructured Query Language Technology Architecture Domain Working GroupTransmission Control Protocol/Internet ProtocolTransformation Leadership CommitteeTransactions Per Second

TRA Threat Risk AssessmentUML Unified Modeling LanguageVPN Virtual Private NetworkWCB Workers Compensation BoardWFDPs Workflow Design PrinciplesWHIMIS Workplace Hazardous Material Information System

June 3, 2005 B-6


B-7 EAPM Version 3.0

enterprise architecture process and methods handbook

Documents

eapm version

eapm handbookoverview

architecture methods

appendix d

appendix c

appendix e

appendix b

ops ea glossary