Architecture is an important part of any development project, regardless of its paradigm; every delivery team needs to address solution architecture in some manner. Even though core agilists might say they don't use any up-front architectural modeling, the 2009 Agile Project Initiation survey found that 86 percent of respondents indicated that their Agile teams had, in fact, done so.
The solution architecture may not be well-documented, work may begin on the solution before a strategy has been identified, and the chosen architecture may not be the best for the situation at hand, but the architecture exists nonetheless. It's good practice to have at least a general idea of how you're going to build the solution, or identify several good options of ways to proceed, in the early stages of a Disciplined Agile Delivery (DAD) project. During the inception phase, the key developers ideally everyone who is on the team at that point will identify one or more potential architectural strategies that support the stakeholder goals for the solution. Even though the details will most likely evolve as the project progresses, your team should begin by heading in a good direction.
This article describes how to take a disciplined approach to architecture on Agile projects. It summarizes material from the book Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise, which I co-authored with Mark Lines of UPMentors. One interesting feature of the DAD process framework is that it is not prescriptive: It is goals based. Rather than saying, "Here is the official Agile architecture strategy," we prefer the more-mature approach of pointing out that architecture is important, that there are several issues that you need to address, several ways to address each of those issues, and trade-offs associated with each one.
The bottom line is that the DAD process framework makes explicit the important process decisions that Agile teams are making. It also provides experienced-based advice to help make them.
A DAD team will strive to address several issues when it comes to Agile architecture. Figure 1 depicts the choices associated with the goal of identifying an initial technical strategy. Early in the project, you have three architectural process issues to address: the level of model detail, the type of models to create, and your modeling strategy. Architecture is addressed throughout the lifecycle in DAD projects, but for now, let's focus on how to get started.
Figure 1: Identifying an initial technical strategy.
How Much Initial Modeling?
As Figure 1 shows, you may choose from several levels of architectural specification. With a detailed end-to-end approach you can specify your architecture in an in-depth manner through all architectural layers. For a business application, this type of approach would include detailed specifications for how the various components/subsystems (user interface, business, persistence, security, messaging, and so on) work. The detailed interface approach, called "API First" in the Eclipse Way and "Contract Modeling" in Agile Modeling (AM), is based on the idea that you define in detail only the interfaces to the main components/subsystems of your architecture. The high-level overview strategy is a middle-ground approach in which you create lightweight, high-level Agile models that are sufficient (but no more) for your needs at the time. These lightweight models are created following AM's architecture-envisioning practice over several hours or days, not several weeks or months, as is common in traditional environments. And, of course, you may choose to do no up-front architectural envisioning at all.
How much detail you use to describe your chosen strategy depends on your team culture, your organizational culture, any external regulations that might apply, and the organizational strategy, if your team is large. Some team cultures lean towards detailed architectural specifications, whereas others are comfortable with high-level diagrams or sketches. Similarly, some organizations prefer detailed specifications, although as Agile strategies gain greater acceptance we're seeing a move towards less-detailed architectural specification in favor of greater collaboration. Some industry regulations, particularly when it comes to safety- or life-critical systems, require the creation of detailed specifications early in a project. And when a large team is organized into smaller component sub-teams, you will want to define what those components are and provide a detailed definition of the interface to each one.
In practice, it's likely you won't need to do much initial architectural modeling; a large majority of project teams work with technical architecture decisions that were made years earlier. Your organization will most likely already have chosen a network infrastructure, an application-server platform, a database platform, and so on. In these situations your team will need to invest the time to understand those decisions and to consider whether the existing infrastructure build-out is sufficient (and if not, identify potential improvements). In such cases, teams will want to identify the aspects of the infrastructure that they intend to leverage and enhance. Apart from the logistics of getting everyone together, this should be hours of work, days at most certainly not weeks or months. Occasionally, a team will find itself building a truly new solution and formulating a new architectural strategy to support it. This is often the case when your solution supports entering a new market or is purposefully replacing an antiquated legacy system. Both of these are risky endeavors that require a bit more thinking and are likely to require several days of initial architecture modeling.
What Should You Model?
Regardless of the level of detail, your architectural modeling will typically focus on several major views. First is the technology view, whose primary goal is to explore the high-level structure of the hardware or software (or both) and how they fit together. Free-form diagrams and UML deployment models are common artifacts used for this purpose. The business architecture view explores how the solution implements business concepts and activities, which are often depicted with process diagrams and conceptual data models. A user interface (UI) view explores the UI for your system, typically via a UI flow diagram. Of course, you could choose from many other types of diagrams for these views, not just the ones named here. For reference, I maintain overviews of a range of model types.
Your situation will help determine the types of models you create. In my experience, teams typically create some sort of architectural overview diagram usually a stack or a free-form diagram and a diagram that explores hardware topology issues, such as a deployment or a network diagram. Less commonly, and often to their detriment, teams will use a mechanism such as a wiki page or a shared text file to track their important architectural decisions.
How Should You Model?
When you're identifying your approach to initial architectural modeling, it is important to get the right people involved. Architectural modeling is inherently a team sport, often requiring a range of viewpoints to be successful. Small and medium-sized teams work best when all available team members get involved with the modeling effort. This improves the quality of what is produced and increases buy-in to the overall vision. This may not be viable for very large teams, for which the architecture owners and other key team members are likely to be involved. It is also wise to invite some of your technical-leaning stakeholders; in particular, the enterprise architects (if any) that will be supporting your team and any knowledgeable operations staff. The enterprise architects will provide guidance about the desired technical direction of your organization and should be able to suggest potentially reusable assets that your team can leverage, as well as applicable development guidelines. The operations staff will be handy for providing insight into current and forecast loads within your production environment, potential limits regarding your production environment, and strategies to address any challenges.
It is also important to choose the right level of formality for your architectural modeling efforts, which typically should reflect the level of formality of your requirements modeling efforts. For example, formal architectural modeling goes with formal requirements modeling. The more formal your modeling approach is, the more expensive and time-consuming it will be, albeit with the potential benefit of being more exact and less risky. I'd be tempted to take a formal approach if I were architecting a space probe, such as the Mars Curiosity rover, but would use an informal approach for a website.
A final consideration is how many technical options you should consider. In some situations, particularly when you're building something completely new for your organization, it makes sense to identify several potential technical strategies and work on them in parallel until one clear winner emerges.
Defining an appropriate technical strategy at the beginning of a project is just the start. Disciplined Agile Delivery teams will continue to evolve architecture throughout a project because it is so important. The architecture owner will guide the team through understanding and evolving the architecture, mentoring people in architecture and other skills as appropriate. Early in the construction phase, the team will help reduce the technical risk on the project by proving the architecture with working code. The architecture owner will also ensure that the architecture handbook, if your team decides to maintain one, is kept up to date. Throughout construction, your team should work closely with your organization's enterprise architects and operations staff, if they are available, to ensure that they are leveraging and enhancing the existing infrastructure whenever possible.
Doing some initial architectural modeling at the beginning of an Agile project has several benefits. You will potentially:
- Improve overall productivity and reduce development time by thinking through some of the critical technical issues facing your project and avoiding some fruitless technical paths.
- Reduce technical risk by having a guiding vision without having to overbuild your system (just because you've modeled it doesn't mean you have to build it, regardless of the claims of some "extreme programmers").
- Avoid technical debt by thinking through critical issues before you implement your solution, thereby reducing the chance for major rework.
- Improve your team's enterprise awareness by taking a systems perspective.
- Improve development/operations (DevOps) integration by working closely with operations and support staff to ensure that the solution addresses operational needs.
- Reduce overall project risk by beginning to address the non-functional "ilities" such as availability, reliability, security, consumability, and others early in the project.
- Improve overall communication within the team and with project stakeholders.
- Scale Agile software delivery to meet the real needs of your organization.
When addressing architecture on an Agile project, you need to consider many issues and choose the strategy that is best suited for the situation. Using the DAD framework provides your team with contextual advice to address the many goals, including architectural ones, that are part of successfully navigating important process decisions.
Survey: Summer 2012 State of the IT Union
I invite you to fill out the latest "State of the IT Union" survey. The goal of this ongoing survey series is to find out what IT professionals are actually doing in practice. The survey should take about 5-7 minutes to complete, and your privacy will be completely protected.
At the end of the survey, you will be given a chance to be entered into a drawing for one of ten copies of Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise by Scott W. Ambler and Mark Lines, published by IBM Press in June 2012, which I discussed above.
The results of this survey will be summarized in a forthcoming article. This is an open survey, so the source data (without identifying information to protect your privacy), a summary slide deck, and the original source questions will be posted at www.ambysoft.com/surveys/ so that others may analyze the data for their own purposes. Data from previous surveys have been used by university students and professors for their research papers, and hopefully the same will be true of the data from this survey. The results from several other surveys are already posted there, so please feel free to take advantage of this resource.
A comprehensive approach to dealing with non-functional requirements (NFRs) is described in my September 2008 Dr. Dobb's article Beyond Functional Requirements on Agile Projects.
The Surveys Exploring the Current State of Information Technology Practices page links to the results of all the surveys in Dr. Dobb's I've run over the years.
Scott Ambler is the Principal of Scott W. Ambler + Associates. Previously, he headed up Agile practices at IBM Rational. Follow him on twitter.