An Agile Approach to Architecture

First and foremost, the values, principles, and practices of Agile Modeling (AM) (see Chapter 8) should help to guide your architecture modeling and documentation efforts. However, this is only a good start. To be successful at architecture, you need to rethink your overall approach and address seven fundamental issues. These issues are connected in a synergistic manner; you must address all them, otherwise you will put your effort at risk:

• Focus on people, not technology or techniques.

• Keep it simple.

• Work iteratively and incrementally.

• Roll up your sleeves.

• Build it before you talk about it.

• Look at the whole picture.

• Make your architecture attractive to your customers.

Focus on People, Not Technology or Techniques

Architects span the boundaries between developers and the people within your organization who have the long-range vision very often senior IT and senior business executives. The architects work closely with senior executives to understand and evolve their vision for the system. The architects will then reflect this vision in their work and will communicate the vision to the project. The feedback they receive from developers will be fed back into the visioning process; thus the architects act as a communication bridge between senior executives and developers.

Alistair Cockburn (2002) likes to say that software development is a communication game, that to succeed you must ensure that the people (developers and project stakeholders alike) are able to communicate with one another effectively. Figure 7-1 depicts a modified version (Ambler 2002a) of Cockburn's communication modes diagram, indicating that the options on the lower curve support documentation efforts, whereas the options on the upper curve support modeling activities. Several interesting points can be derived from this diagram. First, people can communicate in many ways with one another, and you should vary your approach depending on the situation. Second, some techniques are clearly better than others, so given a choice you should prefer to apply the most effective option available to you. Third, although permanent documentation is clearly important, it is the least effective way to communicate. The implication is that if your current strategy is to simply model and then document your architecture and hand it off to developers, you are very likely going to fail.

Figure 7-1. Communication modes.

Agile architects will work with their customers, including developers, in the most effective manner possible. Sometimes this will be drawing sketches face to face with them at a whiteboard. Sometimes it will be working with project teams via video conferencing. Sometimes it will be posing questions and receiving answers via email. Sometimes it will involve publishing models and documents. We highly suggest following the AM practice of Display Models Publicly for your architectural models and documents publish them online at an internal Web site and consider putting up paper versions of critical diagrams in the work spaces of your audience. It isn't enough for architects to put their diagrams on the walls within their work areas; these models must be available to everyone.

This concept isn't new. Fred Brooks (1995) wrote that "The quality of the people on a project, and their organization and management, are much more important factors in success than are the tools they use or the technical approaches they take." The reality is that architectures are developed, evolved, and followed by people. All the arguments over which model is right, which notation is right, and which paradigm is right are meaningless if you don't have a viable strategy for working together effectively. You could create a perfect architecture model, but it doesn't matter if developers can't or won't take advantage of it.

An interesting observation is that enterprises have two organizational structures the formal one documented by your organization chart and the informal one that people use to get things done. Within IT departments there are always the "go-to guys" that developers work with to get things done, very often other developers who have critical skills or knowledge. Agile architects understand this and actively seek to become "go-to guys."

Keep It Simple

Another of AM's core principles is Assume Simplicity. This principle advises you to assume that the simplest solution is the best solution. You should not overbuild your software, and in the case of architecture, you should not depict additional features in your models that your audience doesn't really need. A supporting principle is Model with a Purpose, which advises you to know who the audience is for your work and to know their use for it. This knowledge enables you to create models and documents that actually meet their needs and permits you to streamline your efforts because you don't need to guess what it is that they actually want. In other words, work together effectively with your audience.

These principles lead to two core practices, Depict Models Simply and Create Simple Content. The first practice implores you to depict your models and documents as simply as possible, to use the simplest notation available to you, and to follow modeling style guidelines (Ambler 2003a) wherever possible. The second practice says that you should apply the simplest solution that gets the job done; avoiding unnecessary complexity that would require greater development, testing, and maintenance efforts and thus higher cost (another AM principle is Maximize Stakeholder Investment).

A critical concept is that your architecture models and documents only need to be good enough, they don't need to be perfect. It is naïve to assume that you can produce perfect artifacts you're only human, and you will never get it perfectly right and nobody expects you to anyway. Furthermore, even if you did manage to create perfect artifacts, they'd be out of date the day after you published them because something within your business or technical environment would change (Embrace Change is also an AM principle). Why is this important? Our experience is that a hand-drawn sketch today can often be far more valuable than a fully documented and validated document several months from now. Timely guidance from an agile architect who understands the current environment and the future vision for the enterprise, even when this guidance is imperfect and based on incomplete information, is often far better than the uneducated guesses that developers will make on their own while they wait for the official architecture to be published.

By keeping your architecture artifacts simple, you increase the chances that your audience will understand them, that developers will actually read them, and that you will be able to keep them up to date over time. Overly detailed documents might look impressive sitting on a shelf, but a simple model that project teams actually use is far more impressive.

Work Iteratively and Incrementally

Agile architects work in an iterative and incremental manner, preferring an evolutionary approach as opposed to a "big design up front" (BDUF) approach. Agile architects will follow the practice Apply the Right Artifact(s) and use a wide variety of modeling techniques as required (more on this later). They will also follow the practice Iterate to Another Artifact when they realize either that the model they are working on isn't the appropriate one with which to depict a concept or that they are simply stuck and need to break out of their analysis paralysis. They will also follow the Agile Modeling practice Create Several Models in Parallel so that it is easy for them to iterate back and forth among artifacts. Instead of holding a use-case modeling session, an agile modeler will focus on requirements modeling, or even just modeling, and work on use cases, business rules, change cases, and whatever other artifact is required to get the job done. The advantage of these practices is that the right model is used for the task at hand.

Agile architects also follow the practice Model in Small Increments, modeling just enough to fulfill the purpose at hand and then moving on to the next task. They don't try to create complete models; instead they create models that are just good enough. When they find that their models are not sufficient, they work on them some more. The advantage of this approach is that they evolve their models incrementally over time, effectively taking a just-in-time (JIT) approach that enables them to get the models in the hands of their customers as quickly as possible.

On the preceding advice, some readers may say to themselves "All this sounds great, particularly for a programmer, but architecture is different. It's more complex. It's more important. It requires significant modeling up front to get it right." Aaarrrrggghhh! That's old-style thinking. Agile architects can work in an iterative and incremental manner if they so choose.

Roll up Your Sleeves

Fair or not, many application developers have little respect for IT professionals who do not write code. You may not agree with this, but that's the way it is and, frankly, this attitude is reasonable. Think back to all the "architects" you've met. We bet that the best ones always seemed to be willing and able to roll up their sleeves and get involved with hard-core software development when needed. However, this wasn't their only skill. They were also very good at abstraction, at thinking through both logical and physical architecture issues.

Although an important part of an architect's job is modeling and documentation, that should not be their primary focus. Supporting the architecture within your project team should be the primary focus, particularly coaching developers in the architecture and architecture skills. The best way to do this is to get actively involved in development, to work with developers to help them understand the architecture, and to try it out in practice. This approach has several benefits:

• You quickly discover whether or not your ideas work and, if so, how well they work.

• You improve the chance that project teams understand the architecture because you're working with them face to face. As Figure 7-1 shows, this is a far more effective way to communicate.

• You gain experience in the tools and technologies that the project team works with, as well as the business domain itself, improving your own understanding of what it is that you're architecting.

• You obtain concrete feedback that you can then act upon to improve the architecture, enabling it to evolve over time to meet the actual needs of your organization.

• You gain the respect of your primary customers, the developers, because they see that you're participating and not simply pontificating.

• You actively help to build software-based systems, which is the primary goal of IT professionals.

• You can mentor the developers on the project teams in modeling and architecture, improving their skill sets.

• You provide clear benefit to application teams because you're helping them to fulfill their immediate goals, forsaking the "Do all this extra work because it's good for the company" attitude for a more attractive "Let me help you achieve your goals, and by doing so together we'll do something good for the company" attitude.

Build It Before You Talk About It

Agile architects will ensure that their technical ideas actually work by writing a small version of them to validate the idea. This is called a spike solution in eXtreme Programming (XP) (Jeffries, Anderson, and Hendrickson 2001) and a technical prototype or skeleton in the Unified Process (Ambler 2001b; Kruchten 2000). The idea is that you write just enough code to verify that that what you think will work actually does so. This helps to reduce technical risk because you're making technology decisions based on known facts instead of good guesses.

Look at the Whole Picture

Agile architects believe in the principle Multiple Models and thus strive to look at the whole picture. They don't just focus on data models, or object/component models, or business models, or whatever type of model might tickle their fancy. Instead they strive to model from several points of view so that their understanding and description of the architecture are more robust.

Why several views? First, architecture has several audiences the business community, application developers, database administrators (DBAs), network professionals, and so on each of whom has different priorities. Second, each type of model has its strengths and weaknesses, and no single view is sufficient because architecture is such a complex issue.

The concept that you require multiple views to sufficiently model your architecture isn't new. Kruchten (1995) suggests a five-view approach for software architecture and the Zachman Framework (described in Chapter 5) suggests thirty views for architecture in its entirety. Looking at the whole picture is the norm, not the exception.

Make Your Architecture Attractive to Your Customers

Agile architects realize that they need to make their work, including their services, attractive to their customers (developers and business stakeholders). If your customers perceive that you have value to add and that your architecture efforts will aid them in their jobs, they are much more likely to work with you. If, on the other hand, they think you're wasting their time, they won't work with you. Rather, they'll find ways to avoid you, to cancel or postpone meetings with you, or to find ways around you.