Then:
http://briefingsdirect.blogspot.com/2007/05/briefingsdirect-soa-insights-analysts.html
Again:
This was the week (
The focus of discussion was on how we generally—and OMG’s new “SOA Consortium” specifically--can best spread the gospel of SOA within companies. I heard the words “advocacy,” “evangelism,” and “best practices.” It was all about how CIOs can proselytize the SOA message down to IT and business groups, and how we all can learn to speak a common SOA language, bond more completely, and re-dedicate our working lives to this all-embracing business-renewing philosophy and so forth.
Am I crazy in reading a quasi-religious overtone into all this? Here’s OMG’s Soley on his group’s ever-morphing mission, which has recently begun to focus on a new crusade that involves ministering to the needs of SOA true believers. Read his actual words and tell me what you think:
“Soley: Sure, the Object Management Group is an 18-year-old consortium of software users and vendors, academics, and a growing number of government institutions focused on delivering standards to make interoperability and portability a reality. We were founded in 1989 focused on object technology, later grew into distributed object technology, and were best known for the first few years for our Common Object Request Broker Architecture (CORBA).
In 1997, we moved in two new directions; one being the adoption of a unified modeling language with the clever name, Unified Modeling Language (UML), and also into vertical markets -- originally healthcare, finance, telecommunications, and manufacturing, although we are now in about 25 different markets, everything from robotics to regulatory compliance.
In 2000, we actually leveraged that modeling technology and made it the base technology for all of the efforts that we have under way. So, we defined business models and software models, and, in some cases, even hardware models and process models.
The next big leap came in 2005, when we merged with Business Process Management Initiative (BPMI.org), so that now all of the modeling languages from meta modeling languages like Meta-Object Facility (MOF), to business modeling languages like Business Process Modeling Notation (BPMN), to software modeling languages like UML, and systems engineering languages like SysML are all in one place. That’s been our focus, but looked at from another dimension, what my staff is really good at is getting competitors to agree on things.
We have been doing that at OMG for 18 years with, at this time, between 500 and 600 member companies. We were approached by a group of 11 companies to create a community around SOA, an advocacy group, not a standards group, which is why it’s separate from OMG. We strongly believe that SOA isn’t a technology at all, but rather an approach to achieve business agility. It’s not a technology, but rather a business strategy…..
[I]t’s important to understand that this is not a standards organization. There are plenty of organizations focused on SOA standards and, in fact, OMG is one of them. Let’s get this straight upfront -- we are going to pronounce it SOA (So-wah) from now on, because, otherwise you can’t say, "SOA what?"
Our SOA group at OMG has been focused on modeling SOA, modeling for software assurance, and modeling for software producibility, and so forth….It’s an advocacy group. How do we help the CIO? And, we call this "Corner Office SOA." How do we help the CIO get the news across to the rest of the C-suite that this is not a technology but a business strategy, and a business strategy that can deliver agility and a better bottom line?
Second, "Ground Floor SOA." How do we help the enterprise architect, the domain architect, the data architect get the word across to his alter ego in the line of business that this is a business strategy and not a technology and it’s something he needs to pay attention to?”….
It’s important first of all to note the mix of users and vendors. We are currently running 3-to-1 end-users to vendors, and that’s because the focus is on this advocacy activity. It’s not on whose SOA infrastructure we should buy and "Our Web service is cool," or any of those questions. I am guessing that we are actually going to be more like 5-to-1 or 10-to-1 end-users to vendors eventually, but, as you can see, on Feb. 12 four vendors stepped up to the plate to fund it and get it off the ground. They were BEA, Cisco, IBM, and SAP. ….
You also saw, as you said, some very dedicated end-users who have ideas about how to get the idea across to the lines of business that this is not a technology play, but a business agility play. …. We expect that the SOA Consortium is going to weighted toward end-users, although there will be a couple of sponsors joining…..
[End users] are not building reference models. They are sharing case studies. For example, our enterprise architects and our community of practice is showing case studies of success stories and, more importantly, failure stories, best practices, what works, what doesn’t work? We have even had sessions on how to influence project managers and product managers in the line of business to understand business strategies in general, rather than think of us as “the guy who fixes my Treo.”
We received a lot of feedback from CIOs and CTOs during the [early] summits that said this is very important. We had a Fortune 100 CIO who came into the
At the end of the summit, this particular CIO stayed an extra half hour and said, “The most important thing I learned is that I can now understand how I can position this as -- rather than a technology play -- a business agility play. That will support the efforts that I am making to make our business processes understood, to write them down in a way that’s reusable and discoverable, and in a way that I can make them more efficient. And, I am going to go back to the CEO and say it’s not a technology play.”
While on the call, I heard Soley’s mention of end users sharing SOA “failure stories,” and that sounded like a bit more true confession than most IT or business analysts are willing to own up to (full disclosure: it’s been many years since my last confession, and you know where I’m going). So I called him on it:
“Kobielus: There’s definitely a value for an advocacy organization like this to spread best practices regarding SOA and SOA deployment and management. You mentioned that one of the functions of these – for lack of better term, dog and pony shows -- meetings in various cities is for the CIOs to share both the success stories and the failure stories regarding SOA deployment. How eager are CIOs to share their failures and their screw ups in implementing SOA?
Soley: You saw how carefully I didn’t mention even the gender of the CIO who made that comment in
Listening to one of these stories, actually it was in
But kids write notes on them and say, "They don’t know what they missed," and "You’ll get accepted somewhere else." And, they really help each other out. I think they all understand that failure stories are just as important as success stories. In fact, more important, because it’s very difficult to justify cost savings. It’s far easier to justify increased revenue. So, they do it and I will admit that the enterprise architect level folks do it more readily.”
Ah, there’s the rub. IT professionals, like any other weak mortal, are willing to share their screw-ups if, as Soley stated, “they have the safety and security of knowing they are not going to be quoted, it’s not going to be on their performance reviews, and they know that others in the room are going to do the same.” You’ll confess because there’s a screen in the confessional, you’re not giving your name, and the priest is sworn to confidentiality (though, let’s not kid ourselves, Father Van recognizes your voice, Jimmy).
Of course, who’s to say what constitutes an SOA “failure” unless you can measure your performance against SOA commandments that have been carved in some relatively solid stone by some reasonably recognized lawgiver. That’s why I brought up the issue of OMG possibly “certifying” SOA practices that have been mapped against established holy writ, in the form of IT/business best-practices frameworks:
“Kobielus: I think the industry is looking at the SOA Consortium or OMG to be a third-party certifier -- maybe that’s overstating your mission -- of enterprises' success or lack thereof in implementing SOA. So, it’s the extent to which you are going to be mapping these SOA best practices back to such recognized frameworks as ITIL, Six Sigma, and so forth that would be essentially what the industry is looking for you guys to do -- to catalyze that kind of mapping.”
Soley’s response:
“Soley: The SOA Consortium is looking to not only OMG, but other standards consortia, to deliver standards, mappings, and validation endorsement certifications where appropriate. In fact, it’s in the mission statement that the SOA Consortium is not a standards organization, but it will deliver requirements to standards organizations and where we were talking about modeling things, those requirements would be handed to OMG.
One of the 10 largest banks in the world sent an executive to one of our meetings, and this person said, that all they care about in terms of metrics of success are Lean and Six Sigma, so we're going to need to connect SOA to that world in order to be successful at that bank. I think that’s part of it, but there’s more than that. There are going to be metrics that are not yet in the stack when you fly through the ITIL, Six Sigma and Lean documents.
OMG, as it happens is moving into the direction of maturity models anyway. We are just starting work on a business-process maturity model. You may have read about it. It’s not a standard yet, but it was just starting. What were talking about is a maturity model for business process adoption that measures organizations and their ability to capture business processes. That’s very strongly related to SOA, but again, that’s a standard and belongs in OMG and not in the SOA Consortium.”
Oh…I just noticed that he used the word “summit” over and over to describe the events where the high CIO priests of SOA convene. See what I mean?
Anyway, I don’t want this to come off as too cynical, on my part. But, in my working life, I’ve been “certified” on Myers-Briggs, and Total Quality Management (TQM), and ISO 9000, and at least a few other daylong seminar disciplines instilled/installed in me by goateed parachute-in consultants. And none of those experiences made me feel like I derived anything of enduring value, in terms of wisdom or practical skills.
Of course, this time around, I’m definitely more of an SOA “high priest” than layperson. But SOA is such a heterodox paradigm, with we the faithful having such a wide range of belief and practice, that I can scarcely imagine what validity or value an “SOA certification” doctrine might have.
All I can think of are the sore behinds of the poor parishioners, seated on those wooden pews, listening to the SOA gospel being droned from on high, thinking their own thoughts, struggling to stay conscious.
Jim
