Mike Daconta | Design stovepipes out of the picture
Reality Check | Commentary: To eliminate IT stovepipes, start by recognizing that most systems are that way by design
I recently had an interesting discussion with a senior systems analyst about stovepiped systems. He claimed, correctly, that almost all systems are stovepipes.
Most systems solve their customer's specific problems. To do so, an engineer builds a system that gets the customer from point A to point B as quickly as possible. Sounds OK, right? It's not.
Systems that follow this default path are destined to become stovepipes. Eliminating stovepipes goes beyond solving local problems ' you must prevent enterprise ones. It requires a whole new level of understanding on the part of the developer and upfront education of your customer to both achieve system proficiency and prevent stovepiping.
First, know the enemy: A stovepiped system is one in which the graphical user interface is hard-coded to communicate only to the middle tier, which is hard-coded to communicate only to the back end, or data tier.
The acid test of whether your system is a stovepipe: Can you get at your data only by using your GUI? If the answer is yes, you have a stovepipe.
'Let the data structure the program' is classic guidance from the 'The Elements of Programming Style' (1978) by Brian Kernighan and P.J. Plauger. That one concise statement sows the seed of our solution.
The linchpin is designing your system's functionality ' which solves the customer's problem ' from the perspective of the data first (distinct from the functionality). The key lesson here is to stop building systems from the user interface down and instead build the system from the data up.
In other words, part of your design must be the design of a headless system.
How do you design a headless system? Just remember three acronyms: XML (for the data), MVC (for the service architecture) and PKI (for security).
Extensible Markup Language (XML) lets you create an open, application-independent data format.
The model-view-controller (MVC) architecture enforces the separation of concerns whereby multiple views communicate with a single model, which is controlled by multiple services.
The public-key infrastructure (PKI) is the cornerstone of your Web-services security framework, which lets you authenticate trusted users.
Drilling down along all three of these axes will get you a multiheaded system, which includes headless access, that serves both the immediate customer and the enterprise.
A Web service receives an XML input payload, processes it and delivers an XML output payload. As such, Web services provide the perfect mechanism for your middle tier in a headless system. The best commercial example of Web services is the Amazon Web Services stack (www.amazon.com/webservices). Amazon has successfully implemented e-commerce services (catalog search and payment services), search services (such as Web search and Web statistics) and infrastructure services (such as Web storage).
Following this recipe lets you design your information technology systems as enterprise building blocks. Over time, you create an IT environment where business users can create their own enterprise mashups by dragging, dropping and connecting data to services. Such an environment will not occur by default ' you must design against the default, against the stovepipes.Michael Daconta, former metadata program manager for the Homeland Security Department, is chief of enterprise data management at Oberon Associates. E-mail him at firstname.lastname@example.org