Why split a BizTalk solution into multiple projects

Question

I've read it's good practice to split a biztalk solution into multiple projects
- seen some debate as to the exact nature of the split
- could be split by artifact, i.e. Schemas, Orchestrations, Maps, etc.
- could be split by function

But what's the benefits / con's ??

Answer 1

BizTalk solutions typically include schemas, maps, and orchestrations. Solutions can also include supporting components, Business Rules, definitions of port-based routing and transformations, trading partners, and several other types of artifacts.

Effectively managing all of these artifacts has many benefits – far more benefits than drawbacks.

The benefits include:

• Separation of concerns based on the logical grouping of artifacts (by functionality or artifact type for example). This approach reduces the possibility of modifying aspects of your solution that aren’t related to the problem you’re working on at the time.
• Easier to test – you can compile and deploy just the components you’re modifying.
• Easier to split work among a group of developers.
• Easier to manage when the solution gets larger – it can take several minutes to load large BizTalk solutions in Visual Studio.
• Supports more advanced approaches related to ESB-style solutions (very loose coupling). Depending on your overall approach, you can create a solution that is very modular – to the point that modules can operate and be updated completely independently of each other.
• Makes it possible to version artifacts separately.
• Facilitates more fine-grained control over security and memory utilization by grouping related functions such that you deploy them for a particular host instance, for example (you can also administer fine grained .NET security policies more easily than you can with a solution that deploys a few assemblies).

The main drawback to splitting your solution over several projects or solutions surfaces when you are debugging your solution. Debugging BizTalk solutions is not straightforward for many developers that are new to BizTalk and having to narrow-down bugs across solutions does not make the job any easier. However, you can mange this issue by more effectively arranging your solution and using standards around naming, directory structure, arrangement of namespaces, and related methods to make it easier to figure out where to look.

Other drawbacks include:

• More assemblies to sign and deploy into the GAC
• Inter-dependencies between projects can result in deployment errors that can be difficult to track down in poorly organized solutions.

You should dedicate some time at the beginning of a project – ideally during design – to setup the basic organization of your solution. A one-size-fits-all approach does not exist – you need to think about how you want to manage the solution during development, deployment and maintenance in the context of the functionality that the solution provides to your organization or clients.

A good place to start is to divide your solution based on artifact type or functional areas. As you grow your solution, you’ll get a better understanding about how artifacts relate to each other, how you want to manage strong naming, security, and physical deployment and be in a better position to arrange your solution more effectively. You need to be careful with this approach since you could end up having to rearrange large parts of the solution, which can be disruptive if your project’s timelines are tight.