Applied Architecture Patterns on the Microsoft Platform

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.

The need for a decision framework

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.

Sources of input to the framework

Where do we get the data points necessary to make informed architectural decisions? There are four key sources that will shape our understanding of the business problem: functional requirements, non-functional requirements, derived requirements, and organizational direction.

Functional requirements

The functional requirements of a solution dictate what the resulting system should be able to do and include scenarios that summarize the user's expected experience with the system. Functional requirements could address the type of data entities the system interacts with, how the system behaves when a user needs to invoke a particular calculation, or the order of steps to complete a business process. Functional requirements are typically gathered by a business analyst and are crucial in determining how a system should be architected. A software solution is worthless if it is architected beautifully but does not meet the business need. Staying focused on our client needs will ensure that we build a practical and architecturally responsible solution.

In order to ensure that our functional requirements help and do not hurt our effort to architect a solution, we must remain diligent and not allow system requirements to masquerade as business requirements. For instance, if we see a business requirement that says that customer profile information from System A should be copied via file transfer every night to System B, then that should raise a red flag. That business requirement is dictating system design and does not answer what the business need actually is. The proper business requirement would be "The system shall enable users of System B to view up-to-date customer information originating from System A". As architects, we can choose multiple implementation solutions (for example: shared database, data transfer, real time lookups) that can both satisfy that requirement and fit into the overall design patterns we have laid out for the project. While there may be relevant reasons for technical requirements (for example, security constraints) to get included as functional requirements, often these technical requirements are better stated as non-functional requirements.

Non-functional requirements

Wikipedia describes non-functional requirements in this way:

A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.

http://en.wikipedia.org/wiki/Non-functional_requirements as on 10/2009.

So unlike functional requirements, which dictate system behavior, non-functional requirements stay focused on how the system needs to operate. There are multiple dimensions to look at when evaluating system operations including maintainability, security, compliance, availability, and exception management. A business or system analyst typically uses a pre-defined list of questions to interview stakeholders and identify non-functional requirements. Questions such as "How many users will the system support?", "What is the sensitivity of the data stored by the system?", "What are the regular hours of operation for the system?", "What is the acceptable latency of a user request?", and "What are the disaster recovery expectations?", will all provide insight into how to best architect our solution. It should be noted, however, that it is often the responsibility of the analyst to translate the sometimes technical, non-functional requirements into more business-relevant questions. For instance, I would not ask my client to spell out their explicit disaster recovery needs (for example recovery point objective, recovery time objective, site configurations), but rather, I would focus on questions addressing business continuity and backup procedures and extract the disaster recovery needs from their answers.

Derived requirements

We sometimes forget about the requirements that are not explicitly stated but can be uncovered through the functional and non-functional requirements. Derived requirements are implied requirements and do not come directly from our users. These are the things that go unstated (or even forgotten about), yet still belong in the registry of requirements for the solution. For instance, we may receive functional requirements that state a need to capture key data points and progress indicators during each stage of a long-running workflow process. While no reporting interface was requested by the users, we realize after reading this requirement that the users will need some way to visualize the progress of a given workflow and thus we see a derived requirement for a report. Or we have a business requirement dictating that the solution run on mobile devices but no indication of the required phone platforms, so we may derive the platform requirement based on the types of phones issued by our company. Once we identify the derived requirements, we can assess them with appropriate stakeholders and use them as yet another input to our decision making.

Organization direction

Last, but not least, we need to take broader organizational goals into account when capturing solution attributes that drive architecture. Project architecture decisions should not be made in a vacuum. While I may be able to flip a coin to decide between two perfectly viable ways to expose a web service interface for a given project, I should always be considering enterprise standards and practices when making my selections.

For instance, you may work for a company which has a strict "build instead of buy" strategy for software because of the high caliber of on-staff developers and a consistent need to deeply customize any commercial product. If that is the case, I may have a soft requirement to choose the framework technology over the more rigid commercial product.

Solution decisions also must take into account the short term and long term investments of an organization. Am I basing my solution on a technology that is under consideration for deprecation? Do we have the staff on hand with expertise in a particular product? These are valid considerations that can sway us from a seemingly ideal technology to an alternate choice.

Framework dimensions

Our evaluation criteria have been segmented into four central categories:

1. Solution design: This area focuses on dimensions that shape the broad design patterns that make up our solution.
2. Solution development: This topic addresses what it will take to construct the solution.
3. Solution operations: Here we highlight factors that influence how the solution will be maintained after it has been built.

4. Organizational considerations: These are facets of the solution that take enterprise standards and organization direction into account.

Each category contains a set of criteria along with a description of what those criteria help identify.

Solution design aspects

In this section, we look at characteristics relevant to the overarching design of a solution. Once again, this list isn't exhaustive but it should provide you with a framework for thinking and steer you towards a particular implementation technology.

These data integration considerations touch upon a variety of needs in data sharing scenarios including how you receive data, how much of it you process, and what quality assurances are necessary.

Software criteria	Description
Data integration considerations
Supports high volumes of data	Can a heavy throughput of data reliably flow through the software? While this characteristic is often dependent on other criteria mentioned below (for example: load balancing, latency), it should be a known aspect of any software solution. "High volume" may also be a subjective description. In some organizations, a high volume of data is thousands of records per day, whereas other organizations expect thousands of records per minute.
Handles large individual data sets	The raw size of a data set can greatly influence which software solution you select. Some products are tuned to process small data blocks: while others hungrily tackle megabytes, gigabytes, and terabytes of data all at once. If a particular software package is a perfect match for a solution except for its inability to process thousands of records at once, then maybe we can revisit the data processing requirements and bite off smaller chunks of data.
Offers guaranteed, at-least-once delivery	Reliable delivery is frequently a requirement of messaging solutions, but sometimes, this is a nice-to-have instead of must-have. If a particular piece of data does not reach a destination, can it be sent again from the source? For instance, few request/response query operations require guaranteed delivery since transmission failures can be instantly retried. Asynchronous operations are more directly associated with guaranteed delivery. Also, guaranteeing once-only delivery is something that has to be explicitly designed for. While some tools do support this, this is also where we can architect an idempotent interface where we can send data over and over again, without negatively impacting the data context.
Able to access a wide variety of data repositories	A thorough analysis of the data requirements will surface the range of data sources that our solution needs to leverage. Our chosen software platform should be able to easily interact with the full spectrum of data sources that make up our solution architecture.
Able to access a wide variety of target system APIs	Much like the preceding criteria, we need to uncover which systems we need to interact with and determine whether a given software product is capable of consuming the interface offered by the dependent system. This could be a web service interface, native interface, or a protocol interface such as MSMQ.
Works with batches of data	We looked at large data sets and this criterion is an extension of that. Regardless of the batch size, we need to know if a particular software platform can easily unpack a collection of data records and process them individually. Sometimes, records are batched out of convenience to reduce network traffic and sometimes they are batched because the records are all part of a related transaction. Ideally, our software platform can treat a batch of data differently depending on this distinction.
Accepts real-time data input	The timeliness of data processing is a foundational aspect of most solutions. If we are building an application that demands a real-time (that is, not batch) interface, then we have clear choices as to which type of product to leverage.
Offers data quality features (de-duplication, format standardization)	When sharing data between systems, we may need to apply a series of data quality rules that cleanse and improve the integrity of the data. This could involve removing incomplete data, eliminating duplicate records, enriching the data with information from external sources, and standardizing data field formats such as phone number.

Security is often one of those things that we cannot compromise during application design. We may have to comply not only with organizational standards, but those of regulatory bodies. Here are some criteria that touch on user profiles, data in transit, and data at rest.

Software criteria	Description
Security considerations
Enables enterprise-wide and cross-organization users to access the application	It is important to know if the product can support enterprise directories for authentication and authorization so that we can establish reusable security groups and wide access.
Includes Single Sign-On capabilities	If your solution demands access to systems and repositories that span security domains, then having an SSO product available will be a lifesaver. A strong SSO product will enable you to securely map credentials from one domain to another and seamlessly access cross-domain resources.
Offers range of authentication mechanisms to invoke operations	This applies to items at an API level or even access to the application itself. If we need to be able to authenticate users against a default Windows domain, or also need alternate ways to prove identity (for example: certificates, HTTP basic authentication) then we have to choose a product with this capability baked in.
Provides authorization controls to invoke operations	Ideally, there is at least a coarse set of knobs that we can fiddle with in a software package, which allow us to restrict capabilities by the role of the user. Some software packages may allow granular access only through customization.
Provides authentication and authorization options for securing administrative aspects of application	Depending on the scope of your solution, you may need to provision administrative functions to distinct sets of users. For instance, you might have one set of users who can administer the entire application, while others can only modify specific settings. If your solution demands this, you will need to consider this capability in the available software packages.
Has compartmentalized components with independent security boundaries	One way to reduce the attack surface of a solution is to partition not only the application tiers, but also the modules within a given tier. A component that requires elevated permissions could be isolated on one server while other components running with least privilege can execute on additional servers.
Enables secure storage of configuration or reference values	When we extract volatile data values from code and store them in external configuration repositories, we make our code easier to maintain. However, these pieces of data may contain sensitive information such as passwords and connection strings. Whether embedded in the code or stored in a configuration repository, this data should be encrypted or isolated from prying eyes.

The project's need for exception handling can often be evaluated late in a delivery cycle, which is unfortunate. This is one of those areas to ask our clients about early on and get an understanding of the business need when system, data, or logical errors arise. Based on the expected types and volume of errors, we may lean one way or another on which product to leverage.

Software criteria	Description
Error handling considerations
Failures within the system are captured in predictable way	Even the best of us write code that fails. What we hope to have is a software platform that enables a graceful handling of exceptions occurring in native components, custom components or infrastructure. If the product relies on a database to operate, what happens if the database temporarily goes offline? Or, what if you deploy custom code to the application and an uncaught exception flows up to the application? Knowing how a product handles failure goes a long way in understanding how to build for exceptions and prepare future solution administrators.
There are limited single points of failure	We all hope to build solutions that do not have any one component that can bring the entire system down. When we look at underlying platform products, we need to understand where things can go wrong and which components can or cannot survive a failure.
Failures in dependent systems are handled consistently	When we built systems that rely on other systems, we must prepare for the event when those dependent systems become unavailable. How does a particular software product resolve downstream failures?
Includes facilities to monitor the system and configure alerts	If a product does not offer a management dashboard itself, hopefully it should minimally provide an instrumentation layer that enterprise monitoring tools can tap into so as to actively track the health of the application.

There are always a few uncategorized design aspects that touch upon how a solution can be designed to be maintainable and best leverage existing enterprise investments. Here we have a few items that address loose coupling of components, how operations can execute, and establishing transactions across system boundaries.

Software criteria	Description
General design considerations
Includes a modular set of components with a clear separation of concerns	Software products are at their best when they have clearly defined modules that work both independently and seamlessly with each other. When looking at your solution requirements, you may see aspects that are a perfect match for components of one product while other aspects are ideal for another. If those products are built well, then leveraging the best of each should be possible. Having modular components also means that changes can be made to one component without being forced to deploy or test all of the other ones.
Has functional flexibility and can be built for change	Sometimes a solution satisfies a very fixed need with static business rules and firm interfaces. However, that scenario appears to be an exception rather than a rule. If our solution requirements outline a very dynamic business space where interfaces may undergo change or business logic is susceptible to update, then we need a software product that can accommodate such demands.
Leverages asynchronous model for processing	Asynchronous processing allows us to execute operations without forcing the initiator to wait for a response. This is valuable for long-running processes, activities that can be handled at a later time, or broadcasting data to an unknown number of interested parties.
Is capable of enlisting both local and distributed transactions	If our solution requirements call for us to synchronize the update to multiple repositories then we have to make sure our software is capable of participating in transactions that potentially span application boundaries.

Solution delivery aspects

The big picture solution aspects cannot be the sole factor in choosing a particular implementation technology. We must also seriously consider how well the technology aids in the rapid and successful implementation of our architecture blueprint. A product that looks perfect from a design perspective may introduce an unnecessary burden on the implementation team.

First off, we should look at our development resources and consider if the technology at hand is something that existing .NET or SQL Server developers can quickly adopt, and what sort of physical environments are needed to perform development. While BizTalk Server is a mature product, it can still be difficult to find top-notch talent in the open market. For new products like Windows Server AppFabric and Windows Azure, there is an obvious gap in the marketplace until these offerings become more commonplace and skills can be developed. Consider whether you need, product expertise or have the internal skill set available to grow the expertise in house.

Software criteria	Description
Resource considerations
Skilled developers can be acquired for this technology	This criterion relates to both in-house developers and contract developers. Do we have the resources within the organization and are they even available to work on this solution? If the answer to either question is no, then how easily can we get external expertise?
If a new technology for the organization, the skill can be picked up by existing developers	Many of the products in Microsoft's application platform have similar development paradigms. Someone with expertise in the .NET Framework could quickly understand the development process for products like Windows Communication Foundation or StreamInsight.
Solution components can be run on a standard developer workstation	Most software can be installed on a typical developer computer but we should know early on if we require centralized server software, virtual machines, or 64-bit hardware.

Once we evaluate the compatibility of products with our resource demands, we can look at how well a technology helps us actually build the solution we want. This includes topics such as the richness of the development toolset, maturity of the community ecosystem, and the existence of solid test and automation capabilities.

Software criteria	Description
Construction considerations
Robust set of tools / IDEs available to construct the solution	New technologies typically have development and administrative tooling that is fairly basic. It seems that the priority of the software vendor is on the underlying component maturity and tooling is not a primary concern on the initial release. That said, the proposed solution may not require significant coding and thus advanced tooling is ideal, but not required.
Rich ecosystem of plug-ins, community code, tutorials and blogs to help developers	When building solutions on a given product we always hope to follow best practices and leverage lessons learned by others. This is where established, mature technologies have advantages over newer, less investigated ones.
Written in an expressive language that accomplishes tasks in limited lines of code	Ideally, developers do not have to spend a majority of time writing excessive lines of code to complete simple tasks.
Integrates with a variety of source control systems	A software solution can be comprised of code, configuration files, scripts, images, and a host of other artifacts. We should understand how to collect all of the solution artifacts and centrally manage them in a durable source control system.
Allows developers to build and execute thorough unit tests	The cost of testing and bug fixes goes up as a project progresses towards completion. A software product should enable straightforward unit testing of each component.
Can be set up to run in an automated build environment	A solution may be made up of a number of software packages and components, so automating the regular solution built during construction can free up resources to focus on more strategic tasks.

Solution operation aspects

Even after we have satisfied our design and implementation needs, we absolutely must consider the operational aspects of the proposed solution. Although the project delivery team inevitably moves on to other work after a successful deployment, the actual solution may remain in a production state for years on end. If we have a grand architecture that was constructed cleanly, but is an absolute nightmare to maintain, then we have not delivered a successful project. In fact, many of these operational concerns actually directly affect our original solution design. These factors, which are often gathered through the non-functional requirements, have a noticeable effect on the architecture of the system.

Performance considerations address various topics ranging from application business process performance to data volume and latency.

Software criteria	Description
Performance considerations
Key Performance Indicators (KPIs) can be captured and monitored	KPIs could relate to the business capabilities built into the application or KPIs could refer to the performance of the application itself. If the business client wants to monitor the efficiencies of their processes, then we will want to choose a product that lets us easily capture and modify key business metrics.
Can produce sub-second latency for both simple and complex request/reply operations	Latency requirements will factor into the overall design of the solution, but this also relates to the operations of the solution. Can performance be tuned in the production infrastructure?
Predictable behavior during both standard and non-standard volumes of data	Many integration solutions have to deal with spikes in data processing load at both regular and unexpected intervals. If this is possible in your environment, then you want to make sure that the software can gracefully handle floods of data without crashing.

The availability needs of the client have direct impacts on which product we should choose. How mission-critical is the application? Can we afford for the system to be down for a significant amount of time? What is the consequence if we lose some data when recovering the application? Honest answers to these questions, which typically mean fighting the urge to over-inflate the importance of a given application, will help us direct appropriate attention to availability attributes.

Software criteria	Description
Availability considerations
Natively includes load balancing capabilities	You may not need the software to contain its own load balancing mechanism if you have existing infrastructure to distribute work among machines. However, if you are dealing with a high volume environment with many long running processes, you may benefit from a technology that efficiently leverages the available resources across software nodes.
Can systematically fail over to other active servers	This also is a factor in solution design. While it may be quite useful to leverage a software platform that automatically switches execution to additional nodes when a given node fails, we may also want to define a stateless design. If we limit the state that each node must maintain, then we limit points of failure and can embrace automatic node switching.
Includes data backup routines	We may have to back up application data persisted in the software or back up the artifacts and metadata that comprise the software solution.
Support zero message loss in the product or through storage mirroring	If a software product stores application data (even while in transit), then there may be a business requirement to avoid any data loss in the event of system failure. Accomplishing this can be challenging, so we need to determine the real need and see if the software platform can accommodate this.

The day-in-the-life maintenance of an application is not the most exciting thing to mull over during project planning, but paying attention to this aspect is the greatest gift you can give to a system administrator. What are some of the general things you can do to make the maintenance of this application as straightforward as possible? We must consider the tools we provide, the way we have separated our components, and the means for making incremental changes to the application over time.

Software criteria	Description
General operation considerations
Rich set of support tools and interfaces	Strong administrative tools could be graphical in nature or through a well-defined programmatic interface. We may not want to teach administrators a brand new tool, but rather leverage existing skill sets or enterprise configuration tools. This would factor in to our product choice.
Clear strategy for versioning system components	If a product is built with a clear separation of concerns, it will be easier to make isolated changes. That said, if a solution is expected to undergo regular changes then we have to fully grasp the ways to consistently deploy new versions.
Defined extensibility points	Extensibility can be built both into the software itself and into the system built on top of the software.
Built-in instrumentation and tracing	Many organizations have existing application monitoring tools and it is important to find out if a particular software package can feed its data and system events into such tools.

Organizational aspects

You would think that after you took your project's design, development, and operations into account you have done proper due-diligence prior to architecting a solution. However, a good solutions architect always keeps an eye on organization strategy to make sure that what they are proposing for an isolated solution is in line with the broad vision of the company.

Here are a few things to consider when switching perspective from a project-centric viewpoint to an enterprise one.

Software criteria	Description
Organization considerations
Is sufficient for both temporary solutions and long-lived solutions	Sometimes we build solutions that are meant to temporarily solve a given problem. Maybe the organization is planning a massive system upgrade but needs an intermediate solution to a particular pain point. Conversely, we may be designing a solution that is expected to remain in operation for 4 to 6 years. If we look at the planned lifespan of the solution, this can help us decide which product offers the lowest total cost of ownership over that duration.
Includes support from Microsoft for solutions implemented with product	Product support is a critical component of enterprise systems. When you build a solution on top of a packaged application, you often get more vendor support than when you build a solution on a base framework.
Leverages existing software investments within the organization	These existing investments could be in employees or other software packages. Does the product use an underlying database technology already deployed at the organization? Or, is it an additional module of a product already in heavy use?
Limited impact on budget as introduction of this technology can be built upon existing environments	This relates to the prior criteria. The cost of software that underlies a solution is frequently a factor in product selection and ideally we can share existing infrastructure.
Complies with "buy vs. build" strategy of the organization	If you have an expert staff of developers on site and frequently find yourself customizing packaged products, then your organization may prefer building solutions vs. restricting themselves to packaged products. On the other hand, if an organization prefers to fit their needs into the capabilities of package applications so as to reduce ownership cost and accelerate development, then a heavier evaluation weighting should go to products with fixed boundaries and limited customization options.
Matches the risk tolerance of the organization	Some companies love being early adopters of technology and getting the chance to take advantage of the latest products and capabilities. For such companies, the risks of deploying new technologies are outweighed by the business benefits those technologies offer. However, other companies have a "service pack 1" mentality where only mature products are introduced into the organization landscape.
Provides sufficient speed to market for new solutions	We cannot make a blanket statement that building solutions with "Product X" is faster than building with "Product Y." This all depends on the solution. That said, we want to evaluate our candidate software choices by looking at which software allows us to build (and change!) a given solution as quickly as possible.

Applying the framework

So what do we do with all this information? In each of the "pattern chapters" of this book you will find us using this framework to evaluate the use case at hand and proposing viable candidate architectures. We will have multiple candidate architectures for each scenario and based on which underlying product is the best fit, go down the path of explaining that specific solution.

So how do we determine the best fit? As we evaluate each candidate architecture, we'll be considering the preceding questions and determining if the product that underlies our solution meets the majority of the criteria for the use case. Using the next representation, we'll grade each candidate architecture in the four major decision framework categories. The architecture that is most compatible with the use case objectives will win.

Design

Delivery

Operations

Organization

Filter reviews by

All

Amazon verified reviews

T. A. Nov 10, 2010

I believe any self-respecting architect in the application platform space needs to read that book. The real value of the book to me was how it presents a way of applying the Microsoft application platform technology stack to the decision framework.The content is not available on any other book that cover the app plat technology stack. By taking an approach of `given this scenario with these real life considerations this is how I would you build the solution' it shows the author's thought process which sometimes is the hardest part of a project.

Amazon Verified review

Rohit Sharma Dec 29, 2010

What can I say about person like Stephen W Thomas, he is already a well known tech guru and this book is a good work done by all these well known tech experts.The first chapter talks about the decision framework for solution which describes the factor one need to think about while creating a solution and the next few chapters are premier on technologies like WCF,WF,AppFabric,BizTalk,SSIS,SSSB and Windows Azure.The think that I most like about this book is that it contains useful patterns and the authors have done a very good job of evaluating different technologies using the decision framework for implementing these, which give you a clear idea which technology to use when. Another plus point about this book is that you get the chance to implement these patterns using these different technologies and I prefer to do hands-on instead of just reading.

B. Eaton May 09, 2012

As a developer who has become an architect-by-accident, I picked this up to make sure my knowledge of Microsoft technologies was up-to-date and complete (which BizTalk aside it was). But it's also full of useful guidance about the architectural process which is illustrated with some very well thought-out case studies.It has certainly helped me to re-think my approach to using the Microsoft stack as well as evaluating my rationale for selecting technologies and architectures. A thoroughly informative read.

James McKee Dec 10, 2010

When I found out that Stephen Thomas was writing a book about the upcoming technologies with some of the experts in these technologies, I immediately thought to myself I need to read this book. So after getting my hands on a copy of Applied Architecture Patterns on the Microsoft Platform I found myself with both some interesting reading material as well as a crash course on some of the architectural designs for upcoming and current Microsoft technology.To start off I make my living as a software consultant and I pride myself on my knowledge of many areas of technology, currently in the Microsoft stack. Because of this I think my view of the book has been slightly skewed, to further complicate things I also view myself as an early adopter oftentimes tinkering with the latest CTP of the developer tools for various new products.The book starts by going across the architectural overview that attempts to set down the parameters for what the rest of the book is built against. This section of the book is reserved for the youngest among the developer an architect crowd, and I would imagine would be the most skipped out of all the chapters.The next section of the book deals with primers for each of the different technologies that they are working with including windows communication foundation and workflow foundation, app fabric, biz talk, SQL server (SSIS and SSSB) , and windows azure. These particular chapters I found to be of little help, simply because I keep up with many of the technologies. However if you are walking into a situation where you know nothing about these technologies, then you might find the primer chapters useful.The next section of the book consists of problems that were picked so that they would meet the needs of the examples. But while this is not an uncommon practice in the realm of technology education literature, it is slightly frustrating and let me to wonder exactly how well these technologies would perform under real-world circumstances. The most informative part of the sections includes the side by side comparison of multiple solutions and the bare information provided to develop quick skills with the particular technologies. In many cases I think the book would be useful in the instance that you needed to have a crash course on one of the technologies that was presented.On the other hand there are some chapters in the book that deal with very specific instances of solving real issues that occur when working with the toolset. At least one of the chapters in the book deals specifically with an issue that I have encountered before and stepping through the pages for that particular chapter were in many ways like reliving that assignment complete with the solution.But in the end I don't think most people will read the book the same way I did from cover to cover, and it may not be a great reference for someone looking to update their skills in a particular area. However if you have been out of touch with the latest offerings from the Microsoft stack for more than two years you may find this book extremely helpful as it gives step by step instructions that will act as an introduction too much broader discussions.In the end the book is a blend of content ranging from very specific instances that function more like a recipe than a tutorial to broad overviews of the technology. I think that there is a little something for all architects and developers to pull out from this book, and the format allows you to pull out a specific portion of knowledge and digest it without having to go through the entire book. In this way it represents more of a collection of loosely connected detailed articles than a tome of technical knowledge. In the end I was not upset with the amount of time spent reading the materials. I think much of the information that I gained I will be able to put to good use.

Petitebean Feb 04, 2011

This book covers different architectural perspectives, and provides a nice overview on the latest shipping technologies on the Microsoft enterprise platform including WCF/WF 4.0, Windows Server AppFabric (which is one of the most interesting things on the Microsoft platform today IMO, including the Windows Azure AppFabric), BizTalk Server, SQL Server and StreamInsight, and Windows Azure platform. It then goes into more detail around various types of application and data integration patterns (and at different levels; not just messaging patterns), and discusses the trade-offs and best practices for the multiple solutions that can be used to apply each pattern, and scenarios.It's not another one of those "what's possible with cloud computing" books. The authors took a pragmatic approach to identify and describe today's real-world architectural issues and patterns, from simple workflows, the requisite pub-sub, content-based routing, message broadcasting, etc., to complex event processing, master data synchronization, handling large data and burst Web traffic; and provided architectural considerations (including on-premises and cloud-based models) and options on how these commonly encountered patterns can be implemented with the components of the Microsoft enterprise platform.

Applied Architecture Patterns on the Microsoft Platform: An in-depth scenario-driven approach to architecting systems using Microsoft technologies

What do you get with eBook?