The Unix Philosophy Applied

Applied to Application Glut...
I've always been a big fan of the Unix Philosophy.  It describes a lot of my thinking about systems development and enterprise architecture.  There are times that I wish that application implementers could see the same principle in their own work, too.  Here's an example:

Company X does a major ERP implementation, standing up an enterprise wide GL, AP, HR, PR, and SCM solution.  A couple years later, the philanthropy group decides that they need a consolidated view of the several different applications that are being used to manage prospective donors.  They decide to buy a finance package from the same vendor that supports their prospect management solutions.  When questioned about why they didn't just use the enterprise ERP solution, they explained that it was "too complicated.  We'd have to set up a new company and a new account structure to support the philanthropy work."

It's too hard to take my clothes downstairs, figure out how to use the washing machine, wash them, dry them, fold them, and put them away.  I'll just go to the store and buy some new clothes.

ESR, in his description of the Unix Philosophy, declares the Rules of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do [link].

I think the same applies to an enterprise environment: build or buy new software only when it is clear by demonstration that no existing application will do.

Company Y has an central, enterprise-wide, standard ERP system.  It also has a separate budget application.  Separate applications for AR.  Separate applications for capital management and capital budgeting.  Separate applications for contract management.  And lots of duct tape and glue holding all of these things together.  Sometimes the glue has to be held on with duct tape because one system is made of a material that glue won't stick to very well.  I'm stretching the analogy.

I think the Unix Philosophy applies in these situations, though; or maybe it's the MacGyver philosophy where you take a long a basic set of tools and then work with whatever you have on hand.

Applied to Data Warehouses...
Dan Linstedt wrote a blog post a couple of years ago that describes one way that this applies to data warehousing as well: Federated Star Schemas Going Super-Nova.  I've used Dan's argument more than once to describe the risks of using a strict dimensional model for a transaction grain enterprise data warehouse.  The end result is a data warehouse in which stars only loosely relate to each other at high levels and the same concepts get duplicated inappropriately.


I think that this philosophy is especially relevant during tough economic times.  More often than we think, we can use what we have, even if it isn't tailored exactly to what we would ideally like to have.  If you can use a little bit of customization to make things work, that's better, in the whole, than buying or building a whole new system that will require lots of glue to integrate into your enterprise suite of solutions.