Football as a Web service

Every Sunday, I get a bunch of guys together to watch football. Drawing upon my sharp technical skills, to set up these get-togethers, I used a service-oriented approach.

For example, I let all of these guys use my bathroom, so I take a universal trust relationship for granted. Each guy sets his snack bowl and drink cups on a communal glass coffee table. Requests are handled in a consistent, predictable manner, as Web services interfaces must do.

Take seating. I used to have a sofa, a recliner, and a cushion in my den, but that presented too many possible seating categories — data types, if you will — to manage. So I moved the soft seats to the living room, and now a seat is a seat. A request for one seat is fulfilled with one steel folding chair.

My snack interface is equally simple — one bowl each with sharing at the requestee’s discretion — although I did revise it to allow callers to specify Atkins-compliant or Atkins-go-to-hell snacks, with the default being the latter.

This arrangement has worked smoothly every season. But last Sunday, an audio/video contractor was busy in the den, installing a new projection TV, theater seating, and surround sound (InfoWorld’s latest recognition of my stellar work). So I moved the party to the living room.

It was a new deployment scenario, but my simple, standardized protocols and data types would make redeployment a cinch — or so I thought. What a disaster. I learned that I had designed my football party services to be so isolated from their deployment environment that they only adapted on paper.

Dwayne doesn’t see very well, so we had to scoot the sofa in closer and give him the best seat. Then two guys in the outer seats couldn’t see, so I moved them to a love seat behind the sofa. One guy moved to the floor. Earl pulled the TV tray close to him and took his sweet time passing bowls and beverages to and from “his table.” And everybody argued over who got a soft seat and who got a folding chair.

Clearly, I was facing a redesign. But whatever solution I created would be likely to break again (not functionally, but practically) when we move into the InfoWorld Auditorium.

It turns out that the right thing to do was to ask my wife. She’s an event planner by trade. She winced when I put Earl next to the TV tray because she knew he was there to eat, not to watch. She knew that Dwayne’s characteristics made the middle of the sofa a good location for him, but a bad one for everyone else.

While I wrung my hands over the evils of exception cases, she explained that all event planning takes the venue into account, yet is flexible enough to handle a change of location an hour before the kickoff, as it were. It’s impractical to alter an event while it’s in progress, but she writes down what works and what doesn’t at each event and uses that knowledge to create master plans that are progressively more adaptable.

Web services architectures are no different. Adherence to standard protocols and data types is fine, but that doesn’t mean forcing a square peg into a round hole makes sense.

I didn’t even think of that in my game-party design. Every Sunday, I got to make the first call to the seat, snack, and drink interfaces. From my vantage point, my design was perfect every week.