EAI Light: Can Microsoft’s BizTalk Succeed Where Traditional EAI Fails?
The vision that spawned the Enterprise Application Integration (EAI) boom of the late ‘90s – disparate applications, all serving their specialized purpose, all working in perfect harmony – is still something to contemplate.
EAI Out of Favor
EAI seemed the perfect answer. But the problem, as customers and investors have learned, has to do with practicality. It is a cumbersome and frequently never-ending process to rearchitect and rebuild networks and applications to route transactions through another application layer. Alas, too many companies died upon the pyre of integration projects with armies of consultants and programmers presiding over the funeral.
What Is EAI-Light?
“Traditional” EAI is most certainly dead – but did the original integrated vision die alongside it? No, absolutely not. The vision remains – it’s the approach to achieving that vision that has changed. Enter initiatives like Microsoft’s BizTalk Server. The evolution of this product suite – BizTalk 2004 is on the way – is Microsoft’s attempt to define and capture a new, kinder and gentler EAI market. It’s called EAI-Light.
Any definition of EAI-Light must include the terms “easier,” “cheaper” and “safer” – and most importantly “shorter ROI.”
What Is BizTalk?
BizTalk Server is a set of interfaces and a server, bringing a number of Microsoft technologies under one umbrella and one moniker, enabling Microsoft to compete with the heavyweights in the integration space, primarily IBM. The BizTalk interfaces provide a front end for the purpose of tying together certain software applications and types of underlying data. A typical BizTalk project might be created in this manner:
After having created a Visual Studio project in Microsoft’s .NET suite, users would launch BizTalk’s interface and link to the Visual Studio project from BizTalk. At this stage, users might define schemas, usually by mapping data from a particular application into an XML format and importing that XML definition into BizTalk’s interface. A user might next define what BizTalk calls a “pipeline” to specify how BizTalk Server is going to send a communication to a destination. Finally, there is an assembly phase, which is somewhat analogous to a compiler of source code where all that a user has defined is tested and made ready for live use.
How Do I Use BizTalk?
BizTalk accomplishes a number of goals. Most importantly, it provides a centralized interface for integration processes. This makes large-scale integration projects more manageable, particularly between Microsoft applications. For example, it is very useful for IT developers to build different functional components in a .NET Visual Studio environment and bring that functionality online piece-by-piece, using interfaces provided by BizTalk. And the BizTalk Server can be more flexible than traditional EAI integration platforms.
As long as users are working within the suite of Microsoft products, tying these applications to the BizTalk Server is not disruptive to end users and does not pose any risks associated with having to change code in the applications themselves. Compare this to the equivalent of a messaging bus in the IBM environment or the application message broker in traditional EAI parlance, and it is a big improvement.
Microsoft has brought together a number of moving parts under the BizTalk umbrella. The result is a useful tool for developers to tie into different applications, particularly ones in the Microsoft suite, and design and manage code objects for facilitating integrations through the BizTalk Server.
A Good Integration Choice?
In truth, the BizTalk front end and server are not an integration solution at all. Combined with other Microsoft products – most importantly the .NET suite – BizTalk’s front end and server contribute to an IT team’s ability to tackle integration projects. However, Microsoft is the master at bundling applications under different initiatives. So if we consider BizTalk as the umbrella of all the Microsoft applications necessary to address integration project rather than the interface and server themselves, the question still applies.
While unquestionably it is easier to roll out some integration solutions using Microsoft’s suite of products as compared to traditional EAI products, using BizTalk by no means makes this process trivial. To go beyond functionality provided by Microsoft, a user would generally use .NET’s Visual Studio to write code in Visual Basic, C# or for some industrial tasks, C++ or Java.
It can also be quite challenging to effectively define many data schemas for use in the BizTalk environment. In a very favorable environment for BizTalk consisting only of Office 2003 applications, implementing functionality such that a user receives a simple notification when a Microsoft InfoPath-enabled Web form has received data input requires working with .NET’s Visual Studio, InfoPath and BizTalk’s interface. In total, the process requires over 100 different steps.
Obviously, BizTalk does not suddenly make integration something the faint of heart should undertake.
On the other hand, BizTalk does increase the power of Microsoft’s suite of products for complex integration tasks that compete with traditional EAI solutions. Any degree of integration sophistication is theoretically possible by virtue of plugging in object after object of custom-written or packaged code into the BizTalk interface. This does create overhead on IT staff who must work to achieve some of the high-value aspects of transactional integrity that are part of the more traditional EAI platforms. At the same time, it allows them to make decisions about what aspects of the integration solution might be left out, thereby potentially shortening the overall development cycle.
A Balanced Product, If Not a Total Solution
With BizTalk, Microsoft has attempted to strike a balance that can deliver aspects of EAI functionality while reducing ROI. Given a Microsoft-centric back office, they have succeeded in delivering a tool that gives developers more capabilities for managing and implementing integration solutions. However, while it’s definitely a nice addition to the suite of Microsoft development products, it does not represent a shift in the complexities of system integration; and BizTalk should not be considered as a complete integration solution.
About our author …
Jay Borenstein is President and CEO of Tsunami Software, Inc., developer of the plug-and-play Tsunami appliance that creates an efficient and easy-to-use paradigm for managing real-time data communications. An engineer, Jay has designed and implemented dozens of solutions that take advantage of emerging technologies to simplify data communication between disparate systems. He can be reached at info@tsunamisoftware.com.