Darren Wesemann Blog

If ever there were four completely independent concepts (in terms of evolution) that are destined to be related (even in the immediately family) and together revolutionize our thinking about how software delivers solutions to meet agile needs business needs, it is SOA, SaaS, BPM and Open Source. 

For a couple of decades people have made attempts at componentizing software for the purposes of reuse and rapid composition of solutions with certain measures of success.  Overall, the componentizing of software into parts that can be reused and assembled into composite solutions is far from an exact science. 

Many years ago I served as CTO for a hardware company that produced parallel processing chips for the super-computing marketplace (supplied to NASA, DoD, various government contractors, etc…).  I still remember battles my electrical engineering staff would have with my software developers regarding the lack of exactness in the componentization of technologies and the assembling into the solution (our product).  Developing hardware takes a very systematic approach (real engineering) involving libraries of components and assembling them together (via VHDL or schematic capture, for instance) into the ultimate solution.  Simulators can tell you if you get what you expected far in advance of production.  The components follow exact interfaces, the libraries are clear and open and the simulator works in conjunction with development environment to provide a complete view of what’s happening.

When the time would come to write the driver and supporting software for the hardware, the battles would ensue.  It became apparent that although I had been developing software for many years, I simply didn’t realize how non-exact (un-engineering-like) software development really is.  A driver and other software required didn’t have the luxury of open libraries to pick from, simulators to run exact assemblies through for precise results, instead the software was mostly not exactly what you expected, until multiple iterations of development and testing.  When the hardware is compiled, you have one shot at getting it right, whereas with software each compile yields an attempt at getting closer to what you want.

After multiple attempts at defining distributed component technologies for software (CORBA, DCOM, EJB, etc).  I think we’re finally getting very close to a far better component-and-assembly world for software solutions with the combined power of SOA, SaaS, BPM and Open Source.  SOA yields better standards than we’ve ever had before (not just in terms of software interfaces including WSDL, BPEL, SCA, etc., but the collaborative governance around how an enterprise functions as well), SaaS for the on-demand environment, BPM for the modeling and assembly of the solutions and Open Source for the openness of libraries and infrastructure. 

Having lived the differences between what the presence and absence of these attributes can have in the development of solutions with technology, I’m convinced these are powerful (and extremely related) attributes to successful composition of solutions from reusable components.