I have long said that the failure of SOA programs has to do more with politics of data/process ownership than the technologies on which you build these enterprise SOA initiatives. Furthermore, that the failure to address the information models as first class citizens in a Service Oriented Architecture presents huge risks to both adoption and down stream architectural stability.
As background, working for an Information Infrastructure company, and having worked from a “computer company” in the past, the realization is startling wrt. how easy it is to “re platform” and application (note Sun’s precipitous decline in the face of Linux) vs. re-platform it’s data… after all: Computers are worthless if they have no data to process. And to further this point, as processors got faster, at a rate much higher than the busses that fed them, they became more like space heaters. On the other hand, the information supply chain has grown in relevance as technologies like de-duplication, parallel readers, advanced caching algorythms and even flash disks prove to have a more substantial impact on timeliness of result and thus architectural criticality.
So what does that background have to do with our story? Well all businesses are being told to do more with less; investments are being targeted to deliver real ROI as measured in Revenue, and to some extent, though SOA enabled processes support the automation of processing paths, the programs that I have seen fall short in that traditional SOA offers enterprises the OO promise of a singular Service (first class) which is responsible for Employees, Customers, Accounting, the business unit functions, and this falls short when you ask the simple question… but really who owns the “Customer”… Okay so now everyone raises their hand… the problem now becomes one not of a singular service, but the federation of capabilities across systems exposed through a consistent interface… all well and good until you ask: what is the information model upon which these interactions act. Again, the political fight ensues as to who has the best model, to which there is no answer except the one “whomever has the money makes the rules”… okay so sales wins. No really, SOA needs to become substantially more grounded in information modeling and Model transformational techniques with the recognition that there will never be a single canonical model for the business. But, how do we navigate across these models? EIM(MDM)/EII(MDM) techniques of course? But as we build these transforms to move from model A to model B potentially through some canonical intermediate, we need to concern our self with the impact of changes models included within the orchestration… enter model governance. Yes, the G-word. Governance seems to be the impossible cross-matrixing of staff to produce some semblance of order within a process in which politics, unknowns and of course expectations wreak havoc on the scientific method. One of the critical expectations which needs to be continually addressed is timely-ROI, you have but 6 months to demonstrated tangible evidence of success or you risk losing support… now back to the software development/SOA domain.
eSOA programs have long put waterfall methodologies out of vogue because they seemed to lack “pace and progress” to this end tight spiral RUP based methodologies and even the Agile methods have come into vogue. Learning from that, there is an opportunity for Information Architects to emerge that don’t boil the ocean, but do through an iterative and constructive process continually refine the models, transforms, interactions, accessory/usage policies, stewarding mechanisms that are required to improve consistency (think SEI/CMM scale). Sure, it’s a never ending journey, but at least you don’t get too far away from the business to be viewed as a field of dreams (inconsequential). To this end “Agile Data Governance” is coming into vogue, alongside the realization that SOA, like IT is about the information, and forgetting that we are doomed to follow in the footsteps of failed efforts.