Todd Biske: Outside the Box

Archive for March, 2006

Miko Matsumura recently posted about the myth of starting small which was followed up by a response from Joe McKendrick of ZDNet.

Miko stated that the only ones getting it right were ZapThink, who state that “the things you do in a pilot are the exact opposite of what you need to do to get to enterprise scale.” For the record, I agree. This all comes down to defining the pilot properly. In their book, “Service Orient or Be Doomed!” Jason and Ron call out three SOA Pilot essentials: an architectural plan (the pilot will cover some portion of it), a specific scope, and clear acceptance criteria.

There shouldn’t be much controversy over these, but yet, the case studies and whitepapers that I see presented don’t have these elements, and it’s usually because the study is equating web services usage with SOA. Taking a user-facing customer portal and extending it by allowing customers to integrate their systems directly can be a good thing, but is it really an SOA pilot?

One of the key things, in my opinion, in a proper SOA pilot is to pick a problem that will require the organization to see the cultural changes that are necessary to become a service provider. In the portal case, the group maintaining the portal is already a service provider, so there’s no big stretch there. Instead, we need to find a service that has potential for reuse, and has no clear owner in the current organization structure. This scenario will give a good dose of what SOA is all about from an IT perspective. If you’re using the pilot to sell SOA to the business, you’ve got to be even more careful in your selection, especially in picking the right service consumers. Agility is a particularly difficult thing to pilot, because it only becomes evident when something needs to change. If a pilot is putting it in place for the first time, there’s no change involved. What can help pick the right pilot? The architectural plan. If the architectural plan isn’t already service-oriented, however, what do you do?

My advice is to first focus on why you’re doing the pilot, and what you hope to achieve/prove. If IT begins to understand what being a service-provider means (you need to have a pilot that have distinct service consumers and providers to do this), it is progress, even if the service isn’t as coarse-grained as it should be or can be used as a good case for business justification. It may not be SOA yet, but it is a step in right direction. Once you understand how the IT organization needs to change, now you can pick a service with a bit more impact that really can show the business that IT has its act together and can make a difference.

I had the opportunity to meet Eric Newcomer, CTO of IONA, at the InfoWorld SOA Executive Forum last week. He recently blogged about some of their interchanges we’ve had on a Yahoo SOA group as well as the things he heard from end users at the forum.

What Eric points out is that “Vendor suspicion runs very high.” He goes on to say, “I think it was someone on the SOA discussion list who said that IT vendors today are like going to an automobile dealer and having the dealer tell you what kind of car you want to buy.”

First, I commend Eric for posting this, since he is, after all, a vendor. Just as Eric has called on all vendors to rethink how they’re working with their customers, I encourage all end users to rethink how they’re working with their vendors. It’s a two way street. Vendors can only work from the information that their end users give them. If you want better products, let your vendors know. The ones I’ve spoken with would love it if they had more interaction from their customers. Try asking them for a corporate visit, or a phone call with the product manager for your solutions. I bet they’d be more than happy to accommodate your request.

Another person I had the opportunity to get some face time with is Miko Matsumura, VP of Marketing and Technology Standards for Infravio, as well as the Chair for the OASIS SOA Adoption Blueprints Technical Committee. We had a good chat about SOA governance, as well as discussed some upcoming things for the committee. What’s great about what Miko’s trying to do through OASIS is the fact that it is adoption blueprints. This isn’t some vendor’s reference model intended to sell product, this is a set of blueprints rooted in the experiences of the end user community. I would love to see end user participation increase on this TC, as it will only increase the quality of the deliverables and help us all with our SOA adoption efforts.

Thanks again to InfoWorld for putting on a great event. In addition to Eric and Miko, I also chatted with/met Jeff Schneider and Hjalmer Danielson of MomentumSI (thanks for the t-shirt), David Chappell of Sonic Software, David Linthicum of BridgeWerx (and the voice behind the SOA Expert Podcast), Andrew Nash of Reactivity, Phil Wainewright of ZDNet and LooselyCoupled.com, and Sean Fitts of AmberPoint. It was a great event.

I’ve been at the InfoWorld SOA Executive Forum today, including my stint on Phil Windley’s panel on SOA Governance. I was joined by Ed Vazquez from Sprint-Nextel, along with two last minute substitutions, Jeff Schneider of MomentumSI and Sean Fitts of AmberPoint.

As Ed pointed out, we covered the entire SOA Governance map, whether run-time, design-time, and everywhere in between. Thankfully, we didn’t have to employ any Jerry Springer-esque techniques to keep the audience interested. The interesting part for me was that we were all coming from different points of view, but yet we seemed to agree on all of the major points. My points were consistent with my previous posts, which is to match your SOA governance to your corporate culture. Just as we shouldn’t boil the SOA ocean if the organization still develops in silos, we can’t govern everything if we’ve never governed before.

Both Jeff and Ed made great points on the importance of grass roots governance, that is, relying on the people in the trenches. An ivory tower approach to governance will not be successful, especially when it’s the people in the trenches who have to adhere to the policies.

All in all, it was a lot of fun. Thanks to Phil for the opportunity, and I hope we can do it again.

The latest ZapForum Podcast was a conversation between Ron, Jason, and Charles Stack from Flashline. As always, this was an excellent conversation. One of the things that was very interesting for me was the three patterns for SOA governance that Charles introduced. They were:

1. The gating pattern. You need to have appropriate gates in the development lifecycle at which reviews can occur. This is absolutely critical to avoiding JBOS. The development team is most likely to develop to the constraints of the project at hand. If you don’t provide an external review that brings in a perspective from outside of those constraints, your chances of getting a service that is useful outside of that project are very slim.
2. The library pattern. This is self-explanatory. If you want people to reuse services, they need someplace to find them.
3. The dashboard pattern. Measure and monitor! This has been a key part of Flashline’s products from their early days exclusively focused on reuse. Even beyond reuse, it’s amazing what insight you can get into your systems by add a little bit of metrics. It’s very easy to add a SOAP mediation layer in to collect this information.

To this list, I add a fourth pattern: the legislation pattern. We can’t do a review unless we have something to review against. What’s really interesting about this one, however, is the different approaches to legislation. It’s very important to pick a legislative, or governance, style that matches your corporate culture. There are direct parallels to traditional government. Google “types of government” and you’ll find a number of them (this site has quite the exhaustive list). There is no one style that is best, and you need to match your company culture. A country rooted in deep religious beliefs is going to tolerate a theocracy much better than a statocracy. If you presently have no formal reviews in your enterprise, you need to give careful thought to whether legislation should be done in a dictatorial fashion (sometimes a strong arm is needed to lay down the law) or whether legislation should be more democratic in nature, to build the backing of the developers that must adhere to the law. Anarchy will definitely not get you an SOA. Too many legislators may stymie the agility and flexibility you hope to achieve through SOA. What approach to governance is your enterprise taking?

A subject that I’d love to see discussed more is the role that SOA can play in education, specifically elementary education. Our schools have to make increasing use of technology, yet they certainly can’t afford to spend a lot of money on it. How can SOA play a role in allowing elementary schools to get the most from their technology dollars?

One good thing is that the standardization that has brought about the emphasis on SOA in the corporate world will likely lower the cost of technology for schools. Continued advances in SaaS capabilities should certainly allow many of the administrative functions to be handled through a web-based provider. If SMBs can utilize salesforce.com for CRMs, there’s no reason why there can’t be a schoolforce.com for elementary school administration (except that schoolforce.com is already claimed by SportPal Team Management- we’ll come up with a better name).

My father-in-law is the principal of a K-8 private elementary school. Unlike private colleges, private elementary schools face significant challenges, and he has to utilize every grant and donation, no matter how small. The administrative challenges of this are daunting. It’s not simply about having an online grade book available. They need to keep detailed records regarding student attendance, paid lunch counts (versus kids who bring their lunch), etc. and report it on a regular basis to the authorities that administer the grants. I’m sure this is just the tip of the iceberg. I’m sure technologies used for inventory management could be applied to collect student data in real time, and then send that information to a web service exposed by the grant authorities, eliminating a lot of the paperwork associated with the effort.

Beyond SOA, I think schools can also leverage the social networking technologies associated with Web 2.0. After all, what elementary school doesn’t have a parents’ organization? I’m still disappointed that some open source group hasn’t created a complete school intranet with LAMP and made it freely available.

Are there other more philanthropic uses of SOA? Leave a comment or trackback with your thoughts.

I received my copy of Service Orient or Be Doomed by Jason Bloomberg and Ron Schmelzer of ZapThink earlier this week. I’m through the first 50 pages, and it certainly has my interest, since it is touted as a business book about business concepts, yet, in their own words, it’s written by a couple of technologists. Before I get to the subject of this blog, one warning on the book. Jason and Ron seem to have gone to extremes to follow up with the title. In addition to already being everywhere by virtue of the number of times they’re quoted, the next time I went to Amazon after purchasing the book, there was a photo of Ron, courtesy of Amazon’s new “plog” feature, asking me for feedback on the book. I’m wondering now that if I don’t service orient everything, either Jason or Ron will keep appearing at bizarre places. I’ll go to buy milk on my way home from work, and they’ll be in the dairy case. I’ll go out in the morning to get the paper and they’ll be at the end of my driveway. This could get scary.

Anyway, on to the theme of the blog. The book already has me thinking about the business side of SOA, and I haven’t even reached the sections that really deal with it. We all know that applying service-oriented principles to tactical projects runs a risk of creating JBOS- Just a Bunch Of Services. If we don’t take look at the broader business picture, we won’t reach our goals. Unfortunately, we like to stay in our comfort zone of IT. With all the best intentions, the IT workers on the project begin to ask “What if?” as part of the service interface design. It is likely that this will broaden the scope of the interface, but there’s no guarantee that this will yield an interface any more appropriate than if the IT team had just looked at the project requirements at hand. This pattern of asking “What If?” may result in a number of modifications to the interface that are simply the result of a paranoid influence- Paranoia Oriented Architecture! The decisions are all rooted in possible events that may occur, without an understanding of the core business drivers that could create those events.

To that end, what are the common business drivers/strategies that may point clearly to areas for service interfaces? Here’s some obvious ones I’ve thought of, leave some comments or trackback with others that come to mind.

• Growth by merger/acquisition. Clearly, this has implications when the core processing systems of the two companies need to be combined to eliminate redundancies. The exact areas of interface will vary by company.
• Improved customer experience. How do you improve customer experience? One way is through personalization. Personalization requires gathering information about the customer, and then integrating services based upon their profile. Once again, if things aren’t broken down into composable elements, you’ll only get so far. This also begins to branch into cross product sales, such as is common in the insurance industry
• Reduce costs through by eliminating redundancies. While redundancies can be created through mergers and acquisitions, there are plenty of redundancies that may have already existed prior to the merger. Certainly this was the case in the dot-com bubble, as companies tried to establish an internet presence.
• Improved efficiencies through self service. This is very similar to improving the customer experience, however, this may be directed completely internally.
• My company is a service provider. Okay, this is a no-brainer, but may not be as easy as it looks. What if the service you’re providing is more of a human-based service? I would still argue that sooner or later, someone will want to integrate their system with yours rather than go through the human channel.
• Regulatory drivers. Regulations create new auditing requirements. The easiest place to capture things are at the interfaces between the systems, i.e. the services. If we don’t have services in the right place, the cost associated with regulatory compliance will be high.

If you’re interested in this, another book besides Service-Orient or Be Doomed is Services Blueprint: A Roadmap For Execution by Ravi Kalakota and Marcia Robinson. They list ten focal points that include the few I’ve listed here and then some.