 |
| [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:
No comments:
Post a Comment