Why Agile Software Architecture Will Never Be Agile

The reason Agile software architecture will never be agile is because it is by necessity focused on building software. In other words, it’s caught in a Catch-22 that it will never escape.

OK, now that I have your attention -- let me explain.

Core to the entire Agile movement is the focus on working software. More than simply the Agile Manifesto’s exhortation to favor working software over documentation, the principle that the focus of any software development effort should be on getting the software to work properly – that is, to meet its requirements – is fundamental to what it means to be Agile. If some external force threatens an Agile team’s focus on getting the software right, then get that roadblock out of the way. A misplaced requirement for excessive documentation? Lose it. Battling with customers or stakeholders? Counterproductive. Rigidly following a plan in the face of change? Don’t go there.

In other words, Agile-built software is coded to be fit for purpose. Focus on what it takes to get the software right, and move any impediments out of the way. An illustration of a fit-for-purpose application is in Figure 1 below:

Figure 1: Fit-for-Purpose App

The figure above is about as simple as a representation of an app can be, and that’s on purpose. In the Agile world, you want simple. Here’s what the app should do, so build that, nothing more.

As a result, the focus of Agile software architecture – that is, the architecture necessary for Agile-built software – must by necessity focus on building software that is fit for purpose. And there’s no question that in today’s distributed, Cloud-centric world, most software requires such architecture. And there’s nothing wrong with that, if that’s your goal.

The problem, however, is that fit for purpose software will never help your organization be more agile. The more fit for purpose a piece of software is, the less flexible it will be in the face of varying or changing requirements – making your organization less agile rather than more.

This predicament forms the battleground for Agile software architecture. In one camp are Agile developers who reject the need for architecture altogether. From their perspective, architects deliver “ivory tower” pronouncements that slow down the development process and lead to unnecessary work that contradicts the fit for purpose context for Agile. In the other camp, architects and others who realize that not only does software require architecture (especially if the Cloud is involved), but that the customer/stakeholder requires a level of flexibility in the end product that must be architected into the design of the application in question.

The resulting battle leads to discussions of approaches like change cases that seek to distill the customer’s agility requirement into specific requirements for coding for reuse. Yet while change cases are on the right track, they often lead to arguments over overbuilding software vs. the leanest design that will lead to working software. How do you stick to the principle of creating the simplest possible design that meets the requirements while building in flexibility to allow for functionality that isn’t expressly delineated in the requirements?

And therein lies our Catch-22: adding software architecture to an Agile project doesn’t give us agility. It mostly just gives us arguments over the role and efficacy of architecture. The bottom line: we must architect agility – the style of Enterprise Architecture I discuss in my book, The Agile Architecture Revolution.

When we build software that is fit for purpose, we are building it to have capabilities. In other words, tell me what the software should do, and I’ll code it to do that. Instead, we should build software to have affordances. Give me some examples of things you might want to do, and I’ll build software that affords you those abilities – as well as other things you might want to do with the software that you don’t know about yet. In other words, build a tool for building apps, as shown in Figure 2 below.

Figure 2: The Declarative Pattern

The pattern in figure 2 is familiar, of course: it’s the declarative pattern. Separate logic from control flow. Put the logic in the app, and the control flow in the underlying tool. Now all you have to do to change the behavior of the app is change the logic, which should be simpler and easier than changing the code in the underlying tool. The big win comes from the fact that you don’t have to change the tool to respond to changing requirements.

The declarative pattern has been with us for decades. Compilers enabled the creation of programs in 3GLs. Relational database management systems supported coding in SQL. And browsers empower HTML and JavaScript-slingers. The list goes on and on.

However, Agile developers will look at Figure 2 and point out that if they are following Figure 2 at all (which often isn’t the case, since most Agile projects are more like Figure 1), then the code they write goes primarily in the second box. You don’t generally use Agile approaches to create SQL or HTML, right? That is, unless said SQL or HTML is mixed in with other code, which would take you back to the pattern in Figure 1. And furthermore, while tools do give a broader range of people the ability to create a wider variety of applications, we’d be hard-pressed to say we’re able to architect for agility based on this pattern alone.

In fact, Agile Architecture (the kind that focuses on architecting agility) requires a new third pattern for creating applications, as illustrated in Figure 3 below.

Figure 3: The Agile Architecture Application Pattern

The reason the pattern in Figure 3 is unfamiliar is because creating a suitable tool-building platform for that third box is really hard. In order to do so, you must maximize the affordances in its underlying software. In other words, instead of being built for purpose, it has to be fully generalized in order for the application-building tools you might want to build on the platform to have the variety and capabilities you require.

But the good news is, Agile development projects probably won’t be focused on building tool-building platforms. Enterprises in particular are far more likely simply to buy such a platform, or subscribe to it as a PaaS offering. Instead, the probability is much greater that Agile projects will center on building application-building tools on top of such a platform.

Such tools will also offer affordances over capabilities, as the people responsible for building the end user-facing apps with such tools will be afforded a wide range of capabilities in the apps they may wish to assemble. But such application-building tools can still be built declaratively, as the underlying control flow now belongs to the tool-building platform, thus simplifying and streamlining the Agile development process even further.

The Agile architect must now understand the role of all three elements in the Agile Architecture Application Pattern in Figure 3. Stakeholders can now request the ability to create a wide variety of software-based capabilities for themselves in the form of the applications on the left. The marching orders for the Agile development team are now not simple user stories or use cases, but rather describe the types of flexibility the end-user/application builders will want from their application-building tools. Carefully designing such tools within the greater context of the stakeholders’ need for agility is a critically important role that falls to the architect.

We’ve now redefined the role of the Agile architect on the Agile team, and we’ve also resolved the build-for-purpose Catch-22. But this entire story hinges on the availability of satisfactory tool-building platforms. I’m here to tell this story. If you want to learn more about such a platform, tell me about a product that you’ve built that you believe qualifies as such a platform, or want to know what it takes to build such a platform, please drop me a line.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date