EA Guiding Principles

CMHC EA Strategic documents
Enterprise Architecture Principles
Published by: CMHC-I&T-EA

Status: Draft
Version: 1.0
Date Modified: June 10, 2015
Document No.:
InfoShare Location:
File Name:
Prepared by: EA Team Recommended by: Serge Parisien
Edited by: Approved by: Bruce Langevin
This publication was produced on behalf of the Director of Operational Excellence and I&T
Governance. The latest version is available online at <put URL here>
Please forward any question or comments to the Manager Enterprise Architecture.
This publication does not contain any PROTECTED information.
Published by: CMHC-I&T-Enterprise Architecture

CMHC’s Enterprise Architecture Principles
Revision Record Sheet
VERSION DESCRIPTION DATE AUTHOR & NOTES

NO. ISSUED
2015.01 Initial Draft Document May 1, 2015 First draft of the
document
2015.02 Revised draft June 10, 2015 Serge based on Gartner
feedback and Helen’s
comments
2015.03
2015.04
Prerequisite readings
N/A
Purpose of this document
The purpose of this document is to present CMHC’s Enterprise Architecture principles to
be used as a decisional framework when considering process, system and technology
directions. These principles can also be used to justify exceptions.
The content of this document is the result of research conducted with several on-lines
sources including Gartner, InfoTech, IBM, the City of Edmonton and the University of
Birmingham.
Target Audience
The principles found in this document are to be used as guiding principles for all audiences
involved in the formulation of proposals, business cases, solution designs, request for
proposals and outsourcing agreements.
This Version
This version incorporates the result of research done by the EA team in conjunction with
industry experts and advisory research firms.
Further Readings
EA Charter.
CMHC-I&T- Enterprise Architecture II

Content of the document
1 Introduction 1
1.1 Content and Purpose 1
1.2 Definition 1
1.3 Presentation Format of Each Principle 2
1.4 Categories of Principles 2
2 General Principles 3
2.1 Align with the Business 3
2.2 Include Business Continuity into Planning and Decision-Making 4
2.3 Adopt Industry Best Practices 5
2.4 Comply with Standards, Policies and Regulations 6
2.5 Reuse before Buy, Buy before Build 7
2.6 Deliver Maximum Benefits at the Lowest Cost and Risks 8
3 Information Principles 9
3.1 Treat Information as a Corporate Asset 9
3.2 Make Information Accessible, Shareable and Consumable 10
3.3 Use Common Terminology and Definitions 11
4 Application Principles 12
4.1 Design Simple and Easy to Use of Applications 12
4.2 Adopt Flexibility and Adaptability 13
4.3 Align with the Enterprise Architecture 14
4.4 Apply Enterprise Architecture to Externally Hosted Applications 15
4.5 Implement Service-Based Interfaces 16
4.6 Adhere to Functional Domains 17
5 Technology and Security Principles 18
5.1 Implement Changes Based on Requirements 18
5.2 Control Technical Diversity and Suppliers 19
5.3 Design Solutions with Interoperability in Mind 20
5.4 Use a Risk-Based Approach to Security 21
5.5 Design Solution with Security in Mind 22
6 Lexicon, Abbreviations and Acronyms 23
7 Appendix A - Diagram of Enterprise Architecture Principles 25
References
Ref id Ref title
CMHC-I&T- Enterprise Architecture III

EA Research http://opentext.cmhc-schl.gc.ca/OTCS/llisapi.dll/open/6419388
CMHC-I&T- Enterprise Architecture IV

1 Introduction
Content and Purpose
1 Introduction
1.1 Content and Purpose

This document was developed with the purpose of presenting a set of principles for CMHC’s Enterprise
Architecture (EA) Program. Defining such principles is the first step in establishing a solid foundation for a
decisional framework that will ensure proper alignment with business direction and best practices as well as
guide investments in information and technology. At the outset, the resulting decisions based on these
principles will add value and differentials to the business.
This list was organized and developed based on the selection and adjustment of the most relevant principles
in consultation with several authoritative sources with a particular focus on the financial sector context
being very relevant to CMHC. This being said, these principles are fairly generic and apply to any type of
organization or industry.
1.2 Definition
Principles are basically high-level definitions of fundamental values that guide both business and technology
decisions, serving as the basis for architecture development, policies, and standards. The principles of EA
define general rules and guidelines to use and implement with all Information and Technology (I&T)
resources and assets throughout an organization. They must reflect a level of consensus between several
corporate elements, constituting the basis for current and future decisions regarding CMHC’s business and
technology direction.
Each architecture principle must focus mainly on business goals and the implications to the organization.
CMHC-I&T-EA Page: 1
EA Guiding Principles version 2 0 (Final) (3) (15.12.21 11:46)
1 Introduction
Presentation Format of Each Principle
1.3 Presentation Format of Each Principle

Each principle must be formally stated. This document follows the format suggested by The Open Group
Architecture Framework (TOGAF), in which each principle is presented according to the following format:
Name
The name must represent the essence of the principle and be easy to remember. Specific technology
platforms must not be mentioned in a principle's name or description.
Description
The description must succinctly and directly convey the fundamental guideline. Most information
management principle descriptions are similar among different companies.
Rationale
This must highlight business benefits generated by adhering to the principle, using business terminology. It
must emphasize the similarity between information and technology principles and those that regulate
business operations. The rationale must also describe its relationship to other principles and intentions
compared to a balanced interpretation. It should describe situations in which a certain principle would
outweigh another in the decision-making process.
Implications
This item must highlight requirements, both for businesses and I&T, to comply with the principle regarding
resources, costs, and activities or tasks. The impacts in businesses and consequences of adopting a principle
must be detailed. Readers must be able to easily answer the following question: "How does this affect me?"
It is important not to simplify, trivialize, or question the merit of such impacts. Some implications are
exclusively identified as potential impacts, with a speculative characteristic as opposed to being fully
analyzed.
1.4 Categories of Principles

In most organization, there are around 20 Enterprise Architecture principles that must be followed. A very
short list containing more generic and ethereal principles, may hinder the practical application of these
principles. On the other hand, an excessively extensive list is too specific and generates inconsistencies and
conflicts between principles and changes resulting from technological, environmental, and contextual
evolution. We have chosen a set of Enterprise Architecture guiding principles organized in four categories.
 General Principles
 Information Principles
 Application Principles
 Technology and Security Principles
CMHC-I&T-EA Page: 2
2 General Principles
Align with the Business
2.1 Align with the Business
Description
Use the business alignment perspective to make information management decisions and aim to generate
maximum value for the Corporation as a whole.
Rationale
This principle means "service above all." A better alignment between I&T and the business will result in a
more effective delivery of value in achieving CMHC’s mandate. Decisions based on the corporate
perspective and its priorities have greater long-term value than decisions based on a certain perspective of
a group with a specific interest. An optimal ROI requires decisions to be aligned with the Corporation's
priorities and positioning.
Implications
 Aligning I&T with the business and promoting optimal corporate benefits requires changes in how
information is planned and managed. Technology alone is not enough to promote such changes.
 I&T cost management must focus on services directed allowing the business to effectively deliver its
mandate.
 I&T management must assess its performance against key indicators in alignment with business
performance objectives.
 I&T must implement a complete I&T vision and supporting architecture that is focused on business.
 Some areas might need to waive their specific preferences to benefit the Corporation as a whole.
 Application development priorities must be established by and for the entire Corporation.
 Application components must be shared among all areas of the organization.
 Information and technology initiatives must be conducted based on a corporate plan. Business lines
must align with these information and technology initiatives in accordance with corporate plans and
priorities.
 As new needs arise, priorities must be adjusted proportionally. A corporate prioritization committee
must make such decisions.
CMHC-I&T-EA Page: 3
Include Business Continuity into Planning and Decision-Making
2.2 Include Business Continuity into Planning and

Decision-Making
Description
Define and maintain a set corporate processes and activities that can be invoked in the event of
interruptions always keeping business continuity top of mind.
Rationale
As any other organization, CMHC face uncertainty and change. Consequently, we must ensure business
critical activities are able to continue to function despite internal and external events. We must apply a risk/
impact analysis to our decision making and planning to ensure potential issues are planned for. As a result,
specific organizational alternative mechanisms will be required to manage these unexpected risks and their
impacts.
Implications
 Dependence on shared applications implies that business interruption risks must be expected and
managed in advance. Management includes, but is not limited to, periodic revisions, vulnerability and
exposure tests, or designing business critical services to ensure continuity through redundancies or
alternative resources.
 Risk and impact analysis must be included within planning and decision making.
 Recoverability, redundancy, and maintenance must be approached at inception.
 Applications must be assessed regarding criticality and impact on the Corporation's mission to determine
which continuity level is required and which corresponding recovery plan must be implemented.
 Business resumption plans must be part of the overall business continuity strategy.
CMHC-I&T-EA Page: 4
Adopt Industry Best Practices
2.3 Adopt Industry Best Practices
Description
Align information and technology activities to industry best practices in areas such as processing,
technology, governance and management.
Rationale
An organization must always strive to adopt the best practices from its industry in its business activities. The
I&T organization must follow the same strategy to enhance business activities. I&T must deliver projects and
services on progressively shorter deadlines and with increasingly higher quality within an effective cost-
control process.
Implications
Best practices for I&T disciplines must be identified and studied to implement them properly. These
disciplines, among others, must follow best practices:
 I&T processes must be certifiable and use established metrics.
 Adopt continuous improvement and build this approach into management and governance processes.
 There must be an enterprise risk perspective, focused on no tolerance for failure and records of incidents
and events.
 The management of I&T costs per service must be aligned with those of the industry and commensurate
to the organization’s risk appetite.
 I&T management must be focused on indicators and a program perspective.
 Staff must be increasingly qualified and motivated.
 The established architecture must be effectively applied in projects.
CMHC-I&T-EA Page: 5
Comply with Standards, Policies and Regulations
2.4 Comply with Standards, Policies and Regulations
Description
Corporate information and technology management processes must comply with all applicable internal
policies and regulations.
Rationale
Corporate information and technology management policies must comply with internal policies as well as
external laws and regulations. This does not prevent improving corporate processes that conduct policy
changes.
Implications
 The Corporation must ensure compliance with all internal policies and external regulations regarding the
use, retention, and management of information and technology assets.
 It must inform and provide access to all applicable rules. Efficiency, need, and common sense are not the
only incentives. Changes in standards, policies and regulations might lead to changes in processes or
application.
 While there is a strong imperative to follow prescribed standards and policies, on occasions, exceptions
will be part of reality. Consequently, a process needs to be in place to properly document and escalate
decisions related to exceptions.
CMHC-I&T-EA Page: 6
Reuse before Buy, Buy before Build
2.5 Reuse before Buy, Buy before Build
Description
Prior to acquiring new assets, the Corporation will reuse applicable existing information and technology
assets. If no existing internal asset is available for reuse, the preference is to acquire, by purchasing or
licensing, applicable externally available assets. The Corporation’s least preferred option is to custom build a
new asset.
Rationale
Reusing information and technology assets (for example, automated systems or data) that are already
available is often the simplest, quickest, and least expensive solution, assuming that the assets in question
sufficiently fit the intended purpose. It is less expensive to buy standard technology solutions than to
custom build them, as long as they are not adapted and maintenance is left to the product supplier. Many
authoritative data sources make their data products available (or offer data acquisition/generation
services), reducing the need to generate such data. Custom development of assets is often very expensive
to sustain.
Implications
 When functionality is required, existing I&T assets in the organization must be evaluated and used first,
unless they do not exist and/or are a significant mismatch to the required functionality.
 The Corporation must have a unified approach to a) identifying the business functions that are allowed
to differ from industry standard practices in using corporate assets and commercial off the shelf (COTS)
solutions, and b) determining the extent to which these functions are allowed to be different.
 To ensure that I&T assets are being reused as much as possible, business areas must be prepared to
adapt to existing solutions that provide adequate functionality, particularly in situations where the
accountable governance body does not deem that business area’s practices to be required to be
different from industry standard practices.
 The Corporation will prefer COTS products and particularly those that are configurable. Some products
are so configurable that there is little difference between extensive configuration and custom
development. The Corporation must clearly understand when configuration equates to custom
development (that is, the level of configuration is so high that the COTS solution is essentially the same
as custom development). In these cases, the scenario will change from buy to build.
 Agreements or licenses to use data (i.e. data subscription services) may have legal implications and legal
consultation should be part of the process of deciding to use a new data source.
 I&T assets should only be custom developed as a last resort. That is, custom development should be
prevented as much as possible.
 The Corporation must be able to manage the life cycle of its IT assets, including its custom assets, and
custom assets should be revisited periodically during their life cycle, to allow for reconsideration in case
the custom asset should be replaced with an appropriate purchased alternative.
 The complexity of the integration effort will increases as the environment becomes more diversified with
solutions that made available on-premise (internally developed or COTS) as well as externally hosted.
 Unnecessary diversity in I&T assets and approaches to technology business solutions must be minimized.
CMHC-I&T-EA Page: 7
Deliver Maximum Benefits at the Lowest Cost and Risks
2.6 Deliver Maximum Benefits at the Lowest Cost and

Risks
Description
Strategic decisions for solutions must always strive to generate value for the business at the lowest long-
term risks and costs.
Rationale
Decisions must not be made based solely on reaching lower solution costs. Every strategic decision must be
assessed based on cost, risk, and benefit perspectives through a sound business case. Lower costs often
represent greater risks, lower quality and, perhaps, fewer benefits.
Implications
 A solution must be selected based on an assessment of the qualitative or quantitative cost (ROI), its risk,
and its business benefits. Most times, quantitative assessments are simpler based on a cost perspective
but more complex for risks and even more intricate for benefits. The quantitative assessment must
always be conducted whenever possible as it is a more tangible.
 A qualitative assessment of one or two perspectives is generally sufficient when a quantitative
assessment is properly conducted and already leads to a decision.
 Operating risks must be quantified whenever possible.
 The technology infrastructure must also be optimized based on business requirements and technological
capacity to generate lower costs and risks, thus benefiting the Corporation.
 We will need to balance the portfolio of projects to include higher risk/reward initiatives at in an effort
to ensure continued innovation.
CMHC-I&T-EA Page: 8
3 Information Principles
Treat Information as a Corporate Asset
3.1 Treat Information as a Corporate Asset
Description
Information is a valuable asset to the Corporation and must be managed accordingly through its life cycle.
This implies a need to plan for the strategic use of information to enable differentiating business
capabilities.
Rationale
Information represents a valuable corporate resource, with actual and measurable value. Information is the
basis of the decision-making process. Therefore, it must be carefully managed to ensure constant
awareness of its location, reliability of its contents, and access whenever and wherever necessary.
Implications
 Information management processes and a governance model must be implemented with appropriate
KPI’s.
 An enterprise information architecture will be required to provide a holistic view of the Corporation’s
information and its opportunities for reuse.
 Information risks and compliance will need to be assessed as a continuous process.
 Awareness of the business value of information must be clearly communicated.
 Information-related policies (i.e. privacy) and standard to be developed and followed.
CMHC-I&T-EA Page: 9
Make Information Accessible, Shareable and Consumable
3.2 Make Information Accessible, Shareable and

Consumable
Description
Business lines have access to information that is necessary for performance of their respective mandates.
Therefore, information is shared between different business lines and positions, depending on the security
levels established for that particular set of information.
Rationale
Access to accurate information is essential to improve the quality and efficiency of the decision-making, low
response turnaround time for information requests and delivery. It is less expensive to maintain timely and
accurate information in a single repository and share that than to maintain repetitive information in
multiple sources.
Shared information from a centralized authoritative source promotes better decisions-making, cost-
efficiencies, accuracy and better governance of information.
Implications
 To enable information sharing, a common set of policies, procedures, and standards (i.e. definitions)
must be developed and followed as part of the governance of information.
 Normalized data models and metadata that define such shared environments must be developed, in
addition to a repository to store the metadata and make it accessible.
 As existing systems are replaced, common information access and developer guidelines must be adopted
and implemented to ensure that all information in new applications remains available in the shared
environment.
 In both short and long-term, common methods and tools to create, maintain, and access shared
information must be adopted across the Corporation.
 Information sharing implies a significant cultural shift and will be the focus of the Information
Governance initiative.
 The information-sharing principle is constantly confronted with the information security principle.
Information sharing must not compromise the confidentiality of information under any circumstance.
 Shared information must be used by all collaborators to perform their respective tasks while respecting
accountability for the source of information. This ensures that only the most up-to-date and accurate
information is used in the decision-making process. Shared information shall become the only virtual
source of corporate information.
 The manner in which information is accessed and made available must be sufficiently flexible to satisfy a
wide array of corporate beneficiaries and their respective access methods and use.
CMHC-I&T-EA Page: 10
Use Common Terminology and Definitions
3.3 Use Common Terminology and Definitions
Description
Define structured and unstructured information consistently and coherently throughout the Corporation
through comprehensible and accessible definition by staff.
Rationale
The information used in the development of applications must have a common definition so that the
information can be shared. A common terminology facilitates communication and promotes efficient dialog
and allows information and interfaces to be shared among different systems.
Implications
 The Corporation must first establish a common terminology for business activities. Such definitions must
be uniformly used throughout the organization.
 Whenever a new data definition is required, efforts regarding such definition must be coordinated and
reconciled within a corporate data description "glossary." The Corporation's data administrators need to
be responsible for such coordination.
 Ambiguities arising from multiple data definitions must be replaced by a definition that is accepted and
understood across business lines.
 A dedicated effort will be required to achieve common terminology and definitions.
4 Application Principles
Design Simple and Easy to Use of Applications
4.1 Design Simple and Easy to Use of Applications
Description
The enterprise architecture is built over reusable, modular components that implement services.
Solution architecture must be as simple as possible to maintain yet meet business requirements. Whenever
complexity is required, it must be encapsulated to promote simplicity of solutions defined by the
architecture.
The business community acknowledges the ease of use of its technology solutions. The technology is
transparent as it enables the business to concentrate on tasks, rather than system operation issues.
Rationale
Reusable components represent opportunities to reduce development time and costs. Reusable
components leverage investments in current systems. Modular components increase the systems'
capacities to adapt to different evolution needs, because the change is isolated from affected modules.
The more that users need to understand the technology employed, the less productive they will be. The
ease of use concept is a positive reinforcement for promoting simplicity in design. It encourages individuals
to work within the integrated information environment rather than developing isolated systems to perform
tasks outside of the integrated corporate environment. Most of the knowledge required to operate systems
is very similar. Formatting is limited to a minimum, and system misuse risks are low.
Implications
 The architecture establishes standards and guidelines to develop system components.
 All applications must have the same appearance and layout as much as possible. Thus, a standard layout
must be developed and usability testing criteria must be implemented by the QA organization.
Adopt Flexibility and Adaptability
4.2 Adopt Flexibility and Adaptability
Description
Automated systems are conceived to automate business processes in an effort to gain efficiencies while
reflecting the evolution of laws, social needs, or various other types of changes.
Adaptability and flexibility reduce the complexity and promote integration, which improves the
Corporation's delivery of its business activities.
Excessive customization increases costs and reduces the ability to adapt immediately with longer term
repercussions when upgrading software versions.
Rationale
Adhering to this principle has several benefits:
 Allows the infrastructure to support changes that frequently occur in business processes within the
Corporation.
 Renders the infrastructure mode adaptable to technological changes while aligning with industry
direction.
 Allows the improvement of business processes through the evolution of best practices.
 Promotes a simpler and faster system integration process, with less revision processes.
 Reduces upgrade costs due to a minimized number of customizations.
 Allows systems to evolve to meet business needs and changes.
Implications
 Initially, the systems might require more time to develop/configure and greater systemic consideration
as operations go beyond the systems' traditional boundaries.
 Costs related to the integration of the solution will be less expensive.
 Systems will be in effect longer; therefore, the return on investment will be greater.
 A system can be suboptimal in the short-term but present optimization gains in the long term.
 Adaptability and flexibility performance metrics must be established.
 The development of applications based on components must be promoted and facilitated.
 A minimum number of suppliers, products, and configurations must be maintained to allow maximum
flexibility when implementing changes.
 Application solution should be architected to execute on various end-point devices wherever possible
(including mobile).
 Excessively complex configurations of components, undue customized tuning, and hardware and
software customization based on transient, local, or other conditions must all be avoided.
 Resource restrictions must be considered.
Align with the Enterprise Architecture
4.3 Align with the Enterprise Architecture
Description
Enterprise Architecture begins with the Corporations strategies, objectives, its business outcomes and
business capabilities. Therefore, applications whether developed in-house or purchased, must respect the
provisions of the Enterprise Architecture’s future state.
A convergence with the enterprise architecture’s future state takes place as new applications are built, new
technologies are implemented, and older systems are updated or decommissioned. Exceptions to the
enterprise architecture might be supported for specific cases if there is a consensus that the benefits of
using a solution from a specific technology exceed those arising from the adoption of the enterprise
architecture. In some cases, this may trigger a review of the future state architecture to include the
exception if this is deemed as desirable.
Rationale
Alignment offers several advantages:
 It allows the enterprise architecture to evolve and accommodate changes in processes and technologies.
 It avoids conversions of obsolete systems, which are extremely expensive and often.
 Over time, it preserves the investment while promoting the benefits of the enterprise architecture.
Implications
 Delayed convergence could reduce the benefits of the enterprise architecture.
 Convergence requires a realistic and tangible approach to migration to the enterprise architecture.
 It requires an explicit transition strategy for current systems after the target technology is identified.
 Allows decommissioning a system sooner when that is appropriate.
 Convergence does not allow waiting indefinitely. It requires a business case for exceptions, an exception
process, and an exit strategy. It must establish temporary or permanent exceptions, as well as exit
strategies for temporary exceptions.
 Convergence requires sponsorship to replace obsolete technologies.
Apply Enterprise Architecture to Externally Hosted Applications
4.4 Apply Enterprise Architecture to Externally Hosted

Applications
Description
As new outsourcing contracts and agreements are entered into, they must reflect and incorporate the
enterprise architecture principles where applicable.
This is one of the ways to keep enterprise architecture in line with the business. Outsourced activities must
not be exceptions to the enterprise architecture simply because they are outsourced. Outsourced solutions
must be evaluated against these principles.
Rationale
To be successful, enterprise architecture must be integrated with key phases of IT project delivery: concept,
planning, including procurement of solutions.
Implications
 This requires partnerships and efficient communication between business, procurement, contract
management, and I&T areas to get the benefits offered by the enterprise architecture.
 IT acquisitions must include requirements based on the enterprise architecture.
 The investment vision for the business must include IT requirements.
Implement Service-Based Interfaces
4.5 Implement Service-Based Interfaces
Description
Define interfaces that have low coupling, are self-described, and offer low impact on the design of solutions
as a result of changes.
Rationale
Low-coupling interfaces are preferable, because when interfaces between independent applications are
highly coupled, they are less generic and more susceptible to causing unwanted, secondary effects when
they are changed.
Implications
 Low coupling means that the services (e.g. API’s) are designed and built with no affinity to a certain
service consumer.
 Therefore, the service is completely uncoupled from the service consumer. However, the service
consumer is dependent of the service (that is, contains references for service-based interfaces).
 The service is also responsible for exception treatment. The result is a low-coupling architecture.
Adhere to Functional Domains
4.6 Adhere to Functional Domains
Description
The business rules and functionality of a system are consistent with the mission of that application. There is
complete adherence to the functional domain in which the application is located.
Rationale
The purpose of this principle is to avoid functional redundancy between applications.
Functional redundancy can cause loss of data integrity and increase maintenance costs related to the
redundant business rule.
Implications
 Applications must be located in proper functional domains, with explicit definition of the manager in
charge of the functional domain.
 Each new functionality request must be submitted to the respective manager.
 Applications that are already in production with functional redundancy should be replaced entirely or
partially in a timely manner. The functional redundancy of such applications must not be promoted.
5 Technology and Security Principles
Implement Changes Based on Requirements

5.1 Implement Changes Based on Requirements
Description
Changes in applications and technologies are implemented to meet business needs.
Rationale
This principle promotes an atmosphere where the information and technology environment changes to
reflect business needs, rather than changing the business to reflect technology changes. This ensures a
focus on business operations as the basis for any change proposal while respecting all other guiding
principles. In an effort to stay current with the evolution of technology, technology changes can generate
opportunities to improve business functionality and processes thereby bringing significant value.
Involuntary effects on businesses resulting from technology changes are mitigated.
Implications
 Changes in implementation follow a complete assessment of proposed changes, based on the enterprise
architecture.
 A system development or technical improvement is not implemented unless there is a documented
business need.
 A business need must be considered, but it must also be aligned with other enterprise architecture
principles. There must be a balance between business needs and I&T operations.
Control Technical Diversity and Suppliers
5.2 Control Technical Diversity and Suppliers
Description
Technological diversity is controlled to minimize significant costs related to the maintenance of expertise
and connectivity between several different processing environments.
Supplier management must focus on the lowest number of suppliers possible to meet business needs and
reduce risks.
Rationale
There is a real and significant cost related to the infrastructure required to support alternative technologies
for processing environments. There are other infrastructure costs to maintain the architecture of multiple
interconnected processors.
Limiting the number of supported components and suppliers simplifies and reduces maintenance and
management costs.
A smaller number of suppliers and software packages represent a greater ease and lower integration costs.
Business advantages of minimum technical diversity include:
 Standard Component Packaging;
 Predictable Implementation Impact;
 Predictable returns and validations;
 Defined tests; and
 Greater flexibility to accommodate technological advances.
A common technology across the Corporation generates scalable economic savings for CMHC. Technical
management and support costs are better controlled when limited resources focus exclusively on this
shared technology set.
Implications
 Policies, standards, and procedures that regulate the acquisition of technology or contracting with new
suppliers must be directly bound to this principle.
 Technology decisions are guided by the business and technology blueprints.
 Procedures to increase the set of acceptable technologies to meet evolved requirements must be
developed and implemented.
 In some cases, this will imply working closely with the procurement group to develop appropriate
justifications.
 This principle does not require freezing the technological baseline. Technological advances are welcome
and incorporated into the technological blueprint when they are compatible with current infrastructures,
are likely to improve operating efficiency, or there is a need to increase capacity.
 The selection of contracted suppliers must be a strategic decision, always considering other types of
services that could be provided by the same supplier.
Design Solutions with Interoperability in Mind
5.3 Design Solutions with Interoperability in Mind
Description
Software and hardware must follow established standards that promote data, application, and technology
interoperability.
Rationale
Standards help ensure coherence, thus improving the ability to manage systems, raise user satisfaction, and
protect current I&T investments, thus maximizing return on investment and reducing costs.
Interoperability standards also help ensure support from several suppliers to their respective products, thus
facilitating integration.
Implications
 Interoperability and industry standards must be followed unless there is a mandatory business reason to
implement a non-standard solution.
 A process to establish standards, periodic revision, and exceptions must be established.
 Current technology platforms must be identified and documented.
Use a Risk-Based Approach to Security
5.4 Use a Risk-Based Approach to Security
Description
Create a consistent and effective risk assessment approach to information and technology assets as well as
an engagement model that is aligned with the I&T risk framework. This process will enable a pragmatic
approach to managing risk and security.
Rationale
Risk is the likelihood of something happening that will have an impact on the Corporation’s objectives and
risk assessment is the overall process of risk identification, analysis, evaluation, mitigation and acceptance
of residual risks that are within our defined risk tolerance.
Taking a risk-based approach allows for:
 better identification of threats to our projects, operations, existing systems and information.
 more effective allocation and use of resources to manage those risks, and
 improved stakeholder confidence and trust as we better manage information and business risks.
Implications
 The level and cost of information security controls to manage confidentiality, integrity and availability
risks must be appropriate and proportionate to the value of the information assets and the potential
severity, probability, and the extent of harm.
 Risks must be identified so that we are aware of the likelihood, the consequence should the risk occur,
what existing controls are in place, and a determination is made as to how to treat the risks.
 Options for addressing information risk should be reviewed so that informed and documented decisions
are made in regard to the treatment of the risk. Risk treatment involves choosing one or more options,
which typically include:
- Accepting the risk (implies that the risk is tolerated based on factors such as low severity or low
probability of occurring).
- Avoiding the risk (implies that a risk can be avoided by not pursuing an option or course of action).
- Transferring the risk (implies that the risk can be transferred to an external entity that is better suited
to handle such a risk - i.e. outsourcing).
- Mitigating the risk (implies that cost effective measures can be applied to either eliminate or reduce
its impact or likelihood to an acceptable level of tolerance).
Design Solution with Security in Mind
5.5 Design Solution with Security in Mind
Description
Controls for the protection of confidentiality, integrity and availability must be designed into all aspects of
solutions from initiation, not as an afterthought. Security should be designed into the business processes
within which a technology solution will be used.
Rationale
The implementation of protections for confidentiality, availability and integrity within information systems
later in a project (or after its implementation) is more expensive than including security protections within
the initial design of the solution. Such controls implemented at the end of a project are often less efficient
and less integrated than those integrated within the core of the solution.
Because of its broad mandate, the Corporation is a steward of public and private data assets, which must be
protected, both from a legal and regulatory perspective as well as from a good steward/risk management
perspective.
Implications
 Security is imbedded as an integral part of the solution architecture, not added as an afterthought.
 Security mechanisms must be scalable and span all tiers of the architecture, including the design and
functionality of solutions.
 All solutions, custom or commercial, must be tested to ensure that security requirements are met.
 Possible areas of control which could be addressed and integrated include (but are not limited to):
- asset management and information classification;
- physical security;
- segregation of duties;
- protection against malicious code;
- back-up and recovery;
- exchange of information;
- logging and monitoring;
- user authentication and authorization;
- technical vulnerability management;
- compliance with legal requirements; and
- system control audit considerations.
 A set of requirements are developed for alignment with the principles expressed herein as these relate
specifically to information security.
6 Lexicon, Abbreviations and Acronyms
6 Lexicon, Abbreviations and Acronyms
Term Acronym/ Definition Notes

Abbrev.
Enterprise EA Enterprise architecture is the organizing
Architecture logic for business processes and
technology reflecting the integration and
standardization requirements of an
organization’s operating model.
Return of ROI A measure used to evaluate the efficiency
Investment of an investment or to compare the
efficiency of a number of different
investments. To calculate ROI, the benefit
(return) of an investment is divided by the
cost of the investment; the result is
expressed as a percentage or a ratio.
Lexicon, Abbreviations and Acronyms
CMHC-I&T-S&P-EA Sum.Subject Page: 24

Appendix A - Diagram of Enterprise Architecture Principles
7 Appendix A - Diagram of Enterprise Architecture Principles
CMHC’s Strategic Directions (Five-Year)

(Alignment with Enterprise Architecture Principles)
The Heart of a World-Leading Housing System

CMHC’s
Strategic
Directions
Lead through Information and Be a High-Performing
Align Risk with Mandate
Insight Organization
I&T Strategic Themes

I&T 1. Strengthening Our Foundation 2. Adding Value through Information, Technology People and Process 3. Security
Strategic
Context
Foster an environment of Provide Flexibility and Agility
Reduce Technology Complexity
Information Stewardship to the Business
General Principles
2.2 Business 2.3 Adoption of 2.4 Compliance to 2.5 Reuse before 2.6 Maximum
2.1 Alignment with
Continuity is Industry Best Standards, Policies Buy, Buy before Benefits at Lowest
Business
Imperative Practices and Regulation Build Cost and Risk
Enterprise Technology and Security Principles Information Principles Application Principles

Architecture 3.1 Information to be treated 4.1 Simplicity in
5.1 Changes Based on 4.2 Adaptability and
Principles 5.3 Interoperability as a Corporate Asset Design and Use of
Requirements Flexibility
Applications
5.2 Control of 3.2 Accessible, Shareable 4.3 Convergence with 4.4 Enterprise
5.4 Risk-based and Consumable the Enterprise
Technical Diversity Architecture Applies to
Approach to Security Information Architecture
and Suppliers External Applications
3.3 Common Terminology 4.5 Service-Based 4.6 Adherence to

5.5 Security by Design and Definitions Interfaces Functional Domains
CMHC-I&T-S&P-EA Sum.Subject Page: 25


EA Guiding Principles

Uploaded by

Copyright:

Available Formats

EA Guiding Principles

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EA Guiding Principles

Uploaded by

Copyright:

Available Formats

CMHC EA Strategic documents

Enterprise Architecture Principles

Published by: CMHC-I&T-EA

Prepared by: EA Team Recommended by: Serge Parisien

Edited by: Approved by: Bruce Langevin

Published by: CMHC-I&T-Enterprise Architecture

VERSION DESCRIPTION DATE AUTHOR & NOTES

CMHC-I&T- Enterprise Architecture II

CMHC-I&T- Enterprise Architecture III

CMHC-I&T- Enterprise Architecture IV

1.1 Content and Purpose

1.3 Presentation Format of Each Principle

1.4 Categories of Principles

2.2 Include Business Continuity into Planning and

2.3 Adopt Industry Best Practices

2.4 Comply with Standards, Policies and Regulations

2.5 Reuse before Buy, Buy before Build

2.6 Deliver Maximum Benefits at the Lowest Cost and

3.2 Make Information Accessible, Shareable and

3.3 Use Common Terminology and Definitions

4.1 Design Simple and Easy to Use of Applications

4.2 Adopt Flexibility and Adaptability

4.3 Align with the Enterprise Architecture

4.4 Apply Enterprise Architecture to Externally Hosted

4.5 Implement Service-Based Interfaces

4.6 Adhere to Functional Domains

5 Technology and Security Principles

5.2 Control Technical Diversity and Suppliers

5.3 Design Solutions with Interoperability in Mind

5.4 Use a Risk-Based Approach to Security

5.5 Design Solution with Security in Mind

6 Lexicon, Abbreviations and Acronyms

Term Acronym/ Definition Notes

CMHC-I&T-S&P-EA Sum.Subject Page: 24

7 Appendix A - Diagram of Enterprise Architecture Principles

CMHC’s Strategic Directions (Five-Year)

The Heart of a World-Leading Housing System

I&T Strategic Themes

Enterprise Technology and Security Principles Information Principles Application Principles

3.3 Common Terminology 4.5 Service-Based 4.6 Adherence to

CMHC-I&T-S&P-EA Sum.Subject Page: 25

You might also like