Ever since my new book, The Agile Architecture Revolution hit the streets, I’ve been following the keywords “Agile Architecture” on Twitter. Sure enough, there are plenty of conversations on Agile Architecture – but to my disappointment, most of them aren’t about my book, or even what I mean by “Agile Architecture” in my book.
The focus of my book is on architectural approaches to delivering business agility for the enterprise – in essence, taking Enterprise Architecture (EA) to the next level, where constant business transformation is the goal, rather than a fixed end-state. The more common definition of Agile Architecture, however, is applying Agile (Agile-with-a-capital-A) principles to software architecture – a very different perspective.
I discuss the Agile Manifesto in the book, of course – I could hardly put the word Agile in the title without doing so – but these two definitions of Agile Architecture are quite different. However, it’s not a question of which is right and which is wrong. Rather, the central question of this ZapFlash is how the two senses of Agile Architecture are related to each other.
Agile Software Architecture
Agilemodeling.com is a great resource for learning the basics of Agile Software Architecture. There is far more detail there than we can cover here, but in summary, here’s how ZapThink interprets the principles of Agile Architecture, according to this site:
Everyone on the software team can pitch in and improve the architecture, just as everyone is responsible for all the code in a traditional Agile project. However, not everyone on the development team is equally competent at software architecture, so there should be an owner of the architecture in case of disagreements.
Avoid ivory tower architectures, where the architects handing down architecture artifacts from on high rather than being directly involved in development, through constant feedback among architects, developers, and the rest of the team.
Don’t overdo the architecture. Simple software requires simple architectures which don’t require complicated architectural efforts. Even a doghouse needs a plan, but it’s vastly simpler than the plan for a large building.
Architecture helps Agile software scale, which also means that architecture helps Agile software be more Cloud friendly.
Base your architecture on the requirements for your software. Solicit active stakeholder participation, as with any Agile project. Think about future possible requirements, but don’t overbuild in anticipation of as-yet undefined needs. In other words, defer commitment on design decisions.
All of the above principles follow basic common sense, and any development team that follows them is bound to have better architected software. But thinking about Agile Architecture as an approach to architecting software leads to a central paradox: building software in an Agile way doesn’t guarantee the software will be agile, as we discussed in a ZapFlash in May 2012. The fundamental problem: requirements continue to evolve, but even the most Agile of software development approaches builds to the current requirements. In fact, the final bullet above even exhorts the development team to avoid overbuilding.
We’ve written about the overbuilding trap before in a pair of blog posts. If we simply demand the developers build code to meet future requirements, without specifying what those requirements might be, we’ve just sent them down a rabbit hole. Fundamentally, if you look at the problem of building software that provides business agility as nothing more than how to build software to meet future requirements, you’ll never find your way out of this hole.
How, then, do we get out of this pickle? How to we build software that responds to changing requirements, without overbuilding our software? Agilemodeling.com discusses the notion of change case modeling, where change cases describe potential new or changed requirements for a software system. In fact, ZapThink has been discussing change case modeling since we introduced the Agility Model back in 2008, although the change cases we discussed go beyond a particular software system to include processes, policies, and other elements of the Enterprise Architecture.
Solutions vs. Tools
The enterprise context for software development focuses on solutions: the stakeholder has a problem, so you build a solution to that problem. Hence when the problem changes, you need a new or different solution. However, not all software development focuses on solutions. For example, many software vendors build and sell software tools.
The most important feature of a tool is that you can use it for different things, even when it is fit for a particular purpose. Even if you limit your hammer to only hammering nails, you can still hammer many different kinds of nails into many different materials, and the hammer manufacturer doesn’t have to know any of the specifics. So too with software tools. A software vendor who publishes, say, an Integrated Development Environment (IDE) need have no knowledge about the type of software that users of that IDE might use it for. The tool may be fit for certain types of development, but it’s entirely agnostic as to the code its users call upon the tool to build.
The overbuilding problem tends to rear its ugly head when development teams should be building a tool, but focus on building a solution instead. Now it seems that every nail requires a different kind of hammer, where you should really be focusing on building a versatile hammer in the first place. This mistake is very common on SOA initiatives when the SOA team is trying to sort out the agnostic context for its Services: which Services are built for particular purposes (i.e., solutions) vs. Services built for reuse (in other words, tools). After all, the whole idea behind a reusable Service is that it is agnostic with respect to how people might use it in the future, a characteristic such Services share with hammers or any other kind of tool.
Declarative Programming: Configuration over Code
The primary technique software tool vendors use to support different customer requirements with the same tools is to allow customers to configure the tools to meet their needs. In other words, separate the configuration from the code, where the configuration consists of metadata that describe how the software should behave, and the code reads the config files and behaves the way the config files say to behave.
Creating such a configuration file is a classic example of declarative programming. Describe how the software is supposed to work without having to delineate the control flow that instructs the underlying processor what to execute. Declarative programming has been around for years, of course; SQL and HTML are two familiar examples of languages that support this approach. When you write SQL, you expect your database management system to understand it and behave accordingly. Similarly, writing HTML instructs your browser how to behave, while coding the software for the browser itself takes place independent of the Web pages it will be expected to render.
Unfortunately, while declarative programming separates configuration from code, not all configuration leads to agility. After all, dinosaur enterprise application packages like ERP have been configurable for years, but simply separating the behavior of the software from the underlying code is no guarantee of agility, just as defining the behavior of a Web Service by specifying its Service contract in WSDL and XSD files doesn’t guarantee the Service will be reusable. Something is still missing from this picture.
To see what’s missing, let’s take an example of a software-based tool that does provide business agility: Amazon’s IaaS tools (or any other Cloud provider’s tools that rise to Amazon’s standard). The coding wizards back at Amazon HQ have built interfaces that allow anyone with a credit card to provision and configure all manner of compute resources, without ever having to monkey around with the underlying code that makes the Cloud magic work. Supporting declarative configuration is merely the price of admission here. What the Cloud has done is connect people and process to the technology, empowering end users to handle the configuration themselves.
In the enterprise context, then, the missing piece of Agile Software Architecture is Agile Enterprise Architecture, where EA brings together the organization, the processes, the technology, and the information in a consistent, business-driven whole. Configurability alone doesn’t provide this consistency. Instead, true Agile Architecture – that is, architecture that supports the business agility requirement – must tie these concerns together using a balanced combination of Enterprise Architecture, governance, and Agile Software Architecture.
ZapThink Take
In the Cloud example above, Cloud users may interact with the Cloud via a browser-based user interface, or they may choose to use the Cloud’s APIs. APIs are unquestionably an important part of the Cloud story, but the mere fact we’re calling them APIs – application programming interfaces – belies their significance. Turning the Cloud into a massive piece of software we have to program will defeat the agility benefit the Cloud provides, after all.
Fortunately, today’s APIs are misnamed. We moved from tightly coupled procedure call interfaces (which were truly APIs) to contracted interfaces we called Services to the interfaces we have now, which we once again call APIs. But just as a Cloud API should provide a declarative, scriptable interface to the same capabilities the browser-based user interface exhibits, today’s modern APIs should be user-empowering interfaces.
The movement toward Hypermedia-Oriented Architecture, what some people call REST, is part of this story. Remember, the programmable Web is meant to make software more Web-like, rather than make the Web more programmable. We have all the pieces of Agile Architecture: Agile Software Architecture; declarative, configuration-based programming; hypermedia-based APIs; and Enterprise Architecture to tie everything together. All we need to do now is get the architecture right.
Photo credit: Nadya Peek