Todd Biske: Outside the Box

Archive for July, 2006

Back at the end of June, I posted some of my thoughts on personalized services after the announcement of Google Checkout. At that time, a lot of my thinking was on how a service provider can personalize services for their consumers. Since then, my thinking has went in a different direction. In cases like Google Checkout, a third party is in the position of being able to collect and potentially share lots and lots of information about our shopping practices (no worse than what credit card companies already have).

What would be very interesting is if these service providers gave the true owners of the information the ability to control who and how could access it. This actually creates a very interesting scenario, and one that I think demonstrates the importance of the policy-based infrastructure now available for Web Services. Let’s suppose there is a competitor to Google Checkout called PayIt. PayIt is storing purchase information in their data centers. Let’s also suppose that PayIt can makes this information available to the shopping partners that are leveraging their checkout service, in either an aggregated or anonymous fashion. In reality, the owner of the data being shared is the individual shopper, not PayIt and not their retail partners. Google, however, is acting as both the data steward and the service provider. How does the data owner get involved? The data owner, you and me, sets the policies. While PayIt provides the service, we provide the policies that govern the service execution- who can access them, and what information they can see. Since most of us don’t work for PayIt, there needs to be a way to externalize the policy management from the service execution, even outside the firewall. While this is an extreme example, the same needs exist inside the firewall. The group that own the source code and deploy the services may not be the same group that sets the policies regarding who can access them. While today we have tools for externalizing authorization policies, we’ll soon need better tools for other types of policy management tailored toward the end policy manager which could be you and I.

Brenda Michelson has another good conversation going on her eBizQ blog regarding SOA and Agile Development. Here is my comment:

I fall in the crowd of classifying SOA and Agile Development as apples and oranges. I wouldn’t call it oil and water, because there are some things that agile development practices address that are directly applicable to SOA adoption.

First, my definition of SOA is always at the enterprise level. In my mind, there’s no such thing as an SOA project, only an enterprise SOA adoption effort. If I was on a project that was building both services and consumers, I think agile development would definitely be a good thing. The reason, however, is because by the nature of the project definition, the required collaboration should be in place to allow rapid change. At the enterprise level, however, the service provider and the service consumers are likely on completely different schedules, across many different projects and teams, all of which are barriers to communication and collaboration. Without communication and collaboration, agile efforts will struggle.

At the same time, creating rigid service interfaces that don’t change is completely the wrong approach. The problem is poor communication between service providers and services consumers, not an interface that changes. The business does not remain constant, and anyone who thinks that service interfaces can be defined once and set in stone is destined for failure. The key to success is change management. Change management is not a problem in agile development because of close communication between the parties impacted by the change.

So, I think the takeaway should be that SOA adoption must ensure that communication and collaboration between providers and consumers occurs. It doesn’t mean that service interfaces should change on a rapid basis, as individual component interfaces may on an agile development project, but it does mean that change should be managed.

I’ve decided that my blog needed some kind of name besides “Todd Biske’s blog.” While it certainly implies that it contains what I think, it doesn’t imply much about how I think. I originally thought about calling it “The Big Picture” but someone already has a blog by that name. I would call myself a big picture thinker before I’d call myself an “out of the box” thinker, but when it comes to SOA, a frequent message I give is to think out of the box, so it fits.

The above photo is of my youngest daughter at about 6 months old. I used this picture on a slide in my very first external presentation which was on SOA. I think that thinking outside of the box is an inherent part of adopting SOA. No matter how much strategic planning has gone on, and how much context is given, as soon as things get turned into a project, the project plan takes over and the more strategic needs go on the back burner. It’s important to keep thinking strategically while acting tactically, always taking steps toward continued improvement in the enterprise. If you don’t have someone whose responsibility it is to think outside of the box, you’ll probably have a much longer road ahead of you.