SEP Fields and Service Consumption
A comment from Steve Jones on the Yahoo SOA group a while back really struck a chord with me as a great observation and a conversation yesterday reminded me that I wanted to blog about it (Steve did so as well, in this blog entry). In discussing the difference between a service and an application, Steve had pointed out that the integration-centric view within application development tends to create a “series of ‘not my responsibility’ handoffs.” I think this is very true. Application development is frequently very producer-centric. That is, the focus is on the application itself, not on the users of the application, whether it be a person or another system. Where these dependencies occur, the parties involved can frequently be more concerned about their own pieces, and not about the experiences of those using them. When something goes wrong, as Steve points out, it can frequently be a series of handoffs between groups that are saying “it’s not my problem.”
This was reminded to me in a conversation yesterday when the person I was speaking with made a reference to the SEP field from “The Hitchhiker’s Guide to the Galaxy.” An SEP Field was a mechanism for making something invisible. From everything2.com, I found this explanation:
A SEP field is used to hide something in plain sight. This phenomenon works on the principle that the human brain will filter out impossible objects and situations so as to preserve the sanity of the owner of the brain. When an impossible object or situation is encountered, the brain decides that it is somebody else’s problem (SEP) and promptly deletes it from its perception of reality.
This is an area I’m pretty passionate about, and why I think I’ve enjoyed both usability and SOA. Both of these practices are inherently about consumption, not production. While clearly we need to produce applications and produce services, the focus needs to be producing something that is consumable. If someone has a problem with it, don’t make it invisible by saying, “well, that’s your problem,” because it’s not. Without consumers, you have no service. As a service provider, you must be concerned with how your service is being consumed and be doing everything in your power to ensure successful consumption and a positive experience.
3 Responses to “SEP Fields and Service Consumption”
Leave a Reply
Tod,
Spot on! We are just starting to get to a point with our SOA where we are getting the analysts and service providers on projects to ask the questions “Who are my consumers?” and “under what business context are they consuming my services?”
This has driven a much more useful evolution of our service inventory, allowing for trimmed down operations and simpler semantics.
Prior to having a more “principled” SOA approach it was entirely provider centric with complex services that mirrored application models or models that were easily understood by providers not consumers.
We have a ways to go yet to “weed the garden” but we are starting to see the advantages of a consumer driven approach.
Steve
I can’t quite put my finger on it but there is something amiss here. IT applications not focused on users? Hmm, that seems off-base.
There won’t be hand-offs when services are used? Only if the calling application/service consumes just one service or if the multiple services consumed are all managed by one group.
“‘Who are my consumers?’and ‘under what business context are they consuming my services?’
“This has driven a much more useful evolution of our service inventory, allowing for trimmed down operations and simpler semantics.”
I assume these behaviors and observations are of an advantage to the business. If so, can you elaborate?
I ask because the advantages listed seem like intermediate goals. For example, having analysts ask “who are my consumers” isn’t a good thing in and of itself. Even “trimmed down operations” can be a marginal win. There must be a broader *business* reason for seeing “success” in such behavior, right?