Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Jan. 5, 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 Dana Gardner at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Volume 7, 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 Developer magazine columnist.
Our panel this week -- and that’s the week of Jan. 1, 2007 -- consists of Steve Garone, a former IDC group VP, founder of the AlignIT Group, and an independent industry analyst. Welcome, Steve.
Steve Garone: Hi, Dana, and happy New Year.
Gardner: Thanks. Also joining us again, Joe McKendrick, research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Welcome back, Joe.
Joe McKendrick: Thanks, Dana, I’m glad to be back, and happy New Year as well.
Gardner: Also, Tony Baer, making a second appearance on this show, principal at onStrategies. Thanks for joining, Tony.
Tony Baer: Happy New Year, Dana.
Dana Gardner: Thank you, and making his SOA Insights debut, Jim Kobielus, he’s a principal analyst at Current Analysis. Hi, Jim.
Jim Kobielus: Hi, Dana.
Gardner: Also, welcome to our listeners. Our topics for today span the SOA spectrum of business and technology. We’re going to be discussing metrics of success, ROI, TCO, how do I know I’m doing? I guess we could call this the Ed Koch approach to SOA: "How am I doing?" Yet we can’t really judge how well SOA is doing, if we don’t have metrics.
We’re also going to work on the impact of SOA on outsourcing: outsourcing of IT, outsourcing of business process. Is this an accelerant? Is this a detractor? What’s the impact? We’re going to explore that. Also, the impact of SOA on services -- software as a service (SaaS) in particular; business applications coming across the wire.
So first off, let’s go back to the metrics topic. Someone out there, and I believe it was you, Tony, mentioned that at one point recently Verizon had come out and said that with a stable of 500 services that they were expecting to yield $20 million in savings over two years. Can you tell us where that information came from and how credible you think it is?
Baer: Good question. I actually spoke with the person who went by the title Executive Director of Strategic Systems at Verizon. Essentially, he reported to the CIO and he was in charge of their SOA program.
He gave a presentation on "SOA In Action." "In action" being two words there. I want to be very careful about that. He gave some metrics. I spoke with him about six or eight months ago, so if there is current data, I’m sure it’s different. But this has been going at Verizon for roughly a couple of years. He spoke of creating in excess of over 500, what he called "unique," services.
Now, I’m always a little skeptical when I hear the term "services," because what does that really mean? The definition can be very loose. It could be we have some functionality here and we’re somehow exposing it, or exposing it using standards, using official Web services standards.
Anyway, his point was that these 500 services, which were developed or reused by a community of over 7,000 developers, now account for -- when I say "now," this is as of six or eight months ago -- over 8.5 million transactions per day. He claims that within a couple of years it has saved the company $20 million. I would presume this is in development time, as opposed to having to create each of these things and reinvent the wheel, which is the traditional way of going about it.
My eyes tend to glaze over at such large numbers without having any greater detail, but the fact is, it’s always been a central tenet of reuse that if you can utilize something and not have to create it from scratch, you theoretically should save money and time. So, my sense is that I think the numbers are probably a bit high and a little loose, but I think they point to the potential that SOA can provide in delivering real savings.
Gardner: I wonder if the figures are high, especially on the number of services. I’ve talked to several companies that seem to think that even a smaller number of services could handle just about all of their back-office and front-office needs, perhaps not in vertical usage or industry usage. Then, for a company like Verizon, with the kind of IT budget they have, $20 million might actually not be that much.
Let’s go to Steve Garone. You’ve talked to a number of companies, and you were looking at ROI and business metrics, do these numbers make sense to you?
Garone: The numbers really aren’t out of the ordinary, but I think one of the challenges that organizations face in doing SOA and then trying to determine their ROI -- for want of a better way to put it -- isn't unique to SOA. It’s really a function of various other types of IT-related activities as well. How do you actually quantify what your ROI is, given the advantages of using an SOA approach? I’ve listed the main reasons why people would want to do SOA, in terms of the advantages, and they basically break down to four major areas.
First is what we just mentioned, which is the reuse of IT assets. That's fairly easy to quantify. As I’ve talked to customers and people who have implemented SOA, I find that this is one that they’re comfortable with and are fairly aggressive about putting numbers to, in terms of what they’ve actually saved. It’s not an easy task, because what actually gets saved when you reuse an asset? You certainly save them some development time and development cost. Do you also save maintenance cost, and how do you quantify that? Is it easier to upgrade assets, and to what extent is that dependent on the infrastructure you have in place?
A lot of factors go into it, so I see various levels of rigor. You see people claiming that they were able to reduce the expense associated with doing the application integration test they normally would have to do. That one is a real tough one, because just understanding what you would have had to do and breaking that down into, not only some specific cost, but also the relationship of the result to being able to do business better, faster with more customers and so on, is a real tough task to accomplish.
The other ones have to do with meeting compliance requirements, which we all know are growing by leaps and bounds every day.
Gardner: Regulatory compliances?
Garone: Yeah, and there’s an area where, again, I think the quantification of benefit might be a little bit easier because the requirements are fairly well identified. In fact, they are very well identified.
The fourth one, which I think is the hardest one, is the issue of how agile do you make your business. It’s a buzzword we hear all the time around SOA. That’s a real tough one because you have to ask such questions as: "If I didn’t do this, how many customers that I'm doing business with now, will I not be doing business with, and what affects that? How do I know what my reach was before versus now? How do I quantify how easy it was for a customer to get to me, and if they do, how comfortable they were given what I presented to them, doing business versus leaving because things were taking too long?"
Gardner: So, most of these are soft measurements, and they would take place over a long period of time, because it’s a journey, and you can’t just say, "Well, we went one quarter. What's our payback?"
Garone: That’s right.
Gardner: Now, let’s go over to Joe McKendrick. These are soft paybacks, and it also seems as if we’re comparing apples to oranges. If we look at mainframe, client-server, Web, and then SOA, which is such a different beast, you can’t really compare. It’s almost a leap of faith. Where do you see the right business metrics coming and getting people onboard in terms of dollars and cents here, Joe?
McKendrick: Well one thing I’ve said a lot on my blog is that the companies that are most likely implementing, or are implementing, SOA are probably the companies that don't really need SOA as much. The companies that really could use SOA in their operations are likely not to be the ones implementing, it’s kind of a paradox.
The reason that is the companies that have the management vision, the support to roll out and move an SOA project forward -- providing top management support, for example -- are likely to have lot of other initiatives on the table. They’re likely to be very forward-looking with their management. Their compensation structure, for example, is likely to be a bit more advanced. They’re likely to have other implementations -- a data warehouse, for example -- a very advanced data warehouse. Essentially what you have in these companies is an orchestra making a lot of beautiful music and SOA may be the horn section, but how do you measure the impact of SOA versus another type of implementation or another type of project?
Gardner: Okay. So the song, the piece of art that you’re creating with this orchestra rises up the charts, and if they're a hit, is it because of the woodwind. Is it because of percussion? Is it because of the conductor? We really don't know. We just know that it’s a hit. Right?
McKendrick: Exactly. There are a lot of case studies out there now. A couple of prominent ones are IBM and HP, who had cases of eating their own dog food. They’ve been able show some terrific significant impact from SOA or service deployment. IBM claims it’s reduced its application portfolio by 75%.
They have one quarter of the applications running their business versus back in 1998 when they really first started looking at this. HP claims it's seeing a payback of about $70 million as result of its SOA efforts. These are companies that tend to be forward thinking. They know that they’re being closely watched, and that their own operations are being closely watched.
In both cases, the benefit is coming from consolidation. They’re using SOA as a lever to help consolidate data centers, various far-flung parts of their enterprises. SOA is just part of that consolidation picture. There’s also virtualization going on, server consolidation. IBM, of course, is big with the mainframe, and they’re consolidating a lot of their operations on Linux running on the mainframe. It’s very much a mixed picture, and as I said, Dana, it’s a matter of being able to separate what’s making this beautiful music.
Gardner: I’ve spoken to HP and IBM as well, and they’re really undergoing IT transformation, probably business transformation, and there are many constituent parts to that, of which SOA is one. But SOA is one that has, I suppose, a lot of interdependencies and effects across many of these other activities, whether it’s server consolidation, application modernization, IT shared services, virtualization and what have you.
Let’s go over to Jim. Jim, if SOA is important, almost like a root system that cuts across a number of different trees that are growing, is it even worthwhile measuring it, or should people just be smart enough to recognize that this is the right thing to do?
Kobielus: That’s an interesting metaphor there -- SOA as a root system. My visual image of SOA is a very complex hyper-mesh. In other words, like a root system, where you have tendrils going hither and yon, the tendrils being simply interactions among services and client.
It’s very worthwhile to measure the ROI of SOA as a paradigm or an approach for enabling and for maximizing the sharing and reuse and interoperability of distributed resources across your network. You make an investment as an organization, as an enterprise, and in this approach you want to know whether you’re investing your funds and your resources wisely. When I think of SOA’s ROI, I think of two numbers, and those numbers are 100 and zero.
As we know, SOA focuses on how you maximize the sharing and reuse of services, of application functionality and resources. In other words, how do you enable a 100 percent reuse as a nirvana? We’ll never get there, but in any given organization, 100 percent reuse, service reuse, first and foremost is a consolidation topic. What that means is, if you do SOA right, you’re doing much more with much less.
You’re able to consolidate redundant silos of application functionality and data throughout the organization. You’re able to consolidate fewer software licenses and servers, with the associated translation and cost savings and capital on operating budgets, fewer redundant software components and so forth. The need for fewer programming groups, as we can consolidate that as well.
So 100 percent reuse is the nirvana. The zero comes in the sense that, if you’re doing SOA right, the marginal cost of billing the next application drops pretty close to zero. You’re able to reuse everything that’s already been built. You do not have to reinvent the wheel. So, basically, a 100 percent reuse means zero marginal cost of building the next application. Of course, as I said, you enable that vision through consolidation, both in software and hardware, and in programming teams, and so forth.
So, once again, getting back to your root-system-and-tree metaphor, SOA becomes this ubiquitous root system from which new sprigs can pop up, without needing to lay down their own root system. Rather they are simply branches on a huge underground system. In Northern Michigan, where I’m from, scientists have discovered the world’s largest organism as a mushroom or a fungus of some sort that spans 30, 40, or 50 square miles. They determined though DNA analysis that it's the exact same individual and has got the largest biomass in the world. In essence -- and it’s all underground pretty much. That’s what SOA is all about, essentially all the services in an SOA sort of share a common DNA.
Gardner: Well, there’s the message we need to take to the CEOs and the CFOs. Let’s make our IT like a fungus.
Kobielus: I think they probably already believe that!
Gardner: Let’s take this now to the outsourcing side. You mentioned between zero and a 100 percent in terms of reuse. That would be reuse for your internal resources, but what about reuse of external services? Things that are made available in a marketplace, because of the effects of economics and supply and demand in competition, could push the prices down while even enhancing the quality of services.
For those commoditized services that everyone uses, that really don’t differentiate anyway, why not go in that direction? What’s the relationship here, Steve Garone, between capturing ROI and lowering total cost of ownership, and starting to look toward outsourcing an SOA as being somehow a tag team?
Garone: Well, actually I think there is a fairly close relationship. Again, it’s not unusual that the drivers are really the same as they are in the case of other types of IT investments. Outsourcing can potentially drive costs down, increase quality, allow you to lighten up your IT staff, and so on. So, the same rules apply here. If you look at what’s going on, there are actually several companies now that are doing this. And, it’s not just commodity services. Look at companies like Salesforce.com, for example, which is essentially creating a services-based hosting environment, not only for their applications, but for applications and services that you actually produce in house.
Gardner: Incidentally, we should expect from Amazon.com similar activity around a retail and e-commerce sector.
Garone: I wouldn’t be surprised. So, the drivers are the same, and I think it’s going to happen. I think that if you’re talking about outsourcing services from the hosting standpoint, that’s certainly real and it’s certainly happening now. If you’re talking about outsourcing services from the development and IT support standpoint, meaning how do I go about building my SOA environment, there’s going to be a stage initially where there’s going to be a lot of that, for the same reasons people outsourced that kind of work before.
People look toward SOA and Web services to simplify their application integration environment. That may, in fact, be the case, but in the short term, people still really need to know how to do it and need, in some cases, to outsource for the expertise to get that done.
Gardner: It seems to me that in the not-too-distant future being able to access commodity-level services that you can incorporate into your SOA activities, off the wire, in a competitive environment, would be a really big economic benefit, to reduce your total costs. Maybe not grow your top line right away, but certainly cut your overall cost, which has been an important element of IT for certainly the last five years.
Let’s take this another step sideways. What about IT outsourcing? We had this phenomena a few years ago. Some of the largest entities on Wall Street -- and I’m thinking of JPMorgan Chase -- went to large companies like IBM and said, "Here, you take it. We don’t want to do IT anymore."
Then maybe a few years, even some months, later decided, "Well, maybe that’s not the right approach." If we can get into a marketplace of services, if we created an SOA, doesn't that really obviate the need for IT outsourcing? Don't you want to retain the competency of business process and composite application authoring, regardless of where those sources come from? Isn’t SOA and the outsourcing of services a better model than wholesale IT outsourcing? I’ll throw that to you, Tony.
Baer: I was just thinking back to what Steve was saying, and it kind of applies to this answer as well. If there is one benefit that SOA delivers, it’s that the value becomes the service rather than the plumbing. If you think about the way we've traditionally developed functionality or integrated systems, we’ve had to spend inordinate amounts of time in the plumbing and maintaining it. SOA theoretically, if it’s done right, standardizes the plumbing, makes everything declarative, so you take out the guess work. The result is that if you look at outsourcing, SOA separates the plumbing from the service. Therefore, what is probably ideal for outsourcing would be the plumbing, because that’s where the value is and that’s not where IT organizations should be spinning their wheels.
Gardner: So where is the value?
Baer: The value is in the -- and this will sound a little cliché-ish -- intellectual property, which is represented by the actual service. That’s the service that delivers the actual business logic. It’s the way a company does business. The way a company does business is not the way it puts together its SOA plumbing. That should be standard. That’s obviously an ideal scenario, but look at how this could impact the outsourcing market. If you follow SOA principles and comply with SOA standards, it allows for that kind of separation, and therefore it makes for an ideal opportunity for outsourcing services to say, "Hey, we’ll take care of your plumbing, and you take care of your services."
Gardner: So, you’re saying perhaps that I should look to commoditize services and find the cheapest best way to acquire them, either on premises, co-located, outsourced entirely, software as a service (SaaS). Then, for those differentiating services that I’m applying intellectual property and perhaps even patents to, then I could even host those somewhere off premises, and it’s bringing that together within my organization that makes me a winner in my market?
Baer: That’s one way of putting it, but another way is, "I create the service, and by the way I rely on you to create and maintain the plumbing." There are many different ways of slicing and dicing this.
Garone: To some extent it depends on what kind of vendor you’re dealing with. I’ll go back to the example I gave earlier of Salesforce.com, which will do some of both. They create a services-based infrastructure that you can use to not only host your IP-unique applications in services, but also to host the ones that they’re providing to you, and if you do it right, you can easily integrate with.
Gardner: Right.
Kobielus: On the issue of outsourcing, the only thing that the company should never consider outsourcing in terms of core competencies is the core competency of making money and delivering value. Everything else is fair game, and I think what everybody is saying here is that they agree with that. SOA -- or much of what we think of as SOA -- revolves round the plumbing, the protocols, the application servers, the middleware fabric, etc., that all is fair game for outsourcing.
Gardner: I like the terms that were used a moment ago. It can be "sliced and diced in a number of different ways." That’s the good news, but it’s also the bad news, because no one really has a model they can fall back on and say, "Ah, here’s the proper way to do this, when we apply outsourcing and software as a service to the SOA mix." Or have I got this wrong? Jim, can you think of any past instances in the history of IT we can look at to get some idea of the best way to slice and dice these many variables?
Kobielus: Going back to my sense of knowledge of IT history, I’m going to have to sleep on that one, Dana.
Gardner: Can anyone else out there think of any precedents that we can look to in terms of what’s the right balance of on-premises, commoditized, software as a service, SOA? It gets kind of messy.
McKendrick: I don’t know if there really is a precedent. This is all open for innovation, Dana. There are a couple of interesting examples, actually, if you look at the telecom industry. I like to use the term "loosely coupled business." SOA is based on loosely coupled components or services. A lot of telecoms actually don’t use their own internal resources to provide services to their external customers. They act as a broker.
Gardner: It shows sometimes.
McKendrick: Unfortunately, yes. I’ve heard a statistic that at Cisco, the networking giant, and 80 percent of its products and services come through outside services that it essentially brokers. I think that’s kind of the model SOA is helping us move toward -- this idea of a loosely coupled business that can pull together services from perhaps throughout the globe, package them, and offer them to an end user or customer that they identify as important to their market.
Gardner: So, maybe the metaphor has moved from a 30-square-mile fungus to a 30-square-mile amoeba.
Koblieus: Amoeba is a good metaphor here, because business models must continue or will always continue to evolve; therefore IT must continue to evolve to the next business model, the next IT sourcing model, whatever helps them to survive and make money.
Gardner: We came up against this when we talked to Jeff Pendleton. We thought about architecture and we looked at some of the architects, and we came to Frank Gehry, and we said, "Wow, the outside looks different and almost illogical, but inside, the stuff holding it together is very logically designed."
Then we moved from that to this notion of a sound stage. You would build a sound stage, or even a movie set, depending on whatever scene you were shooting. And, we wanted to have IT act like a flexible sound stage or a movie set. We would just build the set based on whatever the activity was, do what we needed to do, and then perhaps tear it down or reuse parts of it. So, we seem to be coming back to that, although we’re talking about not just our own services as an enterprise on premises, but increasingly a mixture of software as a service and outsourcing.
Anybody want to pick at that or expand on it?
Gardner: Well, we're in complete agreement, that’s great.
Garone: I’m not quite sure I understood it, to be honest with you.
Gardner: Do you remember that call we had about the sound stage show; I think you were on that call?
McKendrick: It’s an interesting analogy.
Gardner: MGM right?
Baer: Right. That actually is about the old movie studio metaphor, one studio and many different productions going on at the same time. Basically, the piece parts were all interchangeable, and piece parts we can call plumbing.
Gardner: So, we’re making five different movies on the lot, and we’re going to bring cameras and lighting equipment and backdrops and makeup artists, and just apply them in the same way, but with a different end outcome. Right?
Baer: I guess you can say the metaphor coming out of this discussion has evolved from fungus to amoeba to let’s bring back the studio system into IT.
Kobielus: Right, if you look at what SOA governance involves, if you examine a given service throughout its life cycle, it begins in the planning stage, it’s a gleam in some business person’s eye, and then it goes to the system engineers, the designers the business people. There’s a governance life cycle on those projects as well. That governance role structure in the movie industry has changed since the very start and it continues to evolve.
The notion of the classic studio system for Hollywood was there between the '20s and the '50s, and then it gradually gave way to more independent producers. Now, you’ve got all these indies everywhere. What I’m getting at is that, the governance of any given movie production project, how it’s done, the best practice for that particular industry, continues to evolve from generation to generation.
Likewise in the IT world. If you look at the life cycle of governance of the creation of any application or functionality, of the whole software is on the life cycle, that paradigm continues to evolve from generation to generation, with new platforms, new tools, and so forth. So, its one of those things where now you’ve got to look at the structure of the SOA governance environment.
You've got roles that are specific to the plan, specific to the development stage, roles that are specific to the deployment and optimization stages and so on. What I’m getting at, then, is that I think the movie studio analogy is very interesting, because it focuses on the core of governance as a workflow over a life cycle involving various roles, and those roles continue to munge into each other and get broken off from each other.
Garone: Dana, just jumping in here, now that I had a chance to think a little bit about your analogy, and just to follow up on that last thought. In essence, the movie studios as we know them now, don’t have the role that we used to know them as having. They used to actually make movies. My understanding is that the customer who is the independent producer, or maybe a larger producer who may bring on another independent producer under them, basically is outsourcing the physical plant requirements to make a movie to the studio.
Gardner: So it becomes an ecology rather than all-in-one.
Garone: Exactly. It’s an ecosystem.
Gardner: Is it the right direction, Steve? David Lean made "Dr. Zhivago" for probably $20 or $30 million. Now, it costs $200 million to make a pirate movie. Can we follow movies as the logical business example? It seems like they’re making less of a movie for more money?
Garone: I know I’m going off on a tangent here in terms of analogies, but the movie industry has almost gone the same way as Major League Baseball. You’ve got stars that get $10, $20, $30 millions a picture. Does it really matter all that much that there’s an independent producer outsourcing the physical plant requirements to a major studio? I don’t know the industry that well, but my gut feeling is that both parties feel that that’s the most efficient way to do it.
Baer: Actually, can I jump in there, because I’ve heard -- beyond the specifics -- of an entertainment industry where values have gotten hopelessly inflated. But look at the mechanism behind this. Before, you had monolithic studios, which had their own life cycles, their own software development life cycles.
Gardner: Exclusive stars that they’d sign up for years at a time.
Garone: Right, it was the Major League Baseball model.
Baer: Exactly, and it’s sort of analogous to the monolithic software marketing, except for the fact that all the piece parts underneath were more interchangeable.
I guess you can argue that if you are an SAP, your piece parts inside the infrastructure were designed to be a self-contained interchangeable ecosystem. But look at the way it has evolved now. Part of it is that the technology for producing films and videos has become much more accessible, and therefore you have now an independent film industry. So, that's analogous to the infrastructure that has become much cheaper, much more open, which is what SOA can do.
In turn, you look at the business model. It's become more interchangeable, so that a studio might collaborate. Let’s say that Universal might work with Sony -- collaborate on a picture -- because it’s so costly that neither one of them could do it themselves. Well, they have the infrastructure and the business process in place that enables that to happen. Meanwhile, an independent film like "Crash" comes out of nowhere last year and wins the Academy Award for best picture of the year, and it’s all possible because you now have this more accessible infrastructure. The moral of the story for SOA here, trying to bring this back on topic -- is that if you get the plumbing down right -- you don’t have to be an SAP to introduce a killer app anymore.
Kobielus: I’m going to take this movie industry metaphor out of the realm of metaphor into the actuality of, teams becoming very SOA-focused in terms of the actual production ... A mashup is reusing existing components of service -- content, -- whatever into new vehicles or new compositions. If you look at the content that’s being developed out there in the IT world, more of it's getting built through various types of mashups, which is very much an instantiation of the SOA paradigm into a different world -- not the software world so much as the normal cultural world that we all inhabit.
Gardner: It's interesting, because when we talk about movie production, it’s really content creation. It’s artistic. It’s creative, complex, and changeable. It has to fit a certain audience at a certain point in time. A movie that was made 30 years ago might not work today and vice versa. What’s also interesting here, looking through this lens of the movie industry, is that depending on the culture of the organization, it can adjust.
So, if you’re a big monolithic enterprise, you're like a command and control structure, you want to do it all your way. You’ve always done this. You’re sort of a traditional brick-and-mortar company. Then, you can perhaps approach IT like an MGM studio, and you can have your own infrastructure, all of your own developers. You can do things without much off-the-shelf or highly customized -- but you come out with a really great product if you’re willing to put that emphasis in. And, if you have such a great product that you dominate your industry, then the numbers will make sense. The investment you made in IT will pay off.
On the other hand, if you want to be a small company, a green-field software-as-a-service organization, you want to only be in an ecology play where you’re acquiring things, and you’re going to plug them in and then rip them out, reuse as much as you can. Then, you can be like a Miramax instead of an MGM. You’re going to do just independent films. You’re going to go in and spend a little bit of money, and maybe you’ll still come up with some great product that will be right fit for your market. The nice thing is, as we said earlier, you can slice and dice it either way.
Does this make sense -- that the culture of the company needs to be considered when we look at the way in which it approaches IT?
Kobielus: For sure. Some companies are not very partner friendly. Therefore, they’re not really the kinds of corporate cultures that lend themselves to outsourcing. First and foremost is managing the relationships. There are other companies that are very partner friendly, it's really quite often a culture issue.
Gardner: Right. I think we’re going to need to cut off our discussion there, but obviously we can take this further and I’m sure we will, but perhaps one of the takeaways that we’ve led to is that companies need to be introspective. They need to look at what kind of organization they are, what kind of organization they want to be, and get a sense of which IT approaches, particularly vis-à-vis SOA and software-as-a-service and outsourcing, make sense for them.
McKendrick: The question is: does management -- does the C level -- understand what SOA is about.
Gardner: I’m not sure we’ve even seen a lot of instances where companies would say, "Let’s take a look at our culture and define it, and then decide our IT approach as a result of that."
Garone: That’s true. They’re going to have to do that. Many of them have not, because they started out looking at SOA from an individual or a pilot project perspective. When it expands beyond there, that will change. It will have to.
Baer: Well, they look at SOA as a technology as opposed to a way of delivering their business services.
Garone: When the technology has been mastered, and has demonstrated its value, it will have to become more than that, and then you’ll see the cultural issues playing a bigger role. A lot of the IT managers and people that I've talked to who are involved in the implementations of SOA solutions, even on a pilot level, seem to understand the cultural issues. They’ve encountered them, and they’ve tried to deal with them. But you’re right. On the C level that hasn’t yet happened.
McKendrick: That goes back to the whole ROI argument we were having a bit earlier as well. The ROI is being seen in developer productivity, for example. If you want to generate hard numbers from an SOA project, developer productivity is the first place you look -- the ability to reuse applications or services without having to have the developers spend X-amount of hours reinventing the wheel.
Gardner: We need to have the equivalent of a Myers-Briggs test, where you actually can ask a series of questions, or do some research, and can define the temperament and the personality traits of a company. From there, you can back up and say, "Well, here’s what your IT should be."
You need to get into the DNA of how a company thinks and behaves organically in order to make the right fit with IT, because the companies that fail are companies where there IT culture and their business culture are at odds or don’t mesh. And they collapse. They can’t function.
Baer: No question about that, and the fact is that, Dana, what you were just saying could apply to almost any type of transformation, but I think this sounds very specific to SOA here. We’ve been providing a whole bunch of metaphors, dealing with other industries like entertainment business or the ability to partner, but if you think about the implications of SOA, it not only should erode barriers between you and your partners. It makes it technologically possible to erode the silos within your organization by going inside and looking at how many instances of the customer object we have? Do we really need 45 instances, when maybe five would do for a business of our breadth and diversity?
Gardner: Okay. Let’s leave it there and we’ll revisit this, but I think metaphors are essential in this period of SOA evolution, because there are so many variables, and because you can slice it and dice it in so many ways. If we can help companies look at ways in which they can reduce the number of variable, and help them get started and find some traction and therefore benefits. That’s an important thing to do.
Joining us in this discussion about the impact of outsourcing, software-as-a-service and how to measure success has been, Steve Garone, the former IDC group VP, founder of the AlignIT group and an independent analyst. Thanks for joining, Steve.
Garone: It’s been a pleasure, Dana.
Gardner: Joe McKendrick, research consultant, columnist at Database Trends, and blogger at ZDNet and ebizQ. Thanks, Joe.
McKendrick: Thanks, Dana, for the opportunity to join you guys.
Gardner: Tony Baer, principal at OnStrategies. Thanks, Tony.
Baer: Thanks, Dana, good way to kick off the New Year.
Gardner: Jim Kobielus, principal analyst at Current Analysis. Thanks for coming, and join us again sometimes, Jim.
Kobielus: Thanks, I’ll look forward to it.
Gardner: This is Dana Gardner, your producer, host and moderator here at BriefingsDirect SOA Insights Edition. Come and join us again next week. Thanks.
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 me, Dana Gardner at 603-528-2435.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 7. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment