Beware Islands of Data & Automation

To learn something complex and paradigm shifting like service oriented architecture (SOA) can be tough. It’s doubly difficult when there is little agreement on what the definition of the thing being learned is.

If you look into its earliest history, SOA is usually defined in terms of specific technical stacks such as SOAP. The W3 penned a more general definition when it defined SOA. The W3 discusses the desirable characteristics of SOA such as exposing metadata, network friendly, and platform neutrality. My problem with these (and many) definitions of SOA is they lean too technical. If SOA is just another technical stack, it’s not architecture. It’s an implementation.

The definition of SOA I found which I like the most is from an article by Boris Lublinsky. it states that:

SOA can be defined as an architectural style promoting the concept of business-aligned enterprise service as the fundamental unit of designing, building, and composing enterprise business solutions. Multiple patterns, defining design, implementations, and deployment of the SOA solutions, complete this style – Boris Lublinsky

This definition appeals to me as it emphasizeds services as the unit of business alignment.

According to Boris, because of the way IT needs are addressed, the enterprise becomes a mesh of siloed applications. Applications are created in a vacuum, with only partial enterprise alignment. Enterprise business processes becomes shaded by application specific purposes. and, according to Boris, “manifest themselves as islands of data and islands of automation.”

Islands of data develop when enterprise concepts are defined too narrowly to meet specific application needs. Such islands results in difficult to reconcile data duplication. For example, an insurance claims application may contain demographics in a different format then a CRM application. They may be similar but not the same. These islands cause semantic dissonance as applications models tiny bits of the enterprise. Each is a discolored slice ignorant of the whole.

Islands of automation are the applications themselves. Automation islands force enterprise users to “application hop” in order to complete meaningful work. Business processes become disjointed, often requiring users to copy and paste between applications or visit multiple web sites to perform work. This context switching costs the enterprise in terms of focus, duplication, and ultimately lost productivity,

SOA should strive to end semantic dissonance in the enterprise and should bring about business alignment. It should tear apart application islands in order to reconstruct the enterprise as a series of autonomous services, each with clear ownership and responsibility for its semantic concepts and business rules. Yet according to Conway’s law the enterprise will produce designs which are copies of the communication structures of these organizations. This means to pay more than lip service to SOA will require enterprise upheaval.

If we have four teams bent on doing SOA but projects are divided up around existing application silos, or even worse technologies, we’ll just get four additional silo applications. If we divide IT by technical lines (Development, Management, Support, Help Desk) we will find each group acting autonomously and aligning along technical boundaries rather than business aligned service boundaries. If we want to do SOA with a capital S and reap all of its rewards, we must accept it will involve changes to IT structure: How projects are conceived and budgeted, how teams are formed, and how IT is governed.