During my past BizTalk engagements, I have had the opportunity to work closely with my clients in developing flexible and maintainable applications.  One of the most common issues that I come across is the misuse of some of the shapes available within the Orchestration Designer.  By misuse, I simply mean to say that many BizTalk developers will drag and drop shapes into an orchestration to implement the business process, but do not take into account the implications of doing so.  More often than not, the result of selecting the wrong shape for the job is not seen until the application is tested or even worse, the production environment.  One of the primary reasons that BizTalk is used is the opportunity to build loosely coupled, flexible and scalable applications.  By choosing the wrong shape, many developers will wind up doing exactly the opposite, thus setting the application down the course of tight coupling and brittle implementation. 

Back in April, there was an interesting article quoting Ron Jeffries et al on InfoQ looking at code reuse from an agile perspective. The conversation steered toward explaining reuse as a concern that is very expensive, looking at it from a top-down, “enterprise”-wide lens.

But is code reuse a black and white issue? My contention is there are varying degrees of reuse that are often neglected on a microscale within an even moderately-sized project. If the code you produce isn’t going to be reused, is it even going to be looked at? These are similar problems with similar solutions.

As discussed in an earlier posting, creating a Domain Model is critical to a successful SOA implementation. But how do you effectively utilize this model within your code base as you start to develop applications that are in tools or languages that do not manipulate the XML directly?