Discussion Items

Business-Time Information Architecture

Building a Better Mousetrap: The Business-Time Information Architecture | DM Review | Industry Led, Industry Read

It wasn’t supposed to be this way. The promise of the enterprise resource planning (ERP) systems and the emergence of enterprise application integration (EAI), data warehousing (DW) and business intelligence (BI) technologies was supposed to revolutionize the way business was conducted, or at least the way systems supported streamlined business processes.

One reply on “Business-Time Information Architecture”

When SAP was new, you had to stop doing business the way you did it and do it the SAP way. Call it a user interface problem, but really it was just bad software. Why should databases revolutionize the way business gets done, rather than just enabling business to get done in a more automated way?

These days we hear the “bust the silo” mantra, the “single version of the truth” mantra, and “the single data model.” All of which are bunk. Silos arose because of the division of labor. The myth of corporate culture pushed the idea that there is one culture, but really there is one dominant culture, the line culture, the culture of the strategic business unit, the culture of power. The division of labor cultures of the functional units are the silos. Of course, power wants to breach the silo, but to do so will force a generalist stance over the functional needs of the silos. The end result isn’t one version of the truth, but multiple versions of fiction.

Culture divides. Even within a single functional unit, paradigms divide on the basis of those who accept the paradigms that wash through a subject domain. In cost accounting you have traditional cost accounting, activity based accounting, and throughput accounting. Each of these paradigms have their adherants and their naysayers. Where a particular cost accounting department is on the issue depends on the manager, and the number of employees who believe in these to different degrees. This is a mess.

The usual practices in requirement elicitation is to say to the various functional units competing over any given requirement “after you settle this call me.” The conflict ultimately is resolved via line power and the requirement then becomes a source of requirements volitility as the political fight continues. Ultimately, it’s a matter of efficent implementation getting in the way of production. Production is always more expensive than implementation, so the efficency desire is pointed the wrong way.

A better mousetrap is really up to the mice, not the mousetrap makers.