The other day I was driving somewhere and listening to the local public radio station as they interviewed Garth Sundem, author of “Beyond I.Q.: Scientific Tools for Training Problem Solving, Intuition, Emotional Intelligence, Creativity, and More.”
During the interview he held up the observed and measured example of problem solving approaches between Physics students and Physics professors. Apparently professors solve problems more slowly than their students. That said, they also seem to be able to solve much more complicated problems than their students. Researchers say this is because they don’t jump at the answers like the students do.
Professors tended to work at the problem in a more deliberate way. They tend to ask “What are our assumptions and which of them are true?” This process allows them to, as Sundem puts it, “Wiggle the assumptions” in a methodical way to determine which ones might be relevant to the results.
I found this a striking way to describe much of what goes on in the senior levels of IT and, in a big way, in the field of Enterprise Architecture. We avoid jumping to the answers and concentrate on wiggling the assumptions to make sure that the ones that affect the results are properly addressed.
In writing our book Building Enterprise Architecture, we discussed a variety of different aspects of IT that relate to Enterprise Architecture. None were more hotly discussed among our readers and editors than the subject of SOA (Service Oriented Architecture).
I started the early chapter drafts with long explanations of where SOA came from, what preceded it and how SOA isn’t real. This wiggling of assumptions made most of the editors pretty uncomfortable with what was being said because, in their direct experience, they knew of countless organizations that use SOA.
The SOA chapter is important to Enterprise Architecture and is, admittedly, widely used. The chapter in the published version of the book is short. We discuss the relationship between SOA and ERAM and show how to use metadata to identify SOA use and candidates for SOA expansion in the organization.
The chapter ends with 15 different definitions for SOA we sourced from 11 different IT vendors, consultants, researchers and industry consortia. We don’t have time to list all the definitions here. You can refer to the book if you’re interested or maybe even drop us a line politely requesting the list. No two of the definitions are alike.
The unstated suggestion is that the organization needs to create an agreed upon definition of SOA and make sure their trading partners and contractors understand what they mean by SOA. Given the cost and consequences, this is one of those variables that shouldn’t be allowed to wiggle.