Recently I started a new job and have had more time to look at how to create architecture catalogues of elements and diagrams for reuse across projects, and realized that a lot of what I’m doing could also be reused by other Government of Canada and related organizations.
I’m going to start documenting some of my ideas on this blog, and also share some of the insights from other people who I work with.
To start I’m going to share my Meta-Model for how I’ve started modeling out the Government of Canada’s Policy Instruments from the Treasury board of Canada.
1.1 How the Source Documents are written and structured
The Policies, Directives, Standards etc. were written with a reader in mind, not a modeler.
You often have to read multiple statements together to understand the overall context, and in many cases these statements are overloaded to describe or infer multiple Architecture Elements.
For Example in the Policy on Government Security, the requirements section is organized as lists grouped under the effective role, this simplifies reading, but makes tracing elements back to these source statements a bit tricky:
6.1 Deputy heads of all departments are responsible for:
6.1.1 Establishing a security program for the coordination and management of departmental security activities that:
- Has a governance structure with clear accountabilities
- Has defined objectives that are aligned with departmental and government-wide policies, priorities and plans; and
- Is monitored, assessed and reported on to measure management efforts, resources and success toward achieving its expected results;
6.1.2 Appointing a departmental security officer (DSO) functionally responsible to the deputy head or to the departmental executive committee to manage the departmental security program (Note: The deputy head of a small department or agency (SDA) can assume the role of DSO);
6.1.3 Establishing a formal arrangement with the service provider when the role of the DSO is fulfilled by a third party (e.g., shared or clustered service provider or a portfolio department);
As you can see,
- you need to read 6.1 in order to understand the context of 6.1.1 (and it’s bullets), 6.1.2, and 6.1.3.
- you need to read 6.1 and 6.1.2 to understand 6.1.3
Reading these statements I can see the following elements that will be needed in my Model to Realize the intent of these statements.
- A Business Role called a Deputy Head. (6.1)
- A Business Actor called a Security Program (I debated having this as a business function, but decided to model as an Business Actor, because the program has the ability to Act) (6.1.1)
- A Business Role called a Departmental Security Officer (DSO) (6.1.2)
- A Business Process for selecting and appointing the DSO (Inferred from 6.1.2)
- A Business Role called a 3rd Party DSO that is a specialization of the DSO Role, a Business Process for establishing and maintaining a formal agreement, and a Business Object that documents the agreement (Inferred from 6.1.3)
1.2 Overlap between different sources
The same Business Role, Business Process, Business Object is often assigned new requirements and rules across multiple Policies and Directives.
For example there are responsibilities assigned to the Departmental Security Officer under the Policy on Government Security and the Operational Security Standard: Management of Information Technology Security (MITS). The directive identifies additional responsibilities for the DSO.
2.0 Modeling Approach
2.1 Meta Model Description
To address the complexities I found, I realized I needed to accomplish 5 things:
- Track what “source” document I’m starting with
- Track what statements from the source document have or have not been addressed (realized)
- Provide a way to relate a hierarchy of statements to provide context
- Support change management as directives and policies change, retire, and get replaced
- Model as much as I can using a single standard to support data exchange.
To all of this I’ve come up with the following meta-model
- Use the Archimate 3.01 standard to create the base models, and CSV files to provide extra data if needed to enhance the models.
- Store the Source Document as a linked Document to an Archimate 3.01 Driver Element
- Statements from the Source Document as a Archimate 3.01 Requirement Element
- In Sparx EA I’m able to import the source document and then select text in the document directly to create statement elements.
- If a statement from one source document expands on, or is dependent on a statement from a different source document use the Archimate 3.01 influence relationship (allowed between motivational elements)
- Create an Archimate 3.01 Business Role, Actor, Process, Object etc. specified or inferred by the statements in the Source Document. (these are stored with the source document in the catalogue, see step 6 to see how they are used)
- Using the Archimate 3.01 realization relationship to relate each of the elements from Step 3 to the 1 or more statement elements I modeled in Step 2
- If the realizing element from Step 3 connected to a statement that is part of a hierarchy, design reports so that all parents and children of the connected statement are included to give full context.
- Create a single central copy of each of the Business Role, Actor, Process, Object etc. in my catalogue at the GoC that are related to the realizing elements I created in Step 3 (across multiple sources) using an Archimate 3.01 aggregation relationship.
- Create a single central copy of each of the Business Role, Actor, Process, Object etc. in my catalogue at the Agency/Departmental Level that are related to the aggregate elements from step 5 using an Archimate 3.01 specialization relationship.
2.2 Meta Model Diagram
The source for the requirements in this meta model is the Directive on Identity Management (DIM).
This is my current thinking an approach on how to tackle this. For GoC staff there is also discussion on the GCConnex site for how to proceed, so if a consensus is reached that differs from my approach I’ll post an update.