Edited transcript of weekly BriefingsDirect[TM/SM] SOA Insights Edition, recorded March 2, 2007.
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Vol. 13, a weekly discussion and dissection of Services Oriented Architecture (SOA) related news and events with a panel of industry analysts and guests. I am your host and moderator Dana Gardner, principal analyst at Interarbor Solutions, ZDNet blogger and Redmond Developer News magazine columnist.
Our panel this week -- and that is the week of Feb. 26 2007 -- consists of Steve Garone, a former IDC group vice president, founder of the AlignIT Group, and an independent industry analyst. Welcome back to the show, Steve.
Steve Garone: Thanks, Dana. Great to be here.
Gardner: Also, joining us once again, Joe McKendrick, a research consultant, columnist at Database Trends and a blogger at ZDNet and ebizQ. Welcome back, Joe.
Joe McKendrick: Good morning, Dana.
Gardner: Also joining us, Tony Baer, principal at OnStrategies, and blogger at Sandhill.com and ebizQ. Thanks for joining, Tony
Tony Baer: Hi, Dana.
Gardner: And also once again, joining us is Jim Kobielus. He is a principal analyst at Current Analysis.
Jim Kobielus: Hi, Dana. Hi, everybody
Gardner: Joining us for the first time, and we welcome him, Dave Linthicum. He is CEO at the Linthicum Group, an SOA advisory consulting firm. Dave also writes the Real World SOA blog for InfoWorld and is the host of the SOA Report podcast, now in its third year. He is also a software as a service (SaaS) blogger for Intelligent Enterprise, and has a column on SOA topics for Web Services Journal. Welcome, Dave.
Dave Linthicum: It is great to be here.
Gardner: We are going to have a couple of meaty, beefy topics today on the SOA and, interestingly enough, Enterprise 2.0 arena. We are going to be discussing and defining the concept around "mashup governance." We are also going to discuss some merger and acquisition news this week, with a deal announced between Hyperion and Oracle, whereby Oracle will acquire Hyperion for $3.3 billion.
First off, let's go to this subject of "mashup governance." Dave, I believe you defined this to a certain extent in a recent blog, and I wanted to give you the opportunity to help us understand what you mean by "mashup governance" -- and why it’s important in an Enterprise 2.0 environment, and perhaps what the larger implications may be for SOA.
Linthicum: Sure. Thank you very much. That was a feature article, by the way, that InfoWorld sponsored, and it’s still up on their website. It basically talked about how mashups and SOA are coming together, since they are mashing up. As people are becoming very active in creating these ad-hoc applications within the enterprise, using their core systems as well as things like Google Maps and the Google APIs, some of the things that are being sent up by Yahoo!, Salesforce.com, and all these other things that are mashable. There's a vacuum and a need to create a governance infrastructure to not only monitor-track, but also learn to use them as a legitimate resource within the enterprise.
Right now, there doesn’t seem to be a lot of thinking or products in that space. The mashup seems to be very much like a Wild West, almost like rapid application development (RAD) was 15 years ago. As people are mashing these things up, the SOA guys, the enterprise architecture guys within these organizations are coming behind them and trying to figure out how to control it.
Gardner: An element of control to an otherwise ad hoc and loosey-goosey approach to creating Web services-based UIs and portal interfaces?
Linthicum: That’s absolutely right. Ultimately these things can become legitimate and very valuable applications within the enterprise. I have a client, for example, that has done a really good job in mashing up their existing sales tracking system, inventory control system, and also delivery system with the Google Maps API. Of course everybody and their brother uses that as a mashup example, but it's extremely valuable.
We are able to not only provide maps to do the best routing for delivery, but also Google Maps right now has traffic reports. So, they can give these to the truck drivers and delivery agents at beginning of the day, and productivity has gone up 25 percent. Over a year, that is going to save them more than $1.5 million. And, that’s just a simple mashup that was done in a week by a junior developer there. Now, they are trying to legitimize that and put it back into their SOA project, as well as other external API’s. They are in there trying to figure it out.
Gardner: So perhaps through this notion of combining what is available on an internal basis -- either as a Web service or moving toward SOA -- the enterprises can also start tapping into what is available on the Web, perhaps even through a software-as-a-service relationship or license, and put together the best of internal data content process as well as some of these assets coming off of the Web, whether it is a map, an API, or even some communications, groupware, or messaging types of functions.
Linthicum: I think you put it best that I have ever heard it. Absolutely. That’s the way it’s coming forward, as we are building these SOAs within these enterprises today. We have the added value of being able to see these remote services, deal with these remote APIs, and bring that value into the organization -- and that’s typically free stuff. So, we are using applications that we are gaining access to, either through a subscription basis in the case of Salesforce.com -- and they are, by the way, hugely into the mashups that are coming down the pipe -- free services that we are getting from Google, or even services that cost very little.
Putting those together with the existing enterprise systems breathes new life into them, and we can basically do a lot of things faster and get applications up and running much faster than we could in the past. Ultimately, there is a tremendous amount of value for people who are using the applications within these environments. Typically, it’s the mid-market or the mid-sized companies that are doing this.
Gardner: Or even department levels in larger companies that don’t need to go through IT to do this, right?
Linthicum: That’s right. Absolutely. That’s how Salesforce.com got started. In other words, people were buying Saleforce.com with their credit cards and expensing it, and they were wiring it around IT. We are seeing the same movement here. It's happening at the grassroots level within the department and it's moving up strategically within the IT hierarchy.
Gardner: Okay, so it sounds straightforward: a good productivity boost, moving toward the paradigm of mashable services. Why do we need governance?
Linthicum: Well, you really need a rudimentary notion of governance when you deal with any kind of application or service that works within the organization. Governance is a loaded word. If you go to the Enterprise Architecture Conference -- and I am speaking at it the end of this month in New Orleans -- they consider governance as a management practice. It’s running around knocking people on their heads, if they are not using the correct operating systems, databases, those sorts of things. In the SOA world, as Joe McKendrick can tell you, it's about a technical infrastructure to monitor-control the use of services. Not only is it about control, but it is about productivity. I can find services. I can leverage services, and they are managed and controlled on my behalf. So, I know I am not using something that’s going to hurt me.
The same thing needs to occur within the mashup environment. For mashing up, there are lots of services that we don’t control or that exist outside on the Internet. It's extremely important that we monitor these services in a governance environment, that we catalogue them, understand when they are changed, and have security systems around them, so they don’t end up hurting productivity or our existing IT infrastructure. We don’t want to take one step forward and two steps back.
Gardner: I read your blog in response to this, Jim Kobielus, and you seem to think that bringing too much governance to this might short-circuit its value -- that it’s the loosey-goosey, ad-hoc nature that brings innovation and productivity. Do you think that what we think of as traditional SOA governance is too rigid and strict and requires some interaction with IT? Or are we talking about some other kind of governance, when it comes to mashups?
Kobielus: Well, Dave made that same point in his article, which is that the whole notion of mashups is half-way to anarchy, as it were, creative anarchy. In other words, empowering end-users, subject-matter experts, or those who simply have a great idea. They typically slap together something from found resources, both internal and external, and provision it out so that others can use it -- the creative synthesis.
This implies that governance in the command-and-control sense of the term might strangle the loosey-goosey that laid the golden egg. So, there is that danger of over-structuring the design-time side of mashups to the point where it becomes yet another professional discipline that needs to be rigidly controlled. You want to encourage creativity, but you don’t want the mashers to color too far outside the lines.
Dave hit the important points here. When you look at mashup governance, you consider both the design-time governance and the run-time governance. Both are very important. In other words, if these mashups are business assets, then yes, there needs to be a degree of control, oversight, or monitoring. At the design-time level, how do you empower the end-users, the creative people, and those who are motivated to build these mashups without alienating them by saying, "Well, you've got to go to a three-week course, you've got to use these tools, and you've got to read this book and follow these exact procedures in order to mashup something that you want to do?" That would have clearly stifled creativity.
I did a special section on SOA for Network World back in late 2005. I talked to lots of best practice or use cases of SOA governance on design time, and the ones that I found most interesting were companies like Standard Life Assurance of Scotland. What they do is provide typical command-and-control governance on design time, but they also provide and disseminate through the development teams a standard SOA development framework, a set of tools and templates, that their developers are instructed to use. It's simply the broad framework within which they will then develop SOA applications.
What I am getting at here is that when you are dealing with the end users who build the mashups, you need to think in terms of, “Okay. Tell them in your organization that we want you to very much be creative in putting things together, but here is a tool, an environment, or enabling technology that you can use to quickly get up to speed and begin to do mashing up of various resources. We, the organization that employs you, want you, and strongly urge you, to use these particular tools if you wish your mashups to be used far and wide within the organization.
"If you wish to freelance it internally, go ahead, but doesn’t mean we are necessarily going to publish out those mashups so that anybody can see them. It means we are not necessarily going to support those mashups over time. So, you may build something really cool and stick it out there, but nobody will use it and ultimately it won’t be supported. Ultimately, it will be a failure, unless you use this general framework that we are providing."
Gardner: I think we need to re-examine some of these definitions. I'm not sure what we are talking about with mashup governance is either "run time" or "design time." It strikes me as "aggregation time." Perhaps we don’t even need to use existing governance and/or even federate to existing governance. Perhaps it's something in the spirit of Web 2.0 and Enterprise 2.0, as simple as a wiki that everyone can see and contribute to, saying, “Here is how we are going to do our mashups for this particular process."
Let’s say, it is a transportation process, "Here are the outside services that we think are worthwhile. Here are the APIs, and here is a quick tutorial on how to bring them into this UI." Wouldn’t that be sufficient? Let us take that over to Steve Garone.
Garone: I am going to push back on that a little bit. What we are wrestling with here is achieving a balance between encouraging creativity and creating new and interesting functionality that can benefit business, and keeping things under control. The best way to look at that balance is to understand what the true risks are.
The way I see it, there are several major areas. The first has to do with what I call external liability, meaning that if you, for example, publish a mashup to a customer base that has a piece of functionality you got off the web, and for some reason that has wrong information and does the customers some harm, who is responsible for that? How are you going to control whether that happens or not? The second has to do with what I call internal risk, which has to do with making available to the outside world information that is sensitive to your organization. In that case, a little more than what you described is going to be necessary, and can also leverage some of the governance infrastructure that people are building generally and relative to SOA.
Gardner: So, you are thinking that these mashups would be available not only to an internal constituency in the organization but across its users, its visitors, and the public?
Garone: Absolutely. Well, I think they can be, and I think there will be organizations and groups within organizations who will want to do that, driven primarily by the business opportunities that it can afford.
Gardner: But, if this is the general public accessing some of these mashups, wouldn’t the risk that they would take accessing the individual services on the web on their own be sufficient? Why would you need to be concerned about liability or other risk issues when these are already publicly facing APIs and services and so forth?
Garone: Conceptually, you wouldn’t, but we all know that in this world anybody can sue for anything, and the reality is that if I go to a company’s website and use a function that incorporates something that they grabbed off the web, and it does me harm, the first place I am going to look is the site that I went to in the first place.
Gardner: Well, you might have stumbled upon the category here that will warm the cockles of many lawyers’ hearts -- mashup risk and assessment.
Garone: Exactly. And, it's one of the problems that governance in general attempts to solve. So, it is relevant here. My bottom-line point is that achieving balance is going to involve some careful consideration of what the true risks are. Maybe resolving that involves a combination of the kinds of solution that you just talked about in some cases. In other cases, they are going to have to leverage the governance infrastructure that exists in other areas within a company.
Gardner: Your point is well taken. This is business, it is serious, and it needs to be considered and vetted seriously -- if it is going to be something that you are using for your internal employees’ use, as well as if it becomes public-facing. How would you come down on this, Joe McKendrick? Do you see the balance between something as unstructured as a blog or wiki being sufficient, or do we need to bake this into IT, get policies and governance, and take six years to get a best practices manifesto on it?
Garone: I did not recommend that, Dana.
Gardner: I know. I'm going from one extreme to the other.
McKendrick: If we do it in two years, that would be fine. But what I’d love to know is, what exactly is the difference between a mashup and a composite application that we have been addressing these past few years within the SOA sphere? The composite application is a service-level application or component that draws in data from various sources, usually internal to the organization, and presents that through a dashboard, a portal, or some type of an environment. It could be drawn from eight mainframes running across the organization.
Obviously, the governance that we have been working so hard on in recent years to achieve in SOA is being applied very thoroughly to the idea of composite applications. Now, what is the difference between that and a mashup? Other than the fact that mashups may be introducing external sources of data, I really don’t see a difference. Therefore, it may be inconsistent to "let a thousand flowers bloom" on the mashup side and have these strict controls on the composite application as we have defined in recent years.
Linthicum: The reality is that there is no difference. You are correct, Joe, and I point that out in the article as well. There are really two kinds of mashups out there: the visual mashups, which are what we are seeing today, where people are taking basically all of these interface APIs and using the notions of AJAX and other rich, dynamic clients, and then binding them together to form something that is new.
The emerging mashups are non-visual. It's basically analogous, and is not exactly the same, as traditional composite applications that are -- if you can call them traditional -- in the SOA realm today. They have to be controlled, managed, governed, and developed in much the same way.
Kobielus: There is a difference here. I agree with what Dave just said that mashups are not qualitatively different from composite apps, but there is a sort of difference in emphasis, in the sense that a mashup is regarded as being more of a user-centric paradigm. The end-user is empowered to mash these things up from found resources.
It relates to this notion that I am developing for a piece on user-centric identity as a theme in the identity management space. The whole Web 2.0 paradigm is user-centric -- users reaching out to each other and building communities, and sharing the files and so on. Mashing up stuff and then posting that all to their personal sites is very much a user-centric paradigm.
There's another observation I want to make. I agree that the intellectual property lawyers are starting to salivate by mashups invading their clients or encroaching on their clients’ rights. Actionable mashups are good from a litigator’s point of view. In terms of governance then, organizations need to define different mashup realms that they will allow. There might be intra-mashes within their Intranet -- "Hey, employee, you can mash up all manner of internal resources that we own to your heart’s delight. We will allow intra-mashes, even extra-mashes within the extranet, with our trusted partners. You can mash up some of their resources as well, whatever they choose to expose within the extranet. And then, in terms of inter-mash or Internet wide mashing, we’ll allow some of it. You can mash Google. You can mash the other stuff of the folks who are more than happy to let you mash. But, as an organization, your employer, we will monitor and block and keep you from mashing up stuff that conceivably we might be sued for."
Gardner: So you could take six years and require a manifesto. Thank you, Jim Kobielus. Tony Baer, let's take it to you. Do you see this as a problem in terms of the governance, or should we keep it loosey-goosey? Should we not get into the structure, and do you think that -- to Jim’s point -- a mashup is conceptually different from a composite application because of the user-centric, user-driven, keep-IT-out-of-it aspect?
Baer: We've got a couple of questions there. I’ll deal first with the technical one, which is that composite apps and mashups are basically trying to do the same thing, but they're doing it in different ways. Composite apps, at least as I've understood the definition, came out of an SOA environment. That implies some structure there, whereas mashups essentially merged to Web 2.0 with the emergence of AJAX-style programming, which lets anybody do anything anywhere with this very loosely structured scripting language. There are practically no standards in terms of any type of vocabulary.
So, there is a bit of a "Wild West" atmosphere there. As somebody else said, you really need to take a two-tiered approach. On one hand, you don’t want to stifle the base of innovation, a kind of a skunk works approach. Having a walled garden there, where you're not going to be doing any damage to the outside but you are going to promote collaboration internally, probably makes some sense. On the other hand, even if the information did not originate from your site, if you're retransmitting it there is going to be some implication that you are endorsing it, at least by virtue of it coming under your logo or your website.
Gardner: Yeah, the perception of the user is going to be on you, regardless of the origins of the service.
Baer: Exactly. So, you need a tiered approach. I was taking a note here earlier. You really need to exert control on the sources of information. Therefore, for the types of information that are exposed internally -- for example something from an internal financial statement -- you need to start applying some of the rules that you've already developed around internal databases. Different classes of users have a right to know and to see it and, in some cases, some read-write privileges.
You need to apply similar types of principles at the source of information. Therefore, if I have access to this, this means implicitly that I can then mash it up, but you have to really govern it at the original point of access to that information, at least with regard to internal information. With external information, it probably needs to go to the same type to clearance that you would exert for anything that goes out on the corporate website, the external website.
Gardner: So, your existing policies and access privileges, your federated ID management brought up into a policy level, that will all play into this and it could help mitigate this concern around the right balance.
Baer: Well, put it this way, it’s a step toward that direction.
Gardner: I want to offer another possibility here. I was thinking about the adage that nobody was fired for using IBM, which was a common saying not that long ago. What if we were to take that same mentality and apply it here -- that if you're going to do mashups, make sure they are Windows Live mashups, or Google mashup services for mashup; or maybe Salesforce.com? So, is there is an opportunity on the service provider side to come up with a trusted set of brands that the IT people and the loosey-goosey ad-hoc mashup developers could agree on to use widely? They could all rally around a particular set of de-facto industry standard services? That would be perhaps the balance we're looking for.
What do you think about that, Steve?
Garone: That can certainly be a realistic part of how it’s done, and it gets back to something someone mentioned earlier about composite applications. We talked about the similarities and the differences. One of the differences I see is when I think back to when people started building applications from software components. There was a flood of products put on the market to manage that process in terms of cataloguing and putting into libraries trusted components with descriptions and APIs that conform to standards, to try to sort of reign in people’s ability to go all over the place and pick software from the sky to build into an application that could be used in a business context.
What you're saying sort of conforms to that, in that you come up with a trusted set of applications or a trusted set of vendors or sources from where you can get application functionality, and an attempt to enforce that.
Gardner: It strikes me that this is a slippery slope, if people start using mashups. That includes the more defined and traditional developer using it through governance and vetting it properly with command and control, as well as across a spectrum of project-level, third-party developers, and even into department-level folks who are not developers per se. The slippery slope is that, suddenly more of the functionality of what we consider an application would be coming through these mashups and services, and perhaps increasingly from outside the organization.
Therefore, the people who are providing the current set of internal services and/or traditional application functionality need to be thinking, "Shouldn’t I be out there on the wire with a trusted set?" We're already seeing Microsoft move in this direction with its Windows Live. We're seeing Google now putting packaging around business-level functionality for services. Salesforce.com is building an ecology, not only of its own services, but creating the opportunity for many others to get involved -- you could call them SaaS ISV’s, I suppose.
And I don’t think it’s beyond the realm of guesswork that Oracle and SAP might need to come up with similar levels of business application services that create what would be used as mashups that can be trusted to be used in conjunction with their more on-premises, traditional business applications. Does anyone else see any likelihood in this sort of a progression? I’ll throw it out.
Linthicum: There's a huge likelihood of that coming up. People are moving to use interface-based applications through software-as-a-service. All you have to do is look at the sales of Salesforce.com to monitor how that thing is exploding. And, they are migrating over to leveraging services to basically mix-and-match things at a more granular level, instead of taking the whole application interface and leveraging those within your enterprise. This is what I call "outside-in" services. I wrote about that three years ago.
People are going to focus on that going forward, because it just makes sense from an economic standpoint that we leverage the best-of-breed services, which typically aren’t going to be built within our firewall. We don’t want to pay for those services to be built, but they're going to be built by the larger guys like Salesforce.com, Google, and Microsoft. It's going to be a slow evolution over time, but I think we are going to hit that inflection point, where suddenly people see the value. It’s very much like we saw the value in the web in the early '90s -- that it really makes sense not only to distribute content that way, but distribute functional application behavior that way.
Gardner: Thanks, Dave. Any contrarians out there? Does anyone think that this back-to-the-future, in terms of the major players stepping up and providing best-of-breed services, is not likely?
Kobielus: Well, I think it's likely. But the fact is that, given the accessibility of this technology, it will encourage independence to startups, and provide unique new services too that may fall between the cracks. It’s the classic long tail here.
Gardner: I’ll be contrarian in this, because I don’t think that these sets of players, with the possible exception of Google and Salesforce.com, are going to be interested in having this occur sooner. They would rather have it come later, because their on-premises, licensed software businesses are far more profitable, and it gives them a more entrenched position with the client and the account than these mashups. Those can be switched in or out quite easily, and are either free or monetized through advertising or in a subscription fee format that is still not nearly as profitable for them in the long run as an on-premises, licensed affair.
Does this notion of the business model, rather than the technology model or the branding model, change anyone’s opinion on the speed in which this happens? Do we need to have a small group of interlopers that comes in and actually forces the hands of the larger players into this mode?
Garone: Dana, I’ll take that. There clearly has to be a business reason for these major players to do it, and the two that I see are, one, that the functionality that they're making lots of money off of is suddenly available as a mashup at little or no cost, in which case they have got to deal with that. The other is to be able to add interesting functionality to their existing products in order to be more competitive with the other enterprise app players out there. Other than that, you're right. There has to be a stimulus from the business standpoint to get them to actually jump into this.
Gardner: Any other thoughts on the pressure in the marketplace and in terms of business and cost?
Linthicum: If they don’t do it, somebody else is going to come up and do it for them. Look at the pressures that Salesforce.com has put on the CRM players in the marketplace. It’s a similar type of market transition. Salesforce.com was never an internal enterprise player, and yet look at their revenues in contrast to the other CRM guys that are out there. The same thing is going to occur in this space. They are either going to step up and provide the new model, or they're just going to get stomped as people run over them to get to the players that will do it.
Gardner: Yeah, Dave, I agree, especially with Google. They’ve got a market cap of $144 billion, and a portion of that market cap depends on how well Google can sell business services to businesses. That’s going to put pressure on the traditional players, right?
Linthicum: Yeah. Google is moving aggressively in that space, and I think they're going to not only provide their own services, but they're going to broker services that they validate and basically recast.
Gardner: And that’s governance isn’t it?
Linthicum: It is going to be governance. You are going to see some aggregators out there. Right now, you’re seeing guys like StrikeIron, which is a small company, but they aggregate services. They are basically a brokerage house for services they control, validate, and make sure they are not malicious. Then, you rent the services from them, and they in turn pay the service provider for providing the service. I think Google is going to go for the same model.
Gardner: It’s about trust ultimately, right?
Linthicum: It’s about trust ultimately. If I were a consultant with an organization and my career was dependent on this thing being a success, I'd be more likely to trust StrikeIron and Google than some kind of a one-off player who has a single service which is maintained in someone’s garage.
Gardner: So that notion of a cottage industry for some little developer out there creating their own widget probably still isn’t going to happen, huh?
Linthicum: It will. What’s going to happen is that they are going to do so through brokerage -- guys like Google. I don’t think Google is going to take a whole lot of money. They're going to take the normal pennies per transaction, and you will see millionaires that are made in a few months -- people who are able to send up killer services that Google and guys like StrikeIron are able to broker out to those who are setting up SOAs. Then, suddenly, they are going to find themselves a hit, very much like we’re seeing the Web 2.0 hits today.
Gardner: We have Google AdWords and AdSense. So, soon we should have "ServicesSense"?
Linthicum: Right, and everybody in that space, whether they say it or not, is building that in the back room right now. They know that’s coming.
Baer: I was just going to add that StrikeIron really has an interesting business model. I have spoken with Bob Brauer, the CEO of StrikeIron, several times. Their message is that there is going to be this marketplace out there. They are looking at SOA and services, perhaps Web 2.0 and mashups may come into play as well, but it’s a notion that rather having corporations worry about building their own internal functionality, they can go out to some kind of marketplace and get the best deal for the functions they need and the types of services they need. Your typical corporation may be run on a combination of internally built services and externally brokered services.
Linthicum: When I was CTO at Grand Central, we had a few companies that were run entirely on external services -- these new startups. They did all their accounting, their sales management, and everything else through external services. That’s probably too much for the larger Global 2000 to bite off right now, but there is going to be a functional changeover. As time goes on, they are going to use more external services than ever before.
Gardner: "Free" is a compelling rationale. All you have to do is look at a little text ad associated with the service and that page for the service and the provisioning and governance of the service becomes fairly compelling, right?
Linthicum: Absolutely.
Gardner: Well, thanks very much. That was an interesting discourse on this whole notion of mashups, SOA, and how it might evolve in the marketplace. For the last 10 minutes today, let’s discuss the deal announced this week whereby Oracle is going to acquire Hyperion for $3.3 billion, bringing the possibility of more analytics and business dashboard functionality into the growing Oracle stable. I believe this must be their tenth or twelfth acquisition since 2002.
Jim Kobielus, you’re data-centric in your studies and research. Does the fit between Hyperion and Oracle make sense to you?
Kobielus: It makes sense knowing Oracle. First of all, because [Oracle Chairman and CEO] Larry Ellison has been very willing in the past to grab huge amounts of market share by buying direct competitors like PeopleSoft, Siebel, and so forth, and managing multiple competing brands under the same umbrella -- and he is doing it here. A lot of the announcement from Oracle regarding this acquisition glossed over the fact that there are huge overlaps between Oracle’s existing product lines and Hyperion’s in pretty much every category, including the core area that Hyperion is best known for, which is financial analytics or Corporate Performance Management (CPM). Oracle itself provides CPM products for CFOs that do planning, budgeting, consolidation, the whole thing.
Hyperion is a big business intelligence (BI) vendor as well, and Oracle has just released an upgrade to its BI suite. You can go down the line. They compete in master data management (MDM) and data integration, and so forth. The thing that Oracle is buying here first and foremost is market share to keep on catapulting itself up into one of the unchallenged best-of-breed players in business intelligence, CPM and so forth. Oracle bought the number one player in that particular strategic niche, financial CPM , which is really the core of CPM -- the CFOs managing the money and the profitability.
It’s a great move for Oracle, and it definitely was an inevitable move. There will be continuing consolidation between the best-of-breed, pure-play data management players, such as Hyperion and a few others in this space, which are Business Objects and Cognos. They will increasingly be acquired by the leading SOA vendors. Look at the SOA vendors right now that don’t have strong BI or strong CPM, and look at the pure-plays that have those tools. The SOA vendors that definitely need to make some strategic fill-in acquisitions are IBM, Microsoft to a lesser degree, BEA definitely, and a few others, possibly webMethods. And, look at the leading candidates. In terms of CPM and BI and a comprehensive offering, they are down to three: Business Objects, Cognos, and SAS.
Now, SAS's Jim Goodnight has been doing it for over 30 years. It’s a great company, growing fast, with very loyal customers. Those product lines are very private, very stubbornly private, and I think they want to stay that way. So, I don’t think they are on the blocks in terms of being an acquisition candidate. But Business Objects and Cognos definitely are in play. So, it’s just a matter of time before both of those vendors are scooped up by some of the leading SOA vendors.
Gardner: So, Oracle has created a little bit of an auction atmosphere? Joe McKendrick, what's your take on this? You’re also a data personage.
McKendrick: Either Neil Macehiter or Neil Ward-Dutton, one of the Neil’s, mentioned on a couple of occasions that Oracle really isn’t playing up its database strengths. Lately, a lot of the activity, a lot of its announcements, and a lot of its acquisitions have been focused on the fusion, the middleware. And this [Hyperion buy] is definitely a play to its strength in the database market. Jim made some great observations, and there are a lot of overlaps. My sense is that Oracle is buying a huge, prominent customer base as part of the acquisition.
Gardner: Even though there is overlap in customer base and in some functionality, isn’t there the ability to integrate on an analytics basis by extracting value from data, rather than providing the data services themselves and/or a business application set? Doesn’t that make for an integrated approach that they could bring these two perhaps overlapping product categories together easier in this category, than they would either in database or business applications?
Garone: Yeah, Dana, I think that’s correct; and I also agree that this is less about database and more about middleware and fusion and building up that software stack. Oracle has clearly got an eye on doing that. This kind of an acquisition in the short term is always a double-edged sword, for Oracle especially. If any of you have been to some of their events as an analyst, you've seen what they’ve gone through in convincing the analyst community that they're going be able to both support all the customer bases of representing the products they acquire and integrate things well into their stack ...
Gardner: And they did seem to do a pretty good job at that between J.D. Edwards, PeopleSoft and Siebel, right? There wasn’t the big brouhaha in the installed base that some people were expecting.
Garone: Right. And that turned out to be true in those cases. It remains to be seen, of course, what will happen here, but it’s always a short-term hurdle that Oracle has to get over, both in terms of perception as well as the actual integration process and business model process. Again, this is really very promising, if Oracle pulls it off. But to me it’s really about their bigger picture of taking what they call Fusion middleware out beyond just middleware to the applications themselves, and essentially creating an entire integrated stack of software.
Gardner: How about you, Dave Linthicum? Do you believe that these services and analytics and creating business insight into operations are an essential part of SOA, as Jim Kobielus believes?
Linthicum: Absolutely. In fact, if you look at my stack, which is actually on Wikipedia right now, one of the things I have on top is Business Activity Monitoring (BAM) and analysis, because once you have those points of service -- both the behavioral visibility and also information visibility into all these different points, and you create these abstraction layers on top of it -- you have a great opportunity to actually monitor your business in real-time. And you have the ability not only to monitor it in real-time, but you can actually go back historically to see how what you are doing now relates to what you did in the past.
A lot of businesses can benefit from that. It's key technology. Oracle did the right thing strategically, and I think this stuff is going to be a necessity going forward for SOA, and it’s a necessity for business going forward as well. It’s one of the things where, if you look at the business, it’s just so huge, but you just don’t hear about it anymore.
Gardner: So, we're saying that the feedback loop becomes more essential for SOA, and that these BI tools are essential ingredients in creating a near real-time feedback loop, as well as a historical perspective feedback opportunity to then fine-tune your SOA, perhaps through a policy-driven governance capability?
Linthicum: Right. Fine-tune your SOA by fine-tuning your processes. I can imagine the potential here. I can see not only the health of my business, but also how my business produced things in the past, or how things were done in the past and how that relates to what I'm doing right now. I even have a rules engine, which is part of my SOA to make adjustments automatically to things that I know will have a positive effect on my business processes. You can get this automatic state which is hugely valuable for these large-product-intensive companies.
Gardner: The last word from Tony Baer, Do you see the analytics as important as some of our other guests?
Baer: Well, put it this way. Analytics is the necessary icing on the cake. All the other pieces tell you what you are doing, and the classic question of analytics tells you why. A lot of folks look at this as an extension to the database business. I see this as an extension of the applications business.
SAP, for example, has had BI for a number of years. Oracle has had some limited analytics starting back with the acquisition almost a decade ago of, I think it was, IRI Express as an OLAP database. Now, that was merely an extension to the database business, but if you look at how this is really going to end up playing out, it’s not that customers are looking for another database to just slice-and-dice their data. They are looking for a way to look at their business processes, which are represented through their application stacks and think, "How are we doing?" So, it’s a logical add-on to that.
In terms of worries about or concerns about a customer -- I guess customers getting dissatisfied when Oracle comes in -- the fact is that in ERP, just as in database, it’s a foundation buy. The fact is that regardless of what your personal feelings are about Larry Ellison, that technology is entrenched in the organization. The pain of migrating from it is greater than just sticking with it. Oracle has also improved its track record in terms of trying to be a little more customer friendly. It still has plenty of work to do. So, in the long run, I don’t see a lot of migration here, and I see this as being a very logical add-on in the apps business.
Gardner: Yeah, I agree. Strategically, this has a lot to do with the business applications. Do you think that this puts significant pressure on SAP?
Baer: It puts some pressure on SAP. I wouldn’t be surprised to see them make the play for one or the other two big ones. I also expect IBM to play in there, because even though IBM says it’s not in the apps business, the fact is that they do have products like master data management.
Gardner: And a lot of BI, too.
Baer: Exactly. And actually what's really ironic about all this is that years ago, IBM and Hyperion had actually had a very close relationship, and it was bordering almost on acquisition. I'm surprised that IBM actually never went the last mile and acquired them. It would make sense for them to make a move with one of the other players today.
Gardner: Interesting. Well, thanks very much. I want to go through our group for today, and we appreciate all your input. There’s Steve Garone, Joe McKendrick, Jim Kobielus, Tony Baer, and Dave Linthicum. We appreciate your joining us. I hope you come back. This is Dana Gardner, your producer, host and moderator here at BriefingsDirect SOA Insights Edition. Please come back and join us again next week.
If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 13. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Showing posts with label Garone. Show all posts
Showing posts with label Garone. Show all posts
Monday, April 23, 2007
Friday, April 06, 2007
BriefingsDirect SOA Insights Analysts on Converged Governance and the New SOA Consortium
Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Feb. 16, 2007.
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Volume 12, a weekly discussion and dissection of Services Oriented Architecture (SOA) related news and events with a panel of industry analysts and guests. I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet blogger, and Redmond Development News magazine columnist.
Our panel this week consists of Steve Garone, former IDC group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome to the show, Steve.
Steve Garone: Thank you, Dana. It’s great to be here once again.
Gardner: Also joining us is Joe McKendrick, a research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Welcome back, Joe.
Joe McKendrick: Real pleasure to be here, Dana. Thank you.
Gardner: Also joining us is Neil Macehiter, a research director at Macehiter Ward-Dutton in the U.K. Welcome back, Neil.
Neil Macehiter: Thanks, Dana.
Gardner: And also here is Jim Kobielus. He is a principal analyst at Current Analysis. Welcome back, Jim.
Jim Kobielus: Hi, Dana.
Gardner: This week -- and it is the week of Feb. 12, 2007 -- we’re going to tackle two subjects. The first one is an important issue around governance, and whether governance is going to evolve into more of a converged activity. What we’re seeing is that SOA governance vendors are putting together policy-based approaches for managing the complexity of SOA. They're trying to automate the various resources within that environment and architecture, and to provide control for those managing the IT development deployment life cycle, as we get more toward a mixed environment of services, perhaps a variety of different sources.
So, we've got SOA governance that is evolving, but with its own technology, its own metadata, its own repositories, and even its own standards. Alongside that on a parallel track are Governance, Risk and Compliance (GRC) platforms, and a number of prominent vendors such as SAP, CA, OpenPages, MEGA and others are providing this as a service for regulatory compliance, principally to CFOs in large organizations.
We've also seen over the years on the management side governance platforms, dashboards, approaches, and methodologies along the lines of a Balanced Scorecard approach or process reengineering for the chief executive’s office. Also we have parallel and yet still disparate tracks for governance. I'm wondering, along with Jim Kobielus who raised this issue, where this might be going? Why don’t you tell us, Jim, what you're seeing, and some of your thoughts around this subject?
Kobielus: Thanks, Dana. I started being fairly cynical about a year ago over whether compliance was a market, I kept hearing about the compliance market, the Sarb-Ox market, and so forth. I was thinking it’s a concern in the same way that competitive advantage is a concern or a benefit from the appropriate and effective deployment of technology, but can you really regard compliance as a platform?
One of the things that I've seen over the past year is the growth of this new sector -- GRC: Governance, Risk, and Compliance Management -- not just as a big top under which many diverse product categories are being lumped, although to some degree it is. You see business intelligence, corporate performance and management, business process management, identity management, document management, all these things, all these existing technologies, being lumped under this GRC heading.
What I've also seen is that a growing group of vendors are building products or platforms into which they’re able to plug in, and are plugging in, various tools specifically geared toward GRC. In other words, a legitimate new niche of GRC vendors is growing up, and, Dana, you listed some of the chief ones that I've come across.
SAP about a year ago acquired a company called Versa Systems, which made tools for continuous controls monitoring. Around the Versa Team as a nucleus SAP has begun to roll out a GRC platform that includes a repository of policies and rules, a process modeling tool geared towards building business controls as structured workflows and also testing and monitoring those controls.
They rolled out a performance management dashboard environment under which you can roll up a unified view of your compliance and your corporate risks across all governance categories. The categories include SOA governance, IT governance, and operational business governance, and so forth. SAP is not alone in this regard.
You mentioned Computer Associates. They have their Clarity family of products, and there are some smaller but just as important like OpenPages and MEGA International, BWise, and several others that have similar product architectures and similar modular approaches to plug-ins. For example, you can plug in to most of these environments a module to do IT governance in compliance to say, CobiT, ITIL, and so forth.
One of the things I haven’t seen yet is any clear convergence between all this GRC governance, a lot of business governance and high level IT governance products, and the SOA governance world of UDDI registries and Web services management agents a la AmberPoint. I see two separate camps right now.
To some degree the GRC vendors are all pretty much SOA-enabled in the sense that they have native implementation of Web services, but I'm not yet seeing the vendors in that camp, other than SAP, with a strong SOA story or SOA partnerships. SAP has significantly SOA-enabled their entire suite of products over the last several years. So, that's the open question I wanted to bring out for group discussion: To what extent do you all see a convergence between business governance a la GRC and SOA governance?
Gardner: Let’s go to Neil Macehiter. Neil, is it necessarily a good thing for a compliance-oriented business policy engine to converge with what is running the IT operations, and increasingly in conjunction with what's going on with the business? Maybe we should check our premises and see if this necessarily a good thing before we start figuring out how to do it?
Macehiter: We’ll have to come back and think about what we mean by governance and compliance. Jim commented on it and he was somewhat cynical about that being a compliance market. I'm still quite cynical about it being a compliance market, because I think compliance and, more generally, governance is something that should be systemic. It’s not something that you sell with a particular tool or even a particular platform. It’s something that has to be systemic throughout the IT architecture, so that, for example, high-level business policies and high-level business requirements, in terms of compliance, can then cascade down through the IT solutions that actually automate and support the business processes that need to comply.
So, yes, absolutely. There is a need for this convergence to occur. For example, the services that are actually supporting your business processes are capable of enforcing the policies that allow you to monitor the controls and enforce the controls that you need to demonstrate compliance. That extends across things like identity management solutions, which have also come up with their own compliance solutions focused on their particular bit of the overall IT architectures. In their case it’s around authentication and authorization and things like separation of roles and segregation of duties. It needs to become systemic, and it’s not just SOA governance that needs to be tied into this. It’s also the work that’s going on in the IT service management market around CobiT- and ITIL-based processes.
It’s a broad issue. The challenge is that SOA, if we take SOA governance specifically, has evolved very much from a bottom-up perspective, in terms of initially addressing design time governance, and then gradually extending into the more run-time governance. Meanwhile, we’ve got things like the GRC solutions from the likes of SAP with Versa coming at it very much from the top-down perspective. The problem is they are not meeting in the middle yet.
It’s largely a semantic problem. How do you translate a high-level business policy that says, "We have to adhere to Sarbanes-Oxley," or "We need to address corporate social responsibility on regulations," or "Provide transparency to operations for customers?" How do you translate that into a set of policies that can then be enforced and actioned at the lower levels of the architecture?
The semantic issue will be enabled through standards, but until there’s some common agreement around the semantics and the translations between these different layers and different solutions, it’s going to be a challenge that does need to be overcome. So governance and compliance become something that’s systemic and continuous, as opposed to a solution you need to address every time, you've got an audit coming up.
Kobielus: I agree completely. It should be systemic. I'm still cynical about the notion of a compliance product market. Compliance is really much more of a professional-services market in terms of consultancies, large consultancies, sending teams of people out to help organizations, to reengineer their business processes, to audit their processes, and so forth. For the most part, at least two-thirds or more of the so called compliance market is purely services, and the products are the least of it. Most of the products in the market are point products for the squeaky wheel that needs the grease. These all-encompassing, omnibus compliance platforms are the least of the market currently.
Gardner: Correct me if I'm wrong, but isn’t the regulatory compliance these GRC platforms are primarily geared at gathering information in a reporting sense -- audit trails and discovery -- to demonstrate whether compliance is happening or not? On the other hand, from the bottom-up perspective as Neil mentioned, SOA governance is also involved with execution and the enforcement, taking a policy and then making it instantiated in the architecture and behavior of the processes. So, it's yet another reason why they should come together is that they actually need each other. How do you see this, Steve Garone?
Garone: I've been listening to the other guys talking. They're very insightful comments, and I agree with them in substance. I think the over-arching issue here is that GRC platforms are taking more of an enterprise architecture approach. They're still looking at business processes, monitoring business processes, and maybe even getting to some extent into the redesign of those processes to optimize the ability to meet compliance needs. SOA has, in fact, been coming from the ground up, and solving maybe a specific problem or issue within the department or organization. Because we’re in the early days of SOA, we're seeing a lot of that.
One of the interesting nuances here is that both approaches eventually need to focus on the business processes within the company, and optimize them for various reasons. SOA tends more, at least right now, to focus on making business processes work more efficiently. How those services are segmented and designed functionally ideally should reflect that; whereas, for the enterprise architectural approach and the GRC approach, we're looking more at being able to meet compliance needs. The question becomes how do you develop a services-oriented approach that meets both of those needs, optimizes compliance on one end, and optimizes customer satisfaction and performance and business agility on the other hand. Those could ultimately be in conflict, as these two worlds come together, and that’s an interesting new answer that organizations are going to have to look at.
Gardner: So, there seems to be some general consensus that there is value in bringing these so far disparate areas together -- governance risk and compliance with the SOA governance. If we were to move toward this middle ground and make them relate, it strikes me that data becomes important.
Joe McKendrick, you keep your ear to the street on data quite a bit. Do you think that this is simply a matter of yet again finding a meta level or layer that allows the data that’s being derived for one or both of these areas to be viewed, or used together, and wouldn’t that be a first necessary step?
McKendrick: Absolutely, Dana. It’s interesting that when we talk about SOA in relation to another type of corporate initiative -- in this case SOX and GRC and so forth -- we're always wrestling with how SOA fits into the picture. We've been challenged to make the pieces fit together, and I find that’s an interesting conundrum for SOA across a range of things happening in organizations. That being said, I recently conducted a survey for the Oracle application’s users group. We just released the survey last month on the very topic of GRC. These would be the folks who are working with the Oracle e-Business Suite, Oracle application server, and so forth…
Gardner: Of course, we know that anything SAP does, Oracle will be coming along, or vice versa.
McKendrick: Exactly. SAP seems to be pretty far head of the curve in this regard in GRC. What we found in the survey is that for the most part, there’s awareness. About 40 percent of the survey group from the 400 companies we interviewed was fairly aware of GRC, what's happening, and what's required for GRC. That was higher than we expected. So they’re trying to getting their heads around what needs to be done with compliance. At this point, the tools that are being used the most to accomplish the task around GRC compliance are the Excel spreadsheets or the Word-type documents that are flying back and forth. Seven out of 10 companies are moving these processes through or doing the reporting and putting out reports for the audits with these manual tools. Only about 15 percent say they have any measure of automation.
Gardner: They are using Excel spreadsheets?
McKendrick: Exactly. Excel. I think automation is going to be the key to all this, because companies are not in the business to meet SOX requirements. They are in business to make money for their shareholders. They’re in business to sell products. Compliance isn't their main line of business. They're being forced to pay attention to compliance and they are being forced to deliver these reports to auditors. Right now, they're committing staff to it. They're committing a lot of resource time, and resources that they don’t want to, and it’s happening on a quarterly basis. The folks involved in the reporting process have to generate the same reports every quarter, and we need to build in automation and repeatable processes. This is where SOA can play a pretty vital role.
Gardner: And, clearly business intelligence vendors, including SAP, have come into the fore. Reporting is the very core of business intelligence. So, first and foremost, if you want to do compliance, you have to produce reports, and if you have to produce reports on a regular basis from structured data in your operational systems, you need business intelligence (BI). That’s really the core, as it were, of any GRC platform.
One of the interesting things I'm finding in the growth of these GRC über-platforms is that there’s another important user interface, other than just the reporting and dashboarding the BI stuff. There are also structured surveys that can be delivered to stakeholders in a process on a periodic basis, asking, for example, procurement agents how well various business requirements or regulatory requirements are being met, from the procurement side to be in compliance with Sarb-Ox or whatever it might be.
So most of these platforms now have what I call a stakeholder interaction environment, involving not only the surveys, but other human workflows, not just GRC as a mean for pushing big rolled-up risk dashboards to the CFOs and the CEOs, but GRC as a way of regularly serving the troops as to how well processes are performing on various levels.
Steve asked earlier about how do you develop a GRC approach that addresses compliance, but also ensures business agility? One of the things that you can do is survey the troops, the grassroots stakeholders and process participants on a regular basis. "How well are we not only serving the Sarb-Ox requirements, but how well are we serving the customers through this retool process that you instantiate every day?"
Macehiter: As we see more of these compliance solutions emerging around identity management, business intelligence, and the stovepipes of technology, what will happen is that the problem will move away from organization struggling to find the information. We actually have too much information and we have to rationalize it. Our identity management system is telling us we're in compliance with Sarb-Ox because x-y-z, and our purchasing application is telling us, but we can’t actually rationalize the different information to provide visibility into whether we are really compliant. That’s going to be a very real problem.
Kobielus: Now, I just want to add a note here too. Hugh Taylor, vice president over at SOA Software wrote a book on this very topic called, "The Joy of SOX." I don’t know where he got that title from. Was there another book with the similar title one time?
McKendrick: "Fox in Sox" is a Dr. Seuss book.
Kobielus: The full title was, "The Joy of SOX: Why Sarbanes-Oxley and Services Oriented Architecture May Be the Best Thing That Ever Happened to You." He actually connects the dots, and it's the first real comprehensive case I've seen of someone actually tying the two together.
For his main point, he talks about the agility that SOA can deliver and the agility that is required to meet various compliance mandates and future mandates that will be coming down the road. The key thing with SOA is that, it enables you to access legacy systems. Most of large companies that are facing SOX audits also have mainframes and many legacy systems that they need to deal with.
Gardner: Well, if he can make regulatory compliance sexy, all the more power to him.
But I think we've come to a point here where hypothetically we recognize that having converged governance makes great sense. It strikes me, however, this is going to be many years before any kind of actualization. In the meantime, the larger message perhaps is that, as you’re doing BI, and as you’re creating more ability to capture data, cleanse it, and provide it in a way that gives you this GRC benefit, then when you decide whether you’re compliant or not, or you come up with an agenda of what needs to be done, that is not by choice but is mandated, how do then face back into the organization and get that into execution?
That’s where SOA can come up to the plate and say, "Well, why don’t we take your mandates and instantiate them into our policy engine that's reflected through the IT systems that has a relation to the legacy systems, as well as to the new systems?" Then SOA becomes the hammer through which something like a GRC platform can mandate and enforce. Even if these two systems remain disparate, it seems that they have a tag team in the near term. Can anyone react to that?
Macehiter: In an ideal world, the way the service-oriented approach works is that it’s much more declarative, much more policy driven. You don’t lock away, for example, the way that you authenticate a request or the way that you log a request into the application logic. You externalize that and control it through policy. That then allows you to drive though these policies from the high-level requirements to the GRC level down into the service infrastructure.
Whatever follows from SOX doesn’t mean building in a bunch of new code that ensures that you comply with SOX-plus, SOX 2.0, but rather that you define the policies that you need to, and then get them enforced through the infrastructure. So, I think you’re right that it’s a hammer, but the hammer needs to be wielded quite carefully. The key is going to be the semantics, and the language that allows you to define what most policies are, so that they can be enforced effectively.
Garone: I agree and just to carry the analogy a little bit further, it’ll be nice to able to design that hammer at the same time you’re assessing your compliance requirements and putting that infrastructure in place as well, so that the wielding of the hammer becomes more closely aligned with your goals as far as compliance is concerned.
Gardner: That would be the ultimate convergence, but even in the meantime it strikes me that there is sufficient short- to medium-term value in generating a SOA governance capability. Compliance and regulatory oversight is perhaps a major rationale for SOA, sooner rather than later.
Anybody else want to comment? Jim?
Kobielus: SOA is about sharing and reusing valuable corporate resources that are networked. The GRC platforms increasingly will differentiate based on their ability to bundle a broader range of best practices accelerator with polices and works flows and roles and metadata, and forth. So, really, GRC platforms are platforms for SIs to customize the policies to meet the needs of particular clients. The accelerators themselves are the sharable, reusable SOA resource that will speed up the implementation of compliance solutions in various markets. The accelerators themselves are the most critical resource that defines a GRC platform or GRC solution.
Macehiter: The point Jim raised about sharing and reusing is absolutely the key here. It's the one of the biggest challenges around compliance. Typically, organizations have multiple instances of processes locked away in different applications. They have 16 different versions of their customer or 14 different versions of a purchase order.
If what you can do by virtue of adopting more of a service-oriented approach is have common services to actually deliver capabilities that need to be audited, logged, and monitored, or if you can have a single shared service that increases consistency and reduces the effort you need to apply for compliance, increasingly what we will see is the rationale for the business case. What underpins an SOA initiative will be either that it improves our ability to comply in a cost-effective way and increases the consistency of what we do to comply.
Gardner: Perhaps what we should expect to see is not only the SOA vendors and service providers talking about compliance and regulation as a rationale for SOA investment and evolution, but perhaps it might be in the best interest also of these GRC platforms to say how well they play in conjunction with SOA and that there is a complimentary nature here.
McKendrick: Right. The only issue is that GRC is typically led by financial folks and, of course, SOA is coming out of the IT department. What happens is that the financial folks are saying, “We need more of this automated. We are not going to give you more budget to do it, but IT folks automate this process little bit more for us."
Gardner: Well, that issue is an excellent segue to our next topic, which is the announcement on Feb., 12 of the SOA Consortium, a group of both vendors and enterprises -- they are calling themselves Global 1000 End-user Organizations -- in order perhaps to bridge some of these gaps and promote the best interests of different constituencies within organizations, as well as within vendors and types of vendors.
The declared goal of this organization is to promote the adoption of SOA, and they’ve given themselves a deadline of 2010. So, in the next three or four years they want to get more people aware of SOA as a key enabler, as an element of any modern 21st century architecture and enterprise. They want to achieve benefits of SOA to change both IT and business, bridging the gaps and silos, both technically as well as culturally. They want to help the perception of SOA by business executives, they say, as an IT integration and productivity story, rather than a business agility story.
That sentence jumped out at me to say, "Aha!" These are some of the things we’ve been discussing for a number of weeks about the positioning of SOA for adoption and appreciation. It seems to me to be saying that the story around business agility is a system’s integrator business and organizational management topic. They want to bring it back into an integration function. Any reaction to that?
Macehiter: I read the press release and I think it’s actually a badly worded release, to be honest. What they’re actually saying is that one of the issues they're trying to address is the fact that SOA is perceived by business executives as an IT and integration productivity story, and they want to turn it into a business agility story. But it’s not clear.
McKendrick: I read it the same way and I agree with that statement, based on my experience with end-users. When I hear them talk about their experiences with SOA, it’s always around cost issues and the integration challenges, and very little about "Look at the business agility we achieved." What they are doing is citing that as a significant issue and potentially a barrier to SOA adoption, and I assume it’s their intent to address that.
Kobielus: I didn’t see a lot of specifics in this announcement. I try to boil down every press release to its absolute core, in terms of substance, and I didn’t see a whole lot here other than they are going to hold a bunch of summits in different cities, present some general mission, seek validation of that mission, and then ultimately produce a detailed report that will validate and direct the charter of the SOA Consortium.
I’m sorry, I had to put on my cynic hat. It sounds like this is an excuse for many fine lunches and dinners to be had. In terms of building awareness of SOA, it’s like -- duh. Aren't we all hyper-aware of SOA by now? Let’s think of the next step. You can sort of understand the vendor’s perspective in working in an organization like this, getting visibility and perhaps more importantly being able to leverage the successes of some of the companies who have used SOA. I’m not really sure what’s in it for the end-user organizations, and that's where I become skeptical.
Gardner: Well, if you look at the very last line of the release, it says, the SOA Consortium is managed by the Object Management Group, and we know from past history that the OMG's job has been to create a consortium generally around a set of standards, and there is no mention here of standards, because these are invitation-only summits, with both vendors and end-users. I think that the underlying agenda between the lines here is to help create a level of some standardization, perhaps around governance, perhaps around SOA interoperability. But, clearly there’s going to be a set of standards that’s going to evolve from this, not just from the perspective of the vendors, but also the end-users. And, that in itself strikes me as somewhat positive.
Macehiter: I think so. Look at what’s happened, for example, around the Liberty Alliance in a different domain involving large adopters and vendors, and that has delivered some tangible results. So, I think it holds promise because this is not the classic vendor "Let's set standards" to help customers, but without actually involving the customers in the process. So, that’s a positive sign.
My concern around this is whether the Object Management Group is going to embrace the work that’s currently on the go, taking place in OASIS around blueprints reference architectures, because there’s a lot of IT being developed there, that could be effectively exploited. I am just slightly concerned that what we are going to get is a proliferation of best practices and no common best practice. I’m also concerned that this is about global initiative, where the initial summit’s taking place just in the U.S., because the way SOA is being adopted in Europe, is very different from the way it’s being adopted in the U.S., and its relationship to things like enterprise architecture. I know this is only the initial meeting, but it sets the frame of reference for the rest of the work.
Gardner: Hold on a second. There could be some hope for this being global, if the funding sponsors are BEA Systems, Cisco Systems, IBM and SAP.
Macehiter: I think that’s global from a vendor perspective, as opposed to an adopter perspective. If I start to see the likes of HSBC or Tesco and some of the big adopters that we have over on this side of the pond involved in this process. That will stand in good stead.
Gardner: That will be critical for them. I agree.
Garone: The OMG has usually been pretty good about globalizing what they do, so I wouldn’t be too concerned about that. I also think that the point about the vendors being global is an important point, because based on the way the OMG model has evolved; I suspect this is being driven mostly by the vendor community.
Gardner: What we should do then is invite someone from this group onto the show in the next few weeks. I’ll reach out to Richard Soley, who is the chairman and CEO of the Object Management Group, and invite him to come on the show, and we can pose some of these questions to him. Is this a movement toward standards? Will they be global and inclusive? Will they be vendor-focused, or is there going to be a good balance between the end-user organizations as well? So, our listeners can look forward to a further discussion on the SOA consortium announcement with someone involved closely with this effort.
Kobielus: I like the parallel you drew with the Liberty Alliance, which is still actually a very vital organization. It started out as a standards organization or standards developer and still is to a degree, but has really moved deliberately to more of a best-practices forum in the identity management space. This is a critically important in a space such as in identity management, where there’s still a blizzard of standards and specifications, competing for market share and so forth. More than that, there is a huge variety of use cases and possible deployment scenarios, topologies and interoperability issues bedeviling that space.
Think about SOA. That’s even more confused and confusing in terms of best practices in such a global oceanic sense. SOA is literally all over the map. So if OMG, as a best practices forum, can help the industry to converge on a consensus of best practices for SOA, godspeed to them.
Gardner: Well, this has been another insightful 45 minutes. I would like to thank our panel of Steve Garone, Joe McKendrick, Neil Macehiter, and Jim Kobielus. I'm your host and moderator, Dana Gardner.
That’s it for this week's SOA Insights Edition, Volume 12. We appreciate your time and listening in. Please come back next week. Thanks, everyone.
If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 12. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Volume 12, a weekly discussion and dissection of Services Oriented Architecture (SOA) related news and events with a panel of industry analysts and guests. I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet blogger, and Redmond Development News magazine columnist.
Our panel this week consists of Steve Garone, former IDC group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome to the show, Steve.
Steve Garone: Thank you, Dana. It’s great to be here once again.
Gardner: Also joining us is Joe McKendrick, a research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Welcome back, Joe.
Joe McKendrick: Real pleasure to be here, Dana. Thank you.
Gardner: Also joining us is Neil Macehiter, a research director at Macehiter Ward-Dutton in the U.K. Welcome back, Neil.
Neil Macehiter: Thanks, Dana.
Gardner: And also here is Jim Kobielus. He is a principal analyst at Current Analysis. Welcome back, Jim.
Jim Kobielus: Hi, Dana.
Gardner: This week -- and it is the week of Feb. 12, 2007 -- we’re going to tackle two subjects. The first one is an important issue around governance, and whether governance is going to evolve into more of a converged activity. What we’re seeing is that SOA governance vendors are putting together policy-based approaches for managing the complexity of SOA. They're trying to automate the various resources within that environment and architecture, and to provide control for those managing the IT development deployment life cycle, as we get more toward a mixed environment of services, perhaps a variety of different sources.
So, we've got SOA governance that is evolving, but with its own technology, its own metadata, its own repositories, and even its own standards. Alongside that on a parallel track are Governance, Risk and Compliance (GRC) platforms, and a number of prominent vendors such as SAP, CA, OpenPages, MEGA and others are providing this as a service for regulatory compliance, principally to CFOs in large organizations.
We've also seen over the years on the management side governance platforms, dashboards, approaches, and methodologies along the lines of a Balanced Scorecard approach or process reengineering for the chief executive’s office. Also we have parallel and yet still disparate tracks for governance. I'm wondering, along with Jim Kobielus who raised this issue, where this might be going? Why don’t you tell us, Jim, what you're seeing, and some of your thoughts around this subject?
Kobielus: Thanks, Dana. I started being fairly cynical about a year ago over whether compliance was a market, I kept hearing about the compliance market, the Sarb-Ox market, and so forth. I was thinking it’s a concern in the same way that competitive advantage is a concern or a benefit from the appropriate and effective deployment of technology, but can you really regard compliance as a platform?
One of the things that I've seen over the past year is the growth of this new sector -- GRC: Governance, Risk, and Compliance Management -- not just as a big top under which many diverse product categories are being lumped, although to some degree it is. You see business intelligence, corporate performance and management, business process management, identity management, document management, all these things, all these existing technologies, being lumped under this GRC heading.
What I've also seen is that a growing group of vendors are building products or platforms into which they’re able to plug in, and are plugging in, various tools specifically geared toward GRC. In other words, a legitimate new niche of GRC vendors is growing up, and, Dana, you listed some of the chief ones that I've come across.
SAP about a year ago acquired a company called Versa Systems, which made tools for continuous controls monitoring. Around the Versa Team as a nucleus SAP has begun to roll out a GRC platform that includes a repository of policies and rules, a process modeling tool geared towards building business controls as structured workflows and also testing and monitoring those controls.
They rolled out a performance management dashboard environment under which you can roll up a unified view of your compliance and your corporate risks across all governance categories. The categories include SOA governance, IT governance, and operational business governance, and so forth. SAP is not alone in this regard.
You mentioned Computer Associates. They have their Clarity family of products, and there are some smaller but just as important like OpenPages and MEGA International, BWise, and several others that have similar product architectures and similar modular approaches to plug-ins. For example, you can plug in to most of these environments a module to do IT governance in compliance to say, CobiT, ITIL, and so forth.
One of the things I haven’t seen yet is any clear convergence between all this GRC governance, a lot of business governance and high level IT governance products, and the SOA governance world of UDDI registries and Web services management agents a la AmberPoint. I see two separate camps right now.
To some degree the GRC vendors are all pretty much SOA-enabled in the sense that they have native implementation of Web services, but I'm not yet seeing the vendors in that camp, other than SAP, with a strong SOA story or SOA partnerships. SAP has significantly SOA-enabled their entire suite of products over the last several years. So, that's the open question I wanted to bring out for group discussion: To what extent do you all see a convergence between business governance a la GRC and SOA governance?
Gardner: Let’s go to Neil Macehiter. Neil, is it necessarily a good thing for a compliance-oriented business policy engine to converge with what is running the IT operations, and increasingly in conjunction with what's going on with the business? Maybe we should check our premises and see if this necessarily a good thing before we start figuring out how to do it?
Macehiter: We’ll have to come back and think about what we mean by governance and compliance. Jim commented on it and he was somewhat cynical about that being a compliance market. I'm still quite cynical about it being a compliance market, because I think compliance and, more generally, governance is something that should be systemic. It’s not something that you sell with a particular tool or even a particular platform. It’s something that has to be systemic throughout the IT architecture, so that, for example, high-level business policies and high-level business requirements, in terms of compliance, can then cascade down through the IT solutions that actually automate and support the business processes that need to comply.
So, yes, absolutely. There is a need for this convergence to occur. For example, the services that are actually supporting your business processes are capable of enforcing the policies that allow you to monitor the controls and enforce the controls that you need to demonstrate compliance. That extends across things like identity management solutions, which have also come up with their own compliance solutions focused on their particular bit of the overall IT architectures. In their case it’s around authentication and authorization and things like separation of roles and segregation of duties. It needs to become systemic, and it’s not just SOA governance that needs to be tied into this. It’s also the work that’s going on in the IT service management market around CobiT- and ITIL-based processes.
It’s a broad issue. The challenge is that SOA, if we take SOA governance specifically, has evolved very much from a bottom-up perspective, in terms of initially addressing design time governance, and then gradually extending into the more run-time governance. Meanwhile, we’ve got things like the GRC solutions from the likes of SAP with Versa coming at it very much from the top-down perspective. The problem is they are not meeting in the middle yet.
It’s largely a semantic problem. How do you translate a high-level business policy that says, "We have to adhere to Sarbanes-Oxley," or "We need to address corporate social responsibility on regulations," or "Provide transparency to operations for customers?" How do you translate that into a set of policies that can then be enforced and actioned at the lower levels of the architecture?
The semantic issue will be enabled through standards, but until there’s some common agreement around the semantics and the translations between these different layers and different solutions, it’s going to be a challenge that does need to be overcome. So governance and compliance become something that’s systemic and continuous, as opposed to a solution you need to address every time, you've got an audit coming up.
Kobielus: I agree completely. It should be systemic. I'm still cynical about the notion of a compliance product market. Compliance is really much more of a professional-services market in terms of consultancies, large consultancies, sending teams of people out to help organizations, to reengineer their business processes, to audit their processes, and so forth. For the most part, at least two-thirds or more of the so called compliance market is purely services, and the products are the least of it. Most of the products in the market are point products for the squeaky wheel that needs the grease. These all-encompassing, omnibus compliance platforms are the least of the market currently.
Gardner: Correct me if I'm wrong, but isn’t the regulatory compliance these GRC platforms are primarily geared at gathering information in a reporting sense -- audit trails and discovery -- to demonstrate whether compliance is happening or not? On the other hand, from the bottom-up perspective as Neil mentioned, SOA governance is also involved with execution and the enforcement, taking a policy and then making it instantiated in the architecture and behavior of the processes. So, it's yet another reason why they should come together is that they actually need each other. How do you see this, Steve Garone?
Garone: I've been listening to the other guys talking. They're very insightful comments, and I agree with them in substance. I think the over-arching issue here is that GRC platforms are taking more of an enterprise architecture approach. They're still looking at business processes, monitoring business processes, and maybe even getting to some extent into the redesign of those processes to optimize the ability to meet compliance needs. SOA has, in fact, been coming from the ground up, and solving maybe a specific problem or issue within the department or organization. Because we’re in the early days of SOA, we're seeing a lot of that.
One of the interesting nuances here is that both approaches eventually need to focus on the business processes within the company, and optimize them for various reasons. SOA tends more, at least right now, to focus on making business processes work more efficiently. How those services are segmented and designed functionally ideally should reflect that; whereas, for the enterprise architectural approach and the GRC approach, we're looking more at being able to meet compliance needs. The question becomes how do you develop a services-oriented approach that meets both of those needs, optimizes compliance on one end, and optimizes customer satisfaction and performance and business agility on the other hand. Those could ultimately be in conflict, as these two worlds come together, and that’s an interesting new answer that organizations are going to have to look at.
Gardner: So, there seems to be some general consensus that there is value in bringing these so far disparate areas together -- governance risk and compliance with the SOA governance. If we were to move toward this middle ground and make them relate, it strikes me that data becomes important.
Joe McKendrick, you keep your ear to the street on data quite a bit. Do you think that this is simply a matter of yet again finding a meta level or layer that allows the data that’s being derived for one or both of these areas to be viewed, or used together, and wouldn’t that be a first necessary step?
McKendrick: Absolutely, Dana. It’s interesting that when we talk about SOA in relation to another type of corporate initiative -- in this case SOX and GRC and so forth -- we're always wrestling with how SOA fits into the picture. We've been challenged to make the pieces fit together, and I find that’s an interesting conundrum for SOA across a range of things happening in organizations. That being said, I recently conducted a survey for the Oracle application’s users group. We just released the survey last month on the very topic of GRC. These would be the folks who are working with the Oracle e-Business Suite, Oracle application server, and so forth…
Gardner: Of course, we know that anything SAP does, Oracle will be coming along, or vice versa.
McKendrick: Exactly. SAP seems to be pretty far head of the curve in this regard in GRC. What we found in the survey is that for the most part, there’s awareness. About 40 percent of the survey group from the 400 companies we interviewed was fairly aware of GRC, what's happening, and what's required for GRC. That was higher than we expected. So they’re trying to getting their heads around what needs to be done with compliance. At this point, the tools that are being used the most to accomplish the task around GRC compliance are the Excel spreadsheets or the Word-type documents that are flying back and forth. Seven out of 10 companies are moving these processes through or doing the reporting and putting out reports for the audits with these manual tools. Only about 15 percent say they have any measure of automation.
Gardner: They are using Excel spreadsheets?
McKendrick: Exactly. Excel. I think automation is going to be the key to all this, because companies are not in the business to meet SOX requirements. They are in business to make money for their shareholders. They’re in business to sell products. Compliance isn't their main line of business. They're being forced to pay attention to compliance and they are being forced to deliver these reports to auditors. Right now, they're committing staff to it. They're committing a lot of resource time, and resources that they don’t want to, and it’s happening on a quarterly basis. The folks involved in the reporting process have to generate the same reports every quarter, and we need to build in automation and repeatable processes. This is where SOA can play a pretty vital role.
Gardner: And, clearly business intelligence vendors, including SAP, have come into the fore. Reporting is the very core of business intelligence. So, first and foremost, if you want to do compliance, you have to produce reports, and if you have to produce reports on a regular basis from structured data in your operational systems, you need business intelligence (BI). That’s really the core, as it were, of any GRC platform.
One of the interesting things I'm finding in the growth of these GRC über-platforms is that there’s another important user interface, other than just the reporting and dashboarding the BI stuff. There are also structured surveys that can be delivered to stakeholders in a process on a periodic basis, asking, for example, procurement agents how well various business requirements or regulatory requirements are being met, from the procurement side to be in compliance with Sarb-Ox or whatever it might be.
So most of these platforms now have what I call a stakeholder interaction environment, involving not only the surveys, but other human workflows, not just GRC as a mean for pushing big rolled-up risk dashboards to the CFOs and the CEOs, but GRC as a way of regularly serving the troops as to how well processes are performing on various levels.
Steve asked earlier about how do you develop a GRC approach that addresses compliance, but also ensures business agility? One of the things that you can do is survey the troops, the grassroots stakeholders and process participants on a regular basis. "How well are we not only serving the Sarb-Ox requirements, but how well are we serving the customers through this retool process that you instantiate every day?"
Macehiter: As we see more of these compliance solutions emerging around identity management, business intelligence, and the stovepipes of technology, what will happen is that the problem will move away from organization struggling to find the information. We actually have too much information and we have to rationalize it. Our identity management system is telling us we're in compliance with Sarb-Ox because x-y-z, and our purchasing application is telling us, but we can’t actually rationalize the different information to provide visibility into whether we are really compliant. That’s going to be a very real problem.
Kobielus: Now, I just want to add a note here too. Hugh Taylor, vice president over at SOA Software wrote a book on this very topic called, "The Joy of SOX." I don’t know where he got that title from. Was there another book with the similar title one time?
McKendrick: "Fox in Sox" is a Dr. Seuss book.
Kobielus: The full title was, "The Joy of SOX: Why Sarbanes-Oxley and Services Oriented Architecture May Be the Best Thing That Ever Happened to You." He actually connects the dots, and it's the first real comprehensive case I've seen of someone actually tying the two together.
For his main point, he talks about the agility that SOA can deliver and the agility that is required to meet various compliance mandates and future mandates that will be coming down the road. The key thing with SOA is that, it enables you to access legacy systems. Most of large companies that are facing SOX audits also have mainframes and many legacy systems that they need to deal with.
Gardner: Well, if he can make regulatory compliance sexy, all the more power to him.
But I think we've come to a point here where hypothetically we recognize that having converged governance makes great sense. It strikes me, however, this is going to be many years before any kind of actualization. In the meantime, the larger message perhaps is that, as you’re doing BI, and as you’re creating more ability to capture data, cleanse it, and provide it in a way that gives you this GRC benefit, then when you decide whether you’re compliant or not, or you come up with an agenda of what needs to be done, that is not by choice but is mandated, how do then face back into the organization and get that into execution?
That’s where SOA can come up to the plate and say, "Well, why don’t we take your mandates and instantiate them into our policy engine that's reflected through the IT systems that has a relation to the legacy systems, as well as to the new systems?" Then SOA becomes the hammer through which something like a GRC platform can mandate and enforce. Even if these two systems remain disparate, it seems that they have a tag team in the near term. Can anyone react to that?
Macehiter: In an ideal world, the way the service-oriented approach works is that it’s much more declarative, much more policy driven. You don’t lock away, for example, the way that you authenticate a request or the way that you log a request into the application logic. You externalize that and control it through policy. That then allows you to drive though these policies from the high-level requirements to the GRC level down into the service infrastructure.
Whatever follows from SOX doesn’t mean building in a bunch of new code that ensures that you comply with SOX-plus, SOX 2.0, but rather that you define the policies that you need to, and then get them enforced through the infrastructure. So, I think you’re right that it’s a hammer, but the hammer needs to be wielded quite carefully. The key is going to be the semantics, and the language that allows you to define what most policies are, so that they can be enforced effectively.
Garone: I agree and just to carry the analogy a little bit further, it’ll be nice to able to design that hammer at the same time you’re assessing your compliance requirements and putting that infrastructure in place as well, so that the wielding of the hammer becomes more closely aligned with your goals as far as compliance is concerned.
Gardner: That would be the ultimate convergence, but even in the meantime it strikes me that there is sufficient short- to medium-term value in generating a SOA governance capability. Compliance and regulatory oversight is perhaps a major rationale for SOA, sooner rather than later.
Anybody else want to comment? Jim?
Kobielus: SOA is about sharing and reusing valuable corporate resources that are networked. The GRC platforms increasingly will differentiate based on their ability to bundle a broader range of best practices accelerator with polices and works flows and roles and metadata, and forth. So, really, GRC platforms are platforms for SIs to customize the policies to meet the needs of particular clients. The accelerators themselves are the sharable, reusable SOA resource that will speed up the implementation of compliance solutions in various markets. The accelerators themselves are the most critical resource that defines a GRC platform or GRC solution.
Macehiter: The point Jim raised about sharing and reusing is absolutely the key here. It's the one of the biggest challenges around compliance. Typically, organizations have multiple instances of processes locked away in different applications. They have 16 different versions of their customer or 14 different versions of a purchase order.
If what you can do by virtue of adopting more of a service-oriented approach is have common services to actually deliver capabilities that need to be audited, logged, and monitored, or if you can have a single shared service that increases consistency and reduces the effort you need to apply for compliance, increasingly what we will see is the rationale for the business case. What underpins an SOA initiative will be either that it improves our ability to comply in a cost-effective way and increases the consistency of what we do to comply.
Gardner: Perhaps what we should expect to see is not only the SOA vendors and service providers talking about compliance and regulation as a rationale for SOA investment and evolution, but perhaps it might be in the best interest also of these GRC platforms to say how well they play in conjunction with SOA and that there is a complimentary nature here.
McKendrick: Right. The only issue is that GRC is typically led by financial folks and, of course, SOA is coming out of the IT department. What happens is that the financial folks are saying, “We need more of this automated. We are not going to give you more budget to do it, but IT folks automate this process little bit more for us."
Gardner: Well, that issue is an excellent segue to our next topic, which is the announcement on Feb., 12 of the SOA Consortium, a group of both vendors and enterprises -- they are calling themselves Global 1000 End-user Organizations -- in order perhaps to bridge some of these gaps and promote the best interests of different constituencies within organizations, as well as within vendors and types of vendors.
The declared goal of this organization is to promote the adoption of SOA, and they’ve given themselves a deadline of 2010. So, in the next three or four years they want to get more people aware of SOA as a key enabler, as an element of any modern 21st century architecture and enterprise. They want to achieve benefits of SOA to change both IT and business, bridging the gaps and silos, both technically as well as culturally. They want to help the perception of SOA by business executives, they say, as an IT integration and productivity story, rather than a business agility story.
That sentence jumped out at me to say, "Aha!" These are some of the things we’ve been discussing for a number of weeks about the positioning of SOA for adoption and appreciation. It seems to me to be saying that the story around business agility is a system’s integrator business and organizational management topic. They want to bring it back into an integration function. Any reaction to that?
Macehiter: I read the press release and I think it’s actually a badly worded release, to be honest. What they’re actually saying is that one of the issues they're trying to address is the fact that SOA is perceived by business executives as an IT and integration productivity story, and they want to turn it into a business agility story. But it’s not clear.
McKendrick: I read it the same way and I agree with that statement, based on my experience with end-users. When I hear them talk about their experiences with SOA, it’s always around cost issues and the integration challenges, and very little about "Look at the business agility we achieved." What they are doing is citing that as a significant issue and potentially a barrier to SOA adoption, and I assume it’s their intent to address that.
Kobielus: I didn’t see a lot of specifics in this announcement. I try to boil down every press release to its absolute core, in terms of substance, and I didn’t see a whole lot here other than they are going to hold a bunch of summits in different cities, present some general mission, seek validation of that mission, and then ultimately produce a detailed report that will validate and direct the charter of the SOA Consortium.
I’m sorry, I had to put on my cynic hat. It sounds like this is an excuse for many fine lunches and dinners to be had. In terms of building awareness of SOA, it’s like -- duh. Aren't we all hyper-aware of SOA by now? Let’s think of the next step. You can sort of understand the vendor’s perspective in working in an organization like this, getting visibility and perhaps more importantly being able to leverage the successes of some of the companies who have used SOA. I’m not really sure what’s in it for the end-user organizations, and that's where I become skeptical.
Gardner: Well, if you look at the very last line of the release, it says, the SOA Consortium is managed by the Object Management Group, and we know from past history that the OMG's job has been to create a consortium generally around a set of standards, and there is no mention here of standards, because these are invitation-only summits, with both vendors and end-users. I think that the underlying agenda between the lines here is to help create a level of some standardization, perhaps around governance, perhaps around SOA interoperability. But, clearly there’s going to be a set of standards that’s going to evolve from this, not just from the perspective of the vendors, but also the end-users. And, that in itself strikes me as somewhat positive.
Macehiter: I think so. Look at what’s happened, for example, around the Liberty Alliance in a different domain involving large adopters and vendors, and that has delivered some tangible results. So, I think it holds promise because this is not the classic vendor "Let's set standards" to help customers, but without actually involving the customers in the process. So, that’s a positive sign.
My concern around this is whether the Object Management Group is going to embrace the work that’s currently on the go, taking place in OASIS around blueprints reference architectures, because there’s a lot of IT being developed there, that could be effectively exploited. I am just slightly concerned that what we are going to get is a proliferation of best practices and no common best practice. I’m also concerned that this is about global initiative, where the initial summit’s taking place just in the U.S., because the way SOA is being adopted in Europe, is very different from the way it’s being adopted in the U.S., and its relationship to things like enterprise architecture. I know this is only the initial meeting, but it sets the frame of reference for the rest of the work.
Gardner: Hold on a second. There could be some hope for this being global, if the funding sponsors are BEA Systems, Cisco Systems, IBM and SAP.
Macehiter: I think that’s global from a vendor perspective, as opposed to an adopter perspective. If I start to see the likes of HSBC or Tesco and some of the big adopters that we have over on this side of the pond involved in this process. That will stand in good stead.
Gardner: That will be critical for them. I agree.
Garone: The OMG has usually been pretty good about globalizing what they do, so I wouldn’t be too concerned about that. I also think that the point about the vendors being global is an important point, because based on the way the OMG model has evolved; I suspect this is being driven mostly by the vendor community.
Gardner: What we should do then is invite someone from this group onto the show in the next few weeks. I’ll reach out to Richard Soley, who is the chairman and CEO of the Object Management Group, and invite him to come on the show, and we can pose some of these questions to him. Is this a movement toward standards? Will they be global and inclusive? Will they be vendor-focused, or is there going to be a good balance between the end-user organizations as well? So, our listeners can look forward to a further discussion on the SOA consortium announcement with someone involved closely with this effort.
Kobielus: I like the parallel you drew with the Liberty Alliance, which is still actually a very vital organization. It started out as a standards organization or standards developer and still is to a degree, but has really moved deliberately to more of a best-practices forum in the identity management space. This is a critically important in a space such as in identity management, where there’s still a blizzard of standards and specifications, competing for market share and so forth. More than that, there is a huge variety of use cases and possible deployment scenarios, topologies and interoperability issues bedeviling that space.
Think about SOA. That’s even more confused and confusing in terms of best practices in such a global oceanic sense. SOA is literally all over the map. So if OMG, as a best practices forum, can help the industry to converge on a consensus of best practices for SOA, godspeed to them.
Gardner: Well, this has been another insightful 45 minutes. I would like to thank our panel of Steve Garone, Joe McKendrick, Neil Macehiter, and Jim Kobielus. I'm your host and moderator, Dana Gardner.
That’s it for this week's SOA Insights Edition, Volume 12. We appreciate your time and listening in. Please come back next week. Thanks, everyone.
If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 12. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Friday, March 23, 2007
BriefingsDirect SOA Insights Analysts Explore SOA's Role Through Failure, Governance, Policy and Politics
Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Feb. 2, 2007.
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Volume 11, a weekly dissection and discussion of Services Oriented Architecture (SOA) related news and events with a panel of industry analysts and guests. I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet blogger, and Redmond Developer News magazine columnist.
Our panel this week, and it is the week of Jan. 26, 2007, consists of Steve Garone, he is a former IDC Group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome, Steve.
Steve Garone: Thanks, Dana, great to be here again.
Gardner: Also joining us, Joe McKendrick, a research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Welcome back, Joe.
Joe McKendrick: Hi, Dana, greetings.
Gardner: Also joining us is Jim Kobielus, a principal analyst at Current Analysis. Welcome back, Jim.
Jim Kobielus: Thanks, Dana. Hi, everybody.
Gardner: This week we’re joined by our guest Miko Matsumura, the vice president of SOA products at webMethods. Thanks for joining us, Miko.
Miko Matsumura: I appreciate being here. It's a great group.
Gardner: Now, Miko, you joined webMethods recently through the acquisition of Infravio. How is that going? Is that officially closed now, and what's the outlook for the two companies working together?
Matsumura: Well, it’s officially closed, and it’s very exciting. I tend to take an Infravio startup perspective, and from that perspective it’s almost like there are 10 times the number of sales people to talk to. It’s a little bit like The Darwin Awards guy that put a rocket engine onto his Chevy and raced it on the salt flats. Things are going a lot faster, and it’s kind of fun.
Gardner: Cool. Is this going to be a case where it’s the Infravio tail that wags the webMethod’s dog?
Matsumura: I listened to the [webMethods President and CEO] David Mitchell earnings call last night and we had a game, a virtual drinking game, we were playing by instant messenger. Every time someone said the word Infravio, we would say,"Drink." Were we actually consuming alcoholic beverages, I’m sure we would have been pretty soused by the end of the call.
Gardner: Cool. Well, it seems like so far it's a happy match up. It’s good to hear.
Matsumura: So far, so good.
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?
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. Any thoughts about that?
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 you just indicated was that, in the case of SOA, the focus in terms of failure might be more on the technology-based pieces associated with building an application. Do you see SOA being different in terms of what actually is responsible for failures?
Matsumura: I'm delighted to have you take that approach, because I’ve actually cast this net out into this group as a very neutral test to see what kind of like fish will come out of it. I used a very generic term, "moving parts," but I didn’t specify. Your inclination was to think that I was talking about technology.
Garone: Well, people do so …
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.
So, thank you very much for heading in that direction. Any one else have anything about "moving parts"?
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 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.
Matsumura: I want to plead guilty as charged. I don’t want to monopolize, but I do want to say that I just recorded an SOA governance podcast on my own, the theme of which was, “Reorganizing the Billion Dollar Software Project.”
Kobielus: I didn’t mean to imply that you were the kingpin of failure, and, in fact, I figured that people who are having trouble in the field look more toward the governance value in order to help solve their problems. I thought I was giving you a soft ball not a hard ball.
Matsumura: No, I appreciate that. Anyhow, I’ll cool my heels and let the others speak.
Gardner: No, you’re the guest. That’s fine. But some of our other discussions on this weekly podcast in the SOA domain come back to the notion of systems integrators (SIs) and even management consultancies getting the lion's share of business in the near term with these things, because it is about culture, people, and process. And the user companies need to shift a lot of what they are doing in order to exploit the benefits of some of the technology and standardization.
I wonder if you agree with that. Do you think that for the next two to five years vendors like yourselves are being dragged along, or do you have another relationship with the SIs that have to get in there and monkey around a little bit with the culture to get companies to transform?
Matsumura: Being dragged along might be a tall order. The reason I say that is that we’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.
Gardner: Joe McKendrick, what do you think? Is this a control issue right now? Or is there some jockeying going on among the internal constituencies in an enterprise, some of the vendor’s constituencies, and also the SIs? And who’s going to win?
McKendrick: There is a lot of jockeying going on, and Steve has pointed this out in a previous podcast as well. 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.
Gardner: Maybe we should define failure. I was thinking of it as an instance where these new practices and methodologies were tried, but people didn’t think they were working. There weren't cohesive approaches. There wasn’t standardization in the organization.
And, so they went back to business as usual, which would have been some of the older application-development ownership and deployment practices, silo-types of affairs. So, in other words, a reversal from a movement toward holistic services, used broadly, to "I’ve got my set of apps. I'm going to maintain control over them. And, if you have any kind of changes or requirements that you wanted to address, you can get in line" mentality.
Matsumura: This strikes to me as a way of defining retreat as a "strategic advance to the rear." There are definitely potentials for failure. Since failure is an orphan, even though success has 10,000 fathers, I can’t allude to a project I know that experienced a failure condition.
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.
The whole thing we alluded to early about this integrator setting up a base camp inside a company ... we’ve had customers who deliberately, pre-webMethods, used Infravio as a wedge and basically said, “We don’t want a single vendor to come in with a product and a set of services, because we don’t want them to control everything. We want an independent to mix things up."
There is a very significant danger of the inmates running the asylum or the integrators taking over the whole account from the inside.
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?
Gardner: So, we can agree that something that would be opposed to failure would be less lock-in, and that could be lock-in from a vendor, lock-in from an integrator, or even internal lock-in, where there is a very strong division within IT or some other organization that’s holding the rest of the enterprise hostage.
Is SOA a democratization type of an effect, or is it really giving command-and-control through policies that you could think of as a governor or an accelerator -- a brake-pedal/dashboard type of an affair -- where suddenly those in the organization that may not have had power before gain it? Is the failure when the control doesn’t go to the right people?
Matsumura: Yes. That hits the nail on the head. I was giving the keynote of the governance track at The Open Group SOA Conference in San Diego [on Jan. 31], and one of the questions that came from the audience was about metadata. Who controls the metadata?
This question is basically The SOA Question, because the people who control the policy metadata are the people who are running the show. The thing that we’re trying to establish here is that the SOA success model is essentially a model where there are federated controls and delegated controls. The reason why this term "federation of control" is so significant is because we’re trying to achieve a balance between the central function, the IT function, and the distributed function, or the business function.
People talk about the agility and control. If you want to balance these things, you need a mechanism that enables some amount of control by the people who are on the periphery, in the business units, trying to create agility. Then, [there comes] some amounts of control by the people in the center, who are trying to create more orthodox standardization and security and orthogonal cross-cutting concerns.
Having the wrong people controlling the wrong things is exactly the pattern that causes things to go a little nuts. The old-school model -- having one single point of control for everything -- has actually proven to be undesirable. While it is not prone to failure, it’s not prone to success either.
Gardner: I suppose when we’ve seen enterprises that are in a suffering mode, when IT and the business are not aligned or not syncing up, well, that can often be due to a cultural clash. For example, if it’s a distributed company and they try to have a distributed approach to IT, that can break down.
If they’re a centralized company, but IT is decentralized among departments that are doing their own applications -- then that could break down. But what’s probably more productive is, as you say, a hybrid approach where certain functions, let’s say procurement, should be centralized. If you can take advantage of a volume approach to your procurement, if you can go to your vendors and suppliers with a larger bid, you can get a better deal. So there are lots of reasons why procurement should be centralized.
But there are other examples, perhaps around knowledge management or around innovation and collaboration, that should be very ad-hoc, very decentralized. How can you manage both of those types of cultures across the company, and then instantiate that through how the IT department behaves and reacts? Anybody have a sense or reaction of that?
Kobielus: A SOA and a SOA initiative are a success if it gives you the ability to adapt the SOA governance structure to your actual business governance structure.
As you’re saying, your business governance structure will evolve over time. All business models change. So the extent to which your SOA initiative and your SOA governance are totally centralized and totally rigid -- but your business environment and the challenges and threats and so forth are constantly changing -- then your SOA failure will ultimately become a business failure, a failure to adapt.
Garone: I’ll concur with what you just said, but also add more in the way I look at it: I don’t necessarily see a contradiction between some levels of centralized control and being able to achieve business agility. The argument for business agility really is about making sure that you make changes quickly to dynamic market conditions and relationships, and so on.
While too much centralization may make that a little bit more difficult than it would be if everything were ad-hoc, I don’t think it makes it impossible. Of course, the world is about balance. The world is about finding that midpoint, where control and governance is centralized enough to keep things safe and secure, and to be able to take advantage of business opportunities -- where consolidation makes sense -- while at the same time staying agile. That’s really the challenge, the way I see it.
Gardner: I guess we need some standard methodologies or best practices around how to approach the whole organization culturally. That brings us into a discussion around ITIL or around what The Open Group has been doing [in terms of certifying SOA architects and the move to the "Town Planner" model of enterprise architrect roles].
Miko, let’s go back to you, do you have a sense of whether there is a legitimate standardization approach that is welling up in the marketplace?
Matsumura: I’ve just been speaking with the head of The Open Group, SOA Governance Working Group and absolutely there are efforts in this area, under the banner of TOGAF, ITIL, and other types of processes. It’s still reasonably early in the game, and what people need to understand and establish are the basic patterns and best practices. A lot of the efforts that create these extremely ornate methodologies are intended to be recipe-book and all-encompassing or one-size-fits-all approaches. I think it’s early in the game to take those approaches.
What I would do is take a look to see if there’s any precedent for a model for policy-managed systems that balance the need of a central entity and the needs of distributed entities, against the desires of the whole. If you look at it from a metaphorical perspective, for example, the federal government of the United States is a very interesting model. You have essentially a bunch of business units called states, that each have their own legislation, their own competency centers called state legislatures, and even their own executives called governors.
Those look a lot like business units to me. If you look at the notion of federation and the federal government model, what you see is this whole principle of jurisdiction. Ultimately, competency centers become the legislative bodies within these organizations. All of the efforts that I’ve seen to codify methodologies around SOA tend to focus on these competency centers or centers of excellence, primarily because there needs to be an inclusive organization for adjudication and jurisdiction, as opposed to having a model, where it’s just a single iron-clad dictator that controls all policy.
If you want to go that way, let’s just go and live in the mainframe and forget about SOA. Not that this would necessarily be a problem, we just have to do it deliberately and well.
Gardner: This is great. 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.
Matsumura: Just to extend that metaphor to the initial theme about failed SOA ... . You can actually look at the failure modes of failed states. If you look, for example, at how you establish and foment democracy, there are some models, some really good, real-world cases about how not to establish democracy. Not to get too overly abstract, but there are a lot of practices and principles around establishing policy federation. The interest in doing so is the interest in establishing a controlled paradigm that actually serves the common good in a way that enables agility, but also enables this centralized capability of control.
Gardner: Right. If your company is behaving like Zimbabwe, you need to do something different.
Matsumura: Exactly.
Kobielus: We talk about political governance in terms of the world community. There is no one right governance model within a state or among the various states of the world. But clearly, history has been marked by individual states or groups of states playing and towing with, if you can use the word, various governance models ranging from absolute dictatorships and empires down to sort of laissez-faire, no centralized government.
But governance is an abstract concept, and you don’t necessarily want to dictate one governance model that’s applicable or should be applicable to all organizations and industries. Everybody has their own pressures, market pressures and so forth. In terms of SOA governance, there are radically centralized models in a given organization. It could be a radically centralized governance model within a given industry sector in the sense that basically one monopoly company controls an entire sector of the economy and they then dictate all the SOA policies and practices for all of their tributaries, as it were.
In the world, you have 230-something countries that are sovereign states ostensibly, and they establish various bilateral treaty relationships and also participate in various multi-lateral treaty organizations like the United Nations and NATO and so forth. Any given country is probably, involved in various international governance schemes as it were -- but also internally, from generation to generation, from revolution to revolution it’s going from centralized to decentralized. One size doesn’t fit all generations of governance.
Gardner: So, maybe we should take a lesson from the United States in Iraq, where you need to look at what you’re getting into. You might not want to just take a company and inject a pure democracy or a federated approach. In fact, each company has its own history, its own culture.
You might want to do the equivalent of a Myers-Briggs test and figure our what kind of company it actually is. Then, figure out in what way to approach governance, so that we don’t try to overstep what’s possible on a linear basis. I suppose it’s also evolutionary. Some companies might need to start out as strict dictatorships, and then perhaps the government withers away and it becomes a democracy. We’ve seen the example of Eastern Europe over the last 20 years. Any thoughts on politics and geopolitics as a lesson for SOA?
Garone: I think it’s a great metaphor. I’m thinking about the model that I think makes sense in that regard, although it’s kind of obvious, which is basically, the U.S. Constitution and the federation of states. You’ve got certain things that are up to each state, and certain things that are up to the federated entity sitting on top of all of it.
Gardner: If I could just pause you. The first step, the Articles of Confederation, which gave too much power to the states, didn’t work.
Garone: Right. So, now you’ve got a dynamic situation where some of that can change and over time. Plus you can also “amend your constitution” to make changes as appropriate. But, there was not always a set of things that are controlled by the centralized entity, the federal government, in the metaphor. But there’s also a certain set of things that those individual states need to comply with in making their own rules.
Matsumura: I just want to jump in here and talk about the U.S. Constitution, which has some key design patterns in it. If you actually look at the separation of power declared in the preamble, it says that the purpose is, "... in order to form a more perfect union." So, there’s this notion of the intent of the formation of this governing entity, which is the goal of a more perfect union, which essentially means that there’s a distribution of power and that the consent of the governed essentially be the overriding principle.
The idea that comes out of that, though, is the clause "provide for the common defense." That’s really talking about the security domain, whether it’s physical security or technical policies associated with the current data. The idea is that it actually should be a federated concern. In other words, security is everybody’s business. You can’t just delegate it to one unit and say, "It’s your business."
The earlier comment about how there’s no one-size-fits-all is absolutely the case. For example, I just spoke with a bank that's highly decentralized. I also spoke with one of our customers, Johnson & Johnson, which has 200 operating companies, and is fairly decentralized. Their central IT exerts a pretty strong coordinating function. So, we’re talking about the big picture, which is, how do extremely large entities organize themselves and how do they achieve success in that organization?
Garone: It comes down to what an organization wants -- centralized or decentralized IT functions. Getting back to the whole notion of the Founding Fathers of the United States, they were not of a single mind among themselves on the proper governance structure. You have Alexander Hamilton, who wanted highly centralized. Then you have Thomas Jefferson, the fellow who wrote the Declaration Of Independence, who wanted it quite decentralized.
And they yanked back and forth until various things happened, and that got more centralized. Then, you had some of those, like in the southern states, who felt it needed to be highly decentralized, and fought a war to try to enforce that kind of order. It’s one of these things that just keeps rocking back and forth, from one generation to another, in terms of the right approach.
Kobielus: Look what’s happening in Venezuela now with this guy Hugo Chavez. He’s totally centralizing everything, establishing a new dictatorship there. Not all of his country people are happy with that. I saw in The New York Times that a lot of them are applying for asylum in places like Spain and elsewhere. This is highly political, but on the IT front, it’s the same thing. Quite often, SOA is justified on a project-by-project basis. "Oh, yeah. We’ll do this project according to the principles of SOA," without necessarily implying that they’re trying to impose SOA practices across all projects and across all systems.
Gardner: Now the corporation as an organizational definition has been around for couple of hundred years. You look back to early mercantile activities, to some of the Dutch companies that had started in 17th century, for example. The modern company is certainly at least a hundred years old.
If we look at some of the large conglomerates, there’s a history of progression around corporations as entities in a more modern sense. Perhaps what's different now, though, is that companies are of, for, and by -- if I could borrow another political statement -- technology. Technology so permeates how a company operates, particularly if you’re Internet-facing and if you’re using and exploiting the Internet for more and more of your supply chain, your distribution, your transportation, for the way in which you attract sales and customers, and so on and so forth.
So technology now is at an intersection with the corporation as an organization, and perhaps that’s what’s forcing this need for a different look at how to organize in general, and, therefore, on how to govern.
Matsumura: I wanted to respond a little bit, too. One of the themes that emerges from our conversation here is that we’re talking about SOA as more or less of a post-modern infrastructure. What I mean by that is that some of the themes that emerge in post-modernism, post-structuralism is the notion of the breakdown of the dominant narrative, which is that there isn’t a universal "thing." The resistance to the one-provider IT stack model, the suite model, is the notion that there isn’t a single system that can rule them all, over all others, and that heterogeneity, components-wise, is the law of the day. Think about that particular heterogeneity in terms of how it functions from a policy perspective.
We talk about federations and policy context, but there’s a degenerate case, where essentially what you’ve done is you’ve created a federation of two. This means that two business units come up with an agreement, or two companies come up with an agreement, which is referred to as a contract. The reason I’m alluding to this degenerate case is that a contract is treated as a completely different class of legal structure within our governmental system, and is protected by the civil law system. When disputed parties get into contention, it’s basically a civil issue.
When someone breaks a policy held by the government at-large then it is either a federal or state issue. From the perspective of creating an appropriate taxonomy, it’s important to consider that these two cases are actually pretty different. Perhaps an attempt to establish initially a sweeping universal regime of centralized federated policy may actually be subsumed by these kinds of groupings of pairs of twos or threes -- or United Nations or NATOS -- or just the kind of loosely coupled and smaller policy domains that are built on top of individual agreements between provider and consumer pairs.
Gardner: I guess we’re somewhat fortunate that there are only about 200 countries in the world, but there are thousands and thousands of companies. So, there’s a lot more opportunity for experimentation in the marketplace and for competitive forces to play out dominance. We can see some success stories, as well as failures, and we can learn from those successes on how to best organize a highly technologically advanced corporation.
McKendrick: We talk about the post-modern corporation. Where are these companies going to get their IT? Where are they going to get their technology? We’re seeing more and more instances of companies going outside, not wanting to get involved with the bits and bytes of managing a technology infrastructure.
We call it "software as a service," "managed hosting," and various types of acronyms and terminology. But I’ll bring Nick Carr into the argument here. Nick Carr said IT doesn’t matter. It’s going to be ubiquitous, available like a utility. Any company can tap into it, whether it’s internal or external, to the point where it’s not that big of a concern.
Matsumura: I can’t resist shooting at this. It’s going to require you to follow along with the metaphor that we’ve drawn. If you can’t suspend your disbelief in the metaphor, it will be hard for you. The metaphor of nations and the competition between nations has typically been along the lines of warfare in our history.
Look at the metaphor of business at war, which is essentially competition for the survival of the integrity of your company against all others. It’s not on the battlefield, but it’s for customer value, for creating services that people treasure. In the history of warfare between governments and nations, what we found is that the organizations that leverage technology to their advantage are the ones that come out ahead.
Abdicating the responsibilities of the management of technology to a commoditized provider creates an extreme vulnerability because your competitive differentiation should not be held or embodied by some generic provider. I think even Nick Carr has backpedaled from his hard-line IT commodity position.
Gardner: I’ve noticed that Nick has backpedaled a little bit, but again we’re back to where it’s not necessarily all-or-nothing. There are going to be some aspects of technology that are commoditized, that should be accessed centrally, and there are many others -- perhaps this will change over time -- that are differentiators. Control over how your organization behaves and controls your assets and resources strikes me as something that you would never want to commoditize.
Kobielus: Think of this notion of where companies in the most post-modern age are going to get their governance structures from. I think a lot of the governance risk and compliance management vendors -- it’s a new market space; companies like SAP and OpenPages and MEGA International and BWise, and others, are building up platforms that have both verticalized and horizontalized governance templates, rules and workflows, and so forth. Increasingly companies or enterprises will standardize on a dominant governance risk and compliance management vendor for their organizations, and then use whatever templates they choose. And their SIs will modify them to suit their own needs going forward.
Bringing this back to the whole notion of where nations get their governance charters. I just read a book, a really good one, called "Declarations of Independence," and it shows that the first actual declaration of independence ever created to found a nation was our Declaration of Independence in 1776. You wouldn’t believe how many other countries have actually plagiarized or borrowed language and whole concepts from it, including Vietnam. The declaration of independence for Vietnam in 1945 directly quotes from our Declaration of Independence, which I found highly ironic.
Garone: I’m going to bring back outsourcing into this discussion as well. Post World War II, the nations that have relied on the Unites States for its defense have thrived economically, because they have not had to spend so many dollars on their own defense -- Germany being the prime example. They’re under our umbrella, and their defense budgets are much lower than ours, and these nations have thrived and moved forward.
Gardner: Well, without getting too deep into what is or isn’t the right approach in world affairs, clearly we’ve defined here that a successful SOA is a lot about politics, power, and moving beyond traditional norms of organization. How you do that probably is going to involve failures. If the Unites States is a good model, it had to fail a couple of times. It failed with the Articles of Confederation. It failed in dealing with slavery up until the Civil War, and perhaps for a hundred years afterward in terms of how it was dealt with in practice, if not in law.
So the idea that we started this discussion with -- where are the SOA failures -- perhaps we should look to failures as a necessary set of learning activities, in that SOA is not going to just happen and spring up like a fungus or a mushroom after a spring rain, but it’s going to have to be something that’s hard-earned.
Matsumura: Well, the way I want to respond to is that having maturity in the way that you deal with failure is essential. If you look at the way that our policy system functions within the United States, what you have is you have a set of policy assertions about what it is people can and can’t do. But then you actually have a policy enforcement mechanism that’s heterogeneous and distributed. You have the FBI, the CIA, the state and local law enforcement, the Army and the National Guard.
You have all these different policy enforcement points everywhere, manifesting these policies. What is extremely important to understand is that there’s an entire judicial system whose function it is to take those policy enforcement actions, monitor their efficacy, and enable the whole system to readjust and adapt.
So, I think that it’s not just an accident of, "Let’s just run out there randomly, screw up badly, and then sit there and try to recover and learn." I think that having a learning engine that monitors, adapts, and revises policies, and having a competency center, an adjudication point that’s deliberately there for the purpose of making those adaptations -- that is an essential function.
Gardner: Or checks and balances ... . If you’ve got failure, that could be a very good learning experience, where you need a check and balance in place, and so the progression toward the value and benefit of SOA can be accomplished. It will be a different path for each company, but they’re going to have to have checks and balances to keep the progression going forward, rather than reverting back to the past, and in a sense giving up.
Well, this has been a very stimulating and interesting discussion, I’m glad that you all could join us. It took on a little different characterization than I was expecting, but a necessary vantage point on SOA in order to make it successful.
We’ve been joined here with our usual panel, Steve Garone, Joe McKendrick, Jim Kobielus and our guest, Miko Matsumura, vice president of SOA products at webMethods. This is your host and moderator, Dana Gardner. You've been listening to BriefingsDirect SOA Insights Edition, Volume 11. Thanks for listening and come back next week. Thank you, gentlemen.
If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 11. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Volume 11, a weekly dissection and discussion of Services Oriented Architecture (SOA) related news and events with a panel of industry analysts and guests. I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet blogger, and Redmond Developer News magazine columnist.
Our panel this week, and it is the week of Jan. 26, 2007, consists of Steve Garone, he is a former IDC Group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome, Steve.
Steve Garone: Thanks, Dana, great to be here again.
Gardner: Also joining us, Joe McKendrick, a research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Welcome back, Joe.
Joe McKendrick: Hi, Dana, greetings.
Gardner: Also joining us is Jim Kobielus, a principal analyst at Current Analysis. Welcome back, Jim.
Jim Kobielus: Thanks, Dana. Hi, everybody.
Gardner: This week we’re joined by our guest Miko Matsumura, the vice president of SOA products at webMethods. Thanks for joining us, Miko.
Miko Matsumura: I appreciate being here. It's a great group.
Gardner: Now, Miko, you joined webMethods recently through the acquisition of Infravio. How is that going? Is that officially closed now, and what's the outlook for the two companies working together?
Matsumura: Well, it’s officially closed, and it’s very exciting. I tend to take an Infravio startup perspective, and from that perspective it’s almost like there are 10 times the number of sales people to talk to. It’s a little bit like The Darwin Awards guy that put a rocket engine onto his Chevy and raced it on the salt flats. Things are going a lot faster, and it’s kind of fun.
Gardner: Cool. Is this going to be a case where it’s the Infravio tail that wags the webMethod’s dog?
Matsumura: I listened to the [webMethods President and CEO] David Mitchell earnings call last night and we had a game, a virtual drinking game, we were playing by instant messenger. Every time someone said the word Infravio, we would say,"Drink." Were we actually consuming alcoholic beverages, I’m sure we would have been pretty soused by the end of the call.
Gardner: Cool. Well, it seems like so far it's a happy match up. It’s good to hear.
Matsumura: So far, so good.
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?
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. Any thoughts about that?
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 you just indicated was that, in the case of SOA, the focus in terms of failure might be more on the technology-based pieces associated with building an application. Do you see SOA being different in terms of what actually is responsible for failures?
Matsumura: I'm delighted to have you take that approach, because I’ve actually cast this net out into this group as a very neutral test to see what kind of like fish will come out of it. I used a very generic term, "moving parts," but I didn’t specify. Your inclination was to think that I was talking about technology.
Garone: Well, people do so …
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.
So, thank you very much for heading in that direction. Any one else have anything about "moving parts"?
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 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.
Matsumura: I want to plead guilty as charged. I don’t want to monopolize, but I do want to say that I just recorded an SOA governance podcast on my own, the theme of which was, “Reorganizing the Billion Dollar Software Project.”
Kobielus: I didn’t mean to imply that you were the kingpin of failure, and, in fact, I figured that people who are having trouble in the field look more toward the governance value in order to help solve their problems. I thought I was giving you a soft ball not a hard ball.
Matsumura: No, I appreciate that. Anyhow, I’ll cool my heels and let the others speak.
Gardner: No, you’re the guest. That’s fine. But some of our other discussions on this weekly podcast in the SOA domain come back to the notion of systems integrators (SIs) and even management consultancies getting the lion's share of business in the near term with these things, because it is about culture, people, and process. And the user companies need to shift a lot of what they are doing in order to exploit the benefits of some of the technology and standardization.
I wonder if you agree with that. Do you think that for the next two to five years vendors like yourselves are being dragged along, or do you have another relationship with the SIs that have to get in there and monkey around a little bit with the culture to get companies to transform?
Matsumura: Being dragged along might be a tall order. The reason I say that is that we’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.
Gardner: Joe McKendrick, what do you think? Is this a control issue right now? Or is there some jockeying going on among the internal constituencies in an enterprise, some of the vendor’s constituencies, and also the SIs? And who’s going to win?
McKendrick: There is a lot of jockeying going on, and Steve has pointed this out in a previous podcast as well. 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.
Gardner: Maybe we should define failure. I was thinking of it as an instance where these new practices and methodologies were tried, but people didn’t think they were working. There weren't cohesive approaches. There wasn’t standardization in the organization.
And, so they went back to business as usual, which would have been some of the older application-development ownership and deployment practices, silo-types of affairs. So, in other words, a reversal from a movement toward holistic services, used broadly, to "I’ve got my set of apps. I'm going to maintain control over them. And, if you have any kind of changes or requirements that you wanted to address, you can get in line" mentality.
Matsumura: This strikes to me as a way of defining retreat as a "strategic advance to the rear." There are definitely potentials for failure. Since failure is an orphan, even though success has 10,000 fathers, I can’t allude to a project I know that experienced a failure condition.
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.
The whole thing we alluded to early about this integrator setting up a base camp inside a company ... we’ve had customers who deliberately, pre-webMethods, used Infravio as a wedge and basically said, “We don’t want a single vendor to come in with a product and a set of services, because we don’t want them to control everything. We want an independent to mix things up."
There is a very significant danger of the inmates running the asylum or the integrators taking over the whole account from the inside.
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?
Gardner: So, we can agree that something that would be opposed to failure would be less lock-in, and that could be lock-in from a vendor, lock-in from an integrator, or even internal lock-in, where there is a very strong division within IT or some other organization that’s holding the rest of the enterprise hostage.
Is SOA a democratization type of an effect, or is it really giving command-and-control through policies that you could think of as a governor or an accelerator -- a brake-pedal/dashboard type of an affair -- where suddenly those in the organization that may not have had power before gain it? Is the failure when the control doesn’t go to the right people?
Matsumura: Yes. That hits the nail on the head. I was giving the keynote of the governance track at The Open Group SOA Conference in San Diego [on Jan. 31], and one of the questions that came from the audience was about metadata. Who controls the metadata?
This question is basically The SOA Question, because the people who control the policy metadata are the people who are running the show. The thing that we’re trying to establish here is that the SOA success model is essentially a model where there are federated controls and delegated controls. The reason why this term "federation of control" is so significant is because we’re trying to achieve a balance between the central function, the IT function, and the distributed function, or the business function.
People talk about the agility and control. If you want to balance these things, you need a mechanism that enables some amount of control by the people who are on the periphery, in the business units, trying to create agility. Then, [there comes] some amounts of control by the people in the center, who are trying to create more orthodox standardization and security and orthogonal cross-cutting concerns.
Having the wrong people controlling the wrong things is exactly the pattern that causes things to go a little nuts. The old-school model -- having one single point of control for everything -- has actually proven to be undesirable. While it is not prone to failure, it’s not prone to success either.
Gardner: I suppose when we’ve seen enterprises that are in a suffering mode, when IT and the business are not aligned or not syncing up, well, that can often be due to a cultural clash. For example, if it’s a distributed company and they try to have a distributed approach to IT, that can break down.
If they’re a centralized company, but IT is decentralized among departments that are doing their own applications -- then that could break down. But what’s probably more productive is, as you say, a hybrid approach where certain functions, let’s say procurement, should be centralized. If you can take advantage of a volume approach to your procurement, if you can go to your vendors and suppliers with a larger bid, you can get a better deal. So there are lots of reasons why procurement should be centralized.
But there are other examples, perhaps around knowledge management or around innovation and collaboration, that should be very ad-hoc, very decentralized. How can you manage both of those types of cultures across the company, and then instantiate that through how the IT department behaves and reacts? Anybody have a sense or reaction of that?
Kobielus: A SOA and a SOA initiative are a success if it gives you the ability to adapt the SOA governance structure to your actual business governance structure.
As you’re saying, your business governance structure will evolve over time. All business models change. So the extent to which your SOA initiative and your SOA governance are totally centralized and totally rigid -- but your business environment and the challenges and threats and so forth are constantly changing -- then your SOA failure will ultimately become a business failure, a failure to adapt.
Garone: I’ll concur with what you just said, but also add more in the way I look at it: I don’t necessarily see a contradiction between some levels of centralized control and being able to achieve business agility. The argument for business agility really is about making sure that you make changes quickly to dynamic market conditions and relationships, and so on.
While too much centralization may make that a little bit more difficult than it would be if everything were ad-hoc, I don’t think it makes it impossible. Of course, the world is about balance. The world is about finding that midpoint, where control and governance is centralized enough to keep things safe and secure, and to be able to take advantage of business opportunities -- where consolidation makes sense -- while at the same time staying agile. That’s really the challenge, the way I see it.
Gardner: I guess we need some standard methodologies or best practices around how to approach the whole organization culturally. That brings us into a discussion around ITIL or around what The Open Group has been doing [in terms of certifying SOA architects and the move to the "Town Planner" model of enterprise architrect roles].
Miko, let’s go back to you, do you have a sense of whether there is a legitimate standardization approach that is welling up in the marketplace?
Matsumura: I’ve just been speaking with the head of The Open Group, SOA Governance Working Group and absolutely there are efforts in this area, under the banner of TOGAF, ITIL, and other types of processes. It’s still reasonably early in the game, and what people need to understand and establish are the basic patterns and best practices. A lot of the efforts that create these extremely ornate methodologies are intended to be recipe-book and all-encompassing or one-size-fits-all approaches. I think it’s early in the game to take those approaches.
What I would do is take a look to see if there’s any precedent for a model for policy-managed systems that balance the need of a central entity and the needs of distributed entities, against the desires of the whole. If you look at it from a metaphorical perspective, for example, the federal government of the United States is a very interesting model. You have essentially a bunch of business units called states, that each have their own legislation, their own competency centers called state legislatures, and even their own executives called governors.
Those look a lot like business units to me. If you look at the notion of federation and the federal government model, what you see is this whole principle of jurisdiction. Ultimately, competency centers become the legislative bodies within these organizations. All of the efforts that I’ve seen to codify methodologies around SOA tend to focus on these competency centers or centers of excellence, primarily because there needs to be an inclusive organization for adjudication and jurisdiction, as opposed to having a model, where it’s just a single iron-clad dictator that controls all policy.
If you want to go that way, let’s just go and live in the mainframe and forget about SOA. Not that this would necessarily be a problem, we just have to do it deliberately and well.
Gardner: This is great. 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.
Matsumura: Just to extend that metaphor to the initial theme about failed SOA ... . You can actually look at the failure modes of failed states. If you look, for example, at how you establish and foment democracy, there are some models, some really good, real-world cases about how not to establish democracy. Not to get too overly abstract, but there are a lot of practices and principles around establishing policy federation. The interest in doing so is the interest in establishing a controlled paradigm that actually serves the common good in a way that enables agility, but also enables this centralized capability of control.
Gardner: Right. If your company is behaving like Zimbabwe, you need to do something different.
Matsumura: Exactly.
Kobielus: We talk about political governance in terms of the world community. There is no one right governance model within a state or among the various states of the world. But clearly, history has been marked by individual states or groups of states playing and towing with, if you can use the word, various governance models ranging from absolute dictatorships and empires down to sort of laissez-faire, no centralized government.
But governance is an abstract concept, and you don’t necessarily want to dictate one governance model that’s applicable or should be applicable to all organizations and industries. Everybody has their own pressures, market pressures and so forth. In terms of SOA governance, there are radically centralized models in a given organization. It could be a radically centralized governance model within a given industry sector in the sense that basically one monopoly company controls an entire sector of the economy and they then dictate all the SOA policies and practices for all of their tributaries, as it were.
In the world, you have 230-something countries that are sovereign states ostensibly, and they establish various bilateral treaty relationships and also participate in various multi-lateral treaty organizations like the United Nations and NATO and so forth. Any given country is probably, involved in various international governance schemes as it were -- but also internally, from generation to generation, from revolution to revolution it’s going from centralized to decentralized. One size doesn’t fit all generations of governance.
Gardner: So, maybe we should take a lesson from the United States in Iraq, where you need to look at what you’re getting into. You might not want to just take a company and inject a pure democracy or a federated approach. In fact, each company has its own history, its own culture.
You might want to do the equivalent of a Myers-Briggs test and figure our what kind of company it actually is. Then, figure out in what way to approach governance, so that we don’t try to overstep what’s possible on a linear basis. I suppose it’s also evolutionary. Some companies might need to start out as strict dictatorships, and then perhaps the government withers away and it becomes a democracy. We’ve seen the example of Eastern Europe over the last 20 years. Any thoughts on politics and geopolitics as a lesson for SOA?
Garone: I think it’s a great metaphor. I’m thinking about the model that I think makes sense in that regard, although it’s kind of obvious, which is basically, the U.S. Constitution and the federation of states. You’ve got certain things that are up to each state, and certain things that are up to the federated entity sitting on top of all of it.
Gardner: If I could just pause you. The first step, the Articles of Confederation, which gave too much power to the states, didn’t work.
Garone: Right. So, now you’ve got a dynamic situation where some of that can change and over time. Plus you can also “amend your constitution” to make changes as appropriate. But, there was not always a set of things that are controlled by the centralized entity, the federal government, in the metaphor. But there’s also a certain set of things that those individual states need to comply with in making their own rules.
Matsumura: I just want to jump in here and talk about the U.S. Constitution, which has some key design patterns in it. If you actually look at the separation of power declared in the preamble, it says that the purpose is, "... in order to form a more perfect union." So, there’s this notion of the intent of the formation of this governing entity, which is the goal of a more perfect union, which essentially means that there’s a distribution of power and that the consent of the governed essentially be the overriding principle.
The idea that comes out of that, though, is the clause "provide for the common defense." That’s really talking about the security domain, whether it’s physical security or technical policies associated with the current data. The idea is that it actually should be a federated concern. In other words, security is everybody’s business. You can’t just delegate it to one unit and say, "It’s your business."
The earlier comment about how there’s no one-size-fits-all is absolutely the case. For example, I just spoke with a bank that's highly decentralized. I also spoke with one of our customers, Johnson & Johnson, which has 200 operating companies, and is fairly decentralized. Their central IT exerts a pretty strong coordinating function. So, we’re talking about the big picture, which is, how do extremely large entities organize themselves and how do they achieve success in that organization?
Garone: It comes down to what an organization wants -- centralized or decentralized IT functions. Getting back to the whole notion of the Founding Fathers of the United States, they were not of a single mind among themselves on the proper governance structure. You have Alexander Hamilton, who wanted highly centralized. Then you have Thomas Jefferson, the fellow who wrote the Declaration Of Independence, who wanted it quite decentralized.
And they yanked back and forth until various things happened, and that got more centralized. Then, you had some of those, like in the southern states, who felt it needed to be highly decentralized, and fought a war to try to enforce that kind of order. It’s one of these things that just keeps rocking back and forth, from one generation to another, in terms of the right approach.
Kobielus: Look what’s happening in Venezuela now with this guy Hugo Chavez. He’s totally centralizing everything, establishing a new dictatorship there. Not all of his country people are happy with that. I saw in The New York Times that a lot of them are applying for asylum in places like Spain and elsewhere. This is highly political, but on the IT front, it’s the same thing. Quite often, SOA is justified on a project-by-project basis. "Oh, yeah. We’ll do this project according to the principles of SOA," without necessarily implying that they’re trying to impose SOA practices across all projects and across all systems.
Gardner: Now the corporation as an organizational definition has been around for couple of hundred years. You look back to early mercantile activities, to some of the Dutch companies that had started in 17th century, for example. The modern company is certainly at least a hundred years old.
If we look at some of the large conglomerates, there’s a history of progression around corporations as entities in a more modern sense. Perhaps what's different now, though, is that companies are of, for, and by -- if I could borrow another political statement -- technology. Technology so permeates how a company operates, particularly if you’re Internet-facing and if you’re using and exploiting the Internet for more and more of your supply chain, your distribution, your transportation, for the way in which you attract sales and customers, and so on and so forth.
So technology now is at an intersection with the corporation as an organization, and perhaps that’s what’s forcing this need for a different look at how to organize in general, and, therefore, on how to govern.
Matsumura: I wanted to respond a little bit, too. One of the themes that emerges from our conversation here is that we’re talking about SOA as more or less of a post-modern infrastructure. What I mean by that is that some of the themes that emerge in post-modernism, post-structuralism is the notion of the breakdown of the dominant narrative, which is that there isn’t a universal "thing." The resistance to the one-provider IT stack model, the suite model, is the notion that there isn’t a single system that can rule them all, over all others, and that heterogeneity, components-wise, is the law of the day. Think about that particular heterogeneity in terms of how it functions from a policy perspective.
We talk about federations and policy context, but there’s a degenerate case, where essentially what you’ve done is you’ve created a federation of two. This means that two business units come up with an agreement, or two companies come up with an agreement, which is referred to as a contract. The reason I’m alluding to this degenerate case is that a contract is treated as a completely different class of legal structure within our governmental system, and is protected by the civil law system. When disputed parties get into contention, it’s basically a civil issue.
When someone breaks a policy held by the government at-large then it is either a federal or state issue. From the perspective of creating an appropriate taxonomy, it’s important to consider that these two cases are actually pretty different. Perhaps an attempt to establish initially a sweeping universal regime of centralized federated policy may actually be subsumed by these kinds of groupings of pairs of twos or threes -- or United Nations or NATOS -- or just the kind of loosely coupled and smaller policy domains that are built on top of individual agreements between provider and consumer pairs.
Gardner: I guess we’re somewhat fortunate that there are only about 200 countries in the world, but there are thousands and thousands of companies. So, there’s a lot more opportunity for experimentation in the marketplace and for competitive forces to play out dominance. We can see some success stories, as well as failures, and we can learn from those successes on how to best organize a highly technologically advanced corporation.
McKendrick: We talk about the post-modern corporation. Where are these companies going to get their IT? Where are they going to get their technology? We’re seeing more and more instances of companies going outside, not wanting to get involved with the bits and bytes of managing a technology infrastructure.
We call it "software as a service," "managed hosting," and various types of acronyms and terminology. But I’ll bring Nick Carr into the argument here. Nick Carr said IT doesn’t matter. It’s going to be ubiquitous, available like a utility. Any company can tap into it, whether it’s internal or external, to the point where it’s not that big of a concern.
Matsumura: I can’t resist shooting at this. It’s going to require you to follow along with the metaphor that we’ve drawn. If you can’t suspend your disbelief in the metaphor, it will be hard for you. The metaphor of nations and the competition between nations has typically been along the lines of warfare in our history.
Look at the metaphor of business at war, which is essentially competition for the survival of the integrity of your company against all others. It’s not on the battlefield, but it’s for customer value, for creating services that people treasure. In the history of warfare between governments and nations, what we found is that the organizations that leverage technology to their advantage are the ones that come out ahead.
Abdicating the responsibilities of the management of technology to a commoditized provider creates an extreme vulnerability because your competitive differentiation should not be held or embodied by some generic provider. I think even Nick Carr has backpedaled from his hard-line IT commodity position.
Gardner: I’ve noticed that Nick has backpedaled a little bit, but again we’re back to where it’s not necessarily all-or-nothing. There are going to be some aspects of technology that are commoditized, that should be accessed centrally, and there are many others -- perhaps this will change over time -- that are differentiators. Control over how your organization behaves and controls your assets and resources strikes me as something that you would never want to commoditize.
Kobielus: Think of this notion of where companies in the most post-modern age are going to get their governance structures from. I think a lot of the governance risk and compliance management vendors -- it’s a new market space; companies like SAP and OpenPages and MEGA International and BWise, and others, are building up platforms that have both verticalized and horizontalized governance templates, rules and workflows, and so forth. Increasingly companies or enterprises will standardize on a dominant governance risk and compliance management vendor for their organizations, and then use whatever templates they choose. And their SIs will modify them to suit their own needs going forward.
Bringing this back to the whole notion of where nations get their governance charters. I just read a book, a really good one, called "Declarations of Independence," and it shows that the first actual declaration of independence ever created to found a nation was our Declaration of Independence in 1776. You wouldn’t believe how many other countries have actually plagiarized or borrowed language and whole concepts from it, including Vietnam. The declaration of independence for Vietnam in 1945 directly quotes from our Declaration of Independence, which I found highly ironic.
Garone: I’m going to bring back outsourcing into this discussion as well. Post World War II, the nations that have relied on the Unites States for its defense have thrived economically, because they have not had to spend so many dollars on their own defense -- Germany being the prime example. They’re under our umbrella, and their defense budgets are much lower than ours, and these nations have thrived and moved forward.
Gardner: Well, without getting too deep into what is or isn’t the right approach in world affairs, clearly we’ve defined here that a successful SOA is a lot about politics, power, and moving beyond traditional norms of organization. How you do that probably is going to involve failures. If the Unites States is a good model, it had to fail a couple of times. It failed with the Articles of Confederation. It failed in dealing with slavery up until the Civil War, and perhaps for a hundred years afterward in terms of how it was dealt with in practice, if not in law.
So the idea that we started this discussion with -- where are the SOA failures -- perhaps we should look to failures as a necessary set of learning activities, in that SOA is not going to just happen and spring up like a fungus or a mushroom after a spring rain, but it’s going to have to be something that’s hard-earned.
Matsumura: Well, the way I want to respond to is that having maturity in the way that you deal with failure is essential. If you look at the way that our policy system functions within the United States, what you have is you have a set of policy assertions about what it is people can and can’t do. But then you actually have a policy enforcement mechanism that’s heterogeneous and distributed. You have the FBI, the CIA, the state and local law enforcement, the Army and the National Guard.
You have all these different policy enforcement points everywhere, manifesting these policies. What is extremely important to understand is that there’s an entire judicial system whose function it is to take those policy enforcement actions, monitor their efficacy, and enable the whole system to readjust and adapt.
So, I think that it’s not just an accident of, "Let’s just run out there randomly, screw up badly, and then sit there and try to recover and learn." I think that having a learning engine that monitors, adapts, and revises policies, and having a competency center, an adjudication point that’s deliberately there for the purpose of making those adaptations -- that is an essential function.
Gardner: Or checks and balances ... . If you’ve got failure, that could be a very good learning experience, where you need a check and balance in place, and so the progression toward the value and benefit of SOA can be accomplished. It will be a different path for each company, but they’re going to have to have checks and balances to keep the progression going forward, rather than reverting back to the past, and in a sense giving up.
Well, this has been a very stimulating and interesting discussion, I’m glad that you all could join us. It took on a little different characterization than I was expecting, but a necessary vantage point on SOA in order to make it successful.
We’ve been joined here with our usual panel, Steve Garone, Joe McKendrick, Jim Kobielus and our guest, Miko Matsumura, vice president of SOA products at webMethods. This is your host and moderator, Dana Gardner. You've been listening to BriefingsDirect SOA Insights Edition, Volume 11. Thanks for listening and come back next week. Thank you, gentlemen.
If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 11. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Subscribe to:
Posts (Atom)
