The Hamster In the Black Box

Every once in a while, we like to take a look back at the insurance industry’s technical literature. It reminded us that, at a time in the not-too-distant past, it was impossible to pick up anything — trade publications, marketing collateral from vendors, reports from the analyst community, et al. — without reading about Service Oriented Architecture (SOA). It seemed as if every developer and his dog were employing and touting SOA to the nth degree.

Our exploration also led us to some architectural relatives of SOA, which we’ve listed here, in part, with their respective definitions:

• SOA. Service Oriented Architecture is a style of software design that provides services (discrete units of functionality, accessed remotely, acted on and updated independently) to various other components through a communication protocol over a network.
• SAP. Service Application Programming. We’re going to leave this one alone.
• SOAP. Service Oriented Application Programming is a clean approach to software development that combines architecture, application development, and protocol programming.
• SOUP. Service Oriented Utility Programming describes the attempt to program utility into application development; that is, to create a solution for which there is an existing problem, rather than vice versa. Utility, in this context, is sometimes used synonymously with objective.
• SOUP TO NUTS. Service Oriented Utility Programming Tapping Objectified Neurons Under Total Secrecy is an approach to enterprise programming that’s so covert not even the people who know about it know about it. SOUP TO NUTS was also known by the abbreviation TCP: The Complete Package.

We certainly found our discoveries amusing, if not terribly enlightening. But it caused us to think a little more deeply, particularly when we found a reference to black box in reference to SOA.

What Difference Does it Make?

The reference we found defined black box as:

a device, system or object which can be viewed in terms of its inputs and outputs (or transfer characteristics), without any knowledge of its internal workings. Its implementation is “opaque” (black).

That prompted us to wonder about what seems to us to be the relative unimportance to the user or the consumer of any specific technology and/or its nature. To be more specific, we wondered what our prospects might say if we asked this in one of our introductory conversations: “If our system comprised a hamster, running on a wheel in a black box — but it was easy to use, processed your business efficiently cost-effectively, and improved your results — would you care?”

We never ask that question, of course. And we’re quite proud of our technology, its facility, and its adaptability. But it did make us think about the possibility that all of us might be better off if we focused on objectives and outcomes, rather than on techniques and technicalities.

If we did that, decision-makers might be able to view all technology as just a hamster in a black box.