Welcome to Sufficiently-Advanced Technology!

An old-school blog where I write with uneven frequency on whatever seems interesting or important to me at any given time. Typically these subjects tend to center around:

But anything is really fair game here. If you wish to subscribe to updates, I publish an atom feed for use in your favourite reader app or you can follow me on mastodon. I speak at a number of conferences, my speaking schedule is maintained over here. I also host live Software Architecture Workshops and do occassional private training, speaking, and consulting gigs.

Thanks for stopping by my little corner of the web.

Recent Posts

Abstract Style: Layered Monolith

Drawn/blueprint-style illustration of the layered monolith architecture pattern.

Patterns have become indispensable tools in software development.. Patterns can provide a high-bandwidth mechanism for communicating ideas, however as our industry has noted (and we explored in-depth in our previous post) application of architecture patterns rarely yield a consistent set of outcomes for any given project. A powerful solution is to apply the idea of design-by-constraint. This resolves the prevalent semantic ambiguities of our current architecture pattern set and enables a more reliable and deterministic means of inducing architectural capabilities in systems.

In the dynamic world of software architecture, be it for buildings or software, two dominant philosophies emerge. The first imagines a designer starting from scratch–a void on a whiteboard–and begins meticulously crafting an architecture, piece by piece, with familiar components until it embodies the system’s aspirations. The alternative perspective envisions a designer commencing with an all-encompassing view of the system’s requirements, unshackled by constraints. As the design evolves, constraints are strategically imposed on system elements, fine-tuning the design canvas and allowing the forces that mold system behavior to move fluidly, in perfect sync with the system’s essence. While the former accentuates unbridled creativity, the latter champions understanding and discernment within the system’s milieu. It’s this latter philosophy that the Tailor-Made Software Architecture reveres, focusing on constraints as composable design elements to both precisely define our architectures and also enable fine-grained control of the capabilities and characteristics the architecture elicits. Architectural constraints possess a high-degree of reusability and they can typically be applied to almost any pattern or candidate architecture. For the next several posts, we will define the eight common patterns in terms of their core constraints, potential optional constraints, and highlight how the composition of these constraints results in a predictable set of architectural capabilities. We begin with the humble layered monolith.

Continue reading...

Architectural Styles - The Tailor-Made Pattern Language

interior of a complex glass building with the caption 'Architectural Styles'

In our previous post, we discussed how the business problems we tackle through software architecture seldom align perfectly with just eight sizes (the conventional architecture patterns). More often than not, any system’s architecture that adheres to a specific pattern tweaks it significantly. This deviation brings forth two critical challenges that the Tailor-Made approach seeks to resolve:

Firstly, the prevalent tendency to oversimplify diverse and distinct systems filled with numerous modifications leads to miscommunication and ambiguity in portraying the architecture’s intricacies. Secondly, relying on a pattern-based language holds value only if there’s a unanimous consensus regarding the pattern’s definition.

We have already shown that an architecture can essentially be defined by its constraints it is, consequently, imperative to embrace Dr. Roy Fielding’s notion of the “architectural style.” Such an adaptation ensures clearer pattern definitions and more transparent architectural communication. Moreover, it unlocks a vast spectrum of architectural styles, moving beyond the confines of the standard eight patterns.

Continue reading...

Eliciting Capabilities Deterministically - Design by Constraint

A Windows XP alert box reading 'task failed successfully'

In the multifaceted world of software architecture, there’s a tantalizing allure to architectural patterns promising given set of capabilities. We, as architects, gravitate towards these seemingly well-structured models, hoping that by employing ‘Pattern X,’ our deployed system will exhibit ‘Capabilities A, B, and C.’ Yet, reality often paints a different picture. Despite our sincerest intentions and methodical adherence to models, these expected capabilities can prove elusive, leaving us pondering where and how the divergence occurred. This divergence isn’t just a hiccup in the grand scheme of system design; it’s an essential reminder that architectural blueprints, foundational as they are, often lack completeness. This fundamental disconnect was one of the major drivers for me to begin to formalize the Tailor-Made Architecture Model. In this post we will embark on an exploration of this inconsistency, striving to understand why deterministic results from architectural patterns can sometimes be more of a mirage than a milestone.

Continue reading...

Business-Driven Architectural Capabilities

A CC-BY illustration depicting putting the cart before the horse

Generally, when I am hiring for any technical position, I am less interested in what a candidate knows and more interested in how they think. This is doubly true when evaluating prospective architects. To this end, I’ll often directly ask “What is the best architecture?” A surprising amount the time, I get answers like “microservices.” In my experience, this type of answer often betrays a lack of architectural thinking. I won’t typically terminate the interview right then and there. I want to give them the benefit of the doubt as it is easy to misunderstand a question and it can be challenging to determine expected answers in the heat of an interview (especially arguably trick questions like this). I will always ask some follow-up questions as an opportunity to course-correct, but historically they haven’t and thus I have yet to hire someone after an answer like that.

Architecture doesn’t exist in a vacuum and we must avoid projecting our own biases and preferences into this type of work. We can’t have the architecture conversations without first having business conversations. Anything less is putting the cart before the horse, which is a formal architecture anti-pattern. In this post, we look at where architecture decisions come from, how to avoid common anti-patterns, and look at a process to begin to infer architectural capabilities from requirements and conversations with business stakeholders.

Continue reading...

Defining Architecture Capabilities

A complex, abstract web of millions of components

Some years ago, I sat in on a conference session hosted by Llewelyn Falco. In one timeboxed exercise, the class collaboratively wrote and iterated over a single line of code. Within about 10 minutes we had come up with several dozen ways to express that single line and, when time ran out, we weren’t slowing down we were speeding up. I left that experience with conviction that there are a near infinite number of ways to write code to implement a set of features. All implementations may provide equivalent functionality, but they don’t necessarily offer the same system capabilities.

In our previous post we discussed how architecture is focused on the capabilities of a system beyond its features and functions. As architects, it’s our job to carefully and mindfully constrain the degrees of freedom on code with the goal of having the desired set of capabilities emerge. But what are the capabilities? In this post we will explore and define various architectural characteristics.

Continue reading...

Becoming an Architect

A blueprint-style diagram of a custom suit and a software architecture diagram. The caption reads 'Tailor Made Software Architecture'

I’ve spent the better part of the past year developing a formal model, process, and distilling a way of thinking about software architecture. The result is an approach I’m calling Tailor Made Architecture. This is the first post in a long series to explore these ideas. If this topic is of interest to you, note that this blog has an atom feed to subscribe to updates. Check out my speaker website for speaking dates where I will be covering this topic. Also, if these ideas resonate and you’d like to participate in an immersive, hands-on, three-day workshop; I’ll be giving the next workshop in Dallas, TX November 13-15. Early-bird discounts are available through October 13th.

Continue reading...

Insights, Shallow-Work, and the Next Correction

Person in front of a computer looking at a down market chart. PD from pexels.com

2020 was a rough year. Much of my income had come from live performances as a magician, live events as a speaker and trainer, and in-person consulting gigs. By March of 2020, every live event was being dubbed a “super spreader” event, markets were cooling, and enterprises were preparing to “batten down the hatches” in anticipation of unknown societal and financial disruption. My livelihood was in grave jeopardy. My wife and I tightened our belts hoping to ride out the storm but, by the summer, it became clear that this particular storm had an indefinite duration. I eventually accepted a job as a principal software architect at an intriguing startup within the enterprise and quickly rose through the ranks to become their Chief Architect.

As my responsibilities grew, I realized it would be crucial to scale myself and my contributions, so my focus turned to hiring and I had never seen a market like it. Salary expectations had inflated 100%+ since I was in the market. Signing bonuses were being offered at a scale I had never seen before. As it became harder and harder to attract talent, compensation only continued to increase. I won’t lie, I was a little bitter and a little envious. My direct reports I hired were earning substantially more than I. I expressed these feelings to a colleague who asked, “Have you considered looking, yourself?” My response was “It crossed my mind, but I think it would be a bad idea. ‘Those who live by the sword, die by the sword.’” In other words, the tech market looked an awful lot like a bubble. I didn’t know when it would burst, but I knew it would. Companies were responding to the market changes by “warchesting” talent; proactively hiring for roles that didn’t even exist yet. 18 months later came some of the most brutal layoffs I’ve seen since the 2000-2001 era and almost all of those who found themselves swept up in the cuts were downsized through no fault of their own.

I believe another correction is imminent, but this might be a good thing, depending on how we navigate it.

Continue reading...

Sufficiently Advanced Technology, Software, & Sorcery

Playing Cards spread out on a table

Somewhere in the world there are magicians who are still talking about a magic trick they simply can’t explain… or perhaps they have solved the mystery. The linchpin is a single idea. One fact.

Almost 20 years ago I crossed an ocean to attend my first live magic conference. The headline acts/speakers included Jeff McBride, Eugene Burger, and Darwin Ortiz; all major influences of my work and I couldn’t pass up the opportunity to meet and work with them in person. I went alone and knew nobody attending, although that would change before the convention even began.

In the restaurant on the eve of the convention, I dined solo and mostly people-watched. I watched the retirees who have devoted a portion of their newfound free time to rekindling a childhood hobby. I watched the one or two young kids with their tiger-parent relentlessly molding them in to future Vegas headliners, and I watched the adolescents who spend every waking moment drilling the most difficult sleights and the most elaborate flourishes. There was a whole group of the latter engaged in what could be best described as the legerdemain equivalent of a rap battle, each attempting to one-up the displays of dexterity demonstrated by the last. With nothing to do (and nothing to lose) I approached this group. Minutes later, I left them speechless.

Continue reading...

Content Negotiation - A REST Superpower

Screenshot of an API testing tool that focuses on the 'Accept' header in the request, with a value of 'application/json'

REST is the architecture of the web and the web has seen unprecedented growth and evolution since its inception over 30 years ago. A web of static documents gave rise to the read/write web–the so-called web 2.0. New media types and formats have evolved, protocols have become more powerful and more secure. In short, the web has only grown bigger in scale, more powerful in terms of capabilities, and continues to evolve. The human web is a marvel of software engineering and its longevity is a testament to the vision its founders and architects. Unlike much of the software I use today, I have never opened a web browser to a message that the back-end of the web has undergone a breaking change and I would need to download new software before continuing.

At some point in the first decade of the 21st century the web crossed an inflection point; machine-to-machine API calls eclipsed human traffic on the web. Many of these APIs have been labeled REST APIs despite many–perhaps even most–of these APIs fail to exhibit the qualities elicited by truly following the REST architectural style. Consequently, the machine web consists of a lot of brittle integrations that require countless person-hours to craft and maintain. To be clear, I’m not here to get on my soapbox about how all these sinners are “doing REST wrong”; I really don’t care. Not every API needs to–or should–be a REST API. The REST architectural style is a very specific tool to solve specific problems.

“Some architectural styles are often portrayed as “silver bullet” solutions for all forms of software. However, a good designer should select a style that matches the needs of a particular problem being solved.” -Dr Roy Fielding Architectural Styles and the Design of Network Based Architectures

Fundamentally I want to talk about some of the overlooked aspects of this architectural style and how they can be implemented to eliminate problems with versioning, evolution, and flexibility. Today we’re focusing on content negotiation.

Continue reading...

The Future is Here (it's Just not Evenly Distributed)

A screenshot of a jupyter notebook demonstrating connecting GPT to a knowledge graph.

A few weeks ago I wrote an article on how investing in structured, semantic data can help move tools like ChatGPT from the “Trough of disillusionment” to the “plateau of productivity” and create intelligent agents that are actually intelligent. The core was that standardizing on REST Level 1 (or better) and beginning to layer in JSON-LD could provide a more meaningful and factual foundation for generative AI like GPT3 to deliver revolutionary value to organizations.

Less that three weeks later, Tony Seale, a Knowledge graph engineer, posted a brief demo video of these ideas in action.

Continue reading...