You’ve adopted Agile? Great! Over the last few years, there has been a huge movement from the sequential Waterfall process towards a more flexible Agile approach. The question is: Has your software architecture followed suit?
The “agile” in software architecture has similar connotations to the “agile” in Agile methodology meaning it can respond quickly to change, adapt to new requirements, reduce overheads, be iterated and released frequently etc.
To be truly adaptive to change, both the process and architecture need to be able to work in synergy.
Agile Team vs Monolithic Application
Even though a team has adopted an Agile methodology, large-scale applications are still often constructed using a monolithic, tightly-coupled architecture. The problems with such an application are:
- They are difficult to scale.
- Changes are woven together, leading to the so-called “Big Ball of Mud” anti-pattern – a term popularised in a paper written by Brian Foote and Joseph Yode in 1997.
- Refactoring is avoided in fear of breaking related code.
- Over time, as the codebase grows, it becomes harder and harder to maintain and eventually has to be rewritten in its entirety.
Clearly, the disconnect between process and architecture makes the long-term benefits of Agile harder to realise.
It’s hard to be “agile” when working with a “Big Ball of Mud”
Aligning Process and Architecture – Decouple Everything
So how does one avoid the “Big Ball of Mud”? By breaking up a monolithic application into discrete components / services, it becomes much more suitable to an Agile delivery mindset, since:
- Components are built to serve a single purpose and do it well.
- They are technology independent: teams can choose the language, tools or frameworks of preference.
- They can be built, modified and tested in isolation.
- New components or services can be added and scaled if needed.
- Refactoring becomes a whole lot easier i.e. smaller component can more easily be rewritten or replaced.
- Organisations can be broken up into smaller teams focusing on different areas of the application.
These principles can be applied at any level of the application including UI, back-end and deployment.
The Future of Agile Architecture
The latest modern standards, tools and frameworks are helping to drive the move towards agile architectures. UI with Web Components, back-end with Micro-Services, and deployment with the help of the Cloud and Containers.
Web Components
These are a set of features currently being added by the World Wide Web Consortium (W3C) that allow the developer to create their own reusable, encapsulated HTML elements. Full browser support is not quite there yet, but modern UI frameworks such as Angular 2 and React allow one to use a component-based web architecture today.
Micro-Services
This “buzzword” has recently gathered much attention, but basically refers to many smaller minimal function services that can interact together to achieve a common business use-case. They are independent in terms of their scalability, failures and deployment. State is externalized and communication between components is performed via defined interfaces and RESTful APIs.
The Cloud and Containers
Gone are the days of spending time provisioning expensive, highly-spec’d servers for running an application. Software containers, such as Docker, guarantee that an application will run the same regardless of the environment. Combining containers, the Cloud and Micro-Services also enables the infrastructure to grow or shrink based on demand. This brings along huge benefits for cost saving and scalability.
More can be said about each of these, but there’s no doubt in my mind that Web Components, Micro-Services, the Cloud and Containers will change the way that we construct applications – and they have begun to do so already.
Challenges
Adopting a decoupled architecture is not without its challenges:
- It can require additional development time and needs management buy-in.
- Introduces additional complexity at the infrastructure level.
- Testing, logging, security, monitoring and performance need to be carefully designed both across isolated components or services as well as when combined as a whole.
The Age of Super Agile
By aligning process and architecture, and avoiding the “Big Ball of Mud”, hopefully software teams can make the move from not just being Agile…but Super Agile.
By: Chad Epstein, Synthesis Software Technologies
