This blog is dedicated to the advancement of what I call the industrialization of software.  Software industrialization is about raising the level of abstraction for programmers to produce quality software products using modern software engineering approaches such as Software Factories. One aspect of the Software Factory approach employs model-driven development using Domain Specific Languages (DSLs) that code generates parts (or all) of the solution for a specific problem domain.  The Software Factory approach enables programmers to produce and assemble software in a predictable and repeatable manner something we dont do well as an industry, but is done well in other industrialized engineering disciplines like civil, electronics, electrical and mechanical domains.  Or at the very least, software engineering is nowhere near as evolved as these engineering disciplines.

 

The author of this blog lived the Software Factory approach while working at a company called 5by5 Software, now called Bridgewerx.  5by5 was initially a Microsoft Systems Integrator (SI) that offered professional services in the area of application integration, designing and constructing solutions using Microsofts BizTalk Server product.  Over a 4 year time frame, we designed and constructed over 25 application integrations solutions.  These solutions included messaging exchanges and workflow of all sizes, shapes and forms for various vertical industries.

 

During this 4 year time frame, we recognized several application integration design/code patterns.  Each pattern went through the process of discovery, reuse, refinement, and then iterated through this process again for each new project we undertook.  After designing and constructing 25 BizTalk integration projects, we found an overall framework design pattern that could be applied to all integration projects.  We decided to encapsulate this design pattern in a modeling tool, which really is a Domain Specific Language (DSL) for designing and generating application integration solutions sitting on top of BizTalk Server. 

 

The idea is that the DSL runtime Visual Designer would be used by a Business Analyst, who has the business domain knowledge to model an application integration scenario and the modeling tools output (XML) would supply the complete definition of this specific modeled application integration. We used this complete definition as input to our software factory template which then grabbed reusable components, other artifacts (with some custom code) and configure BizTalk Server with the specific application integration scenario, automatically build the solution in Visual Studio and produce a Microsoft installer package (MSI) which then can be installed on the customers target machine.  We called our Software Factory and DSL, Bridgewerx.

 

The point is that the software factory approach, incorporating DSLs works.  Our 4 years of application integration domain experience and subsequent ISV product is living proof of this fact.  We were pioneers in producing a software factory for the design of and code generating application integration solutions.

 

To further substantiate this claim, I will walk through a number of our projects and describe the patterns we discovered, designed, codified, categorized and subsequently automated, until we had the entire application integration framework pattern designed. Then we encapsulated the framework pattern into a DSL and built our software factory for code generating application integration solutions. 

 

From where I sit, this is industrializing the software development process for the application integration domain.  Another claim I make is that this same approach can be successfully applied to other software application domains of interest (e.g. software factory for generating families of e-commerce applications.)

 

In part 2, we will discuss what is common and what is variable to every application integration scenario as a way of describing our framework pattern.  Then we will look at some specific integration projects we undertook and how it fits the framework pattern.