Welcome to Sufficiently-Advanced Technology!

Agility is a term that is typically poorly-defined–and often overloaded–in many business circles. Yet the underlying capability remains highly sought-after. Agility can be broadly defined as the ability of the business to adapt and respond to change. Agility is desirable because change is inevitable, and comes in a number of forms. With the progression of technology, from digital computers to personal computers, to the internet, to the web, to the mobile web, and beyond; the rate of change is only increasing. Businesses unable to keep pace will be disrupted, and we see this almost daily. We also cannot escape the fact that software runs almost every business. While there is a near infinite number of ways to write code to ship a set of features, software systems that are rigid and difficult to change will continue to constrain business agility. In short, if our software is not agile, the businesses it powers won’t be either.

As we have discussed in previous posts in this series, conventional wisdom is that monolithic architectures might offer low cost and high simplicity, but aren’t capable of meaningful agility. Through careful combination of key architectural constraints, however, architecture can yield monolithic systems that balance agility and simplicity. The goal of architecture is not to provide “a lot” (undefinable) of a given capability, but a minimum of “enough” (driven by business needs). To this end, we introduce another abstract architectural style, the Microkernel Architecture Pattern.

Continue reading...

When many developers these days are asked “Which is better: Monolith or Microservices?” The answer is often a resounding ‘Microservices!’ The term monolith has become a pejorative; a veritable four-letter word in some software architecture circles. The folk-wisdom criticisms are not entirely undeserved, after all there are a lot of bad monoliths out there; unmaintainable, untestable, brittle to the point of personifying a Jenga tower of code. Yes, the microservices pattern offers many strengths. Yes, the layered monolith carries many weaknesses. However, that’s not the end of the story. As we have learned so far in this series, capabilities like testability, maintainability, evolvability, etc. don’t originate from deployment granularity but instead emerge from architectural constraints.

What might the humble monolith look like if an architect applied some of the constraints that give microservices their magic? Meet the Modular Monolith.

Continue reading...

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...

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...

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...

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...

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...

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...

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...

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...