Category Archives: Entreprise Architecture

Enterprise Architecture – What about “inspections” ?

On Monday January 13th 2020, I attended an event organized by Cyberwayfinder. The event thema was about the different types of architecture required to take care of business strategy, data, technology, security and risk in order to design a Digital Enterprise in a structured way.

The inspection process

At some point one of the presenters talked about an important process for Enterprise/Business/IT/Application Architects : the inspection of the delivery.

This is a well-known problem in IT projects: the target architecture is very often not respected for many good and bad reasons.

This raises the question of “inspection”. When do we inspect the work in progress as Enterprise Architects ? Do we have a mandate for inspection ?

Continuous or punctual inspection ?

We could imagine two types of inspection: continuous or punctual. The continuous inspection requires much more time but is maybe the only way in the context of agile projects…

What to do with deviations ?

At the end of an inspection, deviations could be identified. What can we do with such deviations ?

  1. We accept the deviation and re-integrate it in the “AS-BUILT” architecture
  2. We can ask an immediate rework because the deviation is not acceptable (e.g. bad implementation of security constraints)
  3. We don’t accept the deviation but we don’t force the immediate rework : we register a “technical debt”.

My 2 jArchi scripts

Last year I wrote 2 jArchi scrips. Those scripts allow to add functionality to the Archimate toolkit. (The Archimate toolkit is a a tool which allow Business and IT Architects to model the Business/Enterprise/IT architectutes using the Archimate notation.)

The scripts are tagged #jarchi on Github. (See also github/jfdeclercq)

I always need to search for my own scripts so I post them here also.

Script to add a note to a diagram:

/*
 * New Archi Script
 */
console.log("AddNote Started !");
//var date = new Date();
//console.log(date.toString());
//var note = archimateView.createObject("note", 10, 200, -1, -1);
//note.setText("This is a note.\n\nHello World!");
//var note = visualObject.createObject("note", 10, 200, -1, -1);


// Get the first view in the current selection
var view = selection.filter("archimate-diagram-model").first();
// Get current date
var currentDate = new Date();
// Create a new note and set its text
var note = view.createObject("note", 10, 10, 300, -1);
note.text = view.name + "\n" + currentDate.toString() +"\n" + "Jean-Francois Declercq";
note.fillColor = "#e2e2be";
console.log("Note added to " + view.name);

Script to export a diagram as picture with the name of the view as proposed image name:

//Export View as image (PNG)  with date and diagram name in filename.

// Get the first view in the model
//var view = $("view").first();
var view = selection.filter("archimate-diagram-model").first();
// Get the Base64 bytes of the view in PNG format. Can use "PNG", "BMP", "JPG" or "GIF"
// Options are scale (1 - 4) and margin (pixel value)
var bytes = $.model.renderViewAsBase64(view, "JPG", {scale: 1, margin: 20});

var date = new Date();


// Ask for a file name
var fileName = window.promptSaveFile( { title: "Save View", filterExtensions: [ "*.jpg" ], fileName: ""+ date.toISOString().replace(":","").replace("T","-").slice(0,15)+ "-" + view.name + ".jpg" } );
if(fileName) {
    // Write to file
    $.fs.writeFile(fileName, bytes, "BASE64");
}

Risk Management and ROAM

This nice article on ROAM explains the acronym to be used to manage a risk:.

https://www.linkedin.com/pulse/what-does-mean-own-risk-shawn-yates-csm-spc/

Resolved The risk can be completely or partially avoided. If partial resolution, there is a residual risk
Owned The risk is not fully resolved/accepted/mitigated. Someone is assigned to work on it.
Accepted We accept to take the (residual) risk.
Mitigated Mitigation is what we will do if the risk happens in order to reduce the impact

Demand Manager @ PV Group

From January 1st 2017 until Sept 15th 2017, I worked as “IT Demand Excellence Manager” at PVGroup.

I managed a team of about 5 Enterprise IT architects and 5 Domain Experts (Non-Life, Life, Claims, Employee Benefits and Front).

This was a very good team to aim at the description of the complete Enterprise Architecture : from Business Processes to Technical Infrastructure.

Together we developed an interesting “Enterprise Architecture” process with several activities:

  • Intake
  • Production
  • Review
  • Validation
  • Harvesting

This was the ITDEME  (IT Demand Excellence) process.

In addition we were busy with building some new digital foundations : ESB, ECM, IAM……

Strategies for your enterprise architecture: people or documentation ?

Here is an interesting thought of a colleague yesterday (Thomas Vermassen – Lead Architect ORES) on documenting IT systems:

You have basically two strategies for keeping your Enterprise Architecture knowledge under control.

The first one is to capitalize on people. If your organization is stable enough you can assign clear responsibilities and you should be able to find the right information by finding the right person.

The second one is to capitalize on documentation. Through deliverables you make sure everything is described as it should be. This is most suitable if you have a high collaborators turnover like when you work with a lot of sub-contractors.

The ideal world is probably to have both.

I’m a deliverable minded person and I so I tend to prefer the second one. I value information sharing as it often avoids job protection and silo thinking. The notion of deliverable is also linked to another value that I like : personal contribution.

Also when the architecture is complex I don’t see how you can just book a meeting with someone in oder for him to explain you the 100 business processes in scope. That must be why clever people write books……

PASSME

In IT solution architecture, Microsoft  uses the PASSME acronym for Non Functional Requirements (NFRs):
  • Performance
  • Availability
  • Scalability
  • Security
  • Maintainability
  • Extensibility