thenagin The SOA Avionics Engineering Metaphor

All:

Then: http://briefingsdirect.blogspot.com/2007/03/briefingsdirect-soa-insights-analysts_23.html

Again:

This metaphor—actually, an “SOA projects as airplanes in danger of failing hence going into tailspins” metaphor--comes courtesy of Miko Matsumura (was-Infravio, then-webMethods, now-Software AG), who did a one-off participation in the podcast on Friday, February 2.

Ironically or something, I was reminded of that metaphor yesterday evening--while re-reading the transcript of that day’s (Friday February 2) podcast--while listening to the Jayhawks’ song “Tailspin” (from their excellent 2003 CD “Rainy Day Music,” playing on my laptop)--while sitting cross-legged on the floor at Gate B1 in Atlanta’s Hartsfield-Jackson International Airport—while waiting to get an updated on my much-delayed connecting flight home to DC (flight was canceled right after I started composing this post; as were many other flights yesterday, due first to mechanical problems with my flight, then to various weather issues in the northeastern US that tangled air traffic throughout the country). Was attempting (still attempting this Friday morning, Aug 10, sitting now at Gate A3) to get home from Sybase TechWave 2007 conference in Las Vegas—had dinner with Dana—will share more details in a later post). Nothing much to do now but write this blog entry, offline, and then post it when I get home tonight, tomorrow, whenever. Not in a tailspin so much as just sitting on my tired tail.

Anyway, back to Friday morning, February 2, 10am (eastern). On that prior august occasion (not this current August occasion) Dana focused the discussion on the topic of SOA projects that fail, how they fail, how to detect when they’re failing, and how to prevent them from failing (notice that I’m choosing to ignore the “SOA failure as unpleasant skin condition” metaphor that he seems to be hinting at):

“Gardner: One of the topics I wanted to get into this week, and we’ll throw this out to the entire group, is looking at failure in SOA. What is the problem with those projects that are not going well these days? We talk a lot about SOA, the business value, when the maturity is coming, and where the technology and standards are going. But I thought it might be worthwhile to take a step back and say, ‘Where are the warts, and why are they there? What can we learn from that?’ You’ve had some experience in the field, Miko. Many of our panel speakers are working in these areas consistently. So I wanted to ask the panel, anyone at all. Have you come across SOA projects that have not been stellar successes? And, if so, are there any immediate lessons to be learned?”

Miko’s initial response was funny:

“Matsumura: I'll answer, since you called my name out, and since it’s also a glorious introduction to have someone say, ‘Yes, I’d love to talk about the topic of failures and for this they have a guest expert.’ From our perspective, the thing that is really vital about this topic is that in 2007 we’re as likely to see catastrophic failures as we are limited success. There are a huge number of moving parts within SOA, and I'm going to use that almost as a handout point to this very well-considered group of folks. We need to categorize for the listener which moving parts are more dangerous than other moving parts, because those are the things that eventually cause the thing to kind of wiggle the wrong way, and send it to a tailspin.”

For some reason, Miko’s great “let’s not be afraid to face failure, but, no sir, I’m no failure face” response has me tripping down memory lane. Back in the early 90s, I was a telecom contractor to the federal government, and in a meeting one day I characterized a particular task as a “no-brainer,” then gestured to my colleague across the table, adding, “and we have just the right guy for the job.” Nobody got it. Nobody ever gets my jokes. Maybe it’s my delivery. Or maybe I just suck at comedy. Anyway, back to now, or, rather, six months ago, and this particular podcast. Steve Garone had a good bang-on response that identified the high-level tailspinners in terms of the classic textbook “why IT projects fail” factors:

“Garone: I’ve gotten involved in some research in the past, and it doesn’t really relate to SOA, but the results that I see from this research have tended to point out two major areas that cause or are the main factors behind these kinds of failures. One is a difficulty in nailing down and keeping a continuous eye on requirements for an application. The other has to do with corporate backing for that particular effort within the company. It's more focused on the people-oriented things and the collaborative issues associated with deciding what to build and how to build it. What [Miko] just indicated was that, in the case of SOA, the focus in terms of failure might be more on the technology-based pieces [Jim now-note--i.e., the ‘moving parts’ of the tailspinning aircraft] associated with building an application. Do you see SOA being different in terms of what actually is responsible for failures?”

Then Miko, God love ‘im, extended the “SOA mechanism’s moving parts” metaphor brilliantly and, apparently, spontaneously:

“Matsumura: That’s exactly what I was hoping to elicit -- the idea that, in fact, a lot of the moving parts -- and the most dangerous moving parts -- are people. From our perspective, the system is sort of cybernetic, half-human, half-machine. The human pieces of SOA are the parts that we’ve seen in failure mode. It’s not necessarily just the human beings themselves, but, as you described, the interfaces between the human world and the machine world, whether those interfaces are the specifications used to design applications, or the mechanisms used to manifest constraints and policies. They make sure that people, when they do fight each other, fight each other in a way that's productive, as opposed to destructive.”

Here now was my response then, not so much extending the “SOA aircraft’s failure-prone moving parts” metaphor as sort of beginning to hint at a “each SOA aircraft is a moving part in the larger SOA mechanism defined by the air traffic control system that can fail, six months in the future, to deliver Jim Kobielus on time to his scheduled destination due to the collateral impact of adverse weather conditions such as summer thunderstorms in various cities on flights connecting to and from yet other cities, and if ya really think about it, the entire air traffic control system is itself a virtual moving part in a larger SOA mechanism defined by the dynamic climatic conditions on this planet, which are driven by phenomena such global warming, which, gosh darn it, might be exacerbated by us all continuously trying to boil the SOA ocean” metaphor. Here’s what I actually said then:

“Kobielus: I think that SOA failures are a subset of IT project failures, which are of course legendary. The most common reason IT projects fail is lack of the appropriate business justification for them. Quite often, their aims are so broad and nebulous [Jim now-note: “nebulous” etymological root in “cloud,” which dovetails nicely both with “above the cloud” (my Network World column name), with SOA “clouds” (i.e., what forms when the SOA sun boils the SOA ocean)] that there are over-heightened expectations built up about how it will change the business and contribute to revenues, profitability, and so forth. There’s a ‘boil the ocean’ element of SOA justifications, because SOA as a set of best practices, is often pitched as, ‘We’re going to totally clean up; we’re going to totally clean up our development practices and our integration practices. We’re going to orient them around this new grand unifying scheme called SOA.’ When projects are pitched in that way, and justified in that way, you’re just setting up the SOA project for failure.”

A minute or two later, Miko made the following statement implying, to extend the avionics metaphor, that policy is the cockpit and stick that the human-SOA-pilot moving parts use to control the SOA aircraft:

“Matsumura: [W]e’ve learned that the people who control the SOA are the people who essentially control the policies. The policies include metadata, repository, and registry -- the kind of policies that are machine-enforceable, but also involve human factors. In a way, the model is more of an equal partnership now. On the other hand, real system integrators like to control policy as a way to permanently set up a base camp inside an account, pour people through the door, and take over. It's something that we know they're salivating about.”

Machine-enforceable policies? SOA on auto-pilot? Yeah, now you’re lighting up the radar screen in the control tower in my head…tell me more, Miko, or, OK Joe McKendrick, I’ll hand it off to you, so you can offer up an observation that, in its closing image, puts me in mind of Delta Airlines rerouting passengers—or, more to the point, booking Jim Kobielus on another flight this morning—to work-around the air-traffic snarl that got him so hot and bothered yesterday (in which, incidentally, Atlanta experienced the highest low temperature, 82 Fahrenheit, in its humid history):

“McKendrick: There’s a tension between various groups in the enterprise. I guess there’s a lack of a clear definition as to who is going to be doing what, and who is going to be controlling what. SOA, of course, is inherently cross-enterprise -- or in theory it’s cross enterprise. An SOA that’s confined to a single silo or single piece of the enterprise, by definition isn’t necessarily an SOA. It’s another proprietary system. I was curious as well as to what the definition of failure would be in an SOA situation. Personally, I'm not familiar with situations where an SOA, or components of an SOA, had to be rolled back, such as you’ve heard about with spectacular ERP failures. It seems that there may be heightened expectations of ROI or increased business agility, which don’t happen immediately, but components of the SOA still may stay in place and just be sent off in a different direction.”

Then Miko offered up the example of a real-world “SOA as tailspinning aircraft out of control” project failure, incidentally introducing other “mode of transportation” metaphors that correspond to other options for getting me home this morning that, to be quite honest, I’m more than willing to consider at this point:

“Matsumura: For example, a project I was involved in for the insurance industry was widely touted as an early SOA poster child by the vendor. The CIO was on the speaking circuit, which was dragging him off the field, and he had essentially outsourced the entire project toward a single source. What eventually happened was that this particular individual ended up having to leave the company. I think that the CIO had this mistaken impression that the service interface abstraction allowed him to outsource completely the operational concerns and the implementation concerns, and eventually to treat this service interface as something like a child’s car seat, where really mom is driving. It’s important to treat the interface abstraction layer like a saddle on a horse, which means that the only people who can successfully get from Point A to Point B are the people who have the skill of riding and controlling the horse, which is the service implementation. It’s really an abstract or complicated metaphor. It’s not hard to lose control.”

Then me again, pining for the simplicity of an “SOA as a simple pair of wings that I can strap to my arms and fly my way home under my own power” option (and I can’t believe the exquisite serendipitous beauty, for my present purpose, of the fact that I said “fly in the face of,” which, unfortunately, suggests Icarus, and you recall his epic tailspin):

“Kobielus: I think that the way to define SOA failure is the failure of SOA as a set of practices that a company adopts, the company’s failure to realize the grand claims made for SOA. These include such benefits as improving interoperability, simplifying your IT environment, reducing the cost of that environment, speeding up the development of applications, and enabling greater flexibility in terms of where you can source various components, portals, databases, and integration components from. An SOA project or initiative is a failure if it increases the complexity of your environment, if it increases cost, if doesn’t make much of a dent in the incompatibilities among different platforms, or if it locks you into a given vendor. That’s why last week I brought up the whole notion of SOA suites. This notion of an SOA suite from a single vendor who provides everything for you seems to fly in the face of, ‘Isn’t SOA supposed to allow me to mix and match the BEA, Oracle, webMethods, Microsoft, and everybody else’s components in my environment ?’ If, at the end of the day, you’re a CTO and you say, "Well, here’s my SOA strategy, and we standardize on Oracle or webMethods" -- are you really gaining anything over the monolithic days of yore?”

So take that, you long-departed Mr. Howard Hughes billionaire aircraft manufacturer, and take this you very-alive Mr. Larry Ellison, Mr. Bill Gates, etc. etc, you and your Spruce Gooses of an “SOA as big heavy lumbering monolithic stack that will never quite gain cruising altitude” suite, your so-deliciously-non-metaphorical monument to industry hubris, or something (gee…I need a good night’s sleep right about now…can you tell?). Anyway, at some point in the Feb 2 discussion, Dana ramped up the avionics metaphor to an interstellar science-fiction “SOA as spacecraft” metaphor worthy of Gene Roddenberry (or perhaps Kantner-Balin-Slick Jefferson Airplane-cum-Starship):

“Gardner: We’re getting at the point where world political history is perhaps a guide to how to approach SOA. Do you want a Third World dictatorship? Do you want empires extending their influence? Do we want a Pax Romana approach? Or do we want a pure democracy or a federated democracy? I’m thinking more about Star Trek, when the Romulans and the Klingons get together. If you could only get that to happen in IT, would be in a lot better shape.”

At Dana’s cue (starfleet federation etc.), at that point, we transitioned into an “SOA as federation” discussion, which was substantial in its own right, but ended the discussion of SOA tailspinning, failing, and all that. Which is where I’ll close off this post as well (I’ll take up the SOA as federation/governance topic later….or, hold on, didn’t I do an “arch of governance” thread a while back?....btw, Dana and I had a very pleasant dinner at the Sybase show, and over drinks discussed the potential of wild/wacky SOA evolution or global warming or millennial or anthropology or tectonic or world history metaphors such as “SOA as Bering land bridge” and so forth, but not now….gotta go).

They’re just about to open the gate and board my flight. And hopefully get some wind neath my tuckered tailfeathers. Wish me luck, or something.

Your SOA seatmate.

Jim