4 ways to achieve architectural goals while saving time and money

As architects, we are constantly trying to design the perfect system—something that is sustainable, meets future requirements, minimizes technical debt, leverages all the right tools, adheres to standards, and more. We hope it's a masterpiece that will live on well beyond our time on the project.

In reality, while many architects design systems, the exceptions make it into production. More likely, architectures wind up thrown aside by development, not invested in by product owners, or only partially implemented before the business can no longer wait, resulting in a less capable but readily available solution put into place.

[ Download The automation architect's handbook, a complimentary guide from Red Hat. ] 

I can attest that many of my architectures never see the light of day. They're just diagrams living in some corporate cloud to confuse a future architect or developer about what systems exist within the network.

Of course, there are ways to avoid this cycle. Here are four ways to meet the architect's goals while increasing the product owners' buy-in and improving the time to market.

1. Use existing solutions

The first recommendation is the most obvious: Reduce your cost and time by building around existing open source or cloud solutions rather than creating a custom solution. While this seems obvious, in practice, there are many barriers to such approaches:

• Cloud solutions are not fully adopted within the organization.
• DevOps limits the cloud technologies that the organization can use.
• Corporate or government compliance requirements for using new third-party software are higher or more complicated than for internally built code.
• Developers fall back to languages or tools they know rather than embracing the unknown.
• The organization perceives more risk in using something new than the cost of building it themselves.
• The organization perceives risk that the third-party solution will not be appropriately maintained without adequately considering the internal maintenance tail.
• The cost of existing developers is baked in, while buying cloud or third-party capabilities requires allocating new funds.

In multiple organizations, my role has been breaking down these barriers for developers or analysts, enabling them to achieve better architectures compared to directly designing the systems themselves.

[ Learn how to build a flexible foundation for your organization. Download An architect's guide to multicloud infrastructure. ]

2. Compare fairly

A common misstep occurs when architects or developers compare the (nonexistent) end architecture they've designed against existing solutions. If you are comparing your future solution that's two years out, make sure to take the following considerations in as well:

• Where will the existing solutions be in two years?
• What is the cost and risk of building your own solution?
• What is the opportunity loss of not releasing earlier while building your custom solution?
• What is the opportunity loss of not allocating the company time and developers to other capabilities instead of the custom solution?

Sometimes architects or developers will identify a requirement that existing approaches do not meet and use that to justify building something new without first providing the alternative option to a product manager. For example, is this requirement worth an additional $2 million in development and a 10-month delay in schedule, or can you do without that missing capability? Properly considering these options is one reason an architect exists. Sometimes it's not about the architect managing and solutioning the complex or detailed system but instead about helping to avoid needing the complex solution altogether.

3. Design for the long term, build for the short term

If it is necessary to build new, design for the long term but build for the short term. Here's how: Build an initial scaled-down version that meets immediate requirements, but make sure to identify the components needed to meet the system's long-term objectives.

To do this, first envision an end architecture to satisfy the long-term goals in a traditional system architecture design document. Then, develop a simplified version of this architecture that includes only the capabilities required for the initial release. This is one of the most challenging parts because it means throwing away most of what you learned and decided in your initial architecture document. The first document identifies the components and capabilities required to meet the system's long-term objectives to facilitate making strategic decisions in the initial scaled-down version.

The key thing to remember is that those extra capabilities are not currently required. When they are, you'll have the opportunity to build them, and you may have even evolved your designs into something better by then. If the capability is never built, that should mean it was never required, and you just saved the organization from creating something unnecessary.

[ Use distributed, modular, and portable components to gain technical and business advantages. Download Event-driven architecture for a hybrid cloud blueprint. ]

4. Move quickly, but invest intelligently

So, where should you invest? Here are some questions to ask:

• What components interact with the user or other parts of the system in the initial release?
• What components are doing the core processing required for the initial release?
• What capabilities can be removed, replaced, or simplified with something else to meet the initial requirements? Replace away!

After following these steps, you will have identified the core capabilities you need to build. You can then define integration contracts around these core components while considering your future architecture. This is where to invest in protecting against rewriting these components when new requirements arise.

You are not changing the architecture; you are changing the order that you build the architecture's components. What is the minimum set of features necessary to meet the first set of requirements, and do those components have unnecessary functionality that can be reduced?

Are you investing in some capabilities that you will need to rip out to meet the long-term objective? Yes! But you have also taken months, perhaps years, off the schedule to meet your initial requirements. As project managers request new capabilities, you may need to rebuild or rip out portions of your infrastructure. Those investments will be made in line with the capabilities they offer rather than an upfront cost that will not be realized until a potential future state. By remaining conscious of the system's long-term architecture, you can make guided choices that will continue to evolve the system towards the end goal.

Occasionally, it is useful to reconsider that end goal. Is the end architecture you created still valid? If the answer is yes, consider taking a harder look or having someone less attached provide the critique. Technologies will change, requirements will change, and most importantly, your knowledge of the problem and its solutions will change as the initial versions of the system are built.

My team likes to talk about full architectures as a North Star. I would agree with that categorization. A North Star is there to guide you, but if you attempt to sail all the way to that star, you're probably not going to make it.

This article originally appeared as Achievable software architecture on Medium and is republished with permission.