Deciding upon your architecture strategy

Once the core requirements are set forth, we as architects can begin to craft the major patterns that make up the solution architecture. It would be a grave mistake to jump directly from requirements gathering to a product selection. You would never say "BizTalk is the choice for all our solutions", unless you were clinically insane or ate paint chips as a child. Likewise, it would be foolish to jump immediately to a custom solution unless you had evaluated and eliminated packaged applications as a viable choice. Your architecture strategy should be driven by a full assessment of the architecture quality attributes required by your solution.

Turning requirements into patterns is beyond the scope of this book. That said, there are key aspects you need to decide upon before choosing a particular product for implementation. These areas of focus may include:

• How is data shared? In real time or via batch processing? Is data copied between systems or should we use a shared database?

• Does the system do most work synchronously or asynchronously?

• How do users interact with the system? Via services, mobile devices, command line?

• Is a centralized workflow needed to span the applications that comprise the system, or is distributed logic with queue-based transport the best choice?

• Should the application be deployed in one location, multiple locations, or in the cloud?

• Does the solution require a single security domain or is identity federation needed?

• What types of service level agreements (SLAs) are expected by the client and can I capture relevant measurement data?

The framework described next can help you capture the data points necessary to answer these questions and choose the right product to solve your business problem.