Redmond, Wash.-based Microsoft Corp.’s BizTalk Server is designed to build bridges between people, applications and processes – but not everything is connected.

Unix and AS/400 platforms, for instance, are set adrift, and the only way for application developers to connect the two to BizTalk is by taking a roundabout route through third-party vendors, such as Viewlocity.

“The BizTalk Server is principally oriented toward providing middleware services and protocol translation services in a primarily Microsoft-tinged environment. If you happen to implement CORBA and other non-Micorosft middleware [technologies], you’re out of luck – unless, of course, in addition to deploying the BizTalk Server, you also deploy third-party products that do that bridging,” said James Kobielus, an analyst with the Burton Group in Alexandria, Va.

For Marks and Spencer, BizTalk was an obvious choice to set up information flow between the various stores and head office because of the company’s existing commitment to Microsoft products.

“What we needed was a product that was from a proven company, number one – that we had a partnership with already and that could integrate well with our existing infratructure. So, as a company, we had very strong links to Microsoft software on the majority of our solutions,” said Jerry Boersma, a technical designer for the New Data Transfer Project at Marks and Spencer.

“I think one of the advantages (of BizTalk Server) is its completeness and degree of integration with Windows 2000,” said Patricia Seybold Group senior consultant/analyst Peter O’Kelly in Boston.

“Microsoft is not going to deliver a server that runs on anything other than Windows 2000,” he said, stressing that the BizTalk Server can be interoperable with Unix solutions because Microsoft has partnered with firms like Viewlocity.

And BizTalk is interoperable in other ways too, O’Kelly said.

“They support different message formats right out of the box. They’re not being heavy handed with it,” O’Kelly said. The lists of standards that Microsoft does support, though not exhaustive, is “pretty impressive,” he said.

The BizTalk Server, which is a part of Microsoft’s .NET strategy, has two main components: BizTalk Orchestration and BizTalk Messaging, which allow organizations to bridge internal and external applications.

“The messaging server is a powerful, capable thing. But it doesn’t have a lot of sustainably unique features that other companies won’t be doing as well,” O’Kelly said. It’s the orchestration engine which distinguishes BizTalk, he said.

It is designed to bridge the distance between business analysts and application develpers by having them work together in a common graphical design environment.

“(BizTalk Orchestration) lets a business analyst define the business process without needing to understand the technology. The IT pro takes it from there,” said Kevin McCall, the lead product manager for the BizTalk Server in Redmond.

“It’s a different application and development model,” O’Kelly said. “So if you look at the details, they’re saying that a business analyst is the person who should be specifying the application, so a developer doesn’t even touch it until a business analyst has gone into it and done the workflow. Then the developer comes in and wires the result of the business analyst’s work into components,” he said.

“But, fundamentally, the bet is that they can get a higher level of productivity relative to somebody who would be building things and writing code with more traditional tools.”

Going with the Flow

With BizTalk Orchestration, business analysts create flowcharts in a Visio environment to describe the business processes. They define the way in which applications, processes and information have to flow from one place to another. Then the developer comes in and writes code to link the different applications together and configure the flow of data.

“[Orchestration] allows both the business managers and the technical developers to have a more common development environment they could share that they could use to establish an agreement on the design of a BizTalk application,” Kobielus said.

But O’Kelly wonders if some application developers might resent the new approach.

“I think there are a bunch of historical examples where things have met with resistance from developers because if a developer has decided, I’ve invested a lot of time in learning this programming language and this design tool, then they will just, by definition, have some resistance there.” In order to bring developers on board, systems managers are going to have to carefully explain what the benefits are.

“Because if somebody just goes in and says this is useful for the company, you must use it, then I think history suggests that there would be a lot of resistance, and perhaps even sabotage,” O’Kelly said.

Kobielus disagrees. He believes application developers will welcome the orchestration engine as a tool that will streamline the development process.

“Anything that minimizes the amount of coding that they need to do at the low level, in terms of C++ or Visual Basic, will be much appreciated. This environment will automate the development of that code using the visual paradigm.”

But he wonders how well business analysts will be able to handle the flowcharting.

“In terms of business managers, flowcharts get fairly complicated with all the various conditional branches and loops and stuff,” Kobielus said. “BizTalk – may be more high-powered and sophisticated than the average non-technical user is comfortable with. But that’s not so much a Microsoft problem, that’s more the nature of workflow.”