Let’s create reference architectures to fulfill their purpose of being a true reference point—not treat them as the end-all-be-all
By Bradley Clerkin, BreakFree Solutions CTO
Reference architectures should be as their name suggests: a reference point on the art of what’s possible. But instead, architects often treat them as gospel.
Using a reference architecture as a well-organized method for communicating potential solutions is a great tool for helping the team conceptualize what’s possible. For example, publishing how a company’s mainframe would integrate effectively with cloud-native applications would be a powerful way of identifying problems and solutions. It would also help technical engineering resources to see the ways that the cloud is different, creating a true reference point for the project.
Rather than treating reference architectures as the absolute standard for how an IT organization should build platforms, modern architects take a Minimal Viable Product (MVP) approach to reference architectures in which they are an evolving reference that represents how a technical group overcomes challenges.
One effective method is to apply the concept of MVP to the level of completeness required of any components in the reference architecture. To determine whether you’re in this mindset, analyze how long it takes to publish a reference architecture. Ideally, it shouldn’t take more than a week.
Next, you can worry about getting past the MVP stage. But remember, your architects aren’t the ones who are going to do that. It’s the engineers who are solving these problems. The architects need to focus on either extracting information from real-world initiatives or finding ways to add a default mode for completed work to the reference architecture.
For example, you can advocate that teams add reference architecture updates to their formal definition of “done,” which is a common competent of scrum work management frameworks.
Taking the MVP Approach
Why do it this way? As the saying goes, the best-laid plans of mice and men often go awry. This could not be truer for the modern age of product which relies heavily on modernizing applications and utilizing cloud. The more we plan, the more we are going to get wrong. And when we invest heavily in something we are biased towards seeing it as the correct answer.
A comprehensive reference architecture that takes months to produce will be widely inaccurate compared to what the optimal solution turns out to be. Additionally, a reference architecture with a substantial upfront investment will cause engineers to not think outside the box and slow or completely block the ability to iterate towards the optimal solution.
Naysayers will always bring up the idea that reference architectures set the standard and teams are likely to repeat mistakes if they don’t invest time upfront on making it as comprehensive as possible. To us, this only indicates a misuse of reference architectures.
We encourage individuals to instead extract the architecture guiding principles that lead to the solutions they publish. These principles should be broadly shared and instead of trying to adhere to these principles through reference architectures, create an opportunity to develop skills around them.
The challenge should be: How do we get engineers to think about these principles as they begin the building process? Having them build a certain solution would accomplish this but keep in mind it could also limit your ability to see other potential solutions.
Reference architectures can be a tool for good or bad in a digital/product organization. If a comprehensive RA is required for something to be effectively delivered and one places a lot of up-front investment in theoretical solutioning, it’s likely going to go awry. But, if we see the RA as a starting point for articulating the art of what’s possible, as well as a means for referencing our current understanding extracted from our real-world engineering experience, you’ve got a tool for good.
If you take the effort that you would have put into creating a comprehensive, theoretical RA and put that into skill development around architectural principles and practices so engineers make informed solutions, combined with a focus on getting learned information from the real-world application into reference architectures, you’ll have a huge digital force multiplier.