BizTalk Server Architecture and considerations

I have just returned from a two week holiday (Como Italy) and I was just reviewing my blog and noticed that I haven’t done much posting lately. Well that is about to change and this will be first one of a number of things I would like to share with you regarding some opinions and views around BizTalk Server now in context of approach/business/architecture.

I will first mention that at Inter Access a lot of people and myself have put a lot of effort in an approach for middle sized companies to position BizTalk Server inside their IT landscape or offer a way of implementing integration solutions. The business cases here were whether BizTalk Server can fulfill a role in integration of divers systems like Line-Of-Business (SAP, Oracle eBusiness and J.D. Edwards) or can be placed in center of a service oriented architecture where Microsoft technology is leading. The approach involves a number of steps (activities) to be preformed to reach implementation of a solution or insights (Proof Of Concept) whether BizTalk fits inside the customers IT landscape. Starting point usually is architecture, followed by installation/configuration of BizTalk Server, development, test, acceptation and production environment, implementation, test and deployment. I note here situation is a green field, where customer has little or no knowledge what BizTalk Server is or can do, which is usually the situation I and my colleagues have experienced so far.

From business case a customer presents together with its requirements for a BizTalk implementation or Proof of Concept; architecture is one of the first thing one discusses with customer and colleagues. Therefore I am now going into BizTalk Architecture. As you might know BizTalk Server is based on a messaging sub system and it is capable of doing messaging and/or business process management through its orchestration engine, automated decision engine (which is Business Rules Engine) and business activity monitoring. Below is a picture which outlines some components that can be found inside BizTalk related to other products of Microsoft like SQL Server 2005 and Visual Studio 2005 and roles involved.

















These products/roles are necessary to install BizTalk and develop solutions with it. BizTalk Server can be installed on one single machine and this kind of installation is preferable only to setup development environments. Visual Studio 2005 (Professional or Team System Foundation) needs to be installed first before BizTalk, so templates for creating pipelines, orchestration, schema’s and maps are available. But what kind of installations would one choose and which editions of BizTalk Server. This depends on the needs (requirements) from the customer. High availability, performance, scalability, number of applications and fail-over. For scaling and fail-over there are some considerations to made in number of servers (CPU). For each server whether in passive or active mode a license has to be purchased. And to have scaling for redundancy or fail-over (availability) or just having more performance, the enterprise edition is the only one suited and comes with a cost of $ 35000 per license. So there are some considerable costs involved having this kind of architecture implemented.

I recommend reading the FAQ at pricing and licensing of BizTalk Server. This also account for number of applications; an application is a logical grouping of all the BizTalk Server design-time artifacts (schemas, maps, pipelines, orchestrations), messaging components (receive ports, receive locations, send ports) and other related items, such as policies that comprise an integrated business process. BizTalk Server applications simplify the deployment and management of BizTalk Server–based solutions.

Other things to consider is which adapters are going to used, because there are difference between adapters (state vs. stateless i.e. persisted in BizTalk or not). Depending on functionality of adapters and scenario’s like high availability clustering plays an important role. One should consider setting up a dedicated SQL Server cluster and active/active cluster of BizTalk (meaning at least two or more active BizTalk Instances; host instances do not need to be clustered). More on clustering and availability can be found at tech net site, which is a great resource for information about clustering and so on. Also MSDN site is a great resource concerning subject high availability.

The number of customers worldwide using BizTalk Server is now probably over 7000 and growing. BizTalk Server 2006 R2 has a lot of capabilities and is not limited to messaging or support for business processes only, it now also enables SO(A) and brings more interoperability by supporting native EDI and RFID.

Future will bring us a new update of BizTalk Server 2006 called R3 in 2009 and it will not bear anything concerning Oslo. That will probably in the release after R3, so R3 will be release number 6. It has been announced this month by Steve Martin. I know this is a high overview of BizTalk in context of some possible business cases, but more in depth knowledge can only be achieved by working with BizTalk (experience), reading books, articles, blogs and whitepapers. A lot can be found at Microsoft BizTalk Server site.

Technorati:

Labels: ,