Tag Archives: RACI

Crossing the EA Chasm: Annotating Your EA Models with RACI Roles

In the LinkedIn ArchiMate posting Difference between business/application/technology process?, Anna Aaltonen asked:

“Does someone have good examples how elements Technology process and Application process differ? Maybe comparing also to element Business process. Basically, processes are the same, no matter how those are executed. Basically moving from higher level models to detailed models is just playing with hierarchy, not changing layer. I am looking for a practical example (preferably an example using all those) as well as some hints how to guide modelers (in practice), when they ask whether they should use this or that.”

One tip I use to help clarify these type of questions is to think about the constituencies served by each layer in a traditional enterprise architecture model and add the specific list of roles beside (to the right side of) each layer. Below is an example taken from the article ARMs for Metadata-Driven LOB apps: SharePoint 2013/SharePoint 2016.

parallelspace-arm-sharepoint-2013-2016-v1-0-12-roles4

Figure 1. Enterprise Architecture Layers: Constituencies

 

For each of the layers, the list of pertinent roles is listed.  I choose to further organize the roles based on  RACI categories (also check out this related article):

  • Responsible (Deliverables)
  • Accountable (Approvers)
  • Consulted (Contributors)
  • Informed

Linking back to Anna’s question, this approach helps to focus everything that exists in a particular layer relative its constituency. Business Processes serve the needs to the Business architecture layer constituency; Application Processes, the needs of the Application layer constituency layer; Technology Processes, the needs of the Technology layer constituency.

Application Processes include development, testing and maintenance. For Technology Processes, deployment, operations and upgrading are simple examples.

Best regards,

Michael Herman (Toronto)
Parallelspace Corporation
mwherman@parallelspace.net

 

1 Comment

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Enterprise Architecture

How we think about how we work

How do we think about how we work? We rely on a few simple processes. Here is a list:

  • Progressive Improvement & Learning Process (PILP)
  • Continuous Transformation Process (CTP)
  • Deliverable Review: Initiate, Create, Review, Validate & Approve Process (ICRVA Process – “I crave a” Process)

Many thanks go to Alison Williams for helping me to clarify the Continuous Transformation Process (CTP).

Michael Herman (Toronto)

Progressive Improvement through Continuous Transformation

Progressive Improvement thru Continuous Transformation 1-0-1

Progressive Improvement & Learning Process (PILP)

Progressive Improvement A 1-0-1

Progressive Improvement B 1-0-1

Continuous Transformation Process (CTP)

Parallelspace Continuous Transformation 2-0-1

Deliverable Review

Initiate, Create, Review, Validate & Approve (ICRVA) Process (“I crave a” Process)

Parallelspace ICRVA v12-0-2

Parallelspace ICRVA v12-0-2 Complete

The roles in the ICRVA process are based on the RACI matrix of responsibilities.

Michael Herman’s Hierarchies

  • Awareness – Knowledge – Understanding – Wisdom
  • Dream – Desire – Want – Need
  • Sensing – Learning – Training – Experiencing
  • Keywords – (Controlled) Vocabulary – Glossary – Dictionary – Taxonomy – Ontology

Michaels Hierarchies

Product Management: 3 Prioritization Levels

  1. Need to have
  2. Nice to have
  3. *Neat* to have

Scalability Levels

hyper-scalability-1-0-1

 

 

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation
mwherman@parallelspace.net

 

 

 

3 Comments

Filed under Architecture Reference Models, continuous transformation, Crossing the EA Charm, Definitions, How do we think, Parallelspace TDM, Process, Progressive Enterprise Architecture Map (PEAM)