Internal Audit and Program Evaluation Directorate
Audit of Enterprise Architecture
December 2019

Table of contents

• 1.0 Introduction
• 2.0 Significance of the audit
• 3.0 Statement of conformance
• 4.0 Audit opinion
• 5.0 Key findings
• 6.0 Summary of recommendations
• 7.0 Management response
• 8.0 Audit findings
  • 8.1 Integration of Enterprise Architecture in planning
  • 8.2 Governance
  • 8.3 Variances from approved architectures
  • 8.4 Enterprise Architecture program artefacts
  • 8.5 Performance measurement
• Conclusion
• Appendix A: About the audit
• Appendix B: List of acronyms

1.0 Introduction

1. The Canada Border Services Agency (CBSA/the Agency) is responsible for providing integrated border services that support national security and public safety priorities and facilitating the free flow of persons and goods that meet all legislative requirements. To deliver on this mandate, the Agency relies on various information technology assets. The importance of technology is clear and has been identified as an enabler for achieving the border of the future as defined in CBSA Renewal.^{Footnote 1}

2. The Treasury Board Secretariat (TBS) Policy of Management of Information Technology promotes a Government of Canada-wide, enterprise approach to strengthening business and Information Technology (IT) partnerships through the use of common or shared IT assets, innovative IT services and IT support for program delivery, which provides value for money and effective and efficient IT investments.

3. Enterprise Architecture (EA) is a practice that focuses on the alignment of business strategy and IT Infrastructure^{Footnote 2}. EA guides the process of planning and designing IT capabilities to meet the desired objectives of the organization. EA defines the current-state and target-state architectures, in line with the enterprise’s IT assets and capabilities, business strategy, priorities and needs.

4. The CBSA formally created its Enterprise Architecture Program (EA Program) in 2009. The Agency’s EA Program has adopted the Open Group Architecture Framework (TOGAF) which is a generally-accepted framework for enterprise architecture, which provides guidelines for the successful development and execution of an EA Program strategy.

5. The Enterprise Architecture Division (EAD) of the Enterprise Architecture, Information Management and Common Services Directorate in the Information Science and Technology Branch (ISTB) is responsible for the delivery and management of the CBSA EA Program. Given that the scope of the EA is organization-wide, its stakeholders include all CBSA Branches.

6. An audit of the Enterprise Architecture Program was approved as part of the CBSA’s 2018-2019 Integrated Audit and Evaluation Plan.

2.0 Significance of the audit

7. As the CBSA evolves and modernizes to support the border of the future, the CBSA EA Program can play a significant role in ensuring that Information Management/Information Technology (IM/IT) tools and capabilities are aligned with the overall strategy of the CBSA and the Government of Canada (GC). An effective EA Program should result in efficiencies and cost savings through the reuse of shared services, elimination of redundant operations, and optimization of service delivery through the streamlining of business processes, data standardization and systems integration.

8. The objective of this audit was to assess whether the CBSA established an EA Program that adds value, is effectively governed and is aligned with the CBSA’s current needs and priorities and the future direction of the CBSA.

9. The audit scope included the activities of the CBSA EA Program during the period between April 1, 2017 and March 31, 2019. Specifically, the audit examined:

• CBSA governance processes, including architectural governance processes, to support adoption of the EA Program within the CBSA
• The adoption of EA solutions by the CBSA for business processes and transformational activities and
• Performance measurement and reporting for the EA Program.

10. The audit scope and criteria can be found in Appendix A.

3.0 Statement of conformance

11. The audit conforms to the Mandatory Procedures for Internal Auditing in the Government of Canada, as supported by the results of the quality assurance and improvement program. The audit approach and methodology followed the International Standards for the Professional Practice of Internal Auditing as defined by the Institute of Internal Auditors and the Mandatory Procedures for Internal Auditing in the Government of Canada, as required by the Treasury Board’s Directive on Internal Audit.

4.0 Audit opinion

12. The CBSA has established an EA Program that is governed and aligned with the objectives and priorities of the GC and the CBSA. The EA Program has developed and approved key documentation in support of the CBSA’s business strategy, and implemented processes for the management of EA compliance. Nevertheless, more can be done to mature the EA Program and ensure that it adds greater value to the CBSA. Improvements in earlier integration of EA when planning projects, improving accountability for architectural compliance and better communication and engagement of the Agency will ensure that the EA Program adds greater value to the Agency.

5.0 Key findings

13. Key findings of the audit include:

• While governance committees with responsibilities for EA are established, active and fulfilling their responsibilities, the EA Program would benefit from a strengthened Architecture Review Board (ARB) to regularly discuss architecture issues and oversee the governance of architecture variances
• Key enterprise architecture artefacts are developed and approved, but there are opportunities for a more systematic ongoing review process and communication of the artefacts to all stakeholders
• EAD is generally consulted as required for IT-enabled projects but a process to include EAD consultation for non-IT enabled projects was not established. Embedding EA considerations earlier in the planning process could help increase an uptake of enterprise solutions
• When projects are not compliant with CBSA’s approved EA standards, governance processes are not adequate to hold those responsible for remedying non-compliance accountable
• Performance measures for the CBSA EA Program have not been established or tracked

6.0 Summary of recommendations

14. The audit makes four recommendations, related to:

• Formalizing EA in the planning processes
• Reviewing the composition and mandate of the ARB
• Formalize and socialize the accountabilities and responsibilities related to the documentation of reference architecture
• Establishing, tracking and reporting quality metrics for the Enterprise Architecture Program

7.0 Management response

8.0 Audit findings

8.1 Integration of Enterprise Architecture in planning

15. Organizations will increasingly need to ensure that departmental IT investments, service development and improvement initiatives are informed by and integrated into departmental business planning^{Footnote 3}. Since a core principle of enterprise architecture is the alignment of business with IT in executing the organization’s business strategy, active involvement of both business and IT senior management is also critical.

Business planning

16. Early involvement of EA practitioners in business planning is key to allow the EAD to provide information and guidance on the selection of solutions that meet business needs and are consistent with the Agency architecture. In turn, this collaboration would foster an understanding of the impact of planned initiatives on the Agency’s enterprise architecture eco-system and also inform ISTB planning for the development of required enterprise solutions^{Footnote 4}.

17. The audit assessed whether considerations for EA were integrated in the Agency’s business planning processes, such as the integrated business plans and the CBSA IT plan.

18. At the time of the audit, EA considerations were absent from the planning process and guidance. A review of the branch and region business plans confirmed the absence of not only EA, but IT priorities altogether. While the ISTB 2019–2020 Business Plan did include priorities related to enterprise architecture, business input from branches was not considered when developing this plan.

19. If consultations between ISTB and business do not occur and the expertise of the EAD is not leveraged, there is a lost opportunity to prevent the development of redundant applications and unnecessary stand-alone solutions or inappropriately investing in legacy technology.

20. As part of Renewal, the Agency is transitioning to a new organizational structure and maturing its planning processes. Integrated business planning (IBP) guidance has been developed and a first cycle of IBP was performed in early 2019. As this process continues to mature, the integration of IT priorities and capabilities within business planning processes could promote fuller IT/business integration, including EA considerations.

Project planning

21. In addition to business planning processes, we reviewed planning processes for Agency projects, both IT and non-IT enabled, to assess whether EAD was embedded in the process. As per the TOGAF requirement, we expected that EA would be integrated early on in the process and that, during systems development, Agency projects used the enterprise solutions available to them.

22. The Agency’s Project Management Framework (PMF) states that potential project investments ‘…should leverage various EA services…’. Actual engagement has not been formalized, however, as an imperative in project management Investment Phase Gates 1 to 3 where EA has the most potential to add value and ensure alignment with CBSA Architecture. EAD engagement is indirectly achieved for IT-enabled projects, however, when a project or project component requires the governance of the Service Lifecycle Management Framework (SLMF).

23. The SLMF is the CBSA’s framework for IT service management. The SLMF is used when developing new systems or making changes to existing systems and includes an Architecture Management Method (AMM) which establishes architecture-related processes. The SLMF requires the EAD to be consulted during the Preliminary Design Review (PDR) phase, which occurs prior to solution development. At this phase, EAD employees assess the proposed solution to determine whether it is compliant with applicable EA guidance and whether a project can make use of various enterprise services that the Agency has developed.

24. A sample of 11 IT-enabled projects was assessed as part of the audit to determine whether the EAD was consulted during the PDR phase of solution development. We reviewed Architecture Design Specification (ADS) documents, which showed evidence of EAD consultation and confirmed that 10 out of 11 IT-enabled projects consulted with EAD as required. Out of these 10 projects, however, only three ended up utilizing enterprise solutions. Time and cost were the reasons most often cited for not conforming with the enterprise architecture.

25. We noted that while the PDR phase is early on in the development of IT systems, it occurs after financial decisions and implementation timelines for the project have been made. As such, by the time the EAD consultation occurs, the development of a Solution Architecture may no longer be possible due to time and financial constraints. The solution developed and implemented thus ends up being non-compliant with EA guidance. This topic is further discussed in the next section of this report.

26. As noted above in paragraph 22, while there is no formal requirement for the Agency’s non-IT-enabled projects to consult with EAD, it would be considered a good practice as many projects – although not considered IT-enabled – may still be architecturally significant. A non-IT project, such as a new Container Examination Facility for example, may introduce new business processes which would require an update to the Agency’s Business Reference Architecture.

27. A sample of five non-IT-enabled project business cases and project charters were reviewed for evidence of EAD consultation. We concluded that two out of five non-IT-enabled projects consulted with EAD because an IT component of the project required gating through the SLMF.

28. Implementing solutions which are not in line with EA runs the risk of bypassing requirements for security, privacy, interoperability, accessibility and open information, and can also result in a lost opportunity for costs avoidance and efficiencies. Early engagement of the EAD in business and investment planning and in the project development lifecycle may help in identifying opportunities to leverage enterprise solutions.

8.2 Governance

29. Architecture Governance is the practice by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level.^{Footnote 5}

30. An important element of any architecture governance is the establishment of an Architecture Review Board (ARB) to oversee the implementation of the governance strategy. The ARB should be representative of all the key stakeholders in the architecture and should comprise a group of executives responsible for the review and maintenance of the overall architecture.^{Footnote 6} The Policy on Management of Information Technology mandates that the Chief Information Officer chair the departmental ARB.^{Footnote 7}

31. At the CBSA, the Corporate and Information Management Committee (CIMC), a DG-level committee, serves as the ARB. The CIMC terms of reference, however, do not identify ARB responsibilities beyond the assessment of proposals to be tabled at the GC-EARB, a requirement of the Directive on Management of Information Technology. The VP of ISTB, the CBSA’s Chief Information Officer, is not the chair of CIMC, nor does he attend CIMC meetings. The CIMC includes members of senior management from across the Agency, including the ISTB.

32. During the scope of our review, the CIMC reviewed various EA-related documents, including the architectural reviews of the CBSA Assessment and Revenue Management, Entry/Exit and the Passenger Protect Program. However, CIMC members may lack an understanding of enterprise architecture concepts and the Agency’s EA Program, which makes it difficult for the committee to fulfill its role as the CBSA ARB. To strengthen committee members’ understanding of both enterprise architecture and the Agency’s EA Program, the EAD is developing a series of Enterprise Architecture 101 sessions.

33. In addition to CIMC, both the Financial and Investment Management Committee and the Investment and Project Management Committee were identified as having CBSA-wide responsibilities for financial and investment planning, including initiatives that have significant architectural impacts. Our review of these three committees’ records of decisions confirmed agenda items and discussions regarding enterprise solutions such as Service Oriented Architecture, Master Data Management and the Enterprise Risk Assessment Support Service.

34. The IMB, SEMB and SEMC, which are committees within the ISTB, were also active and making decisions related to architectural compliance, project planning and compliance with regulatory requirements during the scope of the audit.

35. See recommendation 2 on page 11 of this report.

8.3 Variances from approved architectures

36. TOGAF recognizes that there are constraints and operational realities, such as cost and time constraints, which may prevent a project from being compliant with an organization’s EA guidance. In these instances, an organization should create a variance document to approve forgoing compliance in the short term and develop a roadmap which detail how the non-compliance will eventually be resolved.

37. Within the Agency, the assessment of variances is a Service Lifecycle Management Framework (SLMF) Architecture Management Method (AMM) documented and governed process managed by the Oversight and Compliance Unit (OCU) within EAD. Accountability lies with release Service Managers, acting as the variance owner, to document the variance and submit it to EAD for review by EAD Enterprise Architects. After review, a recommendation is made to accept or reject the variance. Variances are valid for one year.

38. Accountability also lies with the Service Manager to bring the variance for initial review and approval to the Systems Engineering Management Committee (SEMC), a director-level committee. EAD is represented at SEMC by the Division Director. If a consensus cannot be reached at SEMC, the variance decision is escalated to the Systems Engineering Management Board (SEMB), a DG-level committee.

39. If the variance has not been closed after one year, it is required to be re-approved by SEMC. It is the responsibility of the Service Manager to re-table variances for re-approval at SEMC one month prior to its expiry date.

40. If a variance request is rejected, an alternative course of action must be determined: re-architect the solution to align with EA guidance, cancel the service change, or appeal/escalate the decision to the SEMB, a DG-level committee. During our audit, it was noted that no escalation from the SEMC to the SEMB had occurred for architectural variances.

41. A key function of the OCU is to promote compliance with the CBSA Architecture. To that end, the SLMF-AMM requires the OCU to maintain a variance registry for tracking the status of variances. Also, the OCU maintains and monitors a generic email inbox for proactive requests for compliance review. Through this process, the OCU reviewed 481 releases for architectural compliance with the CBSA Architecture between September 2017 and March 2019 to determine if variances were necessary.

42. The audit assessed whether the CBSA had an effective process for documenting, approving and closing variances.

43. At the time of the audit, there were 91 active variances in the OCU’s variance tracking system. The audit tested a sample of 20 variances to assess whether they were reviewed by OCU and approved by the SEMC. A review of variance documents and records of decision confirmed that 12 out of 20 variances were approved by SEMC. Of the remaining eight variances, six had expired, while no records of decisions were found confirming that the remaining two had been approved at SEMC.

44. The audit also assessed whether approved variances which were more than one year old were reviewed to assess whether they remained valid. Ten of the 20 variances sampled were more than one year old, which enabled us to test whether they had been re-assessed as required. The audit found documentation to confirm that only one of these ten expired variances was reassessed and approved by the SEMC.

45. During the audit, the EAD identified that 38 out of their list of 91 variances had either not been submitted to the SEMC for approval or had an expired variance. Management indicated that this was due to a lack of maturity of the variance monitoring process. At the time of the audit, the EAD was addressing these expired and non-approved variances and had scheduled each of the 38 expired variances for SEMC review. All but one of these variances have since been approved or re-approved.

46. The SLMF Service Management Method prescribes the development of roadmaps which details how variances will be closed. Roadmaps provide the steps to be taken, within prescribed timelines, to bring a solution architecture into compliance with EA guidance. None of the 20 variances reviewed as part of our sample had an associated roadmap. The development of a roadmap would be key to ensure that key stakeholders are aware of steps and timeframes associated with addressing non-compliance with enterprise architecture.

47. Given that variances are reviewed as part of release management, there is a risk that their importance is diluted and that they may not be challenged so as to not delay a scheduled release. According to TOGAF, the ARB should have responsibility for the enforcement of architecture compliance. The ARB should be tasked with granting variances, identifying divergences from EA, such as the compliance assessments performed by the OCU, and planning activities for realignment (i.e. requiring roadmaps)^{Footnote 8}.

48. Overall, while the process to manage the variance is established, there are gaps in its application. Without a strengthened process to ensure that variances are accompanied by a roadmap, and are overseen by a committee seized with their importance, there is a risk that limited progress will be achieved in ensuring that exceptions to the CBSA architecture are remedied.

49. Active senior management leadership, with clearly defined roles and responsibilities and a mandate to leverage EA in support of the Agency’s strategic business objectives, would contribute significantly to maturing the EA Program.

8.4 Enterprise Architecture program artefacts

50. TOGAF identifies key artefacts which form the foundation upon which an EA Program is built and rests. These include:

• The Enterprise Architecture Vision: Provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture.
• The Enterprise Architecture Charter: Provides a clear scope and mandate for the EA team and its stakeholders.
• The Enterprise Architecture Principles: Provides a set of principles that govern the architecture process, affecting the development, maintenance and use of the EA.

51. These artefacts are meant to be reviewed periodically, in order to reflect changes in the organization or at the GC level.

52. The audit assessed whether the EAD had developed, approved and communicated key EA artefacts and whether they were periodically updated. It also assessed whether these foundational documents were aligned with the Agency’s priorities as well as with the EA priorities of the GC.

53. Version 1.0 of the CBSA Architecture Vision was approved in September 2014. While the Vision was reviewed and updated in 2016, there was no evidence of its approval. The Vision is aligned with TOGAF guidelines for Architecture Vision, which include problem descriptions, objectives for the statement of work, mapped requirements and references to draft architectures.

54. In addition, we found that the CBSA had developed and approved an Enterprise Architecture Charter that states the mission and scope of the CBSA EA Program, as well as roles and responsibilities for the EA Program. At the time of the audit, the EAD was in the process of revising this charter to include the mission and scope of the CBSA EA Program, as well its intended outcomes and risks.

55. The audit confirmed that the CBSA had developed and approved Enterprise Architecture Principles to guide the planning, decision-making, management, development, implementation, maintenance, activities and evolution of the CBSA EA, including Overarching Principles, Business Principles, Application Principles, Information/Data Principles, Technology Principles and Security Principles. However, while subject to an annual review, there was no evidence that the principles were reviewed since they were initially approved in 2017.

56. To assess whether the EA Program was aligned with Agency priorities, the vision, principles and charter were reviewed against the CBSA Strategic Framework, CBSA Renewal initiatives and the CBSA Strategic IT Plan. They were also assessed against the five GC priorities for EA^{Footnote 9}; implementing enterprise IT service management tools, adopting cloud services, evolving IM/IT management practices, processes and tools, adopting agile approaches to implement business solutions and standardizing metadata.

57. It was found that the EA Program was fully aligned with the objectives of the CBSA Strategic Framework and was generally aligned with the objectives of CBSA Renewal and the CBSA Strategic Plan. The document review also confirmed that the CBSA EA Program is aligned with all five GC priorities for EA.

58. To ensure an understanding and buy-in to the EA Program, the EA vision, charter and principles should be socialized with key stakeholders. However, the artefacts were not communicated to senior management or key stakeholders outside of the ISTB. While the revised Enterprise Architecture Charter states that a Communication and Engagement Plan will be developed, the lack of EA awareness throughout the Agency has been an ongoing issue for many years and limited progress has been demonstrated to further promote the EA Program within the Agency.

Reference architecture

59. In addition to establishing an EA Vision, Charter and EA Principles, TOGAF states that organizations should develop reference architectures, which are generic architectures that provide guidelines and options for making decisions in the development of more specific architectures and the implementation of solutions. TOGAF further states that within a mature EA Program, all business units accept and actively participate in architecture processes.

60. The CBSA has implemented an Architecture Collaboration Platform (ACP) in which business processes are mapped to form the CBSA reference architecture (i.e. the CBSA Blueprint). The draft Enterprise Architecture Charter states that the CBSA Reference Architecture (Blueprint) will be overseen through the governance engine integrated within the ACP, and that the Business Owners are required to govern their information.

61. The EAD has taken the initiative to develop the documentation of all of the Agency’s business processes within the ACP, a sizeable and noteworthy amount of work. While the business processes are now mapped (i.e. the Blueprint has been created), Business Owners have not reviewed and validated the mapping. Plans have been developed to engage Business Owners but have not yet been implemented.

62. We noted that the expected practice for validating the ACP has not been formally documented, and it isn’t clear whether the participation of business owners in the development of these architectures has been established. In the absence of an up-to-date, well-socialized charter that documents roles and responsibilities of business owners, there is a high risk that the Blueprint will not gain the authority it requires and will quickly become outdated.

8.5 Performance measurement

63. Performance management is important as it allows management to understand, measure and demonstrate how the EA Program is meeting expected outcomes and benefits and ultimately adds value. It is particularly important for CBSA’s business owners to understand the value of EA, as it is a key enabler to achieve CBSA’s strategic objectives, but can easily be overlooked if it remains an abstract concept. TOGAF states that enterprise architecture quality metrics should be established and regularly assessed to demonstrate value to the business.

64. The audit assessed whether the EAD was measuring and reporting on performance to demonstrate that expected outcomes and benefits were being realized.

65. We did not find key performance indicators established for the CBSA EA Program. When reviewing documentation, we noted that a 2014 CBSA Architecture Maturity Assessment recommended that the CBSA develop performance metrics to demonstrate efficiencies gained due to the EA Program and that these be communicated. While management identified raising awareness of the EA Program and "situating the EA Program within the CBSA landscape" as two main objectives, limited progress was made towards meeting these goals.

66. During the audit, we conducted a survey^{Footnote 10} to assess select employees’ awareness of the benefits associated with an EA Program, specifically with stakeholders who dealt with EA as part of their function (solution architects, service owners, project managers). The survey showed that, in general, while most respondents were aware of the enterprise services as well as their benefits, these respondents did not seem to see or understand the business value of the EA Program, such as improved business efficiency or improved enterprise decision-making.

67. The EAD has taken some steps in addressing this lack of awareness through initiatives such as the creation of an Architecture Community of Practice, with representation from all architecture domains and EA practitioners across the Agency, and ‘Lunch & Learn’ sessions for employees on the Architecture Collaboration Platform.

68. The draft Enterprise Architecture Program Charter states that the EA Program will regularly be evaluated via key performance metrics, and that a Program Performance Management document will detail how the EA Program will be evaluated. These steps, if implemented, will enable the EA Program to demonstrate the value added and benefits of EA to senior management and will be a useful tool to improve performance and further mature the EA Program.

Conclusion

The CBSA’s EA Program has good foundations in place and a dedicated EA team that is committed to delivering a first-class EA program. Their efforts have helped mature the Agency’s EA Program in many respects. To significantly continue to push the envelope, active engagement from senior management is imperative. Further emphasis and clarity on the role of EA within the Agency will become increasingly important as we move towards the Government’s Digital Transformation era and the new Digital Policy and Directive, set to come into effect in 2020^{Footnote 11}. Implementing the recommendations of the audit will help the Agency position itself for success on this front.

Appendix A: About the audit

Audit objectives and scope

The audit objective was to assess whether the CBSA has established an EA Program that adds value, is effectively governed and is aligned with the CBSA’s current needs and priorities, as well as with the future direction of the CBSA.

The audit scope included the activities of the CBSA EA Program during the period between April 1, 2017 and March 31, 2019.

Risk assessment

A preliminary risk assessment was conducted during the audit planning phase to identify potential areas of risk as well as audit priorities. Risk Assessment activities included interviews with stakeholders from the EAD and reviews of relevant documentation. As a result of this assessment, the following key risks were identified:

Governance:

• Senior management is not provided with complete and accurate information related to the EA Program to guide decision making
• EA Program priorities may not be communicated to the appropriate levels of management

Transformation:

• CBSA may not leverage EA when initiating, managing or sustaining organizational, program, policy or other changes
• EA Program priorities may not align with CBSA and/or GC strategic goals
• There is a risk that the EA Program is not maintaining, updating and communicating EA artefacts

Performance measurement:

• There is a risk that the EA Program is not capturing and reporting performance information to demonstrate its value to the CBSA, including senior management

Approach and methodology

The examination phase of this audit was performed using the following approach:

• Review of GC and CBSA legislation, policies, directives, and plans
• Review of governance committees’ terms of reference and records of decisions
• Review of CBSA EA Program artefacts and documentation
• Conducted interviews with stakeholders within ISTB, including EAD and other CBSA branches
• Assessed a sample of IT-enabled and non-IT-enabled projects and
• Assessed a sample of variances from approved architectures

Audit criteria

Given the preliminary findings from the planning phase, the following criteria were developed using TOGAF. We used criteria associated with a high level of maturity (level of 4):

Appendix B: List of acronyms

ACP

Architecture Collaboration Platform

ADS

Architecture Design Specification

AMM

Architecture Management Method

ARB

Architecture Review Board

CBSA

Canada Border Services Agency

CIMC

Corporate and Information Management Committee

EA

Enterprise Architecture

EAD

Enterprise Architecture Division

EA Program

Enterprise Architecture Program

GC

Government of Canada

GC-EARB

Government of Canada Enterprise Architecture Review Board

IBP

Integrated Business Plan

IM/IT

Information Management/Information Technology

ISTB

Information, Science and Technology Branch

OCU

Oversight and Compliance Unit

PDR

Preliminary Design Review

PMF

Project Management Framework

SEMB

Systems Engineering Management Board

SEMC

Systems Engineering Management Committee

SLMF

Service Lifecycle Management Framework

TBS

Treasury Board Secretariat

TOGAF

The Open Group Architecture Framework

Date modified:

2020-05-28