SOA Top-down and Bottom-up / Flexibility and Reuse
SunGard meets regularly with its customers both individually as well as in groups and forums to gather input and validate direction. One such counsel is the CSA & Infinity Customer Advisory Board, which is made up of technology leaders from a cross-section of the market we address. In a recent meeting, I presented a process paradigm we’ve matured as a company through years of our SOA effort. The discussion that ensued validated the concept as a practical approach to SOA. The paradigm is a combination of top-down and bottom-up collaboration. The top-down approach refers to the business-centric domain, which focuses on the flexibility in solution creation and delivery, solving business problems, addressing customer needs and thereby growing revenue. The bottom-up approach refers to the technical-centric domain, which focuses on common code parts, sharing components, fine tuning architectures and best-of-breed development practices. One without the other tends to throw the process off-balance, so a mix of the two is ideal, but the structure of how they weave together is a little complex, and (at least in our case) isn’t at all trivial, and I have to admit that we’re still learning too.
Consider the key drivers of the two approaches first. Most agree that flexibility (a revenue generator) is a stronger and shorter-term benefit than reuse (which is a cost-savings measure). Most of the early press and hype on SOA gave the distinct impression that SOA benefits favor cost savings enabled by reuse, but recent research is validating that flexibility is more important than cost savings, at least in the short term.
Given that, it’s important to realize that the business domain (top-down) needs to weigh in heavier in the mix, at least as it relates to the prioritization of the SOA activities across the board (see my blog entry from last year here regarding the importance of a business focus on SOA). This fosters the energy required to accelerate the flexibility benefits early on. Meaningful reuse takes time anyway, in fact those that realize that sooner rather than later end up less trodden down by missed expectations. In a delicate balance, developers and architects need to deal with the shared architectures and components that both follow those priorities as well as deal with the lower-level technical aspects the business domain doesn’t need to engage in (stuff like which message caching approach to use, which object-relational mapping to adopt, what debugger to leverage, or which API to chose for a particular task, etc).
SOA strategies that weigh heavier on reuse create problems by focusing on technical design and implementation factors that are actually less likely to produce viable business value than functional design models, (which are the focus of flexibility and change priorities). Consequently, if the bottom-up focus is in-line with the business priorities, and governs itself within the discipline of the lower-level architecture (while at the same time, not dragging the business folks too deep into the technical details), then the mix works.