So I started out blogging that Services Based/Oriented Architectures have been confusing to even IT specialists, imagine how the business feels! The confusion result from the definition of SBA’s being morphed by analysts and vendors alike. A web service is not a SBA service – it is similar but a small subset of a SBA service. You see, a SBA (SOA, EDA, and CEP) requires information abstraction using metadata, whereas web services do not use common metadata (definitions of information elements).
The old adage of a single dictionary remained true and this would be one of the original principals that we used to define an SBA back in 1995. That along with that a business transaction would have to adhere to ACID principals (Atomicity, Consistency, Isolation and Durability) – but we first needed to define a transaction. We knew that if we engineered this right, every service could be re-usable and that would create agility!
This is where Governance comes in – Governance links technology with the business --> which creates a common language and understanding of the shared business information --> to facilitate development of business around the information. There is even confusion here – Governance is the development and integration of a set of rules (policies, guidelines, framework, and/or standards) for managing the corporation’s assets (i.e.: Data). Whereas, Stewardship is the execution of the policies and procedures set forth by the Governance rules.
Governance and architecture are inseparable when it comes to building a SBA – you cannot build one without these. Some vendors want you to think this is not true…
We started by decomposing the business process into its functions and processes and drawing them graphically. We next circled the area on the graphic that we would tackle (iteratively); this would give us the interactions for the future that would need stubs. Finally we would create the initial information element referred to as a Unit of Work [UoW]. We make the definition that a UoW was a grouping of data attributes (or elements) that provided for a complete business or technical transaction (update customer address, process credit card, etc.).
Finally we created the foundational statements that would define a SBA:

  • A service is an application that operates on or delivers a Unit Of Work [UoW]
  • Is Designed To Receive Requests From Any Source Making No Assumptions As To The Functional Correctness (Syntactic Or Semantic) Of An Incoming Request (In The Future We Would Not Know How We Would Be Using These!)
  • Within Each Request, Encompasses A Complete & Independent Unit Of Work (Business Or Technical!)
  • May Stand On It’s Own Or Be Part Of A Larger Set Of Functions That Constitute A Larger Service; But It’s Scope Is Such That Each Request Leaves The System In A Long Term Steady State
  • Is Designed For And Provides For A Network-Accessible Interface
  • Keep UoW’s Together That Change Together (High Cohesion) & Build Separation Between Units That Change Independently (Low Coupling)

In the next post, we will speak about the convergence of SOA and BI – a topic that I have been speaking to at conferences for the last couple of years …

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access