Todd Biske: Outside the Box

Brenda Michelson has posted a summary of current conversations between myself, Anil John, and Mark Griffin. My apologies for not posting this directly as a comment, but the response was getting long. She had four questions to continue the conversation that I’d like address as much as I’m able.

1. …understanding the business is critical in preparing an organization for SOA. But what else? As Mark asks, how can he ensure his organization is ready to deliver?

   My first comment refered to the importance of understanding what it takes to be an internal service provider. You can’t just build a service and forget about it. Outside of that, however, you need to have an understanding of the entire picture of SOA adoption. Ben Moreland of the Hartford gave a great presentation on their SOA Maturity Model. It’s a multi-dimensional effort. My dimensions would be (and they are very similar to what Ben presented):

   • Strategy: Bottom up, top down, etc.
   • Standards: What industry standards are you using? What internal standards are you creating?
   • Governance: How are you enforcing the standards? What oversight do you have in place (more on this later)
   • Capability: What is are the skills and capabilities of your staff? How are you training them?
   • Technology Infrastructure: Tools and technology for both development time and run time
   • Processes: What processes have you put in place to support all aspects of the adoption?
   • Architecture: What services have been created? What services do you plan on creating? Do you have references architectures, blueprints, and patterns to facilitate development?
   • Organization: How is the organization changing to support the effort? Do you have dedicated development teams?
2. And the other fork from Mark: “How do I get my IT organization more involved with the business to really understand it?”

   I recommend trying some user-centered design techniques. It’s been a long time since I’ve been able to practice them myself, but if you can find a way for your IT staff to do some field observation, they could learn a lot. Perhaps we need the business to sponsor a “Take your IT buddy to work” day. While I may be poking a little bit of fun, you’d be surprised what you could learn by just tagging along with a business worker for a day. Brenda, is there anything you can share from your own experiences or that of the Patricia Seybold Group?

3. What tools and/or methods are effective for top-down, bottom-up business and service modeling?

   I haven’t had the opportunity to dig into this personally. Clearly, existing modeling tools for software development projects work for the bottom-up case. For top-down, it’s all about business process modeling. I’ll leave this one for other people to offer suggestions.

4. How about that “elusive” governance? How do you sell Governance to IT and Business Leadership? Where do you get the money for people, process and tools? How do you convince people “Governance is good for you” rather than “Governance is a roadblock”?

   This is a tricky one. If your organization has some form of formal reviews, you’re already performing some governance, so it’s simply a matter of utilizing the existing gates to address service issues, such as reviewing the existing service library for possible services, determining where organizational ownership should lie, etc. If you don’t, then it’s time to start gathering some evidence to show the need. I would expect that sooner or later, a situation will arise that formal governance should have caught. The other way I would try to recommend governance is to first get some understanding on barriers to SOA, the biggest of which are the constraints placed by projects. If the project team stays constrained, odds are the effort will only yield results that are of value within those constraints. The only way to get around this is to give someone the responsibility to look outside of those constraints. Assigning the project staff to do this puts the project at risk. A better approach is to assign someone from outside the project to do this at the appropriate times. If you’re able to get people to understand that thinking outside of the box is a requirement for SOA, they may allow a pilot governance program to begin.

One Response to “Preparing for SOA Part 3”