Information architecture is required to deliver the promised value of SOA

Last month, I posted that “SOA is limited in its ability to create value for an organization”  because services are often not reusable.  At some level, developers seem responsible for the failure because we are tasked with developing tailored line-of-business applications, so we do not consider the broader goal of enterprise reusability.  And, as I noted in that post, we also have difficulty transitioning from a “build it” mindset to a “find it” approach where we look before we leap into development.  At the same time, business stakeholders share responsibility for the failure of SOA.  These application owners and line-of-business executives are focused on meeting short-term business needs, and they often shortchange the required ongoing investment in enterprise-wide design, governance, and training.

I believe there is another significant (and overlooked) reason why SOA does not deliver its promised business value:  information architecture.  By design, services expose endpoints into business application silos.  These services cannot be effectively integrated unless they all speak the same language – that is, unless they all understand and share the same information architecture.  In the absence of SOA, application developers create line-of-business applications that have their own unique data stores, and they use data synchronization to push and pull information across the enterprise.  The design is effective because business owners do not have an expectation that information will be integrated immediately.  This architecture does not scale when SOA becomes an IT or enterprise goal.

SOA introduces a significant increase in operational complexity because, suddenly, multiple applications share part of the enterprise picture – but none are complete.  The old patterns of nightly sync jobs and data reconciliation are not enough.  Business owners demand that at least one of the systems serve as a trustworthy system of record in real time.  Developers respond by scheduling hourly (or even more frequent) sync jobs, and the architecture struggles to keep pace with the business demand for high-integrity data.

So, what’s the solution?  SOA must be coupled with information architecture so that critical information can be consolidated, not replicated, and multiple applications can share a unified view of master data.  Senior management must define enterprise-level business strategy for technology rather than delegating all technology decisions to business units and their line-of-business needs.  At the same time, enterprise architects must explain to business unit leaders that the data integrity they demand will only result from tighter integration with the information in other business units.  Information architects should outline master data management programs and organize the governance structures required to support them.  Technologists must justify these programs based on business objectives, and ultimately, LOB data fiefdoms must be replaced with an enterprise view.

Then, and only then, will SOA deliver its full promised value.  Applications will share a common understanding of critical business information.  Updates will propagate natively to other applications rather than relying on a Rube Goldberg framework of jobs and packages to synchronize, consolidate, and cleanse data.  Data quality will improve, and governance structures will protect its ongoing integrity.  Most importantly, business leaders will share a common set of actionable knowledge to drive operations and analytics.

A serious evaluation of information architecture seems absent in many discussions about SOA, but this enterprise information management is the missing link.