It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.
Charles Darwin
So, even Darwin himself has issue with the popular conception of “Darwinism” that only the strong survives. For anyone that has gone through a significant change, it’s certainly not easy. But what is the definition of change that Darwin is driving at? Is it more along the lines of a “catastrophic” change where the world changes in an instant and only those in the best position to adapt can survive? Or is the inability to catch-up and adapt to a multitude of small changes along the way over a life-time, or perhaps over several generations that makes the difference?
Change is a funny subject and certainly with respect to SOA. People have different ideas about the nature of change and how it applies to technology, their business and their overall world-view. However, since a major value proposition of SOA is “agility”, it’s important to define this to some degree. When we speak of agility we largely mean the ability to rearrange how distributed systems are integrated and how business processes are created and run. This is not the only definition but it’s the one, in my humble opinion, most relevant apropos SOA. This agility is important as it allow corporations and government entities to react quickly to market/competitive changes, new legislation or world events. And, of course, this agility is a major component is the Return-On-Investment (ROI) calculations of SOA.
From my experience, when the buyers of SOA think of change, they think of changing all the time. That is to say, change happens often, perhaps everyday, and it’s imperative to react accordingly or doom and gloom is the unfortunate result of sluggish action. Further the users of SOA think that when change occurs, it’s usually imperative to do something about it, if necessary, as soon as possible. The speed at which you are able to react to changes in your environment (and any context will do here: commercial, economic, competitive, military, legal, etc.) is just as important as how often change occurs. In fact, change might manifest itself as the realization that you’ve made a mistake in tactics or strategy and you need to fix it quickly. Obviously, if you can’t react to change faster than it happens, then you’ll be hopelessly left behind. For example, if the competitive landscape changes every 3 months, but you can only make substantive changes to how you do business in a 5 month window, then you’re in for a bumpy ride and perhaps ultimate doom. Therefore, I think that the fear factor of the rate of change dominates the thought process of decision makers when contemplating the subject. But we should remember that there are two aspects to change that we need to balance: A) how often change occurs and B) the speed at which we can react to the change. It’s my position that B is more important than A when thinking about SOA.
This SOA stuff is still not quite fully proven. And we’ve all seen silver bullets come and go and they have never quite lived up to their hype. Now were talking about ESB software and BPEL that will magically mitigate your enterprise integration woes and do it in minutes instead of months. As it turns out, what were talking about is far more than just the technology and network plumbing that connects our enterprise applications and business processes. We’re talking about the fundamental nature of business and complex distributed systems engineering. All of the SOA tools that are available on the market today simply do not do distributed systems engineering and design for you. Nor do they analyze the business implications of the way you’re integrating your components either internally or with outside business partners. The business problems you face with change happens, to me at least, seems to be the “long pole in the tent” with respect to agility. It used to be painfully true that IT department and all the consultants they could possibly hire could not effect a change to the IT infrastructure fast enough to satisfy the business owners. That is changing. Not changing quite as fast as the SOA vendors might lead you to believe, but it’s changing nonetheless. Soon months to minutes will be possible. Give it a couple more years before that kind of technology is really ready for primetime.
When you decide to make changes to react to some event or events in your world, it’s not how often those changes occur that is the issue. It’s how fast you can react to these changes when they do occur. That is what SOA agility is meant to convey. Very soon, it will be time to think about how your business decision making process will be able to keep up, not how fast your IT infrastructure can change.
