Without discussing the morality of war, the concept of war bears many parallels to the concept of commerce. As the military seeks to learn lessons from private industry, remember that business tries to learn from great generals and strategists. Case in point, I'm reading 'The Art of War for Managers'. Therefore, it makes sense that there is much to learn on successful SOA from our military successes - and failures....I'll continue my train of thought on Lt. Gen Van Riper and Service Oriented Architecture (SOA).
War is about adapting. Any potential enemy as well as we, the United States, if we didn't adapt, learn, and evolve from our past experiences, we would be a species or a nation that would not survive. And any enemy that wants to survive against the United States can't fight like some of our recent enemies have, or they won't survive.
So what the heck does it mean to adapt through services? Well, one think that I think that it isn't is creating an entire system through traditional development lifecycles - including infrastructure, expectations, etc. Often, the the world is discussed in terms of 'phenomenon.' That is, when you put a whole bunch of things together that act independently, usually in their own best interests - and then let them interact - things don't always go as predicted....In fact, a 'phenomenon' often occurs. Sorta similar to how disruptive innovations that change some basic assumption previously held.
I'm trying to think of a good example and the best that comes to mind is human flight. As long as we tried to emulate the flight of a bird, no such luck. As soon as we adapted (within the rules of aerodynamics, etc), we started to make progress toward today's jet engines and beyond. This type of progress didn't happen by defining everything from the beginning and codifying all the assumptions.
Scientific rules became the interface into the world. As more was learned, those interfaces adapted...and the implementations, interactions and choreography based on those interactions adapted accordingly....but WITHIN their own time (hence acting independently).
Where am I going? Well, I hear alot talk and pitches about centralization and single point of whatever as part of your and I'm not really on the bandwagon that centralization is necessary. In fact, I will go further and state that centralization often leads to the desire for rigorous control over all aspects of the behavior that occurs through a system - which is a recipe for failure. Independent action leaks out all over the place. In technology, we call it a 'one-off' or 'point to point integration' or spaghetti code (well, not the only reason for spaghetti code, but I digress).
The bottom line is that we have to account for adaptability and one was to do that is to encourage and assume independent interaction (lots of reference here to other chapters in the books The wisdom of the crowd).
Whew...I never even got to my comments on a recent Zapthink Take....
Monday, July 17, 2006
Subscribe to:
Post Comments (Atom)
1 comment:
Centralization always seems to stem from a fear of chaos. Our software architectures do not come close enough to fitting into nature because of their sensitive dependence on initial conditions...and I think we are nearing the point in our history where our computing systems need to evolve more toward being less sensitive to initial conditions, to tolerate the butterfly effect. When we get there, I think centralized architectures will fall out of favor because there no longer needs to be a central, monolithic control (choke?) point.
Yeah, I'm rambling this morning :-)
Post a Comment