 |
[image credit: ValdasMiskinis on pixabay.com]
|
A recent conversation with a colleague has given me pause to think about one of the more severe stumbling blocks - that I now believe - Enterprise Architects are perhaps far too...
unaware of (to be generous),
or have made a conscious choice of perceptual blindness (possibly),
or are simply operating with an unconscious inattentional blindness (likely).
My university education was in the field of classic computer science - so I have an inherent bias towards thinking in terms of data structures, algorithms, and patterns.
Patterns are such a foundational cornerstone of how I think, and how I approach problems & solutions - it is just a part of my professional DNA.
I cannot comprehend working on any endeavor of software engineering, or at any of the various levels of architecture (enterprise, security, infrastructure, information/data, system, software, solution, ...) without leveraging patterns (either intentionally, or unconsciously).
To be sure, there are numerous real-world solutions, and mountains of bad code - that were created with no conscious and intentional use of patterns, although unconscious choices of patterns did occur (e.g., Spaghetti is a pattern - it's just, more precisely, an example of an anti-pattern).
Patterns are building blocks.
They can be defined from the micro to macro scale.
They are the basis for any ability to achieve reuse.
They (generally) should not be implementation specific.
They are not implementation specifications.
They are not solution (detail) designs.
Nor are they solution architectures (which by definition, must be implementation specific).
Patterns exist (and suffer) with many different taxonomies - but they do exist.
By studying patterns, you reduce the cognitive load to understand, or design, anything - and it can be very helpful in bringing clarity and precision to any communication.
Patterns support consistency, repeatability, reliability - in the design of any solution.
Most patterns require stipulation of the types of problems (or conditions) under which a given pattern is appropriate - and those for which it would be inappropriate.
About that stumbling block I mentioned earlier. Sadly, the utility and value of patterns are not universally understood by everyone that works in Information Technology (IT). It is quite often dismissed as too theoretical. Nothing could be further from the truth. Patterns are the bedrock upon which reliable systems are built.
To explore the depth of someone's understanding of patterns, I use a simple discussion exercise, that goes something like this:
Imagine that your company [A] has a new business requirement to send Customer Information updates to partner [B].
Stipulations:
- There is no current integration between [A] and [B], for this data.
From just that baseline description - the relative degree of experience and expertise of an individual can be quickly assessed - based on the questions they ask, before they begin proposing a solution.
Walking someone through this exercise, can also be very useful, to help explore their understanding of patterns.
To help with this discovery effort, I use three different sets of requirements, that I assign to three different project phases.
What is interesting to me, in observing how someone responds to just
the limited integration requirements of Phase-1, is which patterns do they turn to
first? What questions do they ask? Do they discuss any trade-offs in their consideration of possible choices? Or, do they leap to a solution, before asking any questions? To what degree do they understand/explore the possible Non-Functional Requirements (NFRs)?
Phase-1:
- NFR: Data Latency MUST BE Less than 24 hours.
Phase-2 requirements, forces someone, who may be just on the edge of making a different integration solution decision - usually to reveal much about their experience, their preferences, their depth of understanding for long-term change management, solution maintainability, operational impact, and potential trade-offs. Observing the questions that someone asks at this point in the discussion...where their
thinking goes, how they weigh the different potential trade-offs...is often very illuminating...as is any dearth for just such considerations.
Phase-2:
Phase-3 requirements are where someone's depth and breadth of experience and expertise are really discovered. No one can hide from this revealing change in requirements. All is laid bare.
Phase-3:
- NFR: Data Latency MUST BE less than 60 seconds (which, although not explicitly stated, implies an NFR for Scalability)
The long-term implications of any patterns proposed/chosen, across these three sets of fairly simple requirements - can be a great teaching tool, for those that are willing to listen - and engage in an open and honest dialogue.
Hopefully, participants in such discovery discussions, may deepen their appreciation of the nuances of various concerns that a pattern-based approach can help encapsulate and encompass, in a repeatable, and reusable, manner.
Without understanding the implications of pattern choices - some folks may continue to just use techniques that they have grown comfortable with - but which can be woefully inadequate for the requirements stipulated. This has implications for many Non-Functional Requirements (NFRs):
- Accuracy
- Adaptability
- Availability
- Change Management
- Compliance
- Configuration Management
- Cost, initial and Life-cycle cost
- Data Integrity
- Data Latency
- Data Quality
- Disaster Recovery
- Efficiency
- Extensibility
- Failure Management
- Fault Tolerance
- Interoperability
- Maintainability
- Network Latency
- Observability
- Operability
- Performance
- Response Time
- Memory Utilization
- CPU Utilization
- Reliability
- Repeatability
- Resilience
- Re-usability
- Scalability
- Capacity
- Elasticity
- Throughput
- Security
- Authentication
- Authorization
- Encryption
- Exploitability
- Attack Surface Area
- Stability
- Support-ability
A good pattern should address a relevant set of NFRs for a particular problem/solution context. This helps teams be holistic in how they approach solution design - and it can help them avoid missing key/critical concerns.
References:
- https://en.wikipedia.org/wiki/Pattern_language
- https://www.patternlanguage.com/
- https://en.wikipedia.org/wiki/A_Pattern_Language
- https://arl.human.cornell.edu/linked%20docs/Alexander_A_Pattern_Language.pdf
- https://wiki.c2.com/?DesignPatterns
- https://en.wikipedia.org/wiki/Software_design_pattern
- https://en.wikipedia.org/wiki/Enterprise_Integration_Patterns
- https://en.wikipedia.org/wiki/Modular_design
Suggested Books:
(still working on this list, will add [n] numbering later...)
[-] Christopher, Alexander, et al (1977). A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series)
[-] Davis, Cornelia (2019). Cloud Native Patterns: Designing change-tolerant software, First Edition
[-] DiBernardo, Michael, et al, (link retrieved: 2023-08-12). The Architecture of Open Source Applications
[-] Fowler, Martin, et al (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 978-0-321-12742-6
[-] Freeman, Eric T.; Robson, Elisabeth (2021). Head First Design Patterns, 2nd Edition
[-] Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 978-0-201-63361-0
[-] Hohpe, Gregor; Woolf, Bobby (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. ISBN 978-0-321-20068-6, [companion web site]
[-] Indrasiri, Kasun, et al (2021). Design Patterns for Cloud Native Applications: Patterns in Practice Using APIs, Data, Events, and Streams, 1st Edition
[-] Resnick, Pini, et al (2020). Cloud Native Transformation: Practical Patterns for Innovation, 1st Edition
[-] Richardson, Chris (2018). Microservices Patterns: With examples in Java, First Edition, [companion web site]
YouTube Videos:
- Christopher Alexander - Patterns in Architecture
- The 1996 ACM Conference on Object-Oriented Programs, Systems, Languages and Applications (OOPSLA). San Jose, California, October of 1996
- ...
