I'm found of saying that technology is cyclical, and at a certain level I think most people would certainly agree with me. You look at mainframe timesharing, you look at desktop PCs, you look at terminal services, you look at laptops, you look at SaaS, you start to see a certain repetition of basic concepts at the delivery level of information technology. Zoom your telescope in or out a bit and you'll see the same sort of cycling of concepts in such specific areas as programming languages or database modeling. Nothing is ever really new, is it? "This has all happened before, and it will happen again."

But there is a danger in looking at modern technologies through this prism of what has come before, because while the concepts may be similar, the details are often quite different. I fall into this trap frequently enough myself that I have to remind myself that while decisions should always be informed by history, they should never be chained to it. In this case, though, I think that's the trap that Mike Ogrinz, writing at JackBe's Enterprise Web 2.0 Blog, falls into when discussing mashups in terms of the Excel spreadsheets of yore.

Ogrinz, a consultant and enterprise architect who has authored the upcoming book "Mashup Patterns" to provide instruction and examples to other developers and architects seeking to create successful mashup systems, clearly has a good grasp of the detail of the new. And he correctly diagnoses one of the largest failings of the old, the tendency of massive, complex chunks of business logic to become embedded in unwieldy, undocumented Excel spreadsheets carefully horded by accountants away from the eyes of the IT department. No CIO or IT manager from the post-Visicalc era remained unscathed by such pockets of inbred resistance to centralized planning and efficiency. Vital data captured outside IT's centralized databases remained opaque and unreportable, and legions of consultants found employment when the renegade 'sheets were finally uncovered and had to be integrated into a systematic structure.

Ogrinz warns that mashups could share the same fate, that solutions developed in one department might be duplicated in others, without careful central planning and repositories. This is excellent advice, of course, albeit somewhat redundant: most of the mashup generating technologies we have are inherently collaborative; they are web-based, Web 2.0 informed, and come with sharing and searching built right in conceptually.

The comparison, however superficially analagous, mistakes exactly why Excel information silos were (and are) so destructive. It was never so much the development time or the inability to reuse the program logic. It was the fact that the information itself was duplicated or locked away from other units, and that the time and expense of maintaing or distributing that data increased with every new spreadsheet that sprung up containing it.

Mashups avoid this problem right out of the gate. They are very much the solution to the Excel silo problem (which is one of the reasons I have been excited about the technology) in and of themselves, because they rely on data that is centrally stored and maintained by their very nature.

It's true that Excel represented a powerful mechanism for end-users to assemble and process information outside the strict supervision of the IT department, and it's true that mashups provide the same capability. But mashups get right much of what Excel got wrong; the fact that they provide a similar capability doesn't automatically mean that they have similar pitfalls. All those CIOs who got burnt by the Excel silo problem may be leery of putting uncontrolled power into the hands of those users again, but shouldn't burden their decisions with the idea that it was the distribution of power that was the problem with that solution... the power should be pushed out as close to the end-user as is possible. The problem was the control of the integrity of the data, a problem that mashups solve rather neatly.

There is another old saw that the perfect is the enemy of the good. It's good to have a centralized repository of mashups and mashup chunks for users to re-use. The perfection of attempting to ensure that all mashups end up in that repository is a very different goal than the necessity of ensuring the integrity of the underlying data, and spending time and resources trying to discipline users into adopting the same versioning and repository behaviors as professional software developers does much to erase the advantages of giving them easy-to-use pseudo-development tools in the first place. It matters little if John in accounting and Suzy in HR both take ten minutes to whip up the same mashup to pull payroll data out of your ERP system. It's a one-time loss of ten minutes, yes; but it's not the ongoing problem that a similarly constructed Excel data silo would present, and it's cheaper than sending John and Suzy back to school to learn how to use a versioning system.

I don't think this is what Ogrinz was suggesting at all. I do, however, see it as the inevitable conclusion of some CIOs when they read that mashups might suffer the same disadvantages as Excel in the workplace.

Keep a central catalog of your mashups, by all means; make it web-based and easy to use. But don't sweat it when people don't use it universally, and don't get exercised when duplicated functionality starts showing up in the catalog. It should be a resource for users, not a constraint on their creativity... because that really misses the point of what mashups can do for your business.