2025-03-23 Sunday - Design and Architecture Reviews

 

[image credit: Guren-The-Thirdeye on pixabay.com]

 [my companion LinkedIn post]

Today's meditation:

Today I read a LinkedIn post by a Meta IT leader...with a long list of technology preferences/choices by which they would identify when NOT to hire someone...they also included design and architecture reviews.

To me, that is a very harmful belief. It smells of hubris. It is toxic.
I would hope that is not a commonly shared belief within Meta...but if it is, it would explain much.

No one person knows everything.
Humility is a valuable character trait in every leader.

Assuming you probably missed something should be a First Principle for any practice of design or architecture review.

Even if the design and architecture are correct - you may still yet learn something by engaging in a review with others.

But, here's the point that most people miss: Design and architecture reviews are also teaching and communication tools - for the benefit of others.

In 40 years, based on my many and varied field observations, across many organizations, for countless projects and initiatives - for almost any non-trivial problem, I think there have always been some useful observations, questions, suggestions, concerns raised - during a design or architecture review. In some, catastrophically bad decisions were corrected.

You do not waste time by engaging in design or architecture reviews - you are performing an important and necessary governance function - to mitigate potential risks, as well as supporting the communication (and awareness) aspects of change management.

 

2020-05-04 Monday - A Metaphor for The Absence of Enterprise Architecture

Public Domain

A beautiful inverse metaphor for the practical value of Enterprise Architecture and Governance.

Put another way, a perfect example of the __absence__ of Enterprise Architecture.

Today's analogy: Every user/department - deciding to have their own dedicated/different application. No reuse. No governance. Also, point-to-point integration strategies, tight coupling, and single points of failure.

A telephone tower in Stockholm, Sweden, 1890. The tower served 5,500 subscribers. Each subscriber had their own dedicated cable.

• https://rarehistoricalphotos.com/the-stockholm-telephone-tower-1890/

2019-07-27 Saturday - Repeatable Architecture Processes

Photo by Suzanne D. Williams on Unsplash

In my consulting practice, there are several tools that I've created over the years to help clients move toward establishing repeatable architecture processes - and eventually moving toward an Agile (and Lean) Architecture approach.

For example:

1) Architecture Assessment Checklist - useful for quickly assessing an enterprise, application, or vendor product/service offering (often used in collaboration with a client's procurement team during their RFP process and preparing recommendations and vendor evaluation feedback to the leadership team).  Using this particular tool - primarily focused on evaluating technical aspects, this level of assessment analysis can often be completed over a period of 3-5 days.

2) Enterprise Architecture Assessment Template - A template for a deeper-dive assessment process - that is typically completed over a period of four (4) weeks - with the report usually consisting of 60-80 pages - that is intended to examine the following areas:

• Business Operations
• Product Management
• Enterprise Architecture
• Engineering
• Infrastructure
• Data Management
• DevOps
• Non-Functional Requirements
• Information Security

3) Enterprise Architecture Artifact Category Taxonomy - Currently in a working draft status, with 369 entries. I recently completed a major revision (v2) to its organization and structure. The next version (v3) will be another major revision and restructuring - and will be formally defined via OWL/RDF - to help facilitate some additional automated processing capabilities that I have in mind for the future.

4) Architecture Decision Record (ADR) Template - used to help facilitate the adoption of Agile Architecture practices - and help an organization move away from historically centralized governance of the majority of their architecture decisions - and minimizing the historically draconian "gating" function of more heavy-handed choke-point processes such as Architecture Review Boards (ARBs)

5) Solution Architecture Document (SAD) Template - An "illustrative, not exhaustive" exemplar - to provide a team or organization with a starting point of establishing a repeatable level of analysis in the preparation of a Solution Architecture - intended to provide guidance to team members that may be new (or, less experienced) - with respect to the concerns that are often missed. Always customized to suit the culture of the client - depending on their level of Enterprise Architecture Maturity, regulatory/compliance requirements, progression on their journey toward adoption of Agile Architecture practices, and on complexity and mission-critical nature of their systems and business operations.

The journey with a client is always a process of evolution - seeking to: "Accelerate. Innovate. Elevate".

2018-08-06 Monday - GDPR and Blockchain Privacy Implications

Some preliminary reading I'm doing...

GDPR

• https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/
• https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN
• http://www.sqlservercentral.com/articles/GDPR/165180/

Blockchain Technology and the GDPR - How to Reconcile Privacy and Distributed Ledgers

• https://heinonline.org/HOL/LandingPage?handle=hein.journals%2Fedpl2&div=71&id&page

Blockchains and Data Protection in the European Union

• Max Planck Institute for Innovation & Competition Research Paper No. 18-01
• https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3080322
• "This paper examines data protection on blockchains and other forms of distributed ledger technology (‘DLT’). Transactional data stored on a blockchain, whether in plain text, encrypted form or after having undergone a hashing process, constitutes personal data for the purposes of the GDPR. Public keys equally qualify as personal data as a matter of EU data protection law. We examine the consequences flowing from that state of affairs and suggest that in interpreting the GDPR with respect to blockchains, fundamental rights protection and the promotion of innovation, two normative objectives of the European legal order, must be reconciled. This is even more so given that, where designed appropriately, distributed ledgers have the potential to further the GDPR’s objective of data sovereignty. "