Anti-Pattern: Everything but the Kitchen Sink Map


Everything but the Kitchen-Sink Map


Given a complex process with many complex rules, everything (business logic, related and unrelated procedures, etc) is shoved into the map.


Symptoms include the following:

·         Map contains an overwhelming number of “scriptoids” (scripting functoid) performing custom business logic.

·         Map relies on custom functoids or .NET components to perform custom business logic.

·         Map is difficult to debug because of excessive complexity.

·         Map is difficult to maintain; when a rule changes, one or more custom scripts or code must be modified, tested and redeployed.

·         Business rules are difficult or impossible to deduce by looking at the map.

·         Business logic is sprayed across the BizTalk Server solution, from maps to orchestrations to the Business Rules Engine to external components and systems.

·         Encryption, data modification, and other value-added transforms appear in the map.


This anti-pattern produces pain in the following areas:

·         Maintenance

·         Performance

·         Enhancement

·         Debugging

·         Monitoring


There are many potential cures you can explore:

·         Business Logic

o   Use the BizTalk Business Rules Engine (BRE). This will increase the flexibility of your solution, ease some aspects of maintenance (maps, etc) at the expense of adding a dependency to the BRE, and force the business team to succinctly define a vocabulary and ruleset.

o   Call custom components containing business logic from an orchestration. For example, if you have a component that uses a complex algorithm to assign a ranking to a customer, call it from an orchestration (or custom pipeline component) and not from within a map.

o   Concentrate business logic in Orchestrations, the BRE and external LOB systems. For example, if your solution is processing 837 Professional claims, a combination of BRE and Orchestration logic may filter based on primary diagnosis and geographic region but a back-end adjudication system will handle most health claim rules.

o   Don’t forget about BAM. By carefully placing logic in appropriate places, you may enhance your ability to track key data using BAM.

·         Value-Added Transformations

o   Can you migrate some of the transformations into a custom pipeline? For example, encrypting certain fields in a message is better done in a custom pipeline component; doing so may improve performance and make maintenance and debugging tasks easier.

o   If you commonly apply the same pattern of 4 or more functoids against many elements, consider combing them into a custom functoid. This simplifies reuse, makes it easier to modify (change the custom functoid instead of ever instance of the transform), and may provide a performance benefit.

·         Other

o   Locate business logic and other procedures as far downstream in the business process as possible. By deferring potentially complex procedures, you may be able to avoid them.

o   Break large maps into smaller maps and run them serially in an orchestration. It may be better to trade a little performance for easier editing and debugging.

o   Develop a coherent plan for business logic based on business requirements, solution architecture, and performance goals. Make sure the plan is followed through sound process.


BizTalk maps are great because they are so flexible. This also makes them dangerous because all manner of logic can be tossed in on a whim. Before adding more logic to a map, reconsider – is it better placed somewhere else?

Comments (1)

  1. keithknight says:

    Ah yes, have seen this one before! When confronted with an ‘everything but the kitchen sink’ map I usually reach for Steve Hart’s map documenter tool to try and help me come to grips with how the map works.

Skip to main content