Recent trends in IT such as service-oriented architecture (SOA) and Web sevices, in conjunction with the still-increasing popularity of the .NET framework, put Microsoft's BizTalk Server in the center of attention for CIOs, CTOs, architects, and enterprise developers. Apparently everyone who is involved with the Microsoft platform now wants to implement BizTalk. Frequently we see that BizTalk is not implemented in areas where the benefits of the technology can be maximized. This leads to disappointment about the value of BizTalk, even though the problem is in the application of the technology instead of in the technology itself. In this article I will point out where, how, and when the third generation of BizTalk Server can provide real business value.

BizTalk Server Is Hot
In March 2005 BizTalk Server (BTS) reached an implementation base of 4,000 organizations. Microsoft states that these 4,000 implementations in four years make BTS the fastest-growing integration server on the market. Ever since it was first released, BTS has held a firm spot in the upper right quadrant of Gartner's magic quadrants for application integration and orchestration tools.

It's no wonder BizTalk is the center of attention for anyone who has a Microsoft infrastructure or who develops, designs, or architects Microsoft-based solutions. However to fully grasp the benefits of BizTalk Server, we should know where to successfully apply BizTalk Server technology.

A Brief History of BizTalk Server
To fully understand what BizTalk is and what it can do for you and your company, we should delve into the history of the product.

The first version of BizTalk, BTS 2000, was the result of two separate server products on which Microsoft development teams were working. On one side was the development of the messaging infrastructure and the BizTalk Framework (a.k.a. BTF, a SOAP 1.1 extension and XML framework aimed at integrating e-commerce applications), and on the other side there was the development of an extension to COM+ called COM+ Scheduler, which we now know as the Orchestration Engine. Nine months before BTS 2000's shipment in December 2000, Microsoft decided to merge both development teams in order to create one single solution for application integration and XML messaging.

Fewer than two years later Microsoft released the next version of BTS, named BTS 2002. This version contained a few improvements over the BTS 2000 version, and was generally more for administrators than for developers and end users. Additionally BTS 2002 offered some new functionality such as an HTTP receive function and increased Web service support.

Then, in 2004 (as the name suggests), BizTalk Server 2004 (formerly code-named Jupiter, which Steve Ballmer affectionately termed "BizTalk on steroids") was released. BTS 2004 is the first version that is fully based on the .NET framework, and which is written in fully managed code. The differences between it and the 2002 version are tremendous. Any BTS 2000 developer could learn to operate the BTS 2002 version within a day, but the BTS 2004 version is a different story. Development tools are now integrated in Visual Studio.NET, thereby perhaps adhering less strongly to the principle "code less, configure more" that was used throughout the BTS 2000 and BTS 2002 products.

In today's version, we can still see the two pillars of the product: messaging and orchestration. However a big difference with the BTS 2000 and 2002 versions is that by default, orchestration is used within the messaging tasks, even if the messaging task is straightforward and does not need the advanced options of orchestration. There is a way to work around this, but it is not as straightforward as using an orchestration for this task.

The Road to Choosing BizTalk Server
The key to assessing whether implementing a BizTalk-based solution will help your company is to look at it from an architectural perspective. At Capgemini we have developed the Integrated Architecture Framework (IAF) that defines architecture by means of contextual, conceptual, logical, and physical models, which progressively analyze an architectural need and refine a solution.

The architectural levels of the IAF are:

• Contextual: answers the "where" question. Delivers contextual information and key principles that define the architecture. Focuses on the company and its environment.
• Conceptual: answers the "what" question. Defines the architecture on a high abstraction level. Focuses on which business problem the solution/architecture should solve.
• Logical: answers the "how" question. Defines what services are needed to implement the desired architecture. Focuses on the solution for the problem stated at the conceptual level.
• Physical: answers the "with what" question. Defines the products and technologies with which the solution can be realized.

What we often see is companies deciding to implement BizTalk regardless of whether analysis on the upper levels justifies this implementation. The right order to choose any technology at the physical level is to progressively analyze all levels, beginning with the contextual level. We must first understand the problem before we supply a solution. Now that we have our analytical framework, let's see how we can apply it to BizTalk.

Where
The .NET framework has come a long way since it was first introduced about five years ago. On the eve of the launch of the .NET framework version 2.0, even the open source community has embraced the (unofficial) .NET framework, called Mono. Even though .NET is now available for Linux and Unix, BizTalk is still seen as a product exclusively for the Microsoft/Intel platform. To a certain extent this makes sense, as BizTalk Server 2004 runs only on Windows Server, and relies heavily on Microsoft SQL Server for its internal databases. BizTalk offers great opportunities to connect to other platforms, particularly through the broad application of open standards such as BPEL, SOAP, WSDL, XSD, and HTTP to name a few. Also, there are many adapters available to connect to other platforms. The use of open standards and the broad availability of adapters make BizTalk a great player in heterogeneous, mixed Windows-Unix-Linux environments. However the question remains as to whether it is wise to implement BizTalk as the only Intel-based system in a Unix or Linux environment.

If the where question tends to exclude BizTalk as a serious option, then you must have very strong arguments on the what and how sections to ultimately justify the choice for BizTalk.

What
The what question focuses on the business problem that needs to be solved. It states the requirements for the solution. Typical business problems in these areas may be:

• "We need to shorten the time to market for new applications or automated support for business processes"
• "We want to automate the processing of claims"
• "We need to be able to exchange data with our trading partner"
• "We want to reduce operational costs"
• "We want to offer a new service to our customers"
  Also, business problems may already be stated in the form of an envisioned solution:
• "We need to implement an SOA to provide business agility"
• "We must use EAI tools to connect our Billing application to our Order application to streamline our procurement process"