intltechventures.blogspot.com: 2023-08-12 Saturday

2023-08-12

2023-08-12 Saturday - On The Value of Patterns

[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:

Partners: 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:

Partners: 1

NFR: Integration MUST BE designed for High Availability
NFR: Integration MUST BE designed for Reliable Delivery
NFR: Data Latency MUST BE less than 1 hour.

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:

Partners: 1,000

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: