Introduction

The roots of this article are from a real-life case: a Big Consulting Firm (TM) showed us their infrastructure architecture proposal for migrating to the cloud our Drupal and WordPress-based, low traffic, corporate websites. It was like one Kubernetes orchestrator per application (three of them) and per environment (four of them). I will not discuss the details of such project, as one may certainly find an interest to such approach and surely it has a point, but the purpose of this article is not a technical review of this particular or any other architecture, and even less to blame someone (of course I will not disclose any details about my customer nor the consulting firm). Indeed, we had a technical review, and we finally choose something different, but at some point, during the meeting, my customer stared at me and asked: “are they bullshitting us?”. “They are probably trying to sell us something overkill, and it’s going to cost us much more than we want” I answered but that fostered more questions to me. Does a bullshit architecture exist? Can we recognize it? Are there patterns? Frameworks?

What is bullshit?

The interest into bullshit as a social phenomenon and as a speech construct spreads across philosophy, sociology, organization theory and certainly many other fields of study. It is often defined as a talk that has no reference to the truth (Frankfurt, 1986) and that has a purpose – often, to impress and/or mislead the audience. Further research focused to the intrinsic structure and characteristics of the bullshit statement rather than its effect and identifies the key feature in its unclarity (Cohen, 2002) and difficulty to clarify. Related to this point, it seems remarkable to me the “bullshit asymmetry principle” (Brandolini, 2013) that recognize in bullshit something that requires more energy to refute than to formulate. Another (Spicer, 2020) interesting characteristic of bullshit is that it easily spreads (and is often encouraged) in a context of uncertainty (within organizations or communities). The field of ‘bullshitology’ is growing and raises many questions about the nature of our society and organizations, which obviously go beyond the scope and the purpose of this article, but as IT professionals, managers, consultants, and entrepreneurs we are frequently confronted to bullshit. For a practical approach and an everyday framework, I will retain three keywords, “obscurity”, “impress” and “uncertainty” as key characteristics.

Do bullshit architectures exist?

It is not straightforward to translate a feature of a speech construct to an artifact such as an infrastructure or software architecture, but there are certainly some relevant analogies. Architecture has deliverables but is by its very nature a human activity and its social features are important. It requires decision making, setting boundaries, and drawing a line. Digital transformation and move to cloud have been and still are major drivers for organizations transformation at many levels and we have seen entire departments being rebuilt from the ground up, bringing them into new and uncertain territories. As IT professionals we continuously explore and adopt new technologies and we thank Gartner for reminding us that technology lifecycle is also driven by hype and emotions. Jargon and buzzword have both their place in the workplace, and we must be careful when we use them. My belief is that bullshit architectures exist, and, while there may not be an intrinsic or a one-size-fits-all recipe to recognize (or build, if you’re more inclined to) them, some guidance can be provided.

A framework for bullshit architecture

A model should be built to target main aspects of the proposed architecture against the three keywords “obscurity”, “impress”, “uncertainty” to score the bullshit level. Criteria may follow the standard/usual evaluation metrics and could assess:

• Documentation
• Commitment
• Benefits
• Compliance Some examples: Obscurity/Uncertainty: Does the architecture uses exoteric or building blocks completely new to my organization? Impress/Uncertainty: Is the architect accountable for the design? Obscurity/Impress: Is the architecture understandable in its core parts, with regards to actual stakeholders? Obscurity/Impress: Are the arguments correct and verified?

Conclusion

As per the Brandolini law, “the amount of energy needed to refute bullshit is an order of magnitude larger than to produce it”, therefore a framework to identify bullshit (or at least trigger an alert) can be useful to save time and energy just as any other architecture evaluation framework. A side effect of such framework is that, being the bullshit a social phenomenon, it allows to assess the relationship with the [architect/consultant/partner]. We can help you!

About

Ambrate is an independent consulting company based in Paris, France, whose activity spans from management consulting, audit, innovation management and new technologies. Contact us for more information.