I often demonstrate BizTalk to people that are curious about it - they could be developers, managers, even directors. Although orchestrations are great, they are not the primary means of creating a BizTalk solution. In fact, no one BizTalk technology is a primary means -- all BizTalk technologies work together in a loosely coupled way.
In any case, when I do these demos, I try to demonstrate orchestrations last since people usually start nodding and waving their hands the moment I show an orchestration. This usually includes phrases like "So it is easy", "Just drag and drop..simple", "So this is what we pay you for?" (well...not really...I made up the last comment).
The following is an excerpt of an article I recently wrote. The article will appear in full soon; however, this part - which describes how developers work with BizTalk is very relevant:
Understanding BizTalk's Declarative Programming Model
BizTalk is different in the way that you work with it. In contrast to applications you write using code, you may have seen and heard that BizTalk developers write very little, if any, code.
BizTalk programming uses a declarative model. The declarative programming model lets you focus on what you want to accomplish rather than how to accomplish it. You are actually already familiar with declarative programming.
When you create a Windows Forms or ASP.NET application and add a button control to a form or page, you focus on aspects like the button's position and text that appears on the button. If you review the code, you are likely to see code like this:
button1 = new System.Windows.Forms.Button();
button1.Size = new System.Drawing.Size(150, 45);
button1.Location = new System.Drawing.Point(30, 15);
button1.Text = "Click Me!";
Notice that the code simply describes the button. The automatically generated code does not get into window handles and drawing contexts leaving the runtime to handles the details of actually drawing the button and sending click events to your event handlers.
A BizTalk developer describes a message using an XML schema, and declares the location at which the application receives instances of the schema. The developer then describes the processing that takes place when the message arrives: the developer could transform the message, change its attributes, execute rules, and even create new types all using a declarative model.
At runtime, the BizTalk environment handles the details of receiving messages, routing them to interested applications, and converting the developers' declarations into actions. All of this happens in a type-safe environment that makes it easier to create a technically correct solution (correct in terms of handling types and acting on them - BizTalk cannot, of course, confirm that the actions you take are correct).
BizTalk developers can also write code within the BizTalk environment using XLang/s, a language that is modeled after C#. . Writing code in XLang/s often involves actions like message assignment, creating instances of objects, and invoking class member functions. You can use more advanced functionality using statements like call, while, and if; however, this is not strictly necessary since the orchestration designer's purpose is to make it easier to express these statements using orchestration shapes like Call Orchestration, Loop, and Decision.
So there you have it....when someone says BizTalk is simple, refer to this excerpt and set the record straight ;)