I've been used to thinking of SOA as "Dependency-Oriented Thinking" for such a long time that it suddenly struck me that I should readily be able to postulate "dependency principles" that can be applied at each of the BAIT layers. As it turned out, I was fortunate enough to have some actual case studies to verify my proposed set, and these cases were selected for being representative of different tiers, so they were quite comprehensive.
It turns out that the lesson to be learnt after a post-mortem of each of those case studies was that one or more dependency principles had been ignored or violated, resulting in the problem that was being faced. The corollary is that an organisation that scrupulously adheres to these principles will end up achieving SOA.
So, without further ado, here are the dependency principles:
Business Layer Principles
1. Traceability – Enforce core governance; ensure that everything that is done makes sense with respect to the organisation's Vision
2. Minimalism – Challenge assumptions, reject unwarranted constraints, do no more than required, reuse functional building blocks
3. Domain Insight – Understand the true nature of the business; don't be misled by superficialities or conventional wisdom; re-imagine the business from first principles
Application Layer Principles
4. Cohesion and Coupling – What belongs together should go together, with minimal links between distinct systems; question instances of a single logical function split across multiple systems, or multiple logical functions combined within a single system
5. Implementation versus Exposure – Group operations that share a Domain Data Model and business logic into Products, those that share an Interface Data Model into Services
6. Variants and Versions – Identify multiple concurrent flavours of each logical operation, establish a means to support ongoing changes to their logic and interfaces
Information (Data) Layer Principles
7. Inside versus Outside – Distinguish the Interface Data Model from the Domain Data Model; use this to guide the grouping of operations into both Products and Services
8. Content versus Context – Separate the core data elements of the Interface Data Model from its qualifying elements; use this to categorise Variants and minimise Versions
9. Abstract versus Concrete – Create a data type hierarchy for both Content and Context elements; use this to expose multiple Variants as a single logical operation
Technology Layer Principles
10. Bundling Dependencies – Avoid introducing fresh dependencies between unrelated components in the process of implementing business logic
11. Late Binding – Delay unavoidable dependencies till the last responsible juncture
12. The Right Tool for the Job – Implement logic using the most appropriate mechanism
When you put these principles together with the entities at each layer, it forms a simple and mutually reinforcing set of techniques, and the complete approach is what is "Dependency-Oriented Thinking". Refer back to the diagram I had used in my earlier post.