Biztalk Server brings the process to everybody
To automate a business process, an analyst must first diagram the steps of a complex transaction — ordering for goods, for example — from receipt to completion. These diagrams become the model developers then use to craft a stage-by-stage pipeline to meet the analyst’s requirements. Pipelines are then integrated into processes, and the processes are integrated into orchestrations, their deployed form.
The core purpose of BizTalk Server remains, but Microsoft has redesigned or enhanced almost everything around that core. Except as noted below, Microsoft got BizTalk Server 2004 very, very right. With this iteration of the suite, analysts can alter the behavior of transactions — even transactions currently in operation — by creating simple business rules that bypass the need for redevelopment. Using an Excel spreadsheet, any authorized observer can extract transaction status and statistics in real time.
Microsoft has also reached out to a neglected class of process participants, real human users, by smoothly integrating SharePoint Web collaboration and InfoPath XML-based forms as user front ends. BizTalk Server 2004 addresses one of my chief complaints by allowing developers to publish entire orchestrations as Web services, and this release updates — but does not perfect — BizTalk’s standards compliance, mostly as a benefit of moving to managed code. If there is a theme to the new features in BizTalk Server 2004, it is inclusion: More people can get involved in the design and operation of orchestrations; and more servers and apps can communicate with BizTalk Server 2004.
BizTalk 2004 developers will design and code entirely within Visual Studio .Net. BizTalk’s migration to managed code completely changes the landscape both in development tools and the breadth of available functionality. BizTalk can now call out to custom .Net assemblies without going through the COM interop layer. In short, all of .Net is available within BizTalk, and the relevant parts of BizTalk, including real-time business-activity monitoring data, is available to .Net.
I found that the most important enhancement to BizTalk Server 2004 was the degree to which it frees developers and analysts from having to learn each other’s lingo. Developers need to absorb enough business speak to create vocabularies that link the business and technical halves of the solution. But I found the tools for this task remarkably easy to use, and after that initial mapping is done, both groups can usually speak in their own tongues and allow BizTalk to do the translating.
In previous releases, developers had to write work-arounds for everything from poor performance to the need for fragmentation and reassembly of large messages. Microsoft has addressed such issues directly. In particular, the need for BizTalk developers to invent basic front-end features such as forms and Web-based monitoring is all but eliminated. Coders still have the ability to perform these actions one method call at a time, but Excel, InfoPath, and SharePoint should be used for most of the client-side heavy lifting from now on.
BizTalk Server likely will become the hub of the Windows server stack. The days of opaque enterprise solutions that keep users at arms’ length by requiring programming expertise in order to alter or amend processes are short. If Microsoft stays on this track, we might see business software that makes business sense. Imagine that.
To automate a business process, an analyst must first diagram the steps of a complex transaction — ordering for goods, for example — from receipt to completion. These diagrams become the model developers then use to craft a stage-by-stage pipeline to meet the analyst’s requirements. Pipelines are then integrated into processes, and the processes are integrated into orchestrations, their deployed form.
The core purpose of BizTalk Server remains, but Microsoft has redesigned or enhanced almost everything around that core. Except as noted below, Microsoft got BizTalk Server 2004 very, very right. With this iteration of the suite, analysts can alter the behavior of transactions — even transactions currently in operation — by creating simple business rules that bypass the need for redevelopment. Using an Excel spreadsheet, any authorized observer can extract transaction status and statistics in real time.
Microsoft has also reached out to a neglected class of process participants, real human users, by smoothly integrating SharePoint Web collaboration and InfoPath XML-based forms as user front ends. BizTalk Server 2004 addresses one of my chief complaints by allowing developers to publish entire orchestrations as Web services, and this release updates — but does not perfect — BizTalk’s standards compliance, mostly as a benefit of moving to managed code. If there is a theme to the new features in BizTalk Server 2004, it is inclusion: More people can get involved in the design and operation of orchestrations; and more servers and apps can communicate with BizTalk Server 2004.
BizTalk 2004 developers will design and code entirely within Visual Studio .Net. BizTalk’s migration to managed code completely changes the landscape both in development tools and the breadth of available functionality. BizTalk can now call out to custom .Net assemblies without going through the COM interop layer. In short, all of .Net is available within BizTalk, and the relevant parts of BizTalk, including real-time business-activity monitoring data, is available to .Net.
I found that the most important enhancement to BizTalk Server 2004 was the degree to which it frees developers and analysts from having to learn each other’s lingo. Developers need to absorb enough business speak to create vocabularies that link the business and technical halves of the solution. But I found the tools for this task remarkably easy to use, and after that initial mapping is done, both groups can usually speak in their own tongues and allow BizTalk to do the translating.
In previous releases, developers had to write work-arounds for everything from poor performance to the need for fragmentation and reassembly of large messages. Microsoft has addressed such issues directly. In particular, the need for BizTalk developers to invent basic front-end features such as forms and Web-based monitoring is all but eliminated. Coders still have the ability to perform these actions one method call at a time, but Excel, InfoPath, and SharePoint should be used for most of the client-side heavy lifting from now on.
BizTalk Server likely will become the hub of the Windows server stack. The days of opaque enterprise solutions that keep users at arms’ length by requiring programming expertise in order to alter or amend processes are short. If Microsoft stays on this track, we might see business software that makes business sense. Imagine that.
Comments