What causes silos? Should we really care about them? These questions keep popping into my head as I have revisited my report about LINQ, ADO.NET Entity Framework (EF), and ADO.NET Data Services (Application Platform Strategies, "LINQ and ADO.NET: Brilliant and Confusing"). The subject also arises in research for an overview about an IT Governance Framework that I am writing. With my data colleagues, we have talked about Lyn Robison's MODS architecture (see the Data Management Strategies overview, "The Methodology for Overcoming Data Silos (MODS): Using the New XQuery Development Stack", and Lyn's DMS blog post, "Powerful Business Intelligence").
Microsoft's newest data access technologies foster silo building but these tools do not stand alone in this regard. IT Governance according to Peter Weill of MIT's Sloan School (Weill and Ross, "IT Governance on One Page") identifies six IT decision making archetypes, one of which encourages silo building to support rapid growth of a business. The MODS architecture admits silo busting through consistent application of XML-flavored technologies (read open standards for data exchange and access). Most of my clients complain that they have far too many silos. Most architects, including me, lament the existence of silos for hygienic reasons like privacy and security controls, data and application integration, and cost effective operations and maintenance. But are silos an inevitable creation of IT and hence unavoidable?
One cause of IT application and data silos is what I have called the "bag o' cash" (BoC) model for IT governance (the Feudal archetype according Weill). BoC most strongly yields new applications and data stores because there is a 1-1 correspondence between a business entity that wants an application and a development team that builds it - usually by yesterday. An IT organization that employs BoC will inevitably build redundant applications. Their data will be scattered across a host of DBMSes. Their applications will require copious time and effort to improve or fix. But, is this an acceptable price to pay for strong revenue growth? Perhaps.
ORM tools like EF hasten development by reducing the mental fatigue caused by design context switches between object oriented coding and relational algebra. These tools transform an object model into a relational data model with the push of a button (see the Applications Platform Strategies overview, "Object-Relational Frameworks: Finding the Right Mix"). It is reasonable to assert that button pushing takes less time and money than relational data model design and implementation. If the push-button data model works well for the application, then what is the harm in button-pushing other than an architect's disdain? If there is a well considered and properly implemented data services platform (DSP) infrastructure, then this question can be answered in the negative (i.e., the harm is to make data that should be more accessible and secure markedly less so). If not, then the answer must be something of the form - Well, it depends.
Perhaps MODS is the right answer. Build the application and its persistence store agilely but consistently. Stick with a single XML-flavor technology stack. Deploy only those commercial off-the-shelf (COTS) products that support the XML-flavor stack and are RESTful by nature. Worry integration using data services borne naturally of the consistently flavored technology stack. Employ peer-to-peer RESTful design for information exchange, thereby avoiding copious quantities of data copying. But, for many IT shops this just might not work because legacy flavored technology long ago preempted this move. And, will a business manager with a bigger BoC and a penchant for telling IT how to code and which products to buy ever be wrong?
Are application silos inevitable? It's your turn.
Comments