Enterprise Archaeology
Uncover the history and prehistory of the decisions and assumptions that have lead to the current state of an organization as a means to effect change.
ar·chae·ol·o·gy
/ˌärkēˈäləjē/
noun: archeologythe study of human history and prehistory through the excavation of sites and the analysis of artifacts and other physical remains.
As a solutions architect, I sometimes find myself in a situation where I see a deficiency in how the team is executing on a specific process (delivery/deployments, for example). While there a number of ways that this can by remedied, a monolith of organizational history and established practices is skeptical of the need for change; yet, there doesn’t appear to be any concrete reason why the current state is the way it is.
Moreover, the history that lead the organization down the path that lead to the current state was never documented, since the “decisions” were really assumptions.
As an SA, I am in a position were if I chose to, I could push hard enough to force the change. However, that tactic is fraught with unintended consequence, and is really designed to repeat the same missteps that resulted in the current state. First, I would be making an assumption that there are in fact no good reasons for why things are the way they are. Just because those reasons weren’t documented or even formally discovered doesn’t mean there aren’t any. Second, I’m assuming that any alternative I decide on is better than what the team is working with.
“Assumption is the mother of all mistakes.”
— Eugene Lewis Fordsworthe
Example: A delivery team is beholden to a specific release cycle of 3 weeks. This artificial timeline is resulting in often very large releases, which are difficult to manage when promoting to their Production environment. The team is invested in Agile practices, but the mandated release dates are inhibiting further adoption of these practices. At face value, there isn’t an apparent technical or procedural reason for the mandate.
Forearmed with some humility, the only safe assumption is that we don’t yet know what we don’t know.
The Excavation
When I was drafting this article, I dithered on whether to reference archaeology or paleontology. In the end, archaeology won because of its clear ties to people. Every enterprise and its decisions are the result of people, and so the excavation of the history will inexorably be similarly bound.
I treat the notion of “tradition as explanation” with disdain. The reason for the way something is should never be “because that’s the way it has always been”. I should be clear that if tradition is the answer, it doesn’t necessarily invalidate the current state; instead, it’s simply not the correct answer.
In my experience, tradition is wielded as a easy but inelegant way to gloss over the fact that assumptions were made. No one wants to be put on the spot for assuming a fact (especially when it’s not documented in a concrete way). As we work through the layers of process sediment that have settled over our dig-site, just remember that our goal is to find some truth, and not to lay blame.
This excavation exercise can be a long engagement. Depending on the scope of what you wish to change, and the amount of history involved, it may require 6 months to 2 years to finally implement a solution. The good news is that most of the unearthing can be handled (at least initially) in informal meetings and conversations.
It might go without saying, but we are working to avoid assuming — so I will explicitly mention that the discoveries you make should be documented. Remember also that you are documenting history, and your documentation should reflect the timeline of events and record the evolution of the approach. This serves two purposes: 1) Evidence in support of why a change can or should be made, and 2) Documentation of why a thing exists in case the result of the discovery is that the thing should remain in place.
Example: As relatively new additions to the organization, we’re not really sure where to start digging. We ask our counterparts on other product teams their thoughts, and confirm that they too have similar (or the same) strictures. If there is a dedicated DevOps team, or Change Management/Advisory Boards, then they too likely have insight into the reason or history of why/how the release cycle was defined. We may or may not have started formulating alternatives, but the more we learn, the more our options are refined and defined.
The Discovery
With new documentation in hand, we are now able to revisit the topic of redress of the process in question. As stated above, we will almost certainly arrive at one of two conclusions. Either the thing we wanted to change is built on a shaky foundation and should be replaced, or there are valid (and now documented!) reasons for its existence.
Assuming the current state will be replaced, it is entirely possible that the discovery documentation will be useful in planning the eventual solution, since you have the benefit of having knowledge in place of assumption.
On a side note, a previous team I was on had a pre-build validation meeting called a Specify where the proposed solution was presented to the team so that it could be (constructively) critiqued and evaluated. Such a ceremony would be a great forum for presenting an abridged version of the discovery documentation along with the proposed solution.
Example: after several months of informal conversations and formal meetings with various stakeholders, we’ve arrived at the underlying cause of why the release cycle our product team is 3 weeks. Our discussions with the other two product teams has uncovered that one of them requires a significant amount of downtime while changes are deployed. This particular product is a legacy system at the heart of all of the organization’s business logic, and as such its constraints where applied to the other products as an assumption of how they work. Fortunately, our product is a cloud-based SaaS whose specific tech stack requires no downtime. In the next retrospective, we present our findings (including stakeholders from DevOps and CAB) and propose a shift in our team’s delivery model. Instead of only releasing every 3 weeks, our team will move to a continuous delivery model. Our releases are made small, easily manageable, and less prone to errors. Our users are thrilled with being able to see the changes they need being available to them in 3–5 days instead of 3–6 weeks.
Final Thoughts
The goal of this exercise is not to build a body of evidence to support a decision, but rather to build understanding. The integrity of this understanding is directly tied to the empathy employed when discussing the background and cultural environments that allowed for the current state to come to be.
The philosophy George Santayana famously wrote, “Those who do not learn history are doomed to repeat it.” Likewise, those who fail to approach this process with anything but the intent to understand will only replace the old assumptions with fresh ones.
en·ter·prise ar·chae·ol·o·gy
/ˈen(t)ərˌprīzˌärkēˈäləjē/
noun: enterprise archeologythe study of process history and prehistory through the communication of involved persons, and the analysis of assumptions and decision artifacts.
