Preface by David Hill

There is an old joke, told amongst mischievous developers, that in order to be considered an architect you just need to answer every technical question with "it depends" – Q: What’s the best way to implement authentication and authorization in my solution? – A: It depends; Q: How should I implement my data access layer? – A: It depends; Q: Which technology should I use for my solution’s UI? – A: It depends. Q: How can I make my application scalable? – A: It depends. You get the general idea.

The truth is, of course, that it really does depend. Ultimately, every solution is different and there are many factors, both technical and non-technical, that can significantly affect the architecture and design of a solution at both the small and the large scales. The role of the developer and solution architect is to balance the (frequently contradictory) requirements and constraints imposed by the business, the end user, the organization’s IT environment and management infrastructure, the economic environment, and of course the technologies and tools that are used to build the solution.

And, to make life really interesting, these requirements and constraints are constantly evolving as new opportunities arise or as new demands are imposed on the system. Changes to business rules or the emergence of new business areas can affect both new and existing applications. Over time, users expect richer, more consistent and more highly integrated user experiences. New compliance requirements might emerge. Or new IT infrastructure technologies might appear that can reduce costs or improve availability or scalability. And, of course new technologies, frameworks, and tools are being released all the time with promises to reduce development costs, or to enable scenarios that were previously difficult to implement.

Clearly, making sense of all of this and at the same time delivering an effective solution on budget and to schedule is not an easy task. It requires that the developer or solution architect have to account for a whole host of competing and overlapping factors (some of which are non-technical) and strike a pragmatic balance between them all. Trying to account for too many factors can result in over-engineered, complex solutions that take a long time to build and nevertheless fail to deliver on promises of improved longevity or flexibility. On the other hand, consideration of too few factors can result in constrained, inflexible, and improvised solutions that are difficult to evolve or that do not scale well. In other words, developers and solution architects often have to walk the path between a "golden solution" on the one hand, and a "point-in-time solution" on the other.

This, to me, is what application architecture is all about—it’s about using today’s tools and technologies to create as much business value as possible whilst keeping one eye on the requirements and constraints imposed by the business today, and one eye looking to tomorrow to maximize ongoing value through scalability, flexibility and maintainability. A good understanding of architectural principles and patterns allows the developer or solution architect to understand and factor into the overall design process the important design issues that can have a big impact on the overall success of their solution. Armed with this knowledge, they can make more informed decisions, better balance competing or overlapping requirements and constraints, and make sure that the solution not only meets or exceeds its business goals but it does so in way that is cost effective and scalable, maintainable and flexible.

You’ll notice that I refer to both developers and solution architects. I believe that both can benefit greatly from a solid understanding of the architectural patterns and principles outlined in this guide. Some might argue that the implementation details are less important than the overall design. In my experience this is not the case. Small decisions accumulate over time. Implementation-level details can have a very large impact on the overall solution architecture and on its scalability, maintainability, and flexibility, so a solid understanding by both developers and solution architects is essential. In addition, a shared understanding leads to better communication between developers and architects, which is a good thing.

This guide aims to provide an overview of the application architecture and design principles and patterns that will help you make better decisions and build more successful solutions. The guide is structured in a way that allows you to read it from start to finish, or use as a reference resource so you can jump directly to the most relevant sections. The first half of the guide is focused on generally applicable architecture and design principles and apply to any type of solution. The last half is focused on common application types—such as Web applications, rich client application, or mobile applications—and describes the typical architecture and key design considerations for each. It’s likely that your particular solution won’t map directly to these, but they can serve to provide a baseline architecture that you can take and evolve for your particular situation. The guide provides advice on how to identify the key elements of your architecture so you can refine it over time.

There is a particular focus throughout the guide on developing solutions on the Microsoft platform with the .NET Framework so the guide contains references to articles and resources that provide details on relevant technologies and tools. You’ll find though that the underlying principles and patterns are generally applicable to any platform. It is also worth noting that the guide is not meant to be a complete and comprehensive reference to every aspect of application architecture and design—that would require either a much larger guide, or multiple volumes—so the guide aims to provide a pragmatic overview of the most important topics along with links to more detailed guidance or in-depth material.

The field of application architecture and design is dynamic and constantly evolving. The foundations on which successful solutions have been built in the past will continue to serve us well into the foreseeable future, but we should also expect that the pace of innovation, in both technologies and new design approaches, will not decrease. The Microsoft platform and the .NET Framework and the range of technologies and scenarios that they support are both deep and wide, and getting deeper and wider all the time. On the other hand, we don’t need to wait for what might be. We can build compelling valuable solutions right now, and hopefully this guide will help you do just that.

David Hill

patterns and practices

September 2009