Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded
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 22, 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. Our panel this week, and this is the week of
Joe McKendrick: Hi, Dana, glad to be here.
Tony Baer: Hey, Dana.
Neil Ward-Dutton: It's great to be here, Dana. Thanks for having me.
Todd Biske: Good morning, Dana.
Dave Linthicum: Glad to be here, Dana.
Brad Shimmin: Good morning, Dana.
Let's start with the larger topic of the day. What's been coming up in some of the blogs and in some analyst reports is this notion of people overusing the term SOA categorically, and the suggestion that we should go back to the roots and get pure again about SOA. Some are saying that this other business around it being application types, application support, runtimes, and actual products and platforms needs to be muted a little bit.
At the same time, we’re also seeing discussions crop up around such things as platform as a service, particularly around the Salesforce.com ecology and approach, and also integration as a service. I recently did a sponsored podcast with Cape Clear Software on this topic. Then, of course, there's the the long-term discussion around software as a service (SaaS), and the ability to use Web services and a variety of application interfaces and APIs to avail yourself of hosted online applications and services.
So, let’s take this out to the group. Are we confusing topics here? There's this notion of things off the wire, outside of the domain of the enterprise. Should that remain separate and distinct, as a discussion point and as a direction for enterprises, from SOA, which is more of an architectural initiative and philosophy within the confines of their enterprise IT systems.
Let's go to Todd Biske first, because, Todd, you're an enterprise architect and you’re working with clients in the field. How do you come down on this? Is SOA inclusive of all of these "x as a service" or "blank as a service" or are they actually part and parcel of the same direction?
Biske: I really think it should be inclusive of all these external platforms. SOA, in my opinion, is really something that’s driven out of enterprise architecture. To go back to the simplest view, it's about the services. If you are able to get services from outside your firewall, those should be included as part of your SOA. You absolutely need to include the availability of external solutions as contributors to your overall SOA for your enterprise. I know Dave has talked about this a lot as well.
There's a lot of debate as to whether SOA is the whole kitchen sink. There's a Yahoo! mailing group, and they’ve had the same debate going on just recently on not just the technical aspects, but whether SOA should encompass all of the culture change that people are saying is so critical to success with SOA. Are we just muddying the term by trying to lump all of this in together?
If we look at it from what it takes to be successful, if you leave those pieces out and focus strictly on the technologies associated with it, you’re not going to get success. At that point we’re not achieving the goals we set out to do. So, it needs to include all of these concepts and have that factored into your overall enterprise approach.
Linthicum: I agree with Todd. It's inclusive. In fact, look at my career in starting up Grand Central and Bridgewerx and all those companies, where it was all about creating SOA outside the enterprise and delivering it as a service. It's what Salesforce.com is doing with their Apex platform today, what they call Salesforce SOA.
So, it's an architecture, and ultimately lines are blurring between where the enterprise stops and the Internet starts. With mashups, outside-in services, all the stuff Google and Microsoft are working on, and all the services that are being consumed within the enterprise, it definitely is inclusive and it has to be considered in the context of the architecture, enterprise architecture, and architectural patterns like SOA.
Gardner: Tony Baer, do you think that this is begging too much of a typical enterprise IT department to both be managing transition and transformation to SOA internally, and, at the same time, start to work with these off-the-wire elements -- be it platform, integration, or services and applications?
Baer: I’m going to take this to another level, which is the business level. If you look at the way business has evolved, or supply chains have evolved, over the past 20 or 25 years, they're really evolving into an ecosystem that is very partner dependent. When you buy a product that is manufactured by a company or that’s branded by a specific company, chances are it is manufactured by somebody else.
So, SOA and enterprise architecture really need to echo or support the direction in which business is going. More and more enterprises are becoming virtual. As a result, if you're running your internal processes, the chances are you’re going to be interacting pretty intimately with one of your business partner’s external processes.
Baer: It's not just outsourcing. You’re working in coalitions. For example, look at how a car is put together today. There have always been suppliers, but suppliers are now taking higher-level roles. They're actually co-designing. When one of the automakers or OEMs designs a car, chances are they’re designing it with their partners. In the old days, they designed the car and then sent out parts orders to partners.
So, SOA in IT and enterprise architecture really needs to support the way the business is going. Business is becoming more virtual. It includes external processes and partners, and SOA must support that.
Baer: Well, it's cyclical. I remember back around 1990, there was a grand announcement by Kodak, "Well, we’re outsourcing IT, because, guess what, IT is not part of our business." I’m not even going to fast-forward this 20 years. I’m going to fast forward it three years. Kodak realized, "You know something? IT is part of our business." They had to take large parts of those 10-year contracts with IBM and, at that time, Digital and, I believe, EDS, and after about three years those contracts essentially collapsed in. They dropped a number of provisions. Today, Kodak is saying, "We’re a digital business."
It's a cyclical thing. If you outsource without managing it, if you just throw something over the wall, you’re going to get what you paid for.
Ward-Dutton: I thought Tony made some really interesting points there. Certainly, one of the arguments that you could make for a long time about enterprise architecture was that it was locked into a way of thinking that was very last century. It was locked into this evolutionary level of thinking that started around the kind of information-engineering movement that happened in the 1970s and 1980s. It assumed that you were building everything yourself, in long-running waterfall projects, and things didn’t really touch other things. Everything was built in isolation.
That was a big problem for enterprise architecture, because, as Tony pointed out, businesses have been pursuing this kind of virtualization agenda for a long time. Think about EDI and value-added networks (VANs), all that kind of stuff. All of that was designed outside the purview of IT and was done by business teams. The enterprise designers or the architects had no real input into that whatsoever. They were focused on the stuff they build internally for the organization. It's long overdue that architecture practice starts to take a more holistic view of an ecosystem of technology provision.
This thinking is long overdue. SOA, shouldn’t be constrained, as Todd just said, by a particular hosting model, where service is provided from, or indeed a technical choice. It's all about the services and it's all about the architecture, but that shouldn’t be constrained by where that service happens to be delivered or who it happens to be delivered by. You can pursue SOA in an environment where the resources are widely distributed, where responsibility is federated. Indeed, more and more, that’s how people are going have to do it. This is all natural, and as Tony said, really, really needed.
Shimmin: Well, yes to both. IT really has been isolated, and I think we can all look at the cataclysmic failure of the idea of the waterfall method of development, as a pointer to that. You really can’t work in a vacuum, just toss code over the wall, and hope that it runs somewhere. As we were saying with the failures in early investments and outsourcing, I think those were all built in that regard.
Nowadays, when you start to look at what SOA has done to the industry and how it has impacted IT, it has become an enabling notion that allows companies to employ methodologies like the agile development method, that are more kind in how they view the lifecycle of software and where software runs. It's a partnership with the business and perhaps with outsourced parties that might be hosting that software.
SOA, as a collection of standards, technologies, and ideas -- which is how I look at it -- is already playing a very active role in allowing that pendulum to swing back towards platform-as-a-service, integration-as-a-service, SaaS, infrastructure-as-a-service. It's actually enabling those.
If you look at the vendors that we cover all the time you will see that everybody from VAN vendors like GXS, Otics, and
Microsoft is doing the same with their BizTalk Services and with their dynamic CRM, which is tied with BizTalk Services. I think we’re seeing everybody really jumping on this bandwagon.
The best example is one we've already alluded to, Salesforce.com. When I look at them, I see a hosted service that utilizes SOA ideas to facilitate a secured, reliable, manageable, business-savvy domestic environment between your backend systems and their backend systems, which just happen to be on somebody else’s servers.
McKendrick: ISB is something that Microsoft has out there. They calls it BizTalk Services, and it’s now in the community technology preview phase, where they’re offering the functionality of their BizTalk -- essentially their ESB -- on an online basis to companies that don’t necessarily want to invest the time, capital, money, or staff to build their own ESB or SOA.
McKendrick: That’s exactly what they’re hoping to accomplish. You see it happening across the breadth of their product line, with the whole Microsoft Live. You can see them moving to this notion of SaaS, platform-as-a-service. I think they see the handwriting on the wall.
One thing I always say is that Microsoft doesn’t make a move unless it sees a mass market available to pursue. The fact that they’re pursuing the ISB shows that they see it's reaching critical mass in the market. Their natural base is the small- to medium-sized business. It’s not the large corporations that IBM, Oracle, and Sun serve.
McKendrick: Exactly. One model that makes it easy for the business to understand SOA could be an internal SaaS that units of the company are making available to the rest of the enterprise.
What happens is you have this software and it’s something the business can understand. There is a division, maybe at the CIO’s office and maybe somewhere else in the enterprise, that’s deploying these service-oriented applications. The services are available for reuse across the enterprise, across the walls of the enterprise. The enterprise has the option of either picking up these services internally or picking up services externally from another partner. The enterprise becomes both a provider and a consumer of services. It’s two-way outsourcing.
Does anyone else have a reaction to this related area about IT departments shifting in their business models and how that relates to SOA? Todd Biske.
Biske: One of the things that I heard as we went through this conversation, and you hit on it with ITIL and becoming a service provider, is the notion of service management. When we’re looking at why there’s been an outsourcing trend and a backlash against it, a key factor is the degree of service management that’s provided.
It’s one thing to need this capability and go off and find it somewhere, but once you start using that, you realize that there’s this whole degree of transparency that’s needed to understand how that service is being used, where the results are coming from.
In the initial stages of outsourcing there was a lot of people saying, "We want to be a black box and we don’t want to expose any of our dirty laundry, because then our customers may go away." Information needs to be provided to give good service management, as well as to help the customers of those services understand how it’s being used and where they can make incremental improvements on it. It creates a feedback loop.
We can look at virtually anything, whether it’s blogging or podcasting. Before we all got on the call. we were talking about the metrics of how many people are listening to the podcast. By looking at that information we can make things better. We can target audiences or understand exactly who the audience is.
The same thing applies now in the service management domain. I need to have visibility into how the consumers are using the service, where they’re getting good experience, where they’re not, are there trends, and how it’s used. If I’m not getting that information, whether it’s from an internal service provider or from an external service provider, that’s going to start to have an impact over time.
That’s where it leads into culture change -- adopting things like ITIL and understanding service management and what it means to be a service provider. IT is used to building solutions. They put it out there and they go on to the next project. That’s not service management; that’s project management.
It raises the question of whether the complexity starts spinning out of control, but we could combine a couple of these observations today. We’ve talked about governance in terms of comparing it to a government, whether you do a democracy, federalized, local, or state. But, if we consider ITIL Service Bureau, we recognize that one of the best governance mechanisms for the most complex things -- business and the economy in general -- is capitalism, competition, or even more crassly, Darwinism.
Suppose we open up services and allow them to compete for the users and/or the lines of business managers to be able to choose among an external service, an internal service, a shared service, a supply chain service within an ecology. Does anyone think that a capitalistic or Darwinistic approach, if this follows its course, will allow for the best form of governance, which is, "Let the best service at the lowest cost win?"
Ward-Dutton: I say yes and no to that. Competition, or the threat of competition, is sometimes a very, very valuable thing to produce the mix. However, you've got to remember that if you’re talking about free market, one of the side effects of a free market is that an awful lot of companies go bust, and that’s fine. If you’re at the top, looking down, you’re just looking at the performance of a market or an economy overall. It’s fine if companies go bust. If it’s your company, though, that’s not so good.
If you’re looking at IT provisioning in this context, you've got to be careful. You've got to put some regulations in place. You don’t want your own internal IT provider spending a heap of money on stuff that isn’t going to be used, not going out of business, but essentially causing business problems, because they’re wasting a lot of money.
So, you’ve got to have layers of governance, i.e, rules and frameworks about how planning gets done, how priorities are set, what’s important, and what’s not. Those kind of things have to be decided, so that a company knows collectively where it wants to go, what it’s trying to do, and what that means for IT. When you’ve got that in place, then in constrained places you can start to drive competition by saying, "In these places, we want to look for competitive solutions, but it’s not always going to be the right thing to do."
Shimmin: Well, as much as I love socialism I have to say that I’m on the capitalism side of this. I just want to throw out a caveat that if we’re talking about IT departments becoming providers of services, we need to make a distinction between internal provision and external provision, because not every company is a Google that’s going to throw out a Google Maps widget or WSDL, and suddenly everyone is going to be utilizing it, and everyone is going to be happy.
Companies have a better shot at that, however, than doing this internally, because internally you have a lot of federated environments, as we were just saying, with departments acting as their own companies. The whole notion of charging back for services and being accountable for how much you use those services is something that a lot of companies are certainly not willing or prepared to embrace right now. So, the internal adoption of this notion is a long ways off for a lot of companies.
Externally, there are providers and consumers, and the average enterprise is most likely not a provider of services like that. They’re consumers of services from companies, who, as Neil was just saying, hopefully are going to be around for a while. If I'm going to subscribe to one of those services, as a Web service, I want to know a couple of things.
One, I want to know that the company is going to be around a while, because I have an investment in that service, in setting up the interface for it -- for example -- and testing it out, because you don’t just grab a URL WSDL, throw into your designer, and poof, you have a service running. You have to test it and make sure the data models match, etc. So, I want to make sure that my investment is going to be protected.
The second thing is I want to know that the service level agreement (
Linthicum: Absolutely. The SOA architects ultimately need to figure how these services are consumed and how they have value with their internal systems. I would argue, however, that we are getting more experienced at picking outside-in service providers through the whole SaaS notion. However, they deliver it through a visual interface which is, in essence, a Web site, but it’s becoming much more than that.
Salesforce.com, Amazon, eBay, all those guys, are making tons of money now renting their Web services, and the ability to provide the behavior and the value through Web service is going to be a core component. Businesses are probably more advanced than we think they are in integrating those things into the core systems. It’s at a rudimentary level, but ultimately becomes outside-in services, integration with the SOA, and that’s where the architects come into play.
For those that are listening, perhaps they get the sense that creating SOA internally, identifying and cultivating SOA architects, will allow them to, in the future, avail themselves of services across a wider panoply of sources and business models, and ultimately they can become the beneficiary of these market forces. This capitalistic approach towards lower costs, higher productivity, and less waste becomes another economic impetus to pursue SOA. What's your reaction to that, Tony?
Baer: I don’t think there's question that this really follows how companies are running their own businesses right now. It's just not possible to become agile and be competitive if you try and make every thing yourself. So, it will be inevitable that you will, at some point, consume external Web services.
I want to get back to the governance point from before. With all the regulatory compliance mandates that we have to deal with at this point, we have to worry about who is handling financial data. Who is handling customer data? Who is protecting identities?
There's no question that a free market is going to emerge for services, but, at the same time, it's going to have to be accompanied by some very heavy doses of transparent governance. I may need to know, for example, my partner’s mechanism for federated trust and authentication. The short of it is, I don’t think you can stop continental drift in this case. You are going to have a free market of services, but you're also going to need a very transparent governance to support that.
Baer: You have to conduct your own governance. It’s a federated model. It’s not going to be any sort of United Nations agency that's going to be top-down type. There probably will be industry best practices that will be drawn up by industry bodies, but ultimately the enforcement has to be at the enterprise level. You have to decide what protections you need and what you expect from your partners?
Baer: I thought you were going to go towards something more like the Underwriters' Laboratory model, where we have some sort of external certification agency. Actually, you made a good point where you take a company that's very established and say, "Well, we're going to trust Microsoft, because they're too big to try and risk having a bad reputation."
Baer: I would agree with you. I don’t see any new top-down agencies parachuting in. It’s going to be, "I'm going to deal with trusted partners. I expect Microsoft is going to be around for a while. I expect that, considering the type of business they’re in, that they’re going to conduct themselves with the highest standards of good governance."
Gardner: Did we go right back to where we had been, which is five or six major suppliers, and "I'm going to be a IBM shop -- or a Microsoft shop -- or an SAP shop," but it’s going to have to do with the ecology of services and not just the packaged applications or platforms? Is this just going to evolve into another instance of major vendors controlling this. Does anybody have a reaction?
Shimmin: Well, I think it will be the same ecosystem we see now, where you have different tiers in the marketplace. Depending upon how important that service is to your business and your application, and whether or not you can withstand a change in that service, of that service going away or not, having the service availability or not, having the governance or the ability to control the data as you would like, then you might be able willing to go with somebody that's smaller than Microsoft.
Shimmin: I don’t see why not.
Ward-Dutton: You’re getting towards a cooperative model in that kind of environment.
Ward-Dutton: You are, if you're talking about a community banding together to make its own of autonomous decisions about who's to be trusted and how things are going to happen, without any kind of patronage from a benevolent dictatorship like a Microsoft or whatever.
Ward-Dutton: There is space for all sorts of models. I know the B2B exchange thing in the late '90s was over hyped, but Cognizant is still doing some pretty healthy business in the automotive sector, for example. That's not an open-source model, but it is a kind of industry driven, bottom-up collaborative effort. There are all sort of models, a spectrum of commercial models which can work.
It wouldn’t be open source particularly, but a kind of a non-profit community-driven type of approach could be equally valid. I don’t think it’s likely to be one model winning over any other. There are a whole load of things that are likely to have a role to play.
Shimmin: I feel that the open-source vendors are well positioned to get into this space, because you're buying a service, whether it’s support, installation, custom development, etc. It's a service that you're buying from them. You're not buying software. Companies are becoming much more accustomed to that and comfortable with it. Let’s say you have an open-source Mule version that's hosted within the ESB, Mule ESB hosted, maybe New Source is the company that runs the data center somewhere, and they provide SaaS. There's no reason why they can’t, and it would fit well with their model.
If people have transparency on how services are used and consumed, they should also have transparency to share their experiences with those services. If openness and the ability to create community dialog around whether services are being well provisioned or governed, or if costs and benefits are out of alignment, that this might also provide some grease on the skids of competition and efficiency towards the best solution that the community then adopts or shifts.
Any thoughts about how openness in networking, from a sociological point of view across the network, might keep this in some sort of checks and balances?
Biske: It’s part of any kind of capitalistic approach to this. Customer feedback is just part of the market dynamic, and that certainly can make or break somebody. If you're not factoring that in and incorporating what your customers think in leveraging that information, it’s going to come back to haunt you.
I had another comment on the open-source piece as well. There is still going to be plenty of room for smaller companies, closed-source approaches, in these vertical domains. One of the bloggers that I follow has commented that you don’t see a lot of open-source efforts in niche vertical areas, and we're talking about governance and the impact of regulations.
You don’t see people who, in their spare time, are following the new SEC regulations that are coming out and are trying to offer open advice on how to best meet source regulations.
Those who develop software have always had formal jobs and careers based upon it. It’s also been a hobby for lots of people, and has helped the open-source movement. I don’t know too many people who like to follow regulations as a hobby. So, to have this kind of open-source model to handle governance, the broad horizontal domains will continue to see pushes in that.
In these niche areas, where it requires somebody being paid to understand all of those regulations from the various government agencies, that has to go to a proprietary model. One, it’s just not as interesting, and two, it’s not as big as a marketplace. So, you have to get a level of niche expertise and understand who your customers are going to be.
Moving on to our next subject, it's a little less global or universal in scope. The IBM acquisition announcement about DataMirror. Brad Shimmin, tell us a little bit about how you view this announcement and how this will or will not strengthen IBM’s hand in information management?
Shimmin: If you look at this from purely a master-data-management, or just data-management, perspective, it makes sense. It’s something they should have done, and they already have a good deal of energy being extended toward that. So, yes, "yippee-skipee," but what gets me going about it is just thinking about how IBM, and every other vendor that has its toes wiggling in the SOA pool, is really looking to build complex event-stream processing and event-driven architectures on top of their solutions. This allows companies to stop thinking about their processes.
Just as you build the process, you throw it out there. If it maxes the server out, that's a bad thing and you go from there. You have your process running. It has interdependencies upon these other processes, these other servers, these other resources, etc. Over time, there are a number of events that take place relative to that process. Companies want to be able to look at that stream of events in context and over time and be able to make decisions. They also want to have automated actions taken upon those. Something like DataMirror gives IBM the opportunity to do that.
Shimmin: It’s a necessity. Everyone has come to understand that you need to understand the data in the transaction as well. Most of the vendors that we cover in the space either do that or have woken up and smelled the coffee, and are making a lot of efforts in that direction.
McKendrick: Well, that's a tough one to call, Dana, because they are not actively in the data-management space per se. They don’t have the robust data architecture products that IBM, Oracle, Microsoft have. Sybase as well.
I could see HP emphasizing its service aspect in this regard, really getting into this with its service’s space. Sun is a tough call. It’s sometimes tough to keep track of what Sun is trying and trying not to do.
Baer: Well, actually I was doing a study at, of all places, a Telco software company. What struck me was that as part of their SOA strategy they also embraced a very heavily federated data model. If you think about it, it’s the perfect compliment to a SOA strategy, because SOA is built on the idea of a loose coupling of all your processes. If you're really going to realize the promise of that, and you have a lot of different data sources, which is the case in most large organizations today, a federated data strategy, which essentially abstracts the data from its source, is the perfect compliment to realizing the promise of SOA.
I'm not surprised to see that the software business is doing very well, and especially companies that are very heavily involved with managing data in some ways are performing. It's not a big surprise.
Baer: No question. Think about the one key piece that DataMirror brings in there, which is the whole changed-data capture. I can imagine a lot of business scenarios, where that itself could be packaged as a very high in-demand service.
For example, if you're doing any type of market watch or real-time supply-chain tracking, you don't care about all the routine data, when there's no change in the stock or when things are moving on schedule in the supply chain. You want to know when exceptions happen or when things change. I can see this DataMirror capability being packaged into a service that’s not just changed-data capture, but event notification. It fits perfectly in that picture.
Ward-Dutton: How long have I got? 30 seconds?
Ward-Dutton: The role of data is very, very complicated and gives people a lot of headaches. Certainly, this seems to be like a wave-particle duality thing between service and data. If you pursue SOA too simplistically, you just say, "Listen, what's important in the way I design things and architect my environment are services and that's all that matters. That's the primary organizing concept." Then, what happens when you get to data is a whole heap of trouble.
Equally, if you take a very data centric perspective, it can cause problems, when you think about services. When you just think about a service that you're going to reuse in multiple contexts, you have to think quite carefully about implications for the way that data is stored. Clearly, consistently mapping data architecture and SOA architecture is a challenging thing.
What's clear from the adopters I've spoken to, is that you can’t ignore information architecture when you're pursuing an SOA initiative. It’s vital to understand the implications for data architecture and capabilities like federation, changed-data capture, and synchronization of data across boundaries. So, there is a very strong play here.
I wouldn’t go as far as to say that IBM, HP, and Sun are at a disadvantage. I think it was Brad just said, I am not sure, so many people on this call. It’s a cast of stellar participants. Someone was just saying that these guys have never been data-management players, and there are so many things to say about Sun's software strategy, I'm not going to get into it now. HP has managed to survive and is now thriving, but focusing in a completely different area of software delivery. They are much more about management process, quality, and so on, and they are very agnostic in terms of the middleware layer and data layer, and that works very well for them. So, I don’t see why there should be a bigger problem.
I want to thank our participants. It's been another interesting discussion. Joining us today have been, Joe McKendrick, Tony Baer, Neil Ward-Dutton, Todd Biske, Dave Linthicum and Brad Shimmin. Thank you all for joining.
This is Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to Volume 22 of BriefingsDirect, SOA Insights Edition. Thanks and come back again.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 22. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
No comments:
Post a Comment