Creating an Agile Enterprise with Minimum Viable Architecture

Traditionally, organizations have used a waterfall-style approach to defining and designing software architecture, accounting for every detail in the development lifecycle long before a single line of code is written. That model no longer works as it’s way too slow for today’s ever-changing tech landscape.

By the time the architecture is ready for developers, the business environment has completely changed. This means developers are forced to build solutions for the current reality on a framework designed for a different time.

And big-picture, upfront design makes it a lot harder to keep pace with more flexible competitors capable of responding to change as it happens. That said, 37% of organizations still use Waterfall approaches, while 41% use either Agile or a hybrid approach that combines aspects of Waterfall and Agile.

Here, we’ll make a case for embracing minimum viable architecture (MVA), an adaptable model that supports Agile development projects and evolves along with your customers and strategic goals.

What is Minimum Viable Architecture?

One of the key elements of the Agile methodology is minimum viable product (MVP), which means building a product with just enough functionality to deliver a usable product to early adopters.

This allows you to start collecting feedback for more features and potential improvements. Often, it also allows you to start generating revenue early on while you continue to build out the feature suite.

Minimum viable architecture (MVA) applies that same idea to the entire enterprise.

3Pillar’s Javier Trevino breaks it down as follows: “The MVA is about implementing the core architectural components that make up an architecture’s foundation, over which the rest of the architecture can later be implemented. This is done to meet end-users’ most critical functional and non-functional requirements so that you can release an early version to market.”

Typically, organizations start developing an MVA by first defining objectives and KPIs for work delivered in, say, the next few sprints. (There’s no definitive timeline, here. It could take 2-3 sprints or an entire quarter to implement the new architecture.)

The idea is, you want to make sure you have a workable backlog that covers the next series of sprints. It allows you to always have a set of tasks to work on that big-picture; you can continue to move closer toward critical milestones.

This approach helps minimize risks and ensures that the design is informed by facts, not guesses or gut-feeling.

To gain a better understanding of Agile architecture, it helps to look at a concept called Evolutionary Architectures. This flexible architecture supports constant, incremental change and focuses on the following three areas:

• Incremental Change. Incremental change hinges on a modular underlying architecture, combined with the effective use of DevOps, CI/CD, and other mature Agile practices. Developers should be able to make changes to a specific feature or functionality without damaging other features within an application.
• Fitness Functions. Evolutionary architectures should evolve in a way that makes the most sense for solving problems. Focus on building guidelines within the architecture that makes it easy to adapt to new circumstances. At the same time, it protects attributes that should remain intact, regardless of where the market is headed or what innovations are on the horizon.
• Multiple Dimensions. Architects often focus on one or two dimensions of the technical architecture—integration, dependencies, frameworks, etc. Instead, organizations need to zoom out and consider everything from security and scalability to how their data ecosystem enters the mix, testability, and a whole lot more. Agile architectures include all of these dimensions, measuring and refining each of them on a continuous basis.

Ultimately, this “evolutionary” approach to architecture sets the stage for future transformations. It provides a big-picture view of the entire software development strategy, milestones, and goals while allowing them to move faster and easily incorporate requirements into the process as they emerge.

Basic Roadmap for Implementing MVA

• Identify the business needs. What business goals are you trying to achieve? Faster time to market? Improved customer satisfaction? Are you trying to take down a competitor or enter new markets?
• Map out the customer journey. Who is the end-user? What problems are they trying to solve?
• Determine what features to build. What features solve your customers’ most pressing pain points? Focus on the “must-haves” first before digging into the “nice-to-haves.”
• Define the target objectives for strategies and metrics for measuring success. KPIs should be outcome-based, measuring business value as opposed to hours worked or number of products delivered.
• Define a development methodology. This should include best practices for the code review process, repository management, a quality assurance (QA) strategy, CI/CD, and a persistence strategy.
• Define Your Tech Stack. Include programming languages, frameworks, persistence/databases, toolkits, and so on that enable your software solution to meet the business requirements laid out in your high-level strategy.
• Define the cloud environments you plan on using. Consider the SaaS Maturity model that looks at multi-tenancy, scalability, and configurability.
• Identify the processes and roles impacted by the change. Who needs to be involved, and on what level? What information does each group need to make informed decisions and fulfill their responsibilities?
• Identify the minimum viable architecture model. Once you’ve figured out what you’re trying to accomplish, who’s involved, and what features you need to build, determine what architectural pattern makes the most sense based on those factors.

Why Agile Architecture Should Be a Top Priority

Agile transformations call for an Agile architecture that evolves alongside consumers, market conditions, and shifting priorities.

Analysts from the Boston Consulting Group say that Agile transformations face three key challenges in creating an adaptive business model:

• Adapting to changing circumstances
• Planning for the “unplannable”
• Poor or incomplete alignment.

While it can be difficult to shift to an adaptive business model, the fact is, it’s no longer optional.

It’s businesses who prioritize agility and embrace this constant state of change that will succeed in a post-COVID business landscape, regardless of what “normal” looks like in a year, five years, ten years down the line.

Jorge Millán, 3Pillar’s Software Engineer Lead, points toward two famous examples that underscore just how crucial it is to respond to change as it happens.

• “Coke was intended to be a medicine in the beginning. Being flexible and acknowledging it tasted better than it cured resulted in one of the most successful businesses in history.
• “On the other end of the spectrum, you have Blockbuster. The company chose not to buy out Netflix when they had the chance, in part because of its rigidity. And, well, we all know how that turned out.”

In short: Agile architecture is key to allow for businesses to pivot when needed.

Jonathan Andujo, Software Engineer IV, says Agile architecture is “very important when it comes to delivering the best possible software products, as needs always change during development and there’s always an opportunity to improve.”

He adds that “sometimes you’ll start with a clear idea of what the final product should look like, only to discover that the end-user or the market, as a whole, had something else in mind. By using an Agile methodology, you’re able to change course when needed. Decisions are made faster, allowing development teams to adapt solutions to the current situation.”
[adinserter name=”Software-Development-eBook-Offer”]
Denisse Vega, Sales Engineer, says, “Using an Agile approach allows developers to modify and reprioritize requirements based on client needs. This ensures the product will be released to meet end-user needs.”

BCG recommends tackling the above challenges by moving to a flexible planning process where business leaders develop 180-day plans every 90 days. This approach allows them to focus on big-picture goals for the next two quarters while also carving out space to shift milestones and update the action plan in response to changing circumstances.

Additionally, it’s essential to recognize the critical role of AI/ML/predictive analytics in helping organizations detect and respond to changing circumstances as they happen.

Develop a Plan for Communicating Change

Ensure everyone is informed of any changes made.

Internally, a lack of communication can cause issues—going over budget, poor alignment with the strategy, delays, and so on. Ultimately, communication issues can undermine the organization’s desired outcomes.

According to Software Engineer Lead Paul Estrada, “embracing flexibility is generally a good thing so long as there’s a mutual understanding of the consequences of introducing change during the development process.”

He adds, “development teams should clearly communicate the impact changes have on the committed work, including increased costs or missed deadlines. Developers and other stakeholders should be engaged in an ongoing discussion to determine if some pieces of work should be dropped until the next sprint or can be finished on time using the current resources.”

Externally, poor communication can lead to serious reputational damage, a poor customer experience, and possibly a lawsuit or non-compliance fine.

Denisse Vega remembers a project that hit bumps in the road linked to communication failure, “Once, one of my teams released a product to production unaware that the production environment had been modified. Because team members were never notified ahead of the release date, there were noticeable issues when it hit production. This was reported back and the team was able to reprioritize tasks in order to fix the issue and update the environments. The product was quickly resolved before high-traffic hours.”

Luckily, Denisse and her team were able to resolve the problem before it caused any real, lasting damage. It’s easy to see how things might have turned out differently if they hadn’t been able to identify and address the problem quickly.

Abel Gonzalez Garcia adds, “It’s also important that you’re prepared for new members to jump on at any point in the development process. That means you’ll need to ensure complete visibility from the beginning. Anyone—new or not—can quickly understand how the project is being developed and start contributing,”

Build Iteratively, But Don’t Abandon the Plan Altogether

Embracing an Agile architecture doesn’t mean doing away with long-term planning altogether.
Success still hinges on having a mature process in place that’s informed by clear objectives that align with the business strategy and a system in place for sustaining improvements.

Director of Software Delivery, Angel Almada, recalls a situation where building on the strategy iteratively led to a better outcome.

“We were migrating a solution from a monolithic architecture to a micro-services based one. We had laid out the next 3 sprints on back-end definitions. However, on sprint two, we identified that by making substantial changes to already migrated services, we could minimize the remainder of the work and even deliver those a week earlier. Having robust processes and an Agile mentality helped in readapting and delivering earlier.”

He also shared an example where strict adherence to existing requirements had a negative outcome.

“We were working with a customer who had laid out a full release. During development, we learned from support calls that the requirement left out an essential update to support several operating systems. The customer didn’t want to change the scope, so we deployed without the crucial update. Later, we ended up pausing all other efforts to focus on this specific issue. It caused re-work and a negative experience for customers.”

While an iterative approach is key to delivering a product that provides value to your customers, it’s also crucial to strike a balance. Make sure everyone is on the same page before moving forward with changes that impact the budget, scope, or time-to-market.

3Pillar STE Jessica Vega says, “being flexible is important, though we sometimes need to set a limit. On occasion, being too flexible can undermine an entire project. Every change, addition, or new priority should be analyzed before to gauge the impact on the project moving forward. Developers should be upfront about the impacts of proposed changes so that key stakeholders can make an informed decision about how to proceed.”

Test lead Alejandro Ruelas adds, it’s crucial that development teams understand how “changing the current requirements should be postponed to the next sprint unless absolutely necessary.”

In other words, decision-makers need to determine which types of changes require input and consensus among stakeholders and which decisions development teams can make as they work through each sprint.

Generally, development teams should be given the flexibility to make decisions about how they work, while senior leadership teams should focus on the big-picture—avoiding the urge to meddle in the day-to-day stuff that should be left to project managers.

Final Thoughts

In the end, Agile architecture provides a flexible framework for achieving your target business objectives and responds to changing customer needs and technologies as they evolve.

[adinserter name=”Software-Development-Closing”]