In a recent blog entitled "Did BizTalk get more complicated with 2004", my boss, Andy James (who has just moved his blog to GeeksWithBlogs), wrote that "the fine new orchestration engine and toolset [in BizTalk 2004] is now no longer A RAD business process development tool". Now, I know the background to his comments, and I know that this statement is in part because of recent experiences in a piece of development in which I had no small involvement. I would say that BizTalk 2004 is sophisticated, somewhat complex in places, and enforces a steep learning curve. But I think he is not altogether correct (please don't fire me Andy...please) when he says that orchestration tools do not support RAD.
Now, it is true that when you first take BizTalk out for a spin, you are likely to make a ton (sorry, 'tonne' - this is Europe, after all) of subtle mistakes which really slow down your progress and result in over-complex orchestrations. You need to understand the woefully under-documented intricacies of message instantiation and assignment, the best use of schemas and the subtleties of using multi-part messages, .NET classes, etc. Although not as critical as in Pipeline component creation, a failure to adequately partition your code into separate assemblies (splitting schemas off from orchestrations) can get in the way of rapid development. It is also true that the build-deploy-bind-enlist-start-test-debug-stop-unenlist-undeploy-change-die-of-boredom-and-old-age cycle is far from RAD-like and in serious need of attention in the next version (please, please take note, Microsoft). Also, the fact that orchestrations must currently be hosted outside of Visual Studio, and cannot therefore be run and debugged from within the IDE, slows down the speed of development.
However, the secret to RAD orchestration is to get organised. A bit or organisation, coupled with a reasonable grasp of what is going on, works wonders. And if you can do the work as a team effort, then this is so much better. In another (subsequent) piece of development work with BizTalk 2004, I spent three days with a major company doing a proof of concept. Our mission was to create two orchestrations, neither of which was particularly complex, but both of which where substantial enough to merit the use of orchestration and to present some real-world challenges. It took us just over two rather stressful days to create the first (smaller) orchestration. The slow-down was primarily due to a) technical problems getting a third-party adapter to talk to the back-end database system and b) the client's learning curve in understanding how to translate their manual business processes into an automatable form. We eventually solved the technical problems with help from the vendor (thanks, Ian), and built the first orchestration, leaving us to start the second larger orchestration at about 10:30 am on the third and final day. We needed to be up and running for a demonstration by 4:00 pm. A small team was set up initially to come up with an activity diagram. Having learned quickly from their experience of the first orchestration, they were able to use their domain experience to put together a complete and watertight process flow within a very short time. I refined this into a detailed paper design for the orchestration, while someone else got on with writing some stored procedures. A third person was involved in configuring the third-party adapter to call those stored procedures (now a trivial exercise thanks to what we had learned) and generate some schemas and message ports (a very nice feature of the particular adapter). Then yours truly was left with the simplest task of all - drag some shapes onto the orchestration designer, write a few expressions and message assignments, sprinkle in a bit of exception handling, configure a few orchestration ports and voila. We made the deadline. We even had time to create a simple UI to submit messages. A little experience, teamwork and organisation mean it is possible to generate BizTalk 2004 solutions very fast indeed.
In classic VB-style, RAD is often associated with the fast build-test-debug-change cycle enabled through the visual designer (and, of course, the edit-continue features of good old VB and the forthcoming 'Whidbey' release of VS). You don't have this luxury with BizTalk orchestrations, so instead, you need to get organised. If you prepare properly, you can really speed up orchestration design by taking a very rigorous and precise approach. In the work described above, thanks to the defined process design, I was able to sketch out the shapes and process flow in the Visual Studio designer in a full and comprehensive manner, including expression, decision, message assignment and other shapes, and also groups, scopes and exception handling. I could also concentrate on applying rigorous naming conventions. The point here is that with adequate design and preparation (and, perhaps, a little prior experience), you can create an entire sophisticated orchestration and get it into a fairly complete stage before you ever need to start the slow and arduous process of testing and debugging.
I admit that the end result of our development was not polished - for production-quality code, we would have needed more time for development, and, of course, significantly more time for proper testing. However, on only our second orchestration, the team worked like a well-oiled machine, producing a working orchestration of a real-life business process with three separate back-end system interactions and associated decision making, human interaction via email notifications, etc. in just a few hours. The toolset certainly presents some challenges to RAD development, but these can be overcome.