Todd Biske: Outside the Box

I’m sitting in a case study session on SOA Governance. Barney Sene, VP and CTO of Ingram Micro, is currently speaking and just had an interesting slide up. Because they are a global company, one of the things they always do is examine any proposed service (documented through a Service Requirements Specification – SRS) for specialization that may be required for global requirements, versus the context in which that SRS may have been created. I now work for a global organization, and now clearly understand the need for this. I have firsthand knowledge of a business service that will have differences in how it must operate based about the geographic regions involved. Barney’s slide demonstrated how the SRS provided a significant percentage of the final definition, but these other factors like globalization chipped away at the remaining 20%.

From a governance perspective, what I liked about this was that it presented an approach that didn’t mandate, but rather encouraged appropriate behavior. If the company has stated “We are a global organization” rather than acting as a collection of regional organizations, then every project should be asking the question, “Are there any regional nuances that must be factored into the architecture and design of what I’m producing?” This example also got me thinking about what other factors should be explicitly encouraged in this same way, simply because people aren’t used to thinking that way. Globalization makes perfect sense. Security also makes sense. We have to realize that many designers and developers are primarily concerned about the functionality at hand, and need some encouragement to think about factors “outside of the box” that may influence both the non-functional areas as well as the functional areas. Because this is a shift in thinking, it must be encouraged first, enforced second. Dangle the carrot, and only use the carrot when necessary. What other items belong on the list that can take a service from an 80% solution to a 100% solution?