Book Image

Applied Architecture Patterns on the Microsoft Platform

Book Image

Applied Architecture Patterns on the Microsoft Platform

Overview of this book

Every day, architects and developers are asked to solve specific business problems in the most efficient way possible using a broad range of technologies. Packed with real-world examples of how to use the latest Microsoft technologies, this book tackles over a dozen specific use case patterns and provides an applied implementation with supporting code downloads for every chapter. In this book, we guide you through thirteen architectural patterns and provide detailed code samples for the following technologies: Windows Server AppFabric, Windows Azure Platform AppFabric, SQL Server (including Integration Services, Service Broker, and StreamInsight), BizTalk Server, Windows Communication Foundation (WCF), and Windows Workflow Foundation (WF). This book brings together – and simplifies – the information and methodology you need to make the right architectural decisions and use a broad range of the Microsoft platform to meet your requirements. Throughout the book, we will follow a consistent architectural decision framework which considers key business, organizational, and technology factors. The book is broken up into four sections. First, we define the techniques and methodologies used to make architectural decisions throughout the book. In Part I, we provide a set of primers designed to get you up to speed with each of the technologies demonstrated in the book. Part II looks at messaging patterns and includes use cases which highlight content-based routing, workflow, publish/subscribe, and distributed messaging. Part III digs into data processing patterns and looks at bulk data processing, complex events, multi-master synchronization, and more. Finally, Part IV covers performance-related patterns including low latency, failover to the cloud, and reference data caching.
Table of Contents (26 chapters)
Applied Architecture Patterns on the Microsoft Platform
Credits
Foreword
About the Authors
About the Reviewer
Preface

Chapter 1. Solution Decision Framework

Decisions, decisions, decisions. Each and every day, architects and developers make choices, which range from where to store configuration data to whether their solution calls for real-time messaging or batch processing. Each selection brings with it a host of side effects that impact the solution's maintainability, security, performance, speed of development, and more.

Two significant aspects of any architecture decision are: what should be done and how should you do it. The focus of this chapter is to provide advice on the latter by outlining a thought process for making sound decisions. Do you need to deploy your servers globally or in one location? Should the solution employ an asynchronous communication pattern for data processing? These are just examples of solution aspects that result from an architectural analysis of the requirements. This chapter contains a framework to help you determine which architecture quality attributes you should evaluate for your solution. We will leverage this framework in subsequent chapters as we evaluate business problems and choose the Microsoft technology that best matches the requirements of the solution.

In this chapter you will learn the following:

  • The value of having a consistent, reusable decision framework

  • Where to find the input information for your decisions

  • How to organize your architectural assessment of the requirements

The need for a decision framework

There is no substitute for the hands-on experience of designing and building software solutions. The key is how you take what you have learned in each situation and apply these principles and lessons to subsequent projects. Recording and maturing a reusable set of decision criteria goes a long way towards establishing personal confidence in our architectural decisions. Each project should not be a blank slate. Rather, we should be leveraging our experiences and the experiences of others and reuse them so that we can surface key issues, prioritize our feature set, and establish which trade-offs we will need to make early on. While we cannot know every detail or requirement before starting to craft a solution, we must still make critical decisions that have significant impact on the direction of the solution architecture. This is all the more a reason to make consistent, well thought-out decisions.

There is nothing magical about a decision framework. In our case, the recommendation is to do the following:

  • Gather all the facts that you can. See the next section (Sources of Input to the Framework) for ideas on where to obtain the data points necessary to make informed decisions.

  • Look for the hard architectural decisions. What is the big picture? What are the critical aspects that we need to tackle right away? An example of this is determining whether or not your strategy is to copy data between systems, do real-time lookups, or leverage a shared data source. Broad data-sharing patterns shape how you build your system and this is an example of a weighty decision that impacts how we lay out the rest of the solution.

  • Capture and evaluate alternatives. It has been said that "if you only have one solution to a problem, then you are not thinking hard enough". Every significant decision point should have multiple possible alternatives that reflect the interests of the project or organization as a whole.

  • Weigh the strategic importance of feature requests. All desired solution capabilities are not created equal. If I work in an environment where we have limited in-house development resources and place a premium on system maintainability, then I will value products with standard support tools over products that have a more robust, but custom feature set. Amplify what the solution must do and avoid being distracted by "nice to have" capabilities.

The list of solution criteria we have in this chapter is by no means exhaustive. Instead, it is meant to provide a baseline for you to customize with your own experiences and organizational priorities. Following a framework strategy of "gather information, inspect for impact, assess alternatives, and weigh importance" will help you become successful regardless of how big or small your specific list of solution criteria is.