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 SBAs 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 corporations 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 Its Own Or Be Part Of A Larger Set Of Functions That Constitute A Larger Service; But Its 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 UoWs 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