Over a million developers have joined DZone.

What is agile software architecture?

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

I'll be back in The Netherlands next week to deliver the opening keynote at the Agile Software Architecture Symposium, where I'll be speaking about agility and the essence of software architecture. But what does "agile software architecture" actually mean?

In my experience, people tend to use the word "agile" to refer to a couple of things. The first is when talking about agile approaches to software development; moving fast, embracing change, releasing often, getting feedback and so on. The second use of the word relates to the agile mindset and how people work together in agile environments. This is usually about team dynamics, systems thinking, psychology and other things you might associate with creating high performing teams.

Leaving the fluffy stuff aside, for me, labelling a software architecture as being "agile" means that it can react to change within its environment, adapting to the ever-changing requirements that people throw at it. This isn't necessarily the same as the software architecture that an agile team will create. Delivering software in an agile way doesn't guarantee that the resulting software architecture is agile. In fact, in my experience, the opposite typically happens because teams are more focused on delivering functionality rather than looking after their architecture.

If we look at the characteristics of an agile software architecture, we tend to think of something that is built using a collection of small, loosely coupled components/services that collaborate together to satisfy an end-goal. This style of architecture provides agility in a number of ways. Small, loosely coupled components/services can be built, modified and tested in isolation, or even ripped out and replaced depending on how requirements change. This style of architecture also lends itself well to a very flexible and adaptable deployment model, since new components/services can be added and scaled if needed. However, nothing in life is ever free. Building a software system like this takes time, effort and discipline. Many people don't need this level of adaptability either, which is why you see so many teams building software systems that are much more monolithic in nature, where everything is bundled together and deployed as a single unit. Although simpler to build, this style of architecture usually takes more effort to adapt in the face of changing requirements because functionality is often interwoven across the codebase. With pragmatism in mind, you can always opt to build a software system that consists of a number of small components yet is still deployed as a single unit. You need to understand the trade-offs and make your choices accordingly.

However you build your software system, creating a well-structured architecture isn't something that happens all by itself. You need to put time, effort and discipline into it. In order to do this, everybody on the team needs to understand software architecture and contribute to its success. How you do this is what my talk is all about ...


Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

Published at DZone with permission of Simon Brown, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}