Go Ahead, Raise the Scaffolding -- Temporary Can Be Good

by Ken Orr, Fellow, Cutter Business Technology Council

The things you have to be careful about in architecture are those everybody knows but are not true. I was working recently with a friend trying to sketch out a migration plan for an organization whose IT systems were not too great. In the course of that discussion, he remarked that "we don't want to put anything in place that we're going to have to get rid of later." Since later in this case was a couple or three years later, I had to think hard and fast about what he was saying. As it turned out, I think that he was wrong.

Scaffolding -- the building of structures that are used to put up or repair buildings, bridges, etc., and then removed when the structure is complete -- are commonplace in the building trade, as are forms and cranes. Scaffolding has been used since ancient times. However, scaffolding itself is often a significant construction project in its own right and therefore an added expense. Moreover, it is clearly a throwaway cost because the scaffolding itself is discarded before the building is finished. So, why all this added expense? The answer is that it makes construction easier and safer. It is much easier for a bricklayer, roofer, or a painter to climb up a ladder and stand on a scaffold to do his or her work. It is easier to raise material with a crane attached to a scaffold. It all has to do with the manner of construction and having the right intellectual and physical tools.

Now, some people think that with software being entirely a virtual (electronic) product, scaffolding shouldn't be necessary. Unfortunately, that is true only for the simplest products. Software, especially large-scale software, needs a great deal of scaffolding in terms of such things as project libraries, test harnesses, test set generators, and data dictionaries. Like physical scaffolds on buildings, these items may or may not appear in the final product. If the product is a commercial product sold to the public, these items rarely come with the product. Software scaffolding is part of the development environment.

But what about scaffolding in application systems? Is it a bad idea to put up some temporary structure that will be used for a couple of years and then discarded? You bet. One of the things that I've observed in large, complex projects is that people confuse temporary with bad. Moreover, they often underestimate how soon something temporary will actually disappear. If some scaffold system is created -- an interface program to access a legacy database scheduled to be replaced in a couple of years, for example -- it may easily pay for itself in added capability, even if said database is replaced on schedule, which is hardly ever the case.

In enterprise architecture, many big jobs are never completed because no one wants to do the detailed planning it will take to migrate safely from one system to another while still providing the business with needed capabilities. Road designers always build access roads and detours before they start construction of new roads. They not only conceive of the finished product; they think through the construction process and the operational needs. Software architects don't have that tradition. One of the reasons big systems so often fail is that the architects and designers have not learned from their fellow architects and engineers in the real world. So, remember, it is OK, and often necessary, to put things into your development process that will not be there when you're done.

I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at korr@cutter.com.

-- Ken Orr, Fellow, Cutter Business Technology Council