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 an 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
What I like best about this definition is the emphasis on services as a unit of business alignment.
According to Boris, because of the way IT needs are addressed, the enterprise becomes a mesh of siloed applications, each created with only partial business alignment. Enterprise business processes becomes shaded by application specific purposes. According to the article applications “manifest themselves as islands of data and islands of automation.”
Islands of data develop when enterprise concepts are defined narrowly to meet specific application needs. These islands of data cause semantic dissonance as each application models a tiny, discolored slice of the enterprise concept. Such islands results in difficult to reconcile data duplication between applications. 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.
Islands of automation are the applications themselves. These 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 invoke multiple executables or web sites to perform work. This context switching costs the enterprise in terms of lost time, concentration, and duplication of efforts.
SOA then, as an architectural style, should strive to end semantic dissonance in the enterprise and bring about business alignment. SOA 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.
This means if we want to do more than pay lip service to SOA we’re going to have to cause some enterprise pain. According to Conway’s law the enterprise will produce designs which are copies of the communication structures of these organizations.
This means if we have four teams bent on doing SOA but projects are divided up around existing application silos, we’ll just get four additional silo applications. According to Conway, 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. How projects are conceived and budgeted, how teams are formed, even the very structure of IT governance will need to be examined.
Next time we will discuss Udi’s definition of a service and how it is critical to a successful SOA.