Design – Can a system be 100% Data Driven

designdomain-driven-design

My new boss has been working on this project for many years. I've only been here a few weeks, but I am not sure it's possible. He would like to design a system that is "100% data driven".

So if we put in enough data, we can define and generate any application. I've managed to at least get him to concede some things like users, or apps should have predefined values, but he likes the concept of the structure of the system, the user interface and the logic all being stored as data.

There are some demos of simple things and he's basically rediscovered some simple ideas of object oriented programming and your basic template systems, but I think overall that this goal might be actually impossible.

I don't know how you can define logic using data without the system becoming so complex that you are doing actual programming anyway.

I think theoretically it isn't because the thing that interprets the data ends up needing to become turing complete to describe the application so you've just shifted the problem one level higher to no net benefit.

Is such a 100% Data Driven Application possible?

Best Answer

Your boss should read this piece: Bad Carma: The "Vision" project, a cautionary tale about inner platform effect or second system effect.

Abstract

Those of us who work in Information Technology (IT) have all been on a project where something important is just not right. We know it, most everyone knows it, but nobody is quite able to put his or her finger on the problem in a convincing way.

This story is about such an IT project, the most spectacular failure I have ever experienced. It resulted in the complete dismissal of a medium-sized IT department, and eventually led to the destruction of a growing company in a growing industry. The company, which we'll call "Upstart," was a successful and profitable subscription television business.

The project occurred in the early 1990s, and it was a custom-built order-entry and customer-service application, closely resembling what is now referred to as Customer-Relationship Management or CRM. The core functionality of the system included:

  • Order entry and inventory
  • Customer service, help desk
  • General ledger, accounts receivable, billing, and accounts payable

The application was called "Vision" and the name was both its officially stated promise for Upstart as well as a self-aggrandizing nod to its architect. The application was innovative, in that it was built to be flexible enough to accommodate any future changes to the business. Not just any foreseeable future changes to the business, but absolutely any changes to the business, in any form. It was quite a remarkable claim, but Vision was intended to be the last application ever built. It achieved this utter flexibility by being completely data-driven, providing limitless abstraction, and using object-oriented programming techniques that were cutting-edge at the time.

Like many such projects that set out to create a mission-critical application, the development effort spanned two years, about a year longer than originally projected. But that was acceptable, because this was the application that would last forever, adapting to any future requirements, providing unlimited Return On Investment (ROI). When the application finally went "live," almost everybody in the company had invested so much in it that literally the fate of the company hinged on its success.

However, in the event of total project malfunction, mission-critical applications running the core business of multinational corporations are not permitted the luxury of the type of fast flameout demonstrated by thousands of "dot-com" companies in the era of the Internet bubble. Within a month of Vision going "live," it was apparent to all but those most heavily vested in its construction that it was a failure.

See Also

http://en.wikipedia.org/wiki/Inner-platform_effect

Related Topic