Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GC Architecture Crosswalk with Archimate #4

Open
samperd opened this issue May 31, 2019 · 3 comments
Open

GC Architecture Crosswalk with Archimate #4

samperd opened this issue May 31, 2019 · 3 comments

Comments

@samperd
Copy link
Collaborator

samperd commented May 31, 2019

User Story

As a Canada-ca/architecture contributor
I want a cross walk between GC policy instruments and Archimate artifacts
So that I can effectively decompose GC Elements into Archimate elements

Work to date:

This is an ongoing attempt to create such a crosswalk for my own architectures, however it has not been vetted or validated by the community.
MappingTogafArchimate2GovernmentOfCanada Comments are welcome, or ask to contribute

@SteveSavage
Copy link

Hi Dave, I've put some thought in to this already
http://stevenksavage.com/2018/12/16/modeling-policies-and-directives-for-reuse/
http://stevenksavage.com/2019/04/24/departmental-plans-and-priorities/

One thing I realized is that most statements in the policy instruments are overloaded, so I typically stick with just using the Archimate Requirement element to capture the original statement, that is then realized by one or more elements.

Example:
A single statement may indicate the need for an actor, to establish a individual in a role, so that the individual in the role can deliver a business object (which infers that a process will need to be put in place for the creation of that business object)

I looked at your mappings and they pretty much agree with what I use:

  • Driver = Source Document

The following "realize" one or more Requirement Statements extracted from the Driver.

  • Business Actor = Organization or Organizational Unit, e.g. ECCC or a branch within ECCC
  • Business Role = Job Title / Role, e.g. CIO, CSO, DG, Security Experts etc.
  • Business Object = Any document or report that has to be created

The rest of the Archimate elements should be pretty self explanatory for how they get used, but we can formalize if we notice inconsistencies.

@samperd
Copy link
Collaborator Author

samperd commented Jun 4, 2019

Yesterday I was working on modeling Open mandate letters. I am sticking at the motivational level so far. I will work to share the outputted architecture for wider comment, however I think that the challenge for me with architecture will be to tie together each view point level to drive from motivation to systems and tech. it is nice to float at the motivation layer sometimes.

For the mandate letters I think much of the content can be treated as goals and then through refinement draw out the requirements.

@SteveSavage
Copy link

I've done some work with the ECCC Minister's mandate letter, the Departmental Plans.
I agree, most of the statements in the mandate letter can be realized by Goals, that are further realized by the creation or modification of services.
For simplicity I typically just show the trace from statement -> goal ->

  • role and/or actor that owns the goal
  • new/changed business service that allows them to achieve their goal.
  • then the typical elements associated with the service, e.g. who will use, input/outputs.

It may be useful to explicitly model how the change (required to achieve the goal) will be achieved using the Implementation elements. http://pubs.opengroup.org/architecture/archimate3-doc/chap13.html#_Toc489946125

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants