Steve Hart

Denny’s Restaurant Session
Bellevue, Washington, 3:00am
At approximately 3:00am, me and two of my colleagues decided to do a bit of food research at a Denny’s restaurant in Bellevue.  You could call this our first morning session.

There is More to Life in Healthcare Integration than Technical Compliance
Elizabeth Redding, Partner2Learn
Elizabeth has been helping healthcare organizations with technical compliance over the past 10 years and has a lengthy background developing healthcare plans. Based on the title of the session, I suspected that we would be getting slides that state the obvious. Sure enough, one of the slides stated that “Focus should be on the business…”. I really didn’t think it was necessary for the presentation to include such basics when the focus should be more on providing deeper insight into service oriented architecture and business process management from a healthcare perspective.

She spent some time talking through the benefits of the BizTalk integration model using an HL7 patient administration message workflow as an example and also eluded to the benefits of using the BizTalk BAM (Business Activity Monitor) and BRE (Business Rules Engine) in the mix.

On the subject of the administrative overhead in healthcare she said that when HIPPA was first introduced, the [American] healthcare industry was spending 40% of their budget on administrative overhead. From a Canadian perspective, she said that the administrative overhead is currently massive and one of the reasons has to do with the reporting of data which is apparently a burdensome process. She wasn’t specific about the nature of the reporting and how the data is reported so if anyone knows what she’s talking about please post a comment to explain.

Developing and Maintaining Business Rule Solutions
Richard Seroter, Technology Specialist, Microsoft
I thought this presentation would focus solely on BizTalk BRE but Richard did a great job delivering useful content in other areas which made the session worthwhile.

Why have business rules? Richard provided the 3 standard reasons: 1) Accessibility, 2) Flexibility, and 3) Manageability. He then talked briefly about the iterative BPM lifecycle comprised of: Model and Design, Develop and Deploy, Manage and Interact, Analyze and Optimize. What Richard was saying, was that establishing and implementing business rules requires the same level of professional analysis and design as you would conduct for other business solution areas. I guess that’s pretty obvious but I imagine that are lots of organizations/people out there who design and implement business rules in an ad-hoc manner in the wrong places. Actually, Richard did point out that many people implement business rules in inappropriate places like stored procedures, user interfaces, and web service implementations. Yes, I agree, many, many people have done this and it can severely impair a solution’s adaptability making it a very costly endeavor to upgrade applications to accommodate changing business rules.

In addition to BizTalk, Workflow Foundation (WF) also provides a rules engine. The following table is a comparison of the two:

Other takeaways include:

• In BizTalk, when rules are executed via an orchestration, the rule execution can be tracked, allowing you to view the tracking information to discover which rules were used/fired. However, if you call the BRE directly via a .NET class, you cannot do tracking by default. To enable BRE tracking via .NET, you need to implement a certain interface provided by one of the BizTalk BRE assemblies (can’t remember which one; will leave it to you to do the search) and pass the implementation of that interface to the BRE call.
• Richard feels there is a business opportunity around the development of customized rule solutions (e.g. rule templates, function libraries) for verticals (e.g. healthcare).
• RuleBurst is a product that is used to administer complex business rules. Richard did a quick demo of RuleBurst and it did look impressive (much more comprehensive than the BRE composer). It uses a Microsoft Office rule design surface (e.g. rules can be edited directly in MS Word), has a robust management console, and, apparently some great QA (Quality Assurance) testing capabilities.

Web Services Factory
Don Smith, Product Manager, Patterns & Practices, Microsoft
Web Services Factory can be summed up as follows (from Microsoft’s Web Service Software Factory article):

The Web Service Software Factory (also known as the Service Factory) is an integrated collection of tools, patterns, source code and prescriptive guidance. It is designed to help you quickly and consistently construct Web services that adhere to well known architecture and design patterns.

Don was a very enthusiastic presenter and did a decent job of explaining the concept and implementation of the web services software factory. At a high level, Don explained that a software factory is about “communicating” between the architect and the developer and between the architect and the business; in other words, to help increase “communication” across the board. That sounds rather vague but he did go on to explain a bit more: “It’s about allowing the developer to have a conversation with Visual Studio“. Ok, still vague. How about: “an implied or suggested process that you go through to build a solution“. Or, better yet, he also described a software factory as something that helps you build a specific kind of application via the incorporation of a variety of guidance content type including: architecture and design guidance, patterns, and help, reference implementations, application blocks, and guidance packages. To be fair, Don did a pretty good job of trying to explain the concept of a software factory. However, from an implementation perspective, the term “software factory” seems loosely defined (like SOA), starting out as something based on DSLs (domain specific languages), then something that uses GAT and GAX, then “morphing” into something that is being wrongly interpreted as simply a code generator. Microsoft’s answer to the question “What is a Software Factory?” can be found here.

Underpinning the web services factory are two core components: GAT (Guidance Automation Toolkit) and GAX (Guidance Automation Extensions). These are the components that allow “factory builders” to extend Visual Studio 2005 to author and run guidance packages which contain “templates, wizards and recipes, which help developers build solutions in a way consistent with the architecture guidance“.

The services factory contains guidance for designing messages and service interfaces, applying exception shielding and handling, designing business entities in the domain model, translating messages to and from business entities, and designing, building, and invoking the data access layer. The first release of the Services Factory was an ASMX (web services) release in July 2007; the WCF release is scheduled for December 2007.

This session was a great demonstration of the capabilities of the GAT and GAX components and how they can provide substantial benefits in driving solution development.

Microsoft, BizTalk, SOA, BPM, WCF, WF, Workflow, Software Factory, Guidance Automation Toolkit, Guidance Automation Extensions, Domain Specific Language