2023-08-18 Friday - Today's Meditation - Reference Architecture as Abstraction

[image credit: 422737 on pixabay.com]

 Today's meditation:

I think many IT teams have "lost the thread" on the value of abstractions in design.

A pattern is not a detail design specification, nor is it an implementation specification, nor is it a solution architecture.

Likewise, a Reference Architecture *SHOULD* be kept at an abstract level - and not be misconstrued as a Solution Architecture (which is almost always implementation specific).

However, the major cloud vendors - to include Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) - have decided to classify implementation-specific architecture guidance as "Reference Architecture".

Within their respective *WALLED GARDEN* - it is plausibly reasonable - ONLY within the contexts of their specific cloud services environment - as an acceptable exception to classify that type of an artifact as a Reference Architecture.

However, it is not appropriate to let that smudging of the line of Architecture View taxonomy, definition, and distinction - to expand beyond those narrowly defined contexts.

A Reference Architecture SHOULD be something that can be reused, as a macro-level pattern - regardless of the specific technology in any environment.

To put this another way - your Reference Architecture - SHOULD be at the technical capabilities / standards level - not the technology-specific implementation / solution architecture level.

This allows us to define views, the context, use cases, scenarios under which it is fit-for-purpose - and not fit-for-purpose, as well as its limitations, forces & constraints, NFRs, etc. - that are appropriate for a given Reference Architecture - without worrying about the target platform upon which it may be implemented.

The literature within the field of Information Technology - lacks consistency and clarity on this basic definition - and the lack of such clarity - introduces significant issues with getting alignment and agreement - when introducing the concept of Reference Architectures and Patterns into an organization. And thus, more's the pity.

As I mentioned in the 2nd paragraph of this posting - with intention - I have stipulated my view & definition of Reference Architecture with the proviso of "SHOULD" - I allow that there are edge cases (e.g., Walled Garden) .

The benefits of adopting such discipline in how we define and use Reference Architectures:

• Reuse
• Clarity
• Conciseness 
• Consistency

And designs that consistently address:

• Availability
• Scalability
• Reliability
• Performance
• Security

#patterns, #ReferenceArchitecture, #EnterpriseArchitecture, #SolutionArchitecture, #DetailDesign, #SAD, #Specification, #Abstraction, #Reuse  

 

Finally, none other than Gregor Hohpe (Sr. Principal Evangelist, AWS - and author of the books The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise; and Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions) weighed in with this comment on my original LinkedIn post:

 

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".

2019-07-27 Saturday - Solution Architecture Document (SAD) Template

I've published an update to my Solution Architecture Document (SAD) Template - and have begun to incorporate elements of my Category Classification Taxonomy into the SAD.

Still very much a working draft - intended as a helpful starting point from which teams can further customize to suit their needs.

https://github.com/intltechventures/Consulting.Project.Tools/blob/master/templates/SAD.md