Note that business problems stated this way already hold an answer to the how question; we will describe this in the next section which discusses the logical level.

Since we are assessing BizTalk here, we should see if the problem stated matches up with the problems BizTalk aims to solve. BizTalk is a platform for:

• Application integration
• B2B messaging
• Business process automation

At the end of analyzing the conceptual level, we should have further narrowed the area into which BizTalk should fit. If the stated business problems are no where near the kind of problems stated here, then BizTalk might not be the right way to go. The conceptual phase sets the boundaries and constraints for the solution, which is outlined by answering the how question. Business value is determined at the conceptual level.

How
At the logical level, we often encounter popular, possibly hyped concepts such as SOA, Enterprise Service Bus (ESB), Business Process Management (BPM), and Enterprise Application Integration (EAI). BizTalk Server often gets associated with these concepts; therefore, it is tempting to already make the decision to choose BizTalk Server at this stage. This is the major pitfall for most failed BizTalk projects and implementations. To successfully solve a problem, you must understand the problem. To provide a solution, you must know how to provide this solution. This is why some implementations fail to meet the expectations from the business people. Thorough analysis of the solution is crucial, since BizTalk is very good at some tasks, average at others, and not suitable for some functions. It is still too early to choose BizTalk at this stage.

Key design decisions are made at the logical level. Some of the design decisions and constraints that are relevant to application integration, B2B messaging, and Business Process Automation solutions are:

• Are we going to need [XML] messaging?
• How are services or components going to interact? By method calls? By messages?
• Are there any long-running transactions?
• Is there end-user interaction?
• Will users perform tasks that require online, real-time processing?
• Is there any workflow involved?
• Are we working with sensitive information?

At this stage, you should get as much detail as possible on the solution design. The result of this analysis is the input for the next stage, where we decide whether or not to implement BizTalk.

With What
Eventually analysis of all other levels leads to the question: With what are we going to realize this solution? At the physical level, we should have a look at the functionality BizTalk has to offer and see how it fits into the architecture, requirements, and the solution we have analyzed so far. To provide a complete view, we should also assess available alternatives.

Arguably the best way to start describing BizTalk's capabilities is to point out what BizTalk Server is not:

• BizTalk is not an application server. In particular, functionality such as support for atomic transactions is hard, if not impossible to deliver with BizTalk.
• BizTalk is not Human Workflow. BizTalk's key focus is on what is called technical workflow, not on human interaction. Human Workflow is present in the 2004 version, but at a level that will not be sufficient for any sophisticated workflow system. Usually we see that a BizTalk add-on like K2.NET is used for the Human Workflow part in BizTalk implementations. (It is uncertain whether the Human Workflow Services (HWS) will still be present in the 2006 version of the product, since a lot of aspects of Human Workflow will be implemented in the Longhorn operating system.)
• BizTalk is not an application framework: BizTalk just gives you the tools to implement an application framework like a Service Oriented Development Architecture (SODA), or an Enterprise Service Bus (ESB) for instance. But it is not an application framework as such.
• BizTalk is not an ideal option for synchronous interaction. By nature BizTalk is a messaging engine that uses queues to process messages, and is optimized for asynchronous interaction. Synchronous processing through BizTalk is similar to chatting with e-mail; it is possible, but there are better ways to provide the same function.

Some of the core capabilities of BizTalk Server 2004 are:

• XML messaging through different open Internet standards
• Connectivity through third-party adapters
• Message transformation/mapping
• Message validation
• Business process orchestration
• Business rules repository and engine
• Secure and reliable messaging
• Long-running transactions
• Human Workflow Services for simple workflow tasks

This makes a BizTalk particularly good pick for application integration, B2B integration, and business process automation as we have seen.

At this point in the architecture study we are in a situation where we know the environment, we understand the business problem, and we know how we are going to realize the solution to this problem. Also, we know what BizTalk is good at and what it is not so good at. The decision of whether or not to implement BizTalk can be reached by using the decision tree in Figure 2.

The decision tree is primarily a quick help in the selection process for the right tool for your integration or process automation needs. It should not be considered a deterministic model to decide whether or not to use BizTalk. There is more to making the decision to implement BizTalk than merely looking at this decision tree, as we have seen. BizTalk Server should fit into the existing architecture, and a good cost-benefit analysis is the key to deciding the full business value of the solution.

Summary
BizTalk Server 2004 has gained its fair share of attention lately, and it has become the fastest-growing integration server on the market. This is not surprising since it offers rich functionality for integration and orchestration tasks. However, even if you already have a .NET environment, under certain circumstances there are other alternatives and options to consider. In this article I have presented an analytical framework to assess whether BizTalk Server 2004 is the right product for you, or whether you should consider alternatives. By applying this framework, and thus by bringing some common sense in selecting the right solution for a posed problem, we can prevent BizTalk from becoming too hot to handle.

• Figure 1