The “Temporary” Building

By Stephen Putman, Senior Consultant

I was walking my dog on a sunny morning recently when we cut a path through my daughter’s middle school. I saw a group of temporary buildings attached to the main wings of the school, operating as additional classrooms. These new buildings were made to appear to be integrated with the existing classrooms, but it was obvious that they didn’t quite fit.

I thought back to my own years in middle school in the 1970s. My school was a recently-converted elementary school, and there were several temporary buildings constructed to provide facilities appropriate to a middle school, just like at my daughter’s school. I went back to that school a couple of years ago, and those temporary buildings were still there, 35 years later. I thought, “Aren’t these building called temporary for a reason?”

I believe that these buildings are still being used well past their original lives because of short-term, tactical thinking - it’s easier to keep things going as they are than to endure short-term disruption to build more long-lasting, integrated structures. Years of this tactical decision-making extend the lives of these buildings, even though it is likely that it is more expensive to maintain these buildings than the cost of erecting solid and permanent structures.

This reminds me of some data warehouses I’ve seen at our clients. Their enterprise reporting capabilities are built like these temporary buildings, with mismatched parts that are not integrated and often maintained at a higher cost than a solid, foundational system. I have seen many instances of reporting systems that are maintained constantly, manually, and reactively, nursed along over the years in the mistaken belief that maintaining these systems are less costly than building a permanent, integrated system, ignoring the cost and synergy benefits.

Don’t spend your time, effort, and money maintaining temporary structures--they may stay around much longer than you intend, and cost you much more in the long run.

photo by teofilo via Flickr.

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles.

Comments

[Jim Harris]

Great post Stephen,

I have encountered many client systems that started out as temporary solution and then got “promoted” to a permanent solution by renaming the system.

One client had an “Enterprise Data Warehouse” that actually was built by a previous consulting firm as a rapid prototype simply for proof-of-concept (POC).

Unfortunately, the POC was all the client could afford to build at that time and since it was so well-received (i.e. it provided much needed functionality not available in existing systems at that time), it started being used.

At first, they called it the “Reporting Database,” then the “Prototype Data Warehouse,” and then after a few years, it just became the Enterprise Data Warehouse (EDW).

Eventually, because of all the mismatched and poorly integrated parts, it became known internally as the Frankenstein Data Warehouse (FDW) – although the F sometimes stood for something else :-)

Best Regards…

Jim

[Steve Putman]

Hey Jim -

Thanks for the comment...I'm always fascinated by the lineage of some systems. Fortunately, I've lost my idealism long ago...

Thanks, Steve