Agile Architecture
In the mid-1990s, the prevailing trend in the industry was to begin a software development project by building elaborate models of the system. The idea was that writing the code was simple once the architectural structure and requirements were in place. However, many software development projects spent large amounts of time building these models only to find that they became quickly outdated as soon as coding began. This practice became known as “big design up-front” (BDUF).
The impact of BDUF was felt on many fronts. First, it alienated developers of the system. After all, coding was merely an afterthought and many leaders in the BDUF community suggested that writing software would eventually require lower levels of skill. Model-Driven Architecture (MDA) promised to make developers obsolete by creating models that would generate systems with absolutely no coding at all. While technological advances were made in MDA, the full promise of "codeless software" was never realized.
Many BDUF projects also failed because these projects expended large amounts of time building the models and left little time for the actual coding. Since the models provided no mechanism for feedback, it was difficult to tell how good they were. Interaction diagrams such as message sequence charts could generate lower level coding structures such as methods and classes but a fully working system could not be created from their outputs. In contrast, code can be compiled to form a system that can be tested and verified.
The agile movement started as a backlash against BDUF. The first agile software development process, Extreme Programming (XP), forbade the use of modeling on projects that used it. Software modeling was considered “un-agile”. Kent Beck, the founder of XP, was determined to break the grip that the BDUF community had on the creation of software. The agile movement was very successful in this endeavor.
Software modeling slowly came back in vogue with the Agile Modeling (AM) movement by Scott Ambler. Scott argued that modeling should be done on whiteboards to communicate architectures and designs during software development. The idea behind Agile Modeling was that models were not high-end software artifacts that should be kept around forever but low-cost work elements that reflected the rapidly changing code base.
As Extreme Programming evolved, Kent Beck realized the value of architecture and found a very simple modeling language that he called Simple Modeling Language (SML) that was similar to the subset of UML that Agile Modeling used. This language consisted of boxes and lines that were used to reflect the components and/or classes and their relationships, the basic construct of object-oriented languages. This language was the simplest thing that could possibly work as a modeling language.
AM and SML identified lightweight approaches to describing the designs of systems but there is so much more to architecture than design. George Fairbanks defines architecture as “The architecture of a system is the design decisions made by system developers to achieve their top-level intentions, and the designs that follow directly from those decisions.” This implies that design elements such those described with AM and SML might be descriptions of the decisions but won’t reflect the alternatives that were discarded. In other words, through a modeling language, we can understand the consequences of the decisions but not the reasons that the decisions were made.
Another definition of architecture comes from Ward Cunningham through conversations that I had with him when he worked for Microsoft. Ward told a story where his brother was building video editing software before Movie Maker and the Adobe ilk. At some point in time, he realized that he could add no more functionality without stepping back and refactoring the system. Ward argued that this was architecture. It was the point in time when a developer had to look at the system as a whole and move it to a desired state where it could be extended.
I have given several “Agile Architecture” presentations including a panel at this year’s OOPSLA in Orlando. In these presentations, I describe my first experience with the planning game. Our team met with the customer to “price” the user stories. The first user story was read and two developers came up with different numbers of story points. We agreed that we would use the larger as a baseline. As we continued, the story point numbers continued to be “all over the place”. In fact, the developers began to disagree with each other in front of the customer.
It turned out that each one had a different architecture in mind and that they would never agree on how hard each story was until they agreed on some of the system characteristics. I use the word “some” deliberately because they have to know just enough to “price” the stories. In other words, the planning game for nontrivial systems (and maybe for trivial systems too) requires that developers be on the same page with “how” the system will be implemented at the highest level. This is NOT BDUF.
I would argue that this understanding is necessary also throughout the development of the system especially when multiple teams are involved (team of teams). I have thus looked at expanding AM and SML through a technique called “Shadow Architecture”.