GC Enterprise Architecture/Standards/Business Architecture

From wiki
Jump to navigation Jump to search

<<Enterprise Architecture Standard main page

Information Architecture>>

1. Business Architecture

A Business Architecture is where an organization identifies the various services that it suppose to provide externally, as well as the various functions it owns or needs to own internally to support the external service. In terms of GC Enterprise Business Architecture, this is where the Government of Canada identifies the various departments, the services they provide to Canadians and the functions they owns.

Align to the GC Business Capability Model

With multiple departments providing various services to Canadians, there are some commonalities in the internal functions that the department must have to support these external services. These common functions are being categorized in a GC Business Capability Model (BCM).

Several departments have come together in a form of a working group to create this BCM model for the Government of Canada, with the hope of making it inclusive to all departments. The working group has been working for quite some time and there have been a few iterations of this model, the latest one being GC BCM v2.0 with definition for each category to clarify how to use the model.

For more information about the working group or other documents produced from the working group, please visit the GC BCM WG.

  • Define program services as business capabilities to establish a common vocabulary between business, development, and operation
  • Identify capabilities that are common to the GC enterprise and can be shared and reused
  • Model business processes using Business Process Management Notation (BPMN) to identify common enterprise processes

Design for Users First and Deliver with Multidisciplinary Teams

  • Focus on the needs of users, using agile, iterative, and user-centred methods
  • Conform to both accessibility and official languages requirements
  • Include all skillsets required for delivery, including for requirements, design, development, and operations
  • Work across the entire application lifecycle, from development and testing to deployment and operations
  • Ensure quality is considered throughout the Software Development Lifecycle
  • Ensure accountability for privacy is clear
  • Encourage and adopt Test Driven Development (TDD) to improve the trust between Business and IT

Design Systems to be Measurable and Accountable

  • Publish performance expectations for each IT service
  • Make an audit trail available for all transactions to ensure accountability and non-repudiation
  • Establish business and IT metrics to enable business outcomes
  • Apply oversight and lifecycle management to digital investments through governance