Contrary to popular belief, architecture is an important aspect of agile software development efforts, just like traditional efforts, and is a critical part of scaling agile approaches to meet the real-world needs of modern organizations.  But, agilists approach architecture a bit differently than traditionalists do.  This article addresses the following issues: Towards agile architecture Architecture through the lifecycle Have an "architecture owner" role Choose your architecture team Base your architecture on requirements Model your architecture Travel light Prove your architecture with concrete experiments Communicate your architecture  Think about the future, just wait to act Take a multi-view approach How does this work?

1. Towards Agile Architecture

Architecture provides the foundation from which systems are built and an architectural model defines the vision on which your architecture is based. The scope of architecture can be that of a single application, of a family of applications, for an organization, or for an infrastructure such as the Internet that is shared by many organizations.  Regardless of the scope, my experience is that you can take an agile approach to the modeling, development, and evolution of an architecture.

Here are a few ideas to get you thinking:

1. There is nothing special about architecture.  Heresy you say!  Absolutely not.  Agile Modeling’s value of humility states that everyone has equal value on a project, therefore anyone in the role of architect and their efforts are just as important but no more so than the efforts of everyone else.  Yes, good architects have a specialized skillset appropriate to the task at hand and should have the experience to apply those skills effectively.  The exact same thing can be said, however, of good developers, of good coaches, of good senior managers, and so on. Humility is an important success factor for your architecture efforts because it is what you need to avoid the development of an ivory tower architecture and to avoid the animosity of your teammates.  The role of architect is valid for most projects, it just shouldn’t be a role that is fulfilled by someone atop a pedestal.

2. You should beware ivory tower architectures.  An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).  The mighty architectural guru(s) go off and develop one or more models describing the architecture that the minions on your team is to build to for the architect(s) know best.  Ivory tower architectures are often beautiful things, usually well-documented with lots of fancy diagrams and wonderful vision statements proclaiming them to be your salvation.  In theory, which is typically what your architect(s) bases their work on, ivory tower architectures work perfectly.  However, experience shows that ivory tower architectures suffer from significant problems.  First, the “minion developers” are unlikely to accept the architecture because they had no say in its development.  Second, ivory tower architectures are often unproven, ivory tower architects rarely dirty their hands writing code, and as a result are a significant risk to your project until you know they actually work through the concrete feedback provided by a technical prototype.  Third, ivory tower architectures will be incomplete if the architects did nothing else other than model because you can never think through everything your system needs.  Fourth, ivory tower architectures promote overbuilding of software because they typically reflect every feature ever required by any system that your architect(s) were ever involved with and not just the features that your system actually needs.

3. Every system has an architecture. BUT, it may not necessarily have architectural models describing that architecture.  For example, a small team taking the XP approach that is working together in the same room may not find any need to model their system architecture because everyone on the team knows it well enough that having a model doesn’t provide sufficient value to them.  Or, if an architectural model exists it will often be a few simple plain old whiteboard (POW) sketches potentially backed by a defined project metaphor. This works because the communication aspects of XP, including pair programming and Collective Ownership, negate the need for architecture model(s) that need to be developed and maintained throughout the project.  Other teams – teams not following XP, larger teams, teams where people are not co-located – will find that the greater communication challenges inherent in their environment requires them to go beyond word-of-mouth architecture. These teams will choose to create architectural models to provide guidance to developers as to how they should build their software.  Fundamentally, the reason why you perform architectural modeling is to address the risk of members of your development team not working to a common vision.

4. Architecture scales agile.  This is true of traditional techniques as well.  Have a viable and accepted architecture strategy for a project is absolutely critical to your success, particularly in the complex situations which agile teams find themselves in at scale.  Scaling issues include team size, regulatory compliance, distributed teams, system complexity, and so on.  An effective approach to architecture enables you to address these scaling issues.

2. Architecture Through the Lifecycle

Figure 1 depicts the lifecycle of Agile Model Driven Development (AMDD).   During "iteration 0", the first iteration of an agile project, you need to get your project organized and going in the right direction.  Part of that effort is the initial envisioning of the requirements and the architecture so that you are able to answer critical questions about the scope, cost, schedule, and technical strategy of your project.    From an architectural point of view, during iteration 0 the goal is identify a potential technical direction for your team as well as any technical risks which you will potentially face (risks which should be addressed by proving it with code).  At this point you don't need a detailed architectural spec, in fact creating such a spec at the beginning of a software development project is a very big risk.  Instead, the details are identified on a just-in-time (JIT) basis during iterations via initial iteration modeling at the beginning of each iteration or by modeling storming throughout the iteration.  The end result is that architecture emerges over time in increments, faster at first because of the greater need to set the foundation of a project, but still evolving over time to reflect the greater understanding and knowledge of the development team. This follows the practice Model in Small Increments and reduces the technical risk of your project – you always have a firm and proven foundation from which to work. 

Figure 1. The Agile Model Driven Development (AMDD) lifecycle for software projects.

An alternative to this approach, albeit an extreme one, is to attempt to define your architecture completely before implementation begins, something often referred to as big design up front (BDUF).  Often the motivation behind this approach is that project management doesn’t want anyone moving forward until a consensus has been reached as to the approach or to the "one data truth".  Unfortunately, this approach typically results in nobody moving forward for quite a long time, an ivory tower architecture that more often than not proves brittle in practice, an architecture that is overkill for what you actually require, and/or development subteams moving forward on their own because they can’t wait for the architects to finish their work.  This approach is often the result of a serial mindset among the people involved, a legacy thought process leftover from the days of waterfall software development (the 1970s and 1980s, when many of today’s managers were software developers).

The reality is that the development of architecture is very hard, an effort that is key to your success, and one that you’re not going to get right from the start.  An iterative and incremental approach addresses the risk of an inadequate or inappropriate architecture by developing it a bit at a time, and only when you need it.

3. Have an "Architecture Owner" Role

For any reasonably complex system you're going to need to invest some time architecting it.  You'll do some up front architecture envisioning to get you started in the right direction and then the architecture will need to evolve from there.  Many agile teams find that they need someone in the role of "architecture owner", often the most senior person on the team, who is responsible for facilitating the architectural modeling and evolution efforts.  Just like Scrum's product owner role is responsible for the team's requirements, the architecture owner is responsible for the team's architecture. 

Architecture owner is different than the traditional role of architect.  In the past the architect would often be the primary creator of the architecture and would be one of the few people who worked on it.  They would often develop the architecture and then "present it" to, or more accurately force it upon, the development team.  An architecture owner collaboratively works with the team to develop and evolve the architecture.  Although they are the person with the final decision-making authority when it comes to the architecture, those decisions should be made in a collaborative manner with the team.

4. Choose Your Architecture Team

The practice Model With Others tells you that you really don’t want to be working alone, and frankly architecture is far too important to leave in the hands of a single person no matter how bright they are, therefore architecture should be a team effort.  My strategy for choosing an architecture team is typically based on the size of the project team.  On a small project team, say of ten people or less, I prefer to include all of the developers because it allows everyone involved to have their say in the architecture.  This increases everyone’s understanding and acceptance of the architecture because they worked on it together as a team.  It also increases the chance that developers are willing to change aspects of the architecture when the architecture proves insufficient, perhaps it doesn’t scale as well as you initially thought, because it is the group’s architecture and not just theirs.  When something is developed by a single person it becomes “their baby” and nobody likes to hear that their baby is ugly – when you find a problem with their architecture they are likely to resist any criticisms of it. When an architecture is developed by the entire team then people are often far more willing to rethink their approach because it’s a team issue and not a personal issue.

On a large project, or for enterprise-wide architectural efforts, you will require a core architecture team (yes, the abbreviation is "CAT" but I refuse to use it).  Your core architecture team should be comprised of developers experienced in the technologies that you organization is working with and have the ability to work on architecture spikes to explore new technologies.  They should also have a good understanding of the business domain and have the necessary skills to communicate the architecture to developers and to other project stakeholders. 

At the beginning of a large project I will identify my most experienced developers and abstract thinkers, as well as a few people that I want to see get some architectural experience, and invite them to be members of the core architecture team.  I do this for two reasons.  First, I want good people on this team.  Second, when we organize the large project team into smaller subteams that will each focus on developing one or more subsystems we will see to it that each subteam includes one or two members of the core architecture team (one of these people will typically be the architecture owner on each sub-team).  This helps to increase the chance that each subteam learns and follows the architecture as well as increases the chance that the core architecture team will not ignore portions of the system.  Furthermore, it ensures that each subteam has some senior people on it.  There will also be an an overall architecture owner who leads the core architecture team effort (this could be a rotating role).

Figure 2 depicts the process for architecture activities on an agile process.  The core architecture team is responsible for envisioning the initial architecture then bringing it to the rest of the project team for feedback and subsequent evolution.  To avoid an ivory tower architecture the members of the core architecture team will take active roles on the various subteams on the project, communicating the architecture to the subteams and working with them to prove portions of the architecture via concrete experiments.  From the point of view of the development subteams the architects act as consultants whose expertise is the corporate architecture as well as active members of the subteam.  The core architecture team should view the development subteams as their customers, as project stakeholders for their architecture, customers that will need help from them and who will have new requirements that necessitate change to the architecture.  In short, the core architecture team should actively work with their project stakeholders, in this case the development subteams.

Figure 2. Agile architecture process.

The core architecture team will find that they need to get together occasionally to evolve the architecture as the project progresses, negotiating changes to the architecture and updating their architectural model(s), if any, as appropriate.  These meetings will be frequent at the beginning of a project and will be needed less and less as the architecture solidifies.  It will be common for members of the development subteams, who may not be members of the core architecture team, to attend some meetings to present information, perhaps they were involved with some technical prototyping and have findings to share with the architects.  The best meetings are short, often no more than half an hour in length, and are often held standing up around a whiteboard – everyone should come prepared to the meetings, willing to present and discuss their issues as well as to work together as a team to quickly come to resolutions.

5. Requirements-Driven Architecture

Your architecture must be based on requirements otherwise you are hacking, it’s as simple as that.  The practice Active Stakeholder Participation is critical to your success when it comes to identifying architectural requirements – remember, requirements come from project stakeholders, not developers. Good sources for technical architecture requirements will include your users and their direct management as they will often have some insight into technical requirements and constraints.  Operations staff will definitely have requirements for you pertaining to your deployment architecture.  The best sources for business-oriented requirements are exactly who you would expect – your users, their managers. Senior management within your organization will have insights that may lead to potential change cases for your system.

As you would expect the practices Apply The Right Artifact(s) and Create Several Models in Parallel apply to your architectural requirements effort.  When you are working on the technical aspects of your architecture you will want to base it on technical requirements, constraints, and possibly change cases. Similarly, when you are working on business aspects of your architecture, potentially identifying software subsystems or business components, you will likely need to focus on essential use cases or user stories that describe critical usage requirements and potentially the key business rules applicable to your system. 

A common mistake that architecture teams (or for smaller projects the architecture owner) will make is to ignore existing and pertinent artifacts, such as network or deployment diagrams that describe your organizations existing technical infrastructure, enterprise-level business models (use case models, process diagrams, workflow diagrams, corporate business rules, and so on), or corporate deployment standards (for workstations, branch offices, etc.) that your system is expected to conform to.  Yes, the existing artifacts may be out of date or simply not apply to your effort, but you should at least make an effort to examine them and take advantage of the existing work wherever possible.  A little bit of reading or discussion with the right people is likely to save you significant effort later on.  In other words, don’t forget to reuse existing artifacts whenever possible.

An important concept to understand about architectural modeling is that although it typically occurs early in your project it never occurs first.  Fundamentally, you will always invest time identifying some requirements first.  Anything else is hacking, and hacking certainly isn’t agile.

6. Model Your Architecture

The primary goal of architectural modeling should be to come to a common vision or understanding with respect to how you intend to build your system(s).  In other words, you will model to understand.  My experience is that 99.999% of all software project teams need to invest some time modeling the architecture of their system, and that this is true even of XP teams that rely on a metaphor to guide their development efforts.  While your XP team is identifying your system’s metaphor, something that you and your teammates may think about for weeks as you are developing your initial releases, that you will often draw sketches of how you think your system will work.  You may not keep these sketches, following AM’s practice Discard Temporary Models, often because they were ideas that didn’t work out or simply because you were modeling to understand an issue and once you did so the diagram no longer had value to you.  Having said that, there is nothing wrong for an XP team to develop architecture models.  The models may be something as simple as a sketch that you keep around on a publicly visible white board, because although metaphors can be very effective things an architectural model often provides the greater detail that your team requires.  As you would expect RUP teams will also do some architectural modeling, not only because it is an effective thing to do but because it is a fundamental activity of the Analysis & Design workflow during the Elaboration phase.

How do you model your architecture in an agile manner?  I typically strive to create one or more navigation diagrams, diagrams that present an overview of the “landscape” of your system.  Just like a road map overviews the organization of a town, your navigation diagram(s) overviews the organization of your system.  Navigation diagrams are the instantiation of your system’s architectural views. When you read books and papers about architectural modeling a common theme that the authors put forward is the need for various architectural views, with each author presenting his or her own collection of critical views that you need to consider.  My experience is that no one set of architectural views is right for every project, that instead the nature of the project will help to define the types of views that you should consider creating.  The implication is that the type of navigation diagram that you create depends on the nature of the system that you are building. This is conceptually consistent with AM’s practice Apply the Right Artifact(s) which tells you that you should use the right modeling technique for the task at hand. For example, a team building a complex business application using J2EE-based technology will likely find that a UML component diagram and a workflow diagram are appropriate for use as architectural navigation diagrams.  However, a team building a corporate data warehouse will likely gravitate towards a data model and UML deployment diagram on which to base their architecture.  Different projects, different architectural views, hence different types of navigation diagram(s).  It is interesting to note that both projects needed two navigation diagrams, consistent with the Multiple Models principle.  You need to be flexible in your approach because one size does not fit all.

A common mistake that organizations will make is to base their architectural efforts on their organization structure.  For example, an organization with a strong data group will likely want to have a data model as the primary artifact for their architecture regardless of the actual nature of the system.  When you have hammer specialists every problem looks like a nail to them.  This problem is quite common when you are working with new technologies or attempting to develop a new class of system that your organization has little experience with – organization structures that worked well for you in the past may no longer work for you in your new environment.   For more about the implication of architecture and organization structure please refer to the organizational pattern Conway’s Law. 

To create a navigation diagram the primary driver of your modeling efforts should be to assume simplicity. The practice Create Simple Content indicates that you should strive to identify the simplest architectural approach(es) possible – The more complicated your architecture the greater the chance that it won’t be understood by individual developers and the greater the opportunity for error and breakdown. Furthermore, your architectural models should contain the right level of information, showing how various aspects of your system work together but not the details (this is what design is all about) following the practice Depict Models Simply.  You should also Use the Simplest Tools to do the job, many times a whiteboard sketch is all that you need to model the critical aspects of your architecture.  Don’t use a CASE tool when a drawing tool will do.  Don’t use a drawing tool when a POW will do.  Don’t use a POW when paper and Post-It notes will do.

An important point to be made is that navigation diagrams are typically sufficient to describe your architecture when all of your communication is face-to-face.  When this isn’t the case, when your architects are not able to work closely with the developers (perhaps some developers are at a distant location) then you will need to supplement your diagrams with documentation.

When you are architectural modeling you should consider taking advantage of the wealth of architectural patterns available to you but you should do so in an effective manner.  The book A System of Patterns: Pattern-Oriented Software Architecture is an excellent place to start learning about common architectural patterns such as Layers, Pipes and Filters, Broker, Model-View-Controller, and Blackboard.  As with analysis and design patterns, you should follow the practice Apply Patterns Gently – introduce them into your architecture only when they are clearly required.  Until then if you suspect that an architectural pattern may be appropriate, perhaps you believe that you will have several sources of critical services that will need to be brokered, then model your architecture so that you can apply this pattern when this actually becomes the case.  Remember that you are developing your system incrementally, following the practice Model in Small Increments, and that you don’t need to get your architecture right on the very first day (nor could you achieve this goal even if you wanted to).

You should recognize that your architectural models will reveal your system’s dependencies on other systems or their dependencies on yours.  For example, your system may interact with a credit-card processing service via the Internet, access data from a legacy relational database, or produce an XML data structure for another internal application.  Network diagrams and UML deployment diagrams are very useful for identifying these dependencies, as are process-oriented models such as workflow diagrams, UML activity diagrams, and data-flow diagrams.   The implication is that these dependencies indicate the potential need to follow the practice Formalize Contract Models between your team and the owner(s) of the systems that yours share dependencies with.  Ideally many of these models will already be in place, the credit card processor likely has a strictly defined protocol that you must follow and the legacy database likely has a physical data model defined for it, although new functionality such as the XML data structure will require adequate definition.  Sometimes you will need to perform an analysis of the existing interface to a legacy system if accurate documentation is not in place and other times you will need to design a new interface.  In both cases a corresponding contract model will need to be developed, either by your team, the other team(s), or co-jointly as appropriate.

How should you organize your architectural modeling efforts?  At the beginning of a project I will typical gather the architecture team together in a single room for an initial envisioning session.  Ideally this session will last for no more than several hours but on some larger projects it may last for a few days.  As always, the longer the modeling session the greater the chance of going off course due to lack of feedback.  The goal of this modeling session will be to come to an initial agreement as to the landscape of the system that we are building, perhaps not consensus but sufficient agreement so we can start moving forward as a team.

7. Travel Light

One goal of your architectural efforts should be to travel light, to be as agile as possible.  Don’t create a fifty-page document when a five-page one will do. Don’t create a five-page document when a diagram will do.  Don’t create a diagram when a metaphor will do.  Remember the "They Ain't Gonna Read It (TAGRI)" principle.

Not sure of how documentation much to create?  Err on the side of not having enough because you can always go back to the whiteboard if you need to, but the time you’ve wasted creating artifacts that you didn’t need or adding unnecessary detail to artifacts is gone for ever.  Your goal should be to think through the critical issues faced by your project team (or organization or even industry depending on your scope), it shouldn’t be to create reams of documentation. The principle Maximize Shareholder ROI tells you to focus on high-value activities such as working through the hard problems as a team and coming to a common vision.  Similarly, it tells you to avoid low-value activities such as writing detailed documentation or developing scores of pretty diagrams.  These activities are often comforting because they provide the illusion of progress, and provide you a source of digression if you are trying to avoid dealing with difficult issues, but in reality are rarely as effective as you imagine because the are rarely looked at by anyone other than the author(s).  The principle Software is Your Primary Goal implies that you should model your architecture until the point where you believe you have a viable strategy, and at that point you should move on and start developing software instead of documentation.

When will you want to write architectural documentation?  There are two instances where it makes “agile sense” in my opinion.  First, when you have a distributed development team and you cannot find a more effective manner of communication, such as face-to-face conversation, then documentation is an option.  Second, at the end of a project when you want to leave behind sufficient documentation so that someone else can understand your approach later on.  The reality is that for reasonably complex systems it’s incredibly difficult, if not impossible and certainly not desirable, to document everything in your code.  Sometimes the best place to describe your architecture is in a brief overview document.  This document should focus on explaining the critical aspects of your architecture, likely captured by your navigation diagrams, it might include a summary of key architectural requirements, and an explanation of the critical decisions behind “questionable” aspects of what you did.  As always, if you’re going to create an architecture document then it should add positive value and should ideally do so in the most effective way possible. 

A lot of people get worried when they discover that an architecture isn’t “well documented,” whatever that means.  I’m not so worried about this issue, but what I do worry about is whether the architecture is realistic and whether the developers understand and accept it if it is.  If you were to prioritize having your architecture documentation, having a workable architecture, having the architecture understood by your developers, and having it worked to by all the developers I suspect that documentation would come in dead last on that list.  Think about it. 

8. Prove Your Architecture

The practice Prove it With Code points out that a model is merely an abstraction, one that may appear to be very good may not actually be so in practice, that the only way you can know for sure is to validate your model through implementation.  The implication is that you should prove that your architecture works, something that XP calls spikes and RUP calls architectural prototypes.   When your architecture calls out for something that is new to you, perhaps you are using two or more products together for the first time, you should invest the time to explore whether or not this approach will work as well as how it works in accordance to the principle Rapid Feedback.   Remember to obtain permission from your project stakeholders to perform this effort because it is their money you are spending. Sometimes you will discover through your efforts that your original approach doesn’t work, something that I would prefer to find out sooner rather than later, and sometimes you discover how your approach actually works (instead of how you thought it would work). The development of an architectural spike/prototype helps to reduce risk to your project because you quickly discover whether your approach is feasible, that you haven’t simply produced an ivory tower architecture.

9. Communicate Your Architecture 

There are two primary audiences for which communication of your architecture is important: your development team and your project stakeholders.  To promote communication within your development team I am a firm believer that you should follow the practice Display Models Publicly for all of your architectural diagrams because an architecture that is a closely guarded secret isn’t an architecture, it’s merely an egotistical exercise in futility. I’ve worked on several projects where we have successfully maintained a whiteboard that was reserved specifically for architectural diagrams, making them visible publicly to every developer on the project as well as to anyone else who happened to walk by.  We would also allow anyone who wanted to add comments or suggestions to the diagrams, along the lines of the principle Open and Honest Communication and the practice Collective Ownership, because we wanted their feedback on our work. We had nothing to hide and trusted that others would be willing to help us out (and they did).

At the start of a project, and less so throughout your project, you will often find that you need to make your diagrams “look pretty” so you can present them to your project stakeholders.  Your stakeholders want to get a good idea as to what approach you intend to take to determine whether your are investing their resources wisely, which means you’ll need to model to communicate and orient some of your models so that others can understand them.  This may mean you need to invest the time to clean up your models to make them presentable as well as write overview documentation for them.  To remain as agile as possible the principle Model With A Purpose tells you that you should know exactly who you are developing the model(s) for and what they will use them for so you can focus on the minimum effort required.  Presentations to important project stakeholders, efforts that are often annoying and distracting for developers, are critical to your project’s success as they provide opportunities for you to garner support for your project and to obtain needed resources.  Furthermore, you can promote the importance of having stakeholders available to you that are able to actively participate on the project (you can’t follow the practice Active Stakeholder Participation if you don’t have stakeholders available to you).

Be prepared to communicate your architecture in a presentation, and there is no reason why you cannot keep the presentation agile.

10. Think About The Future But Don’t Overbuild

I suspect that the most controversial concept about agile architectural modeling is that you should consider future changes but not act on them until you actually need to.  In other words, don’t overbuild your system but at the same time be smart about it.  The XP community is fairly blunt about the concept of overbuilding software with their belief that “You Ain’t Gonna Need It Anyway” (YAGNI).  The basic idea is that you cannot accurately predict the future[1] and therefore shouldn’t attempt to build for future possibilities.  Instead you should focus today on building what you need to today and building it cleanly so that your software is easy to change when you need to.  Tomorrow, when you discover that you need to change your software to fulfill new requirements then change it then.  When you overbuild your software to be more general, to fulfill future potential requirements, you are actually making very serious trade-offs.  First, you are not focusing on meeting today’s needs, resulting in you not producing something of immediate value to your users.  I’ve been on several projects where the first several months, and in a few cases first several quarters, of effort focused on the development of common infrastructure (persistence frameworks, messaging frameworks, and so on).  Technically interesting things, we definitely had a lot of fun building them, but of no value to our users.  Second, you don’t really know if you will even need whatever it is that you’re building – you may be building a Porche when a Volkswagon would have been sufficient.  Third, anything that you overbuild today will need to be tested and maintained throughout the life of your project, violating the principle Travel Light.  Fourth, when you overbuild something the only way you can accurately validate it is via imaginary feedback – nobody asked for whatever you’ve overbuilt so you have no one to go to that can validate your work.  Yikes.

So how can you be smart about all of this?  Although you don’t want to overbuild your system based on future/mythical requirements there isn’t anything wrong with thinking about the future.  This is where initial architectural modeling, in particular change case modeling, become a consideration for you.  Change cases are used to describe new POTENTIAL requirements for a system or modifications to existing requirements.  Change cases are requirements you may, or may not, need to support in the future but you definitely do not need to support today.  Change cases are often the result of brainstorming with your project stakeholders, where questions such as “How can the business change?” "What legislation can change?" "What is your competition doing?" and "Who else might use the system and how?" are explored.  On the technical side developers will often ask fundamental questions such as "What technology can change?" and "What systems will we need to interact with?" that will lead to the identification of change cases.  Change cases should be realistic, for example “We enter the insurance business” for a bank or “We need to support the [INSERT FLASHY NEW TECHNOLOGY] in our system” are reasonable change cases but “Our sales staff is abducted by UFOs” isn’t.  Furthermore, change cases typically describe requirements that are reasonably divergent from what you are currently working on, requirements that would potentially cause major rework to fulfill.  By identifying change cases you are now in a position to intelligently choose between what would otherwise appear to be equal architectural or design decisions.  You should only bring relevant change cases into the decision making process when your current requirements are not sufficient to help you to choose between alternatives.  Another advantage is you can now explain to your project stakeholders why you chose one approach over another, as I like to say you have a story to tell.  However, I cannot stress enough that change cases should not be used as excuses to gold plate your system.  Stay agile and don’t overbuild your system.

So what do you do when you think you have a change case that you truly believe needs to be implemented now?  Simple – discuss it with your project stakeholders.  Ask them if the change case is an immediate requirement, and if so act accordingly.  If it isn’t an immediate requirement then accept the fact and move on.  Never forget that it is the project stakeholder’s responsibility to prioritize requirements, not yours.

Would there be harm in modeling for the future?  This is a slippery slope because I suspect that if you model it then you are much more likely to build it.  It would require great discipline not to overbuild, I believe, because once you’ve got it captured as a collection of bubbles and lines it will be far too easy to convince yourself that there’s no harm in overbuilding just this once.  Having said that there’s nothing wrong with drawing a few throw-away sketches as you’re discussing a change case, just don’t over model any models you intend to keep.

11. Take a Multi-View Approach

Agile Modeling's Multiple Models principle advises you to recognize that because modern systems are complex that you will need to consider a range of views in your architecture.  Although they take different approaches, a multi-view strategy is a fundamental concept in modern architectural frameworks such as the Zachman Framework, TOGAF, 4+1, and so on.  Each of these frameworks have very good reasons for their choice of views, they all seem to work well in practice, they can all be approached in an agile manner, so my advice is to review your options and pick the architectural framework which best reflects the culture of your organization.  My goal here isn't to propose yet another architecture framework, it is to make you aware of them and their underlying concepts.  Figure 3 overviews the views and concerns which software/system architects need to be concerned about.

Figure 3. Architectural views and concerns.

A view/viewpoint is captured as a combination of diagrams and text descriptions (such as use cases, technical specifications, or prose) . The potential issues, which may be views in and of themselves, which your views that your architecture should address include:

• Usage/business process
• User interface
• System interface
• Network
• Deployment
• Hardware
• Data storage
• Data transmission
• Events
• Code/component distribution
• Function/logic/services

To borrow the language of aspect oriented programming (AOP), there are also "cross-cutting concerns" which your architecture may also need to take into account.  These concerns/perspectives should also be addressed by your architectural views and in some cases may be specific views in an of themselves.  These concerns are:

• Layering/partitioning
• Reuse
• Quality and validation
• Accuracy and timeliness
• Reliability, Availability, Serviceability, and Performance
• Customization points
• Consumability
• Concurrency
• Security
• Internationalization
• Regulations
• Maintenance, operations, and support issues
• Usability

The implication is that anyone in the role of architect needs to have a wide range of skills to be effective, that they need to move away from the traditional philosophy of over specialization and be more of a generalizing specialist.  Minimally they should move away from being simply a data architect, or security architect, or network architect towards being an architect.  Being just an architect is arguably too specialized as well, but that will vary depending on the situation.  True professionals strive to have a wide range of skills as well as one or more specialties.

12. How Does This Work? 

The architectural approach that I’ve described is markedly different that what a lot of organizations are currently doing today.  Table 1 compares and contrasts the architectural practices that are commonly found in many organizations with their agile counterparts.  Clearly, there’s a big difference.  The agile approach works because of its focus on people working together effectively as a team.  Agile Modeling recognizes that people are fallible, that they aren’t likely to get the architecture right to begin with and therefore need the opportunity for acting on feedback from implementation efforts.  When agile architects are productive members of the development team, and when the development team has been involved with the architectural efforts to begin with, then comprehensive documentation isn’t needed by them, the navigation diagrams are sufficient (granted, when this is not the case documentation, hopefully minimal, may be required).  Architecture reviews aren’t needed because the architecture is being proved through the concrete feedback of architectural prototyping/spikes and because people can see the architecture evolve because your models are displayed publicly for everyone to see.  Agile architects have the courage to focus on solving today’s problem today and trusting that they can solve tomorrow’s problem tomorrow (Beck, 2000), and the humility to recognize that they cannot accurately predict the future and therefore choose not to overbuild their architectures. 

Table 1. Comparing Common and Agile Architectural Practices.

13. Acknowledgements

I'd like to thank Birol Aygun, Jesper Rugard Jensen, Ashely McNeile, and Paul Oldfield for their observations which went into updating this article.

13. Recommended Resources

• Agile Best Practices for Data Warehouse (DW)/Business Intelligence (BI) Projects
• Agile Enterprise Architecture
• Agile Model Driven Development (AMDD)
• Agile Strategies for Enterprise Architecture (in Enterprise Architecture Trends 2007, Cutter Consortium)
• Best Practices for Agile/Lean Documentation
• Comparing the Various Approaches to Modeling in Software Development
• Development Phases Examined: Why Requirements, Analysis and Design No Longer Make Sense
• Enterprise Modeling Anti Patterns
• Generalizing Specialists
• Initial High-Level Architectural Envisioning
• Initial High-Level Requirements Envisioning
• The "Model a Bit Ahead" Pattern
• The "One Truth Above All Else" Anti-Pattern
• The Process of Database Refactoring
• Software Systems Architecture by Nick Rozanski and Eoin Woods
• The "They Ain't Gonna Read It (TAGRI)" principle of software development
• A UML Profile for Data Modeling
• When is Enough Modeling Enough?

		The Practical Guide to Enterprise Architecture demystifies enterprise architecture and helps organizations recognize real business value through effective implementation.  Many enterprise architects have significant responsibility, but do not have the necessary authority to bring about success. The primary focus of this book is to be a guide and trusted advisor to those who want to be successful in this pursuit. Through real-world examples from experts who have filled the role of enterprise architect, the reader will learn how to solve complex problems, maintain technical competencies, and make a positive impact on the overall business. The most successful architecture will have an architect that can describe the motivation behind the technical choices; this book provides the background the practitioners will need to become the enterprise evangelist.
		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.
		The Enterprise Unified Process: Extending the Rational Unified Process describes the EUP, an extension to the RUP.  Whereas the RUP defines a software development lifecycle, the EUP extends it to cover the entire information technology (IT) lifecycle. The extensions include two new phases, Production and Retirement, and several new disciplines: Operations and Support and the seven enterprise disciplines (Enterprise Business Modeling, Portfolio Management, Enterprise Architecture, Strategic Reuse, People Management, Enterprise Administration, and Software Process Improvement).