TL;DR

Antifragile Design for Systems [AD4S] started as a thought experiment - a moment of clarity from my 20+ years in hardware and software - leading engineering teams from start-ups to multi-national conglomerates. AD4S is a rubric for decisions in complex systems that demand a first-create-then-evaluate working pattern.

The intent of AD4S is to establish an agreed-to set of shared responsibilities among the various constituencies that build, maintain and use a given (ostensibly complex) system. Think of it as version management for higher-order system governance. Through curation of an AD4S ledger a shared agreement is established between the between system builders, managers and users as well as other affected groups, and provides guide rails to the teams that create and support the components they build and maintain.

The Longer Bits

AD4S provides descriptive and prescriptive guidance for teams to evaluate for and avoid costly mistakes in user experience, performance, scale, accessibility, sustainability, security and proactively mitigates legal and regulatory risks. It also provides a declarative framework for anticipating potential unintended harms and related ethical considerations - particularly those ripple effects that trigger outsized rework efforts in the wake of "move fast and break things" environments.

Everyone in the working group must acknowledge their responsibilities outside of the 'super power' that brought them to their role. In Antifragile Design for Systems this precept is as foundational as the law of gravity.

AD4S aspires to make measurable the true cost and actual consequences of product decisions. In order to make it useful to as many organizations as possible it is conceived as a community-led project, which will pose many challenges and opportunities. For that purpose a handful of useful TLDs have been reserved. The next step is to establish the proper location for contributions to be collected and receive comments from the broader community. The result will be a clearinghouse of information where concepts and course-corrections can be mapped out. The hope and expectation is that organizations and individual contributors of good faith will help cultivate AD4S precepts and help build an actionable, responsive and responsibility-minded compendium for crafting better solutions.

What will follow is a series of notes, sketches and ideas that outline the problem space, along with a few ideas around how to shape a potential solution. This isn't an attempt to create the entire AD4S site - but more of an initial ontology and "sketchbook" of examples that underscore the need for AD4S to exist - and hopefully inspire some constructive dialog along the way.

On the corrosive nature of performative leadership

One crucial factor that should be stated up front is that this is not another rubber stamp acronym program. Yes, there's an acronym. But that's as far as it goes. If you're scouting for more flare to put on your suspenders to wear to work - look elsewhere. My experience is peppered with similar experiences where someone plants their flag in front of the parade with, "I'm here to represent the business" - and in AD4S that posture is a cardinal anti-pattern and goes against a core tenet of human centered design. This anti-pattern is most often brandished in project management as a means to confer authority - but can surface within a variety of roles across the working group for any number of reasons. To be fair this can be constructive, but history betrays this to be more akin to explaining a joke - if you have to explain it, it's not as impactful as you think. While it's more common for this type of slippery language to be passed around in corporate IT (where software is a cost center for the business, as opposed to being a driver of profit and loss) it has leaked into prima facae software product shops as well. It implies that the business-to-software-engineering dynamic can be proxied by any generalist. And as with many systemic problems it's often a signal of a broader issue within the organization.

It's a dire warning signal when an IT project is primarily cast as a procurement exercise. This particularly applies to "digital transformation" where previous procurement-centered systems have left an ocean of technical debt in their wake. You can't spend your way past missing technical or domain expertise - and the longer it has been absent, the more expensive it is to restore. While it's more obvious than ever in today's technology landscape, it has always been that way.

Any manager that reflexively "buffers" themselves from the responsibility of active systems management is likely missing key elements in their background and experience to realize that this approach works against business needs. This is what "performative leadership" refers to - and it has myriad forms in any size organization. It's both a process and institutional "smell" for this attitude to persist. At its worst it's a double abdication. On one hand, engineers may be "let off the hook" to disconnect from business input due to proxies that don't have actual domain knowledge. And similarly it can also be a means for the non-adept business leaders to parachute non-technical staff into the project. While it has any number of excuses, it too often is also used to shield the responsible business party from exposing their inability or unwillingness to provide actionable domain knowledge.

These kinds of institutional disconnects - whether by accident, cultural reflex or by design are the beginning of the end for any project and is often an unseen strategic liability for the company. The common practice of "body-ing up" the room with a cadre of eager-but-inexperienced contributors only serves to further undermine a project's charter and dims prospects for a successful delivery.

Good design and proper engineering is everyone's business

Everyone in the working group represents the business. Everyone in engineering has some responsibility to comprehend the broader aims of the system they're building. This concept is about the necessity of a "Venn overlap" across the working group and everyone being fully engaged in expressing the targeted domain. Simply eye-balling a Gantt or burn-down chart won't cut it. Along those lines, it's the role of every business person and their assignees into a working group to carry enough comprehension of business domain to cultivate an ongoing constructive dialog with technical resources. This means that the business "meets the engineers where they are" and having a working understanding of the technical solution such to support their side of a meaningful discussion that can propagate a virtuous feedback cycle. Engineers also must have a working mental model of the current state and future state of the business process under purview - a shared "tribal knowledge" construct that fosters rapid solution development and minimal course corrections. This is about more than competency, it's about empathy. There are no exceptions to this. There are no "escape hatches" - such as excusing business-facing internal software solutions as separate from customer-facing end-user applications. Regardless of whether the tools are licensed or built in-house, everyone in the working group must recognize their responsibilities outside of the 'super power' that brought them to their role. In Antifragile Design this precept is as foundational as the law of gravity. Without it, things simply fly apart.

What's in a name?

So the first footnote to this series of posts is to answer the question "why AD4S?" Of course I wanted a moniker that was brief and catchy, but I also thought it was equally important for the long form to convey specific intent. First and foremost, this process is about antifragility - a term coined in financial circles but has resonance within any compute platform that aspires to professional grade resilience in adverse conditions. It also recognizes the continuous natural tensions within complex solutions well beyond technical concerns - even on a relatively mature platform with a low internal change rate. This framework is about expressing design intent as an ongoing initiative that's equal to and sometimes supersedes elements of technical concerns. Yes, user demands and Moore's Law are most definitely two pivotal factors. But there are an array of issues and considerations that are their equal - and AD4S attempts to embrace and reconcile each of them in a way that's responsible to its customers, producers and where applicable also to broader constituencies that may be indirectly impacted by those decisions.