Blogger: Lyn Robison
The standard recipe for creating enterprise information systems has been around for a long time: relational data behind application logic behind a user interface. This basic N-tier architecture has been and continues to be the de-facto standard for enterprise IT application development. Sure, service oriented architecture and Agile methods are intended to remedy several of the pesky problems that are inherent with N-tier development. But still, the fundamental architecture persists, and that architecture is data in a database behind software for application logic behind software for the UI. Unfortunately (and demonstrably), this is a recipe for stodginess.
In fact, the N-tier design paradigm just touches the surface of the stodginess. My colleague Jack Santos rightly pointed out to me that IT architecture today really is NxN-tiers. It is not only two dimensionally data-process-logic, but two dimensions multiplied by multiple different implementations, due to stove pipe approaches, varying off the shelf software implementations, or (now) external cloud solutions. Each have an N-tier approach, and each can stand on their own.
When enterprise IT groups are forced to spend multiple man-days changing code in several NxN-tier software layers just to add a data attribute, those enterprise information systems are patently stodgy.
Here is an example of enterprise stodginess that we have encountered right here at Burton Group. My colleague Joe Bugajski wrote a paper on governance that is quite popular with our clients. However, we have no way of knowing how many readers agree with Joe’s recommendations or how many readers have implemented or plan to implement Joe’s recommendations. We don’t even know how many client “key issues” or “problem statements” Joe addressed in that paper.
To find out how many readers agree with Joe and are implementing his recommendations, we will need to implement a way to better collaborate with our clients. We will also need to make sure that inside these collaboration system(s), we use the same customer identifiers that we use for customer data within our other information systems. IOW, it will not help us to have our collaboration systems tell us that “Customer 47” is implementing Joe’s recommendations and then have our CRM system tell us that it has no record of a “Customer 47”. Clearly, effective collaboration and proper data identifiers are a powerful combination.
To find out how many “key issues” or “problem statements” Joe addressed in his paper, we will need to go back and add that metadata to Joe’s document. And then we will need to change the code (in perhaps several layers of software) to make use of that new metadata.
We have to make those code changes because the metadata for our data is hard-coded and our data is trapped behind our software. These are problems with NxN-tier architecture that neither SOA nor Agile can remedy. Whenever you have to modify software in order to take advantage of new data and metadata, you have stodgy systems.
Eliminating this stodginess requires a different mindset. You have to stand enterprise IT’s traditional approach to creating enterprise information systems on its head. Basically, you have to use flexible metadata and you have to put the data in front of the software instead of behind it. You must not bury the data behind software that is hard-coded to only understand certain types of information. You have to use commodity software that can readily understand, process, and display lots of different information types.
In order to avoid in stodginess in enterprise information systems, you need:
- Front-end software that can understand new data and metadata without modification
- Back-end software that that can help you create and recreate your metadata
I don’t have room in this blog post to tell you what that software is -- I only have room to tell you what that software isn’t. That software isn’t a relational database trapped behind software for application logic behind yet more software for the UI. Avoiding stodginess requires something else entirely. I will describe this front-end and back-end software and its associated cures for enterprise IT stodginess in my next blog post.
Comments