Architecture Agility

Many CIOs and CTOs face pressure to build enterprise systems that are aligned to both business outcomes and future innovation. Younger companies are at an advantage here—they are usually free of big, clunky systems, and can respond faster to market expectations. Larger organizations, on the other hand, are often burdened with legacy applications that can be expensive to maintain and prove to be inflexible when external factors change. Case in point is the current COVID-19 pandemic. While younger organizations were able to quickly adapt to remote work, many larger organizations were caught napping.

According to Deloitte’s Global CIO Survey 2018, only 54% of CIOs think of their organization’s existing technical stacks as capable of supporting existing and future business needs.

Technological architecture has a strategic role to play in innovation-led organizational agility. And C-suite leaders acknowledge this, which is why they’re moving away from building big complicated technology infrastructure upfront, and instead opting to invest in agile architectures.

Take the case of ANZ Bank, the third-largest bank in Australia. It was losing its position as a leader in the industry because of a lack of investment in its banking app. This changed when ANZ adopted an agile architecture which gave it much-needed flexibility. The bank is now able to release new features and upgrades on a monthly basis.

New application development is a tricky process. At the very beginning, it can be challenging to anticipate every important decision that needs to be made. And right at the end of the development and delivery process, when lessons have been learned, there’s little opportunity to use that knowledge to make improvements.

An agile methodology resolves this by providing the space and opportunity to build an architecture that follows an empirical process, where each decision is thought of as a hypothesis to be validated and fed back into decision-making.

However, adopting an agile architecture process is not without its challenges:

  • If the interaction with the application developers and architects are inconsistent, or if they’re brought into the project late, it can result in the creation of something poorly aligned with the organization’s purpose. A partial view of the bigger picture can also make it difficult for architects to move beyond a transactional outlook when building the system, leading to a complete design breakdown.

  • By its nature, an agile architecture process needs senior management to indicate where to innovate, but not how. But a lack of direction can result in oversights, and make effective collaboration across teams difficult. This can result in processes that are agile locally, but don’t completely tie into the overall product strategy, and push up build and delivery times. To tackle this, a lightweight governance model is needed—one which sets up gates at the end of every stage of the project.

Best practices for architectural agility

So how do organizations make their technology architecture agile? Here’s a five-step framework highlighting the best practices for getting started:

  • Model: Information technology architecture is the process of development of methodical information technology specifications, models, and guidelines, using a variety of Information Technology notations. To begin with, design a high-level tech architecture that is just enough to get started. The idea is to wait until the last responsible moment, and then build a just-in-time architecture. Such a model avoids the analysis-paralysis trap, which is the result of doing too much, right at the outset.
  • Evolve: The strategic themes and project requirements should be translated into detailed user stories to improve upon the architecture. The focus should be on the stories that are needed in the current release. With each user story, the team identifies which architectural elements are necessary to support it, and those elements should be implemented first. This results in a rapid, fluid iteration of application delivery. Loosely coupled services enable the creation of a minimum viable product (MVP). Since an MVP focuses on developing the smallest set of features that can be rolled out for feedback to the actual users, it allows developers to assess which features are valuable and which are not. By introducing the voice of the customer early in the process, waste is reduced.
  • Validate: Define key metrics to track the fitness of the architecture you are building upfront. These metrics should be regularly validated to test how closely the designed solution is aligned to the desired outcomes.
  • Refactor: The next step is to refactor an existing body of code by making suitable alterations in the internal structure without affecting its external behavior. This allows the architecture to evolve using agile practices, through continuous integration and unit testing.
  • Update: Finally, it’s important to regularly review the model using kanban and scrum processes, and then update the architecture accordingly. This can be done through design workshops, customer reviews, and retrospective assessments. The idea is to treat design and architecture as the scrum product backlog that has a story, as well as a cost and business value attached to it.

Pitfalls encountered while implementing the best practices

While the notion of adopting an agile architecture is exciting, there are problems an organization may encounter as a result of implementing these best practices poorly.

  • The role of architects throughout the process may not be properly understood. It’s imperative that architects stay invested through all five steps of the program, and manage change while keeping the overall vision in mind. This may even mean redefining the role of an architect into someone who understands that they’re working towards bridging the gap between technology and business, in order to deliver value, and is responsible for creating a path into the future.

  • Deviation from the desired outcomes can result in an architecture that doesn’t serve the function needed. It’s important to continuously check with all stakeholders and maintain proper governance to avoid losing sight of the overall goal.

  • Agile architecture may be mistakenly thought of as pertaining to an individual project, when it actually intends to create value throughout the organization. It’s important to bridge any gaps between the implementation teams and senior management, and provide interdisciplinary teams with the capability to deal with complex decisions. This can be fostered by creating communities where architects and members from IT and business teams share their knowledge and best practices openly. For instance, at Spotify, cross-functional teams called “squads” have been created, with up to 8 members. Each squad is responsible for deciding what to build and how to build it, while staying aligned with the overall product strategy. With small and frequent releases, new features are released as soon as they become viable, instead of conforming to specific scheduled dates. And without the rigidity of hierarchical structures, problem-solving is much easier.

Increasing responsiveness to technical and business outcomes

Quick decision making is the key goal. Organizations need to experiment fast and figure out how the actual outcome stacks up against the objective. Depending on the findings, they should decide whether to scale, discard, or continue experimenting on the idea. Only an agile architecture can provide the space necessary for discovery and for allowing enterprise applications to grow in response to customer feedback.

Agile architecture simplifies the technical stacks and reduces the technical debt of systems. This provides business leaders with the accelerated pace needed to be more competitive in the marketplace. Google is a classic example of this. With multiple applications like Gmail, Google Maps, Google Assistant, and many more, the company needs to provide regular updates that must be tested extensively before they can be rolled out to the entire population. One way Google achieves this is by allowing users to participate in its beta programs, to test upgrades to the Android OS. If the feedback reports major bugs or usability issues, updates are rolled back, thus eliminating the risk of delivering a poor or incomplete experience to the end-users.

Agile architecture is really an evolution that begins with transforming the idea that organizations have of enterprise architecture. Applications cannot be rigid machines designed to serve specific functions only. Instead, they must be like growing and thriving organisms that adapt to the changing demands of the marketplace, allowing organizations to innovate quickly and deliver thoroughly validated and relevant experiences to customers.

So, what do you think? Let us know your thoughts in the comment below.

Also, for the past 14 years, we have been enabling organizations to be more nimble and agile through our low-code platform – Zoho Creator. For instance, someone who built a web app in 2006 (a year before the launch of the first iPhone) using our platform, got a mobile app in 2013 without any additional effort or cost.

Try it for free!!

Leave a Reply

Your email address will not be published. Required fields are marked *

By submitting this form, you agree to the processing of personal data according to our Privacy Policy.