If you have read this 7 part series, you will see how our DSL Visual Designer works for declaratively defining complete application integration models and see how our Software Factory works by taking the DSL Visual Designer tools output (an XML model definition) and using it to configure our Software Factory template, which is a set of scripts that configures a Visual Studio solution, including BizTalk server as the core integration engine, to code generate complete application integration solutions.  Our framework design pattern can be applied to any application integration scenario.  Further, I assert that the Software Factory approach can be applied to any software problem domain just as successfully as we have applied it to the application integration domain.

 

Our DSL Visual Designer is very specific in the sense that its domain language is specific to application integration scenarios.  We built our Visual Designer on top of BizTalk Servers integration engine to provide a higher level abstraction so that Business Analysts (BAs) can easily model their specific integration scenarios as BAs typically have the business domain knowledge and just need a modeling tool, specific to that business problem domain, to model the solution which is declaratively complete.  Since the model is complete (i.e. high fidelity, meaning not missing any pertinent information) and that we are in the virtual world of software, we can code generate the entire output, meaning producing the solution in a predictable and repeatable way.

 

Thats the main point of software industrialization.  As mentioned in the introduction to this series of blog posts, software industrialization means raising the level of abstraction to producing software solutions in a predictable and repeatable manner.  Producing software solutions in a predictable and repeatable manner is the bane of our industry.  In our case, using the Software Factory approach enables us to use model-driven development techniques using Domain Specific Languages (DSL) and assemble pre-built components based on a domain model pattern specifically designed for modeling application integration scenarios.

 

Because we designed and constructed over 25 application integration scenarios by hand over a course of 4 years we saw many application integration patterns based on producing these solutions for several different industry verticals and different types of integration scenarios (i.e. basic messaging exchanges to complicated, recursive workflows, all using orchestration).  In fact, in almost every project we were seeing these patterns repeat themselves over and over again.  Based on these repeating patterns (i.e. our evolution), we saw how we could embody these design patterns into a modeling tool (i.e. our DSL) and take the modeling tools output (XML definition of an application integration scenario) and configure a Software Factory to code generate the output, producing an installer package that can be easily installed on the target system, including a number of runtime applications that can monitor and manage the installed application integration solution.

 

I personally believe that this Software Factory approach will be the way that most (business) software applications will be designed (i.e. DSL models) and constructed (i.e. code generated) in the future.  Why do I say future?  Why has this approach not caught on (yet)?  This blog has discussed many themes to the reasons why.  Mostly it boils down to education.  I work with developers today that do not see the value in interface-based programming let alone the value of model-driven development or code generation or the concept of a Software Factory.

 

The education/experience gap in our own software engineering community is quite large and when some programmers (new and seasoned alike) are introduced to these concepts well, lets say that there is considerable resistance to even thinking about using this approach.

 

Now throw into the mix the vendor community that insists on producing marketecture. Our very own software vendors are doing us a disservice by selling hype to our target business community.  Now add the business community to the mix, who are the target audience of this marketecture to most, software is a complete mystery.  All they know that it is an incredible time consuming, costly, painful process that mostly results in never ending work, endless upgrades and broken promises.  Unfortunately, given the current state of the art in the software industry, this is all but true.

 

With a few exceptions, I consider the software engineering industry to be still in the dark ages, yet to go through the industrialization process that other, more mature, engineering disciplines have evolved to.  This series of posts is intended to show, in one companys way, how we evolved the industrialization of software in the application integration domain using modern software engineering techniques and tools.