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: