Uncertainty may not be what you think it is
Tom Koulopoulos was the keynote speaker at a conference that I attended last week. He's a really bright guy and a very entertaining speaker (or at least I think so).
Tom covered a wide range of topics, one of which was in dealing with uncertainty. He began with a question to the audience:
"What are some games that involve uncertainty?"
Audience members tossed out three examples:
Sure enough, Tom's next slide showed the same three games (He swore he didn't plant shills in the audience, but you never know).
We fell right into his trap. None of these games really involves uncertainty. For example, with dice you will never roll a 13 (Assuming that you are using two "standard" dice).
Uncertainty is not what you least expect, it's what you don't expect at all.
So how do you plan for uncertainty? I can tell you from my own experience that the answer is not "plan for every eventuality". In the first place, you can't know "every eventuality". In the second place, if you try to add in hooks to deal with anything that might happen your product will be bloated and over-engineered. In the third place, the hooks that you build will seldom be the ones you need.
Agile methods evolved from the recognition that you can't predict the future:
- Build only what you need today
- Build it lean
- Build it well
- Get really good at building things fast
If you can build things quickly, you can respond quickly when the thing that you never expected happens.
I have great respect for Bruce Tate and his Better, Faster, Lighter mantra, but in my world of application integration I have to focus at a different level. The Spring/Hibernate stack is great for implementing point solutions, but it's not enough for implementing connect the dots scenarios. Put another way, Spring/Hibernate is great for creating individual services, but it's not the answer for implementing solutions that require orchestrating dozens of services.
Einstein is quoted as saying:
"Make things as simple as possible, but no simpler"
I think that Spring/Hibernate solutions by themselves are too simple for most enterprise-wide problems.
Spring/Hibernate articles generally discuss solutions that are created from scratch. Enterprise-wide solutions evolve over time, and they're never pure. Just as our DNA contains garbage sequences, enterprise-wide solutions always contain legacy junk that will never quite die.
There is no "homogenous future". There will never be a single language, operating system, database management system, or presentation technology.
We need a better, faster, lighter approach towards integrating heterogeneous services.
This is where SOA comes in. SOA mandates loose coupling between services. Loose coupling leads to less efficient solutions, but the agility of the solutions to respond to changing requirements is preserved.
If you tailor a suit too well, it will only fit one man. The suit will look great, but as the man gets older (and middle-age spread sets in) the suit will probably end up at a thrift store.
SOA is a paradigm that allows for growth. OpenEAI is a Java-based open-source framework for implementing solutions that can grow.
Stephen Wheat and Tod Jackson presented a session on OpenEAI at the conference that I attended last week. The framework and methodology were developed by the University of Illinois and then released publicly under GNU licenses.
From their web site:
In the face of this complexity, it is very helpful for an enterprise to have an integration methodology that can be uniformly applied to any new integration project, regardless of the technology involved. Even more helpful is a flexible technology foundation that has already been applied to many types of projects and can be readily extended and applied to new situations. The OpenEAI Project strives to provide this methodology and technology and, most importantly, to provide it in a way that allows all the individuals and enterprises that practice the methodology and use the technology to share their experience and benefit from each other's work. The goal of the OpenEAI project is to explore and codify the science of enterprise application integration in a practical, public, and methodical way.
I don't know if OpenEAI will be to SOA what Spring/Hibernate is to Agile methods, but it looks like a good start.