Within the context of software systems and development, what is "architecture"? And what makes an architecture Agile?
According to IEEE and others, software architecture is:
(system) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution" 
Notice that within software development, architecture is not simply the way the software is put together. It's not just the way the pieces relate to each other. Architecture within a software development and functioning environment deals with:
- The properties and relationships of its elements (how the pieces fit together)
- The principles of its design
- The principles of its evolution (processes used to create the system)
Waterfall Software Development
A system's evolution can take place in two ways. The standard development approach for the initial system makes use of a waterfall lifecycle approach. This involves establishing a specific set of milestones that include requirements gathering, analysis and validation, design and design review and approval, coding, testing, delivery, and maintenance. If any changes are identified, the process is repeated on a scale in preparation for the next version or release. In a waterfall environment, changes are slow. And usually, by the time the changes are implemented, more changes have been identified. One of the primary drawbacks of the waterfall approach is the amount of time between the identification of a new or modified functional requirement and the availability of the function to the user. As noted in other articles, this process does not fit particularly well in an Agile environment.
Agile Software Development
Agile development is discussed in other articles within this site. There, we see that the Agile principles (a part of defining the architecture) call for the involvement of the project managers, the system users, and the software developers (coders) to create software value early in the project. In the development of any portion of the overall system, users are able to make changes. It means being open to changes in the requirements, the design and even the functions to be delivered. Within the Agile architecture, the development of the software and the evolution of the software are dependent on a self-directing team composed of the user, the analysts, and the developers. More about this later in this article.
So how does working in an Agile environment impact the architecture to be implemented? What principles within an Agile environment apply to the architecture?
The traditional software development process follows Figure 1.
The general philosophy embodied in the waterfall development process is a practical and functional separation between the analysts, coders/developers and testers. One team works on designing and developing the system. Another team works on testing the code once it has been integrated. Often, an IV&V (Independent Verification and Validation) team is given the software and test cases, but with no real idea of what to expect when they develop their test cases and test the software. This often results in needless failure of code because the IV&V testers didn't understand what the code was designed to do and identified results they didn’t expect as errors or bugs. This misunderstanding often results in lost time and money.
This process (a part of waterfall architecture) is rigid. It does not allow for much in the way of flexibility in the development or evolution of the system. Indeed there is no significant effort to inject flexibility into the process. Version control, documentation, and testing actually gravitate against flexibility.
On the other hand, an Agile process in an Agile architecture will bring flexibility into the overall architecture.
The organization of an Agile project differs significantly from the traditional waterfall project. The two philosophies (aspects of each architecture) differ significantly and this drives a difference in the organization of the teams.
Rather than the implementation of a multi-layered management process, the work is planned and executed by the Agile team. Clearly the client/developer philosophy differs between the two. The first approach has minimal interaction between the client and the developers. An Agile organization encourages extensive interaction between the parties. An approach taken by some organizations is to even include IV&V in some portions of the Agile development process. Sprint planning and review are good places to expose the IV&V testers to the software function.
An Agile development process looks more like Figure 2 where the green circles/arrows represent interaction between the developers, the analysts, and the users. Generally, the daily scrum will last no more than 10 - 15 minutes and will not generally involve the participants in attempting to develop solutions to problems that may exist.
An Agile architectural environment involves the analysts, the developers and the user/client from the very beginning. And the interaction between them is ongoing throughout the project development. One of the primary benefits of this approach is the ability to avoid misunderstanding or mis-communications. Another is the ability to adjust for changes since, with an Agile approach, changes are only likely to affect small portions of the overall system, minimizing the need for change driven coding.
Within an Agile project four activities take place on a rotating basis once the project is initiated.
- Sprint Planning - The users and the developers decide what functions will be worked on during the next period (1 - 3 weeks).
- Daily Scrum - Users, developers and analysts discuss the progress being made, any impediments and their impacts, and ways to mitigate the impact. This activity is usually guided by a Scrum Master.
- Sprint Review - What was accomplished during the last completed sprint (the 1 to 3 week coding and testing period) along with a demonstration of the completed function.
- Sprint Retrospective - What went well, what needs to improve with respect to communications, development or analysis to name a few items.
Unlike Waterfall, an Agile philosophy requires close communications between the client and the development team. The participants in the Agile activity are:
- The Scrum Master
- The Developers (Analysts, coders, etc)
- The User
- The Manager (Product Owner)
One of the most significant differences in the Agile architectural approach is the importance of collaboration. In fact, Agile processes include collaboration between the four entities. This collaboration takes place in the selection of the system organization, structural elements, and their interfaces. These decisions, as the development progresses, evolve the system into a progressively larger and more complex system.
When properly implemented, an Agile architecture provides greater flexibility within the project. While you do need a certain level of stability with respect to the requirements and by extension the functions, minor changes can be addressed and negotiated in a Sprint Review or Sprint Planning meeting.
An Agile architecture allows flexibility in the development schedule. If a capability, or function is developed in less time than planned, testing and the test results can also be accomplished ahead of schedule. In fact, for the average Agile project, testing a particular function won't stop until the function's code passes.
The results of implementing an Agile Architecture are manifold. The project schedule will be much more realistic since it was developed by the team with Management's support. The quality of the software, both in terms of being error free and, more importantly, doing what the user wants the way the user wants it done, will be much higher. It does little good if the application or system functions perfectly but doesn't have the functions the user wanted. Time spent re-coding to modify a function is time wasted. Time wasted is money wasted.
The agile process and architecture are sometimes mistakenly thought of as free form processes in which no documentation is required. When a system uses an Agile architecture in what has customarily been a traditional waterfall environment, the two architectures will sometimes clash because of this misconception.
If the configuration management organization requires documentation for such things as Initial Design Review, Critical Design Review and other major milestones within a waterfall process, the Agile owner will experience push back from the various committees responsible for controlling software development within the organization. Unless the Agile process and the products it produces are carefully coordinated with the committees, moving forward to implementation of the developed software can be difficult.
Remember, the waterfall model has been used for decades. More than that, it has worked overall when followed in a consistent and disciplined manner. The Agile architecture is still proving itself.