Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Oct. 13, 2006.
Listen to the podcast here.
Dana Gardner: Hi, this is Dana Gardner. I'm principal analyst at Interarbor Solutions, and you are listening to latest BriefingsDirect SOA Insights Edition. This is a weekly discussion and dissection of Services Oriented Architecture (SOA)-related news and events. We bring to this subject a panel of independent industry analysts and guests. Joining us this week, we have Steve Garone. Welcome to the show, Steve.
Steve Garone: Great to be here, Dana.
Gardner: Steve is an independent analyst, a former program vice president at IDC (responsible for software), and he is also founder of The AlignIT Group.
Also joining us today is Jon Collins, principal analyst at Macehiter Ward-Dutton. Jon comes with a number of years of experience with other research firms including Bloor and IDC, and has worked as a consultant, network manager, and software engineer for such companies at Admiral Management, Alcatel, Philips and Sun Microsystems. Welcome to the show, Jon.
Jon Collins: Hi, everyone, and good morning to you.
Gardner: Yes, we should mention that you’re joining us from the U.K. today. Well, the subject this week -- and we’re talking about the week of October 9, 2006 -- includes some interesting developments in SOA. Among them is the rising specter of SOA and virtualization. I don’t know about you guys, but I got an invite from Sun Microsystems to an announcement that apparently has quite a bit to do with virtualization and SOA. As we know, Sun has quite an offering in greater utility computing.
If you want to expand the definition of virtualization, they are able to create instances of operating systems as well as instances of Java virtual machines, I believe, and support of other operating systems through their Janus Project. And they're running applications in a closed individual environment that's secure and can exploit the power of the hardware, and threading in multicore, as well as to provide a high-performance series of instances of an operating system environment or an application environment. That is, I suppose, virtualization on the level of operating system and perhaps middleware as well.
So, let me go around our small table of three analysts here today and get your take on the role of virtualization in SOA. Are they distinct, do they crossover, and what do you expect you hear from Sun? Let’s start with you, Steve.
Garone: Thanks, Dana. This is a particularly interesting area, and one of the reasons is because many organizations are being confronted with these two new “paradigms” -- granted an overused word -- and they require adoption of two new ways of doing things pretty much at the same time. They are related in a lot of ways, and complementary in a lot of ways.
When you look at SOA, you look at high-level advantages in terms of greater business agility and flexibility, lowering costs, being able to interact and interoperate with others more easily through integration at a high-level of abstraction, and so on. Operationally, with SOA you have to deal with issues around deployment, provisioning, monitoring the environment, scaling -- sometimes virtually in real time -- meeting the requirements of service level agreements and so on.
When you think about it in terms of the operational aspects, the two paradigms really do share drivers in terms of lower costs and greater efficiency. You see, in fact, a lot of complementary relationships between the two. If you think about being able to flexibly deploy operating systems and virtualized environments on top of platforms and monitoring them and being able to manage them efficiently, that is really sort of a management and infrastructure underpinning for effectively doing SOA. You’re going to have to deploy services and understand where they are, and understand how to use them, within the context of a virtualized environment. To me they sort of go hand-in-hand. So it’s no surprise that both end-users and vendors, in response to end-users, are taking a great interest in the overlap between these two areas.
Gardner: It sounds like a very efficient way to deploy services instead of having a monolithic approach of full stack infrastructure. You can put underneath that service just the amount of infrastructure that's required by virtualizing it; and therefore creating a data center or an application services environment that uses less electricity, smaller foot prints, and -- as the demand on that service increases -- the provisioning of additional resources beneath it should happen at a fairly automated basis, along with the clustering and other virtualization benefits.
Garone: I agree, and, in fact, one of the potential end-points of this is a scenario in which vendors will create a virtual environment that includes the required operating system functionality needed to make it work and basically be sort of bare-bones and tailored to the specific application type being deployed. VMware (Oct. 12, 2006) actually had a pretty interesting announcement around virtual appliances that addresses just that.
Gardner: So you can approach this from an appliance perspective or virtualized instance of an operating system environment, and either way you’d be basically approaching this from the same value proposition -- just doing it in a different way.
Garone: Right, and again, all of this sort of forms the underpinnings for where you build, deploy, and manage the services that are part of an SOA environment.
Gardner: Okay, Jon, over to you. If you can do virtualization for an operating system and/or a business application, why not do it for services?
Collins: Absolutely. I can only agree with everything that Steve said. I think one of the complications comes when you start thinking in terms of software services rather than in terms of software applications. They have a little different life cycle and a different approach to traditional -- let's call them siloed -- software applications. If you've got virtualization managing the infrastructure and helping you actually serve up the right type of the infrastructure in the right way, the right size and scale, and so on, to run the services, then you’ve got SOA. That’s managing the demand side, if you like, that can consume those resources and allocate what runs where, and how things communicate with each other. There is a definite fit.
Gardner: I suppose what’s less clear at this point is the relationship between SOA governance and the provisioning and resource allocation that will be taking place as part of the virtualization. Are these going to be going off in their own orbits with no relationship? Or will there be an opportunity to bring them together somehow?
Collins: Well there's the rub. But there is also a difficulty, because of the way they traditionally have been done. SOA governance has been the evolution of software development and application development, and people working together to procure and deploy applications. The whole IT operational governance side traditionally has been two very different parts of the organization. So, while it's easy to say, yes, let's do it in a service life cycle approach -- where the service starts in one place and goes from development to operations very smoothly -- we’ve got to get two sides of the organization talking to each other.
Gardner: Now, we mentioned Sun Microsystems having an announcement around this, and that makes great deal of sense, given where they are coming from. But the other big vendor in this space, in my thinking, is IBM. They’ve been talking about the virtualized corporation for sometime, and they take this even further than Sun in terms of conceptualizing the virtualization of data, the virtualization of applications, the virtualization of infrastructure -- and now increasingly the virtualization of services. And if you look at the total picture, what you start to see is a highly increased productivity and agility around how IT is consumed, but also perhaps significantly reducing the operating and maintenance costs for these services. How do you understand the IBM virtualized corporation?
Garone: If you just a step back for a moment, you talked about two vendors, Sun and IBM. You’d expect Sun to be playing to some extent in this sandbox that brings together virtualization and SOA because they are obviously an important SOA player, at least in terms of their support for technologies that are going to be used to build SOA-type implementations. But there are all sorts of system vendors, and all system vendors are going to have to deal with this some time or another. And, of course, they are also storage vendors. You didn’t mention storage in your list although that could be considered that part of the infrastructure.
Gardner: Yeah, that would be certainly virtualized as well.
Garone: Yes, and so you’d expect Sun to be there. IBM, if you ask me, based on what I’ve seen from them, as it has done with SOA, is probably going to be sort of a champion in this area. I’ve spoken to them, and they pretty much get it. Are their products there yet? Probably not.
IBM is burdened -- as it usually is, when it tries to put these comprehensive strategies together -- with the fact that it's got a lot of legacy products that it should, and it does, want to integrate into this strategy. But its legacy products need to be adapted for it. So, they IBM has a ways to go in terms of giving a comprehensive vision. I think you're going to hear more and more from them in a leadership sense in terms of defining what the space looks like.
Gardner: Jon, who are the vendors to be keeping an eye on in terms of the intersection of virtualization and SOA?
Collins: All of the big players obviously -- meaning IBM, Microsoft, and HP -- who are talking about their virtualization offerings.
Interestingly, if you are taking IBM as an example, virtualization can mean very different things, depending on which part of the organization you're talking to. If you are talking about, for example, virtualization of information access, that’s almost a middleware question of how to access multiple types of structured data.
But, if you're talking about virtualization as infrastructure, then it’s very much about the resource management question. So, any one of the organization may have different virtualizations. And I can credit Steve in this case, it's a question of how you bring those together. One company that’s probably coming up alongside -- it’s trying to get as far up as it can before people stop it -- is EMC.
And, yes, obviously EMC has VMware, so they have done a great deal in virtualization on the server side, but equally with their nLayer acquisition, and other management-type acquisitions, they're putting in place a lot of the pieces they need to be able to manage the virtualized infrastructure they end up with. I think they're doing that quietly and hoping that no one sees they're trying solve that problem.
Gardner: I'm actually a little bit surprised we haven’t seen even more acquisitions out of EMC moving up toward this SOA deployment capability. Perhaps they are not interested in going into it for design-time, but clearly they seem to be heading in that way for the runtime. Does anybody have any quick, blue-sky thought about who EMC might look at in that regard?
Collins: That’s a good question. Why did I just think of BEA?
Gardner: A BEA-EMC fit?
Collins: That does make EMC a very different company.
Garone: I'm not sure if that’s a likely scenario, but from the functionality and product standpoint, maybe.
Gardner: Yeah, technical fit but not cultural or geographic one -- and I don’t think Wall Street will look at it as a whole greater than the sum of the parts; probably as a whole less than some of the parts.
Garone: Well, for every acquisition that EMC makes, it's constantly having a battle with Wall Street, which wants it to remain a storage company.
Collins: And that’s another reason I think it’s acquiring its portfolio by stealth, buying a company like RSA to say, yes, we need to get into the security space, which is partially true. But then look at what it’s doing with Smarts and the potential incomes between RSA and Smarts from the identity management side and on the event’s profiling and behavioral analysis sides. There’s a lot more to its acquisition than it's letting on.
Gardner: I think Documentum was the first big signal that they are moving aggressively outside of just storage.
Collins: Absolutely.
Garone: There's another nuance to this company relationship issue, getting back to the question you asked earlier about other players. There are some, and I’ll call them pure play, although I am not sure it really applies to all of them. We mentioned one before -- VMware. There’s also Intel, which is doing a lot work in the virtualization area, given the fact that it makes a large number of the processes that are out there. While they are focused on virtualization, in some cases they have a narrow view in terms of platform coverage, but they also are not necessarily expert on things like SOA. So, I think you’ll find a lot by way of partnering between companies like those and some of the large vendors who are providing parts of those solutions.
Collins: I’ll just make one more point on the virtualization and the SOA thing. I’m reminded of when Microsoft stood up and said: "Of course we’ve always been a virtualization company." They tend to say that they've always been a "this" company, they’ve always been a "that" company. The reason they said they’ve always been a virtualization company is, of course, virtual file systems -- caching and paging and swapping all these mechanisms inside the operating system.
I think extreme virtualization ... will succeed ... (and) ... we’ll stop talking about it, and it will become parts of the distributed platform of the future. And it will just be an expectation -- SOA will run and run because it’s a way of doing things. Virtualization should just become part of the standard, if you like.
Gardner: One of the things we haven’t gotten into with virtualization is the impact it has on how a vendor would price. Per-processor, per-seat, per-client access license, perpetual enterprise license? It gets rather murky. And I don't think that the high-margin approach to up-front licensing for software will hold up in the virtualized world. Therefore, some companies might actually be interested in dragging their feet on this trend to preserve some of their fat profit margins.
Collins: It’s a huge problem for Oracle and companies like that who have charged for everything in the past.
Garone: I agree. I think it is a huge problem for them. In fact, there are a couple of problems. One is virtualization, and the other is just how many processors, given the multi-core designs that are coming out today, are you actually deploying on?
Gardner: What’s Intel talking about now? It's 64 cores on a chip, right?
Garone: Yeah. So, it is a big problem. Whether or not they’ll have a choice of dragging their feet is really debatable at this point. I think there are going to be other factors that are going to affect just how fast or slow they go into that area.
Gardner: Let's move on to another subject. We’re certainly going to be revisiting the notion and the concept of the intersection of virtualization and SOA. But there’s been another topic in discussion around SOA recently, and that's about the impact of SOA on ERP, and CRM, and other packaged business applications.
On one side of the fence, we have people saying that SOA is going to be the death-knell, if you will, or certainly diminish the role and impact of packaged applications. We’ve had some large analyst firms come out with reports and some sensational headlines to that effect. And, yet, when I speak to people in the field they say, "No way"; that SAP and Oracle and other packaged application vendors are in for the long haul, and that they’re entrenched.
And, they say that SOA might become a layer above those packaged applications in order to create a data services layer and perhaps a transactional and logic services layer above those. But that doesn’t mean you’ve ripped them out. And, like the mainframe, they'll be there in 20 years. Let’s talk a little bit about the impact of SOA on the packaged business applications field.
Jon, let's go to you first over in the U.K. Should SAP and Oracle be very worried, vis-à-vis SOA?
Collins: I think they’ve been worried for years, but not because they’re worried about the impact of other people coming and stealing their markets. You can only sell these things once, and once you’ve got it in place, you put it under consultancy. The massive number of man-hours that went into implementing things like ERP in enterprise companies then becomes an issue.
What you are going to make money from this year? Yes, of course, we've got the Computer Associate scenario with repeat licensing of old software, but the real revenue streams and increases come from how you get people to do newer and more innovative things with your products. So, I know that probably three, four, or five years ago SAP started to talk about how it’s going to componentize it’s platforms. We’ve seen NetWeaver. We've seen MySAP port. We've seen a whole number of different ways of essentially adding a level of distribution to SAP.
Now, to be honest with you, with your initial preamble, I actually find I can read the line from my notes, which says pretty much exactly the same thing. When I’ve spoken to actual customers of these things, no one is looking to go and replace them. And if they are, that it's not because they are thinking about SOA. What I’ve written here is that at the bottom line, you’ve got a database, you’ve got a rules engine, you’ve got a workflow engine, and it's been crafted and customized for that organization. Why on earth would they want to rip it out and put something else in place? Probably other analysts think about it in terms of market segments and products, and so on. But that’s not the way that we need to think about this.
Gardner: What I think has been happening is that some analysts are confusing a will or a desire to rip them out with an intention.
Garone: That may be part of it, but I'm not even sure there’s a will at this point. First of all, I have a lot of faith in end-users. The more I talk to them, the more I believe that they worked very, very hard to make the right decisions. And in fact, with the AlignIT Group, the company you mentioned earlier, my goal was to be able to help them do the massive amount of work that they need to do to get to a short list of vendors and products they look at as quickly and as inexpensively as possible.
But they do a lot of work. And so, I am confident that, generally speaking, they do make the right decision. It’s not always trendy, and it's not always what the analysts say. And, I think that when you’ve got something that really works for you, there’s a lot of inertia there that says, “Stick with it and see how you can adapt the new paradigms that exist, that will help you do your business better, to what you currently have.”
There is a little bit of that deja vu all over again. We talked earlier about SAP and components. I remember discussions like this back when software components started to appear in the mid 1990s, and even before then, when people were talking objects and CORBA and how we're going to get all this stuff to work. If you go by those kinds of predictions and supposed trends, SAP and PeopleSoft -- well, PeopleSoft isn’t independent now -- but an Oracle and the other enterprise app vendors would have been out of business a long time ago.
The fact is that people will want to stay with their current solutions, especially in the case of the ERP, where that high level of integration that brings a lot of the benefits of ERP, has been established and is working for you. And then, tack on to that the technologies that will allow you to say, “Manage the supply chain better,” "Bring your supply chain in better contact and better integration with the systems that you currently have."
Gardner: All right. Let me just push back a little bit on this. If you look at a lot of large organizations, they're spending somewhere between 60 and 80 percent of their total IT budget just keeping these systems up and running. They're spinning their wheels, not really adding anything new or innovative. That leaves them with a very small section of their budget for discretionary spending, to be innovative, to get out in front with some alternatives and to try to be a competitive in their environments and their markets. If they can somehow get out of this vise of being 60-80 percent in maintenance of a monolithic business packaged applications, back office and front office, wouldn't they want to do that?
Garone: Well, it’s hard to say "no" to that question. The question is, what's the trade-off, what’s the ROI, and to what degree does the business has to be upended and set on its ear to get that accomplished? And if the cost-benefit case can be made, then certainly, they’re going to look seriously at it. My suspicion is that the trade-off is not all that clear cut and, at least for the time being, many enterprise application vendors are going to be able to sort of buy time in convincing their customers that the short term is not the right time to make that move.
Gardner: Okay.
Collins: Absolutely. I think we’ve seen in the past two or three years that infrastructure consolidation projects were very popular. And now, we’re seeing a lot of application rationalization and consolidation projects. People are trying to reduce the number of processor cycles they are using, looking for legacy applications that not many people are using anymore, and seeing how they can merge the data from those into other applications. And, that’s all well and good -- that’s all about, giving them more flexibility in the budgets.
But I admit it doesn’t necessarily mean that they are putting up lots of money for innovation. It might just mean that they’re making the place more efficient, just so that they can cut costs, but that doesn’t mean that they are going to go out of their way to remove the large amount of investment they’ve put into ERP system, or the CRM applications.
Gardner: So, perhaps the way to look at SOA is not what we’ve been hearing a little bit of lately, which is SOA kills ERP. It's not rip and replace. It's not either-or. It's both. From my perspective, SOA’s main value proposition in the short- and medium-term is about risk reduction.
If you can put in some buffer around your legacy systems -- if you can use SOA for more greenfield development, too -- if you can use it for extended enterprise opportunities where you can share services in a close-knit trading or supply chain environments, or a business ecology environment -- then you’re reducing your risk for being backward compatible because your services can continue to be modernized. That is to say, your legacy can be modernized into services and the investments can be exploited. You can reduce your risk in terms of flexibility by being fast to business process development in the current day, and you can reduce your risk in terms of being ready to accept what’s going to be new and interesting, innovative, and productive in the future. What’s wrong with this logic about SOA, as a risk reducer and not a displacer of packaged applications?
Collins: I’ve got the phrase written down here, "augmentation not replacement." I think that you're absolutely right to see everything in terms of reduced risk. I would say that companies are always looking for reduced risks, but they are not necessarily saying that they’ve got high levels of risk, and need to reduce them. But, maybe I would re-phrase it to, “Increase flexibility without increasing risk.” With the idea of replacing something and starting from scratch, there’s an inordinate amount of risk involved, because potentially you go through the same problems you went through last time. Whereas if you create an interface to the tried and tested, you can develop new ways of using that tried-and-tested business logic and tried-and-tested the data management logic without being held back.
Gardner: Okay, Steve, what’s the risk in looking at SOA as risk reduction?
Garone: No, that's a great point. What I was alluding to earlier is that the core enterprise application functionality that organizations have trusted and have used for some time -- and that's well integrated and working for them -- is something that they’re going to want to keep. On the fringes of that, if you will, is the use of SOA-type scenarios and implementations that will allow them to increase their flexibility, keep up-to-date on new technologies, and integrate with those that are outside the realm of that ERP application. And, I think that, in the short term, is what’s going to happen over time. In fact, I think SOA will become the new way to do applications and deploy and manage applications. Then, they will gradually move in that direction, and be either followed by or pushed by the enterprise. Apps vendors are going to move in that direction as well.
Gardner: Okay, we have been looking at ERP versus SOA through the lens of the enterprise. What if you're a software as a service (SaaS) provider? What if you're an ISV who is moving from packaged apps to services? Wouldn’t you want to build that for the way you are going to go to market -- on an SOA -- and therefore it might be a rip-and-replace; if you are providing your services, your business services as a service?
Garone: It’s certainly a desirable option for all the reasons that all of us talk about when we talk about using an SOA-based approach. Again, they’ve got decisions around, being able to make sure that the services to their customers are not interrupted and, once that migration has occurred, that they are as good, if not better, than they were before. But, certainly they can take advantage of all the benefits that end-users can, when moving toward SOA.
Gardner: I think this is the "dark horse" trend here, around the SaaS provider. If they can start delivering solid business services for something along the lines of $20-$40 per user per month, and mid-sized companies can latch onto this -- probably quicker and easier than a large enterprise where they’ve got entrenched monolithic applications and large investments in them -- then, suddenly, a company that has 200 to 2,000 seats of users can start doing business processes far more fleet and productively than a big, lumbering enterprise (that's) locked into some older paradigm of development and applications. Wouldn’t that perhaps provoke a tipping point, whereby there could be a move towards rip-and-replace?
Garone: I think you are pretty much right on. In fact, I think you are making a very important point in terms of the type of end-user organization that will go for that initially, and will start that ball rolling. And, yes, I think when you are talking about a solution provider -- software as a service provider in terms of enterprise applications -- then absolutely pricing is going to be an issue. The business model is going to be an issue, but if they can get that together -- it has been proven in the case of companies like Salesforce.com -- then, yes, they are going to be on to something, and that will, I think, push larger organizations and providers to start thinking in those terms as well.
Gardner: Do you buy into that, Jon? Do you think that SaaS could actually be a catalyst to SOA and create a tipping point that changes of the dynamics of packaged business applications business?
Garone: I think it can, and it should in certain domains. If you look at when Salesforce.com saw its initial success, it was delivering a very generic, what I usually call a CRM application, to the widest possible audience and lowest common denominator. And, it did it very well.
So, despite everyone saying, "ASPs are dead and so on and so forth," Salesforce.com kind of rose like a phoenix from the ashes of the ASP, and it's done very well ever since. I’ve just finished a consultancy with an ISV that is looking directly these issues, and it seems to me that there are companies like that. They're having to balance and manage the risks from two sides. The first is that, for example, they do have a lot of, let’s call it "legacy business logic."
So, let’s say, if you had health care, for example, you’ve already developed some quite complex logic in terms of how you are going to manage in terms of compliance regulations and so on and so forth. We don’t want to just throw that out and start again, because you’ve already put a lot of work into that. At the same time, if you do take an existing system and you try to open it up to much a wider user base, you could be very likely to have issues with scalability. So, you can’t necessarily just take your existing application and say, "There you go -- everyone come in" because you'll all just get jammed in the door.
So, it’s about balancing the risks of both sides. It’s not going to be a tipping point, but it's definitely going to be a route toward the tipping point. And the [accelerant] will come from something -- as typically the tipping point starts from -- that no one expects. At the moment, we're seeing that there's a whole mash-up. Everyone is trying out stuff like that -- everyday things that actually encourage and capitalize on these more old-fashioned applications.
Gardner: So, if we consider that Rich Internet Applications (RIAs) have the front end, allowed for a mashing up, if you will, of services from an entrenched internal enterprise packaged application infrastructure, as well as using SaaS provider services, as well as some greenfield customized SOA services internally -- then you get the best of all worlds, and that probably would be very attractive to a lot of companies.
Collins: To an extent. I think Steve very early on made a good point about, when it comes down to operational management, service management, and service delivery and so on. In India, you’ve got a scenario where you just have all of these things available to you and you can pick and choose -- decide which ones you’re going to need. Then how are businesses going to differentiate themselves?
They’re going to differentiate themselves by being able to make very fast decisions about what’s best for them as a company, or what’s going to best serve their business activities and their customer relationships. And how to do that faster than the competition is largely going to come down to how well they’ll manage their IT and how well they’ll manage that process of change and ongoing adoption.
So, that’s why most companies still have to wait. Most companies still are very slow in terms of adoption and adaption of big technologies. So, that’s where the battleground's going to be.
Gardner: If I read you correctly then, the companies that will do well in terms of their competitive advantage in their fields are not necessarily the ones that master a particular technology, but master the ability of picking and choosing and moving among these technological innovations in a way that benefits them and their particular situation. That reduces their risk but gives them more choice and agility. I am afraid that, of course, these things are much easier said then done. But clearly the intersect between ERP packaged applications, SOA, SaaS and the ability to manage all of them and keep the plates spinning -- this will be an issue of great importance in the next decade. I don’t think we can say too much more with a 90-percent authority, but we’re getting closer.
We're out of time, but we’ve hit on two major subjects today that affect SOA. We’ve discussed the virtualization issue and SOA, as well as this notion of business applications and the effect on that market and industry. Joining us to discuss these have been two noted industry analysts, independent Industry analysts: Steve Garone, a former VP at IDC and a founder of the AlignIT group. Steve, I want you to give us your disclosure at this time. We’ve discussed a lot of companies. Would you just list the ones that you had a business relationship with, so they we're all, on the up-and-up here?
Garone: Great. Yes, currently, based on the ones we talked about, it's IBM and Sun.
Gardner: Superb. And also helping us weed through these issues, has been Jon Collins, of Macehiter Ward-Dutton. He is the principal analyst there. And I wonder if you could do your disclosure exercise as well, please?
Collins: Sure, I’ve been working recently with IBM, and I think I mentioned Mercury. And Microsoft, we’ve done some work with them.
Gardner: All right, and for me on disclosure, I’d been doing work basically through sponsorships of podcasts with HP and, I think that’s perhaps the only one that we’ve mentioned right now.
Thanks for joining us. I would also like to point out to our listeners that if you'd like to learn more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, feel free to contact me, Dana Gardner, at 603-528-2435. This is Dana Gardner, the principal analyst at Interarbor Solutions, and you’ve been listening to Briefings Direct SOA Insights Edition. Come back and listen next week too. Thanks.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 2. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.
Sunday, October 22, 2006
Monday, October 16, 2006
Transcript of Dana Gardner's BriefingsDirect Podcast on Application Development Quality
Edited transcript of BriefingsDirect[TM] podcast with Dana Gardner, recorded Oct. 2, 2006. Podcast sponsor: Borland Software.
Listen to the podcast here.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today a sponsored podcast discussion about IT quality, and the importance of quality as an essential ingredient in any application development activity -- and not necessarily as an afterthought or an after-effect but quality throughout, from inception and requirements, right through production and then to lifecycle. Joining us in this discussion we have a representative from Borland Software, Brad Johnson, who is the director of product marketing. Welcome to the show, Brad.
Brad Johnson: Thanks, Dana.
Gardner: Also joining us is a practitioner of quality in the application development process, Chris Meystrik, the vice president of software engineering at Jewelry Television in Knoxville, Tenn. Welcome to the show, Chris.
Chris Meystrik: Good to be with you Dana and Brad.
Gardner: Okay, we’ve heard a lot over the years about software development, and we’ve seen study after study that shows abysmal rates of on-time performance, of being over-budget, of requirements that don’t seem to make sense once the application gets into production. Obviously, not the best track record, and yet increasingly -- because companies are online with their marketing, they are online with the way they actually produce and deliver services, they are online with the way they acquire their resources through a supply chain -- it seems that application development is more important than ever. What do you think we need to do here, Brad, to make this a high-quality process from start to finish? What's been missing?
Johnson: Well, I think what's been missing is a real focus on quality -- essentially from day one, where organizations are thinking about building out complete requirements that include attributes of performance and functionality from the very beginning; when they start thinking about a project. As they move through the project lifecycle, they need to think about architecture and development. The testing organization, which very often is responsible for verifying quality at the tail end of a project, is actually involved earlier in the cycle. We need projects that essentially capture what the business users want, and also capture quality attributes so that as that development process flows across the whole software delivery lifecycle, quality is considered a priority from the very beginning.
Gardner: So we’re not really just talking about the quality of the code itself. We’re talking about the quality of the process, the people, the organization, and the tools -- everything that lines up before the code. Is that the way to think about it?
Johnson: That’s absolutely important. Thinking about the process, Borland looks at it in four dimensions, from managing the whole process to planning everything; from what the requirements of the project are, through to verification and validation, which as most people understand, is much bigger than just testing. It’s exactly as you stated. It’s looking at the process, it’s putting in gates and checks that include peer reviews, and making changes to the process -- iteratively if necessary. So you’re right, it’s looking at the holistic view of a project as it’s delivered, and quality is essentially built-in, but it’s not independent of testing.
Gardner: I suppose when you had an environment where all of your developers were within a stone’s throw of one another, and there was a single code base to work from, with centralized check in and check out, and you could manage component-by-component activities in a tight-knit group, that would be one issue. It's one problem to inject quality into that process.
But we have a much different environment today, where we’re seeing development teams that are dispersed geographically. We’re seeing much tighter timelines where code is getting checked in and checked out, and there are implications for how that impacts architecture and infrastructure earlier in the process.
We’re also seeing distributed computing environments where we’re going to have a heterogeneous runtime environment, most likely. Now that we’ve involved ourselves with the complexity of these distributed environments, is there a team approach to this? Should we think about it as check-in and checkout from a decentralized geographic standpoint, or do we still need to have a sort of a centralized approach? Is this a monolithic quality process for a distributed development process?
Johnson: A centralized kind of quality control center is a great idea. In practice and reality, I think we're far away from that. But you hit on what's absolutely a significant pressure on organizations today. That is, we’ve actually queried prospects, customers, and partners over the last few months, and distributed development is not just coming, it’s here, and it’s one of the biggest challenges faced by development teams today.
So, what you really need is a centralization point, where everybody is getting the same view of quality throughout the whole process … whether code is being checked in by the teams over which we have very little control -- where they are either outsourced or off-shored. Or they are under our control as far as being part of the organization, but distributed geographically and across time zones. You need to be able to understand, from a development standpoint, what exactly is being checked in, and what type of quality gates have been put in. So that when code gets checked in, we know that it’s free of security risks.
We need to know that there is no open-source code, for example, that’s in there, which is going to cause problems later. Hopefully, we’ve done the right level of J unit or N unit, or even functional automation on that early-stage code, so that at least we know that when code is added to the build, that build is not at risk. So, if we’re looking at that from a worldwide perspective, it's very, very challenging.
Gardner: So a brittle sort of top-town quality approach doesn’t seem to be the right fit for today’s development environment. I suppose we need something that’s got multiple levels, multiple components with an ability to integrate, but also to pass the baton, if you will, from one aspect of development to another. I think we all refer to this sort of multifaceted, flexible, and yet controlled environment for production as Lifecycle Quality Management (LQM). Or am I missing the point of what LQM is about?
Johnson: No, you haven’t missed the point, you’ve nailed it. Lifecycle Quality Management is about exactly that, looking across the software delivery lifecycle, and thinking about quality throughout the whole process. And that includes institutionalizing methods of assuring that requirements are correct, the code is complete, and as many defects have been as minimized as possible. Again, it’s looking across the lifecycle, and not just at one specific place in time, or one specific organization that’s contributing to any of those aspects.
Gardner: All right. That sounds like it makes tremendous sense. Of course these things are easier said than done. Let’s talk to the practitioner here. Chris, tell us a little bit about Jewelry Television and what your role is there as vice president of software engineering?
Meystrik: Jewelry Television is based in Knoxville, Tenn. We are a multi-channel sales vehicle. Our biggest sales channel is our cable television programming. It’s in more than 50 million homes across the United States. We have an ecommerce-based Web sales channel also. The vast majority of our calls come into our call center here in Knoxville, and we offload a good percentage of that to the ecommerce Website, and through interactive voice response systems here at Jewelry Television.
When I came in here, my role was to basically rebuild the enterprise infrastructure, specifically around the business that Jewelry Television is in. They’ve had experiences looking at competitors, some of them they have bought -- others are still out there in the market. They believe we need a customized service-oriented solution to tackle the marketplace, and basically give Jewelry Television a strategic and tactical advantage, to be better than anybody else in our industry. And my job right now is to build that infrastructure for Jewelry Television.
Gardner: So, IT is integral to your organization, not just for the ability to take in orders and deliver them, but you also acquire. And, if I understand it correctly, you’re also in the jewelry production business in terms of buying jewelry around the world and adding custom elements to these pieces. So, you’ve got a supply chain, and then you’ve got a distribution channel you've got to manage. Is that right?
Meystrik: That’s correct. And we have an inventory warehouse that we have to manage in the middle there, as well as customer relationships from an ecommerce perspective, a call center perspective, customer service, merchant services, the whole business. One of our biggest strengths is our buying channels. Some of the best buyers in this industry are here at Jewelry Television. Some of the best show hosts that know how to sell jewelry on the television are here at Jewelry Television. It’s a world-class environment; we need world-class systems that help this company keep growing.
Gardner: So you’ve got a jewelry lifecycle quality management problem, right?
Meystrik: It occurred to me, that while Brad and you were conversing about the code, and you made the comment that it really isn’t about the code -- to me it isn’t at all about the code. All the code is doing is saying, "Our buyer’s made some decision," or is potentially going to make a decision on some piece of jewelry or gemstone. And somehow that piece of jewelry, or that bulk-load jewelry, has to make it to Jewelry Television.
When it comes, I’ve got to account for it. When we account for it, we’ve got to put it away. When we put it away, we’ve got to be able to sell it, and tag it and picture it. And then we have to be able to manage it when somebody actually buys it, which might not be for another year, depending on what we bought it for. Maybe it's instantaneous, and we’re buying it out of bulk. All that stuff has to be managed, and the code just does that. In order for me to test the quality of my software, I have to prove that that process works; I have to do a real live end-to-end test.
Gardner: Give us a sense of the scale here. How many pieces of jewelry do you guys move in a typical month, or maybe even in the fast months, like just preceding the holiday shopping season?
Meystrik: Preceding the holiday seasons, we will do on the order of 40,000 orders a day. And those are previous numbers. It may get bigger. We’re anticipating a good holiday season.
Gardner: Give our listeners a sense of the type of concern we have here. What are your annual revenues at this point?
Meystrik: We are a private company, but our annual revenues are somewhere around $500 million.
Gardner: So, how do you keep the trains running on time in your application development, and deployment IT infrastructure?
Meystrik: People are the key, it turns out here: Having high-quality engineers that really understand the landscape, and can think out a couple of years and understand where we’re trying to get to. We tried several solutions when we first got here. They didn’t have a lot of processes in place, and we went for a waterfall approach. We really wanted the business to define to us what it is they were trying to build.
If those projects were small, they were fairly successful. If they were medium-size, we could do them pretty well. In some of those bigger projects, time just ran on, and time ran on, and by the time we got to the end of them, we weren’t dealing with the same problem anymore.
When that happens, the software wasn’t necessarily satisfying the solution you intended for it. So, what we’ve done is to move to a very agile, iterative development process, where quality has got to be a part. At the very beginning of this process, from requirements even in pre-discovery, we have QA engineers, and QA managers onboard with the project to get an understanding of what the impacts are going to be. With this we can get the business thinking of quality in the very beginning, with our product managers, and project managers getting a bird’s eye-view of what a real-life project schedule might look like. From there on, our QA is heavily involved in the agile process, all the way to the end, measuring the quality of the product. It has to be that way.
Gardner: What do you look for in a vendor, in the Application Lifecycle Management (ALM) space? What is that you need to make these multi-dimensional problems manageable?
Meystrik: We need the vendors to supply us with products that are open, products that will communicate with one another at every phase in the lifecycle of our product development. We have requirements engineers, product managers, and project managers -- both in the initial stages of the project together with the project charter -- trying to allocate resources, and then putting initial requirements together.
When the engineers finally get that, they’re not dealing with the same set of tools. The requirements engineer’s world is one of documentation and traceability, and being able to make sure that every requirement they’re writing is unambiguous and can be QAed at the end of the day. That’s their job at the beginning.
When that gets pushed off into engineering, they’re using their source code management (SCM) system, and their bug and issue tracking systems, and they’re using their IDEs. We don’t need them to get into other tools. All these tools need to coexist in one ALM framework that allows all these tools to communicate.
So, for example, within Eclipse, which is very, very popular here, you’re getting a glimpse of what those requirements look like right down to the engineers’ desktop, without having to open up some other tool, which we know nobody ever does. Without that, you have this barrier to entry that you just want to avoid. The communications are heavier.
When it comes to traceability, you want traceability all the way down to the source-code level, from those requirements into Subversion, which is the tools we’re using. All the way down into generating test plans out of requirements, our QA engineers are not using the requirements tool; they are using automated regression testing tools and automated performance testing tools. They want to write their test plans, and have bidirectional input in and out of the requirements tools, so they can maintain their traceability. So, all across, it has to be communicating and open.
Gardner: Now, it sounds to me as though you’re asking for a lot here. You want openness, you want interchangeability, but you also want full visibility, soup-to-nuts. You want traceability, and in sense you want both integration and openness. Let’s bounce it back to Brad here. When your customers say that to you, how do you fulfill that sort of a need?
Johnson: Well, it’s not an easy request, but the reality is that we live in a world today where development organizations have to put together a set of very heterogeneous tools. The core of LQM is our test management framework, which was developed was to be very open and to support many types of technologies.
Specifically, we realize that there are a lot of test automation tools out there, and many companies have made investments with other vendors, as well as open source vendors. So our objective around test management, therefore, is really to be able to support other vendors' test automation as well as our own.
We’ve brought in the Silk products from Segue, and certainly the integration between our test management and test automation tools with SilkTest and SilkPerformer is the best, right. But we realize again that there are many other types of testing out there. So test management needs to be the core harness of however organizations are doing their testing.
We’ve realized one thing that’s very important: That 80 to 95 percent of testing is still manual. So we’re spending a lot of time working on how we better enable and make more efficient the manual testing process, as well as the test automation process. From an openness standpoint, we are very focused on creating a platform that supports whatever customers are doing around testing.
Expanding that further, we also realize that as far as requirements management and source-code management, and so forth, there are other solutions in the market as well. So our integration strategy around those products is to support what’s out there, and what’s leading in the marketplace. But we really make sure our holistic platform includes requirements management and SCM, and test management and is seamless and deeply integrated from the beginning to the end.
Gardner: You’ve just come out with some announcements in early October -- the Borland Lifecycle Quality Management Solution -- and it’s a framework approach where you have interchangeability, but you’re also, of course, trying to toot your own horn about what you think are your best-of-breed components within that framework. Give us a rundown, if you would, of what this Lifecycle Quality Management Solution consists of, and how it helps folks like Chris at Jewelry Television manage their complexity, while also giving choice?
Johnson: Sure. First I want to reiterate that recognizing that there’s a need for a lifecycle approach to quality is really the first step. Getting the right management buy-in across the organization, developers as well as business leaders, needs to be the first thing you do before you really think about changing the way you’ve approached this. The other thing is, as companies make decisions about going Agile, these issues need to be considered.
The process I’ve already defined is very important. We understand that, and we understand how to get there from where we are today.
From a technology standpoint, the platform that Borland is delivering allows business users, and business analysts to capture a requirement correctly from the very beginning. We use a workflow-based definition and elicitation tool within our LQM Solution that lets users do that very, very well -- and lets them write in the quality attributes of that requirement. And then they can even take that basic requirement and develop and generate -- automatically generate -- test cases to put into our test management harness. We also deliver a full enterprise-class requirements management framework that is now deeply integrated with our test management framework.
So, as Chris was mentioning, we’ve got bidirectional traceability now between a business requirement that’s driving the project, and the testing requirements for the whole QA process in organization. And then we’re integrated on the test management side with our SCM solution, so that all of the test assets that are created during the testing process can be versioned and source-controlled as well as providing a defect-management capability -- so defects are rooted out of the application throughout the whole process.
So, the technology stack is really a deeply integrated platform for traceability from the very beginning to the very end of the testing process.
Gardner: It sounds as if there is actually a continuum of suites here, right?
Johnson: There is. We have the Silk suite from the Segue acquisition, which is growing and blending into the Caliber suite for requirements definition, and management, as well as our StarTeam suite for software configuration management. Our strategy moving forward is just to continue to make the integrations more seamless, and more valuable.
Gardner: Okay, back to Chris in Knoxville. When you hear this -- and this is just been out, so I know you don’t have it in place necessarily -- does this sound like a good fit? I know you do use some of the Borland brands and products now. Does this give you a big impetus to then say, "I’ve got to have this framework in addition to these individual suites and products?"
Meystrik: It gives me an impetus to go check it out. I am not a very big monolithic purchaser or consumer of technology goods. I like very open frameworks, and to that end we bought Segue before we even thought Borland was in the picture. We thought Segue was the best tool on the market. We did a long evaluation on automated test suites, and now it’s a part of Borland.
We purchased a different requirements management tool that did not work out for us because it didn’t have the openness that Brad’s talking about. It didn’t have the integratibility of the CaliberRM product. It just turned out Caliber was Number 2 on our list. We didn’t do another evaluation. We picked the Borland product.
We had already purchased Together for IDE integration to Eclipse for all of our architects. So we are a fairly large Borland customer. But for all of the listeners out there saying, "Well this guy, he’s into Borland, so of course he is on the call," we kind of stumbled into the whole deal by making some really good decisions. And we believe that the integration between CaliberRM and Silk tool is going to be outstanding. We’ve seen it in action, and it keeps getting better. We’re installing the Caliber products very, very soon to overtake the product that we had in-house, and we’ve had the Silk tools for over a year and half now, and we love them.
Gardner: And what about the use of this framework in conjunction with non-Borland products, I assume that you’ve got some of those too?
Meystrik: We do, and I’m hoping that really works out. We’re very big users of open-source products. We have Subversion as our source code management system, and we actually have made some open-source modifications to the Bugzilla tool for tracking; what we call action request, things that we do to our system. We have heavy traceability between Subversion and the Bugzilla implementation here at Jewelry Television. And we hope to move that traceability all the way up into CaliberRM, and thus all the way over into Silk.
I would like to know when somebody -- when some senior executive -- comes to me and says, "We’ve got this high-level requirement wrong," I want to understand the impact of that all the way down to my source code, and how much quality the QA team already put into uncovering SLAs, and things like that within the code. How much rework is it going to take? I think they’ve got a solution that’s going to do it.
Gardner: Now, within Jewelry Television what group is your biggest problem? And I don’t mean that in a negative way, but I mean, if Monday morning comes around, and you go in the office, who are the people you don’t want to see? Who is your most troublesome internal constituency, and I don’t need names, but sort of a department level or something like that?
Meystrik: I think not in terms of trouble, because we just value our customers across Jewelry Television. This is an amazing place to work, and all the people here are brilliant.
But when I come in and I hear, for example, that we had a huge Saturday and that the call center had to go on paper tickets for an hour. What I know is I have 300 or so people that did not have a very fun hour on Saturday. I take it personally, and I want to fix that problem. That’s a big impact.
There are other areas too. You could have some backups in inventory that affect your customers. All this stuff is very customer-facing. I would say that right now, that’s the area we’re really, really focused. We’ve got a new order management system going out within the next 30 days.
Gardner: And come Monday morning, you can’t go to those people who are doing the paper tickets, and explain to them that you didn’t have sufficient visibility into the requirements process due to a lack of integration between two disparate tools vendors, can you?
Meystrik: No, no. In fact I’m not even sure they would even know what that meant, just because they don’t know the IT world. They'll still say, "We still ran paper tickets."
Gardner: They just want to know that it works, right?
Meystrik: Exactly. They want to know that it works, and they want to know the process is going to get better. They want to know their talk times and their queues are going to go down, and that their customers are going to be significantly happier. We’ve got a lot of repeat customers here, and we want to know we can take care of them quickly, and they can do more shopping on the phone because the systems are more efficient, because we’ve thought about quality from the very beginning. We understand the SLAs that have to happen.
Gardner: Let's look to the future a little bit. You mentioned early on, Chris, when you were describing what you do, that services orientation was important to you. It strikes me that quality, while important in a distributed environment, is absolutely critical in a Services Oriented Architecture (SOA), or distributed services environment. Do you concur with that, and where do you see the importance of quality going as you move more into these independently created services?
Meystrik: I absolutely concur with that. When you put out a SOA and you start doing B2C, and B2B, and business-to-vendor communications on a broad scale -- you basically open up the kimono and say, "You want to communicate with Jewelry Television? This is the service framework that you can use to talk with us. Have fun."
That means that any one of those components that you don’t even know about could be the centrally hit hot spot in the system. You’ve got to be able to uncover, first, what is that hot-spot going to be. And if that is a hot spot, what kind of SLAs do you have to put around that thing? You have to know as you scale up -- whether it’s a down-stream call, or an object, or a method that’s being called by more web services than you thought -- you’ve got to be able to uncover what that hot-spot is and test it, and you’ve to have SLAs around it.
Brad mentioned a little while ago that too many people are doing manual testing, and I concur. We do too much of it around here, too. If we’re doing an Agile method in iterative development cycle, we can’t replay manual testing stuff through every iteration. It doesn’t work. Our QA development step has to become iterative also, they have to be able to manually iterate the first step, and then payload that thing into a regression test in the Silk tool.
This quality becomes just paramount when you go to SOA, mainly because there is non-determinism involved. You don’t necessarily know what your customers or vendors or other businesses are going to think is the most valuable service until you deploy them and they use them.
Gardner: Okay, well, super, I think we’re about out of time. We’ve been talking about the importance of quality in application development, about the necessity for a framework that allows interchangeability, but also coordination management and visibility. And helping us along on this discussion journey has been Chris Meystrik, he's the vice president of software engineering at Jewelry Television. Thanks for joining us, Chris.
Meystrik: Thanks Dana, I appreciate it.
Gardner: And also joining us from Borland Software: Brad Johnson, the director of product marketing, and he’s been talking about the new Borland Lifecycle Quality Management Solution, and why this is relevant now. But it sounds like something that will be increasingly relevant in the near future. I want to thank you also, Brad.
Johnson: Thank you, Dana. It was my pleasure to be here.
Gardner: This is Dana Gardner. I am principal analyst at Interarbor Solutions. You’ve been listening to BriefingsDirect. Thanks for joining us.
Podcast Sponsor: Borland Software.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect podcast on application development lifecycle quality. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.
Listen to the podcast here.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today a sponsored podcast discussion about IT quality, and the importance of quality as an essential ingredient in any application development activity -- and not necessarily as an afterthought or an after-effect but quality throughout, from inception and requirements, right through production and then to lifecycle. Joining us in this discussion we have a representative from Borland Software, Brad Johnson, who is the director of product marketing. Welcome to the show, Brad.
Brad Johnson: Thanks, Dana.
Gardner: Also joining us is a practitioner of quality in the application development process, Chris Meystrik, the vice president of software engineering at Jewelry Television in Knoxville, Tenn. Welcome to the show, Chris.
Chris Meystrik: Good to be with you Dana and Brad.
Gardner: Okay, we’ve heard a lot over the years about software development, and we’ve seen study after study that shows abysmal rates of on-time performance, of being over-budget, of requirements that don’t seem to make sense once the application gets into production. Obviously, not the best track record, and yet increasingly -- because companies are online with their marketing, they are online with the way they actually produce and deliver services, they are online with the way they acquire their resources through a supply chain -- it seems that application development is more important than ever. What do you think we need to do here, Brad, to make this a high-quality process from start to finish? What's been missing?
Johnson: Well, I think what's been missing is a real focus on quality -- essentially from day one, where organizations are thinking about building out complete requirements that include attributes of performance and functionality from the very beginning; when they start thinking about a project. As they move through the project lifecycle, they need to think about architecture and development. The testing organization, which very often is responsible for verifying quality at the tail end of a project, is actually involved earlier in the cycle. We need projects that essentially capture what the business users want, and also capture quality attributes so that as that development process flows across the whole software delivery lifecycle, quality is considered a priority from the very beginning.
Gardner: So we’re not really just talking about the quality of the code itself. We’re talking about the quality of the process, the people, the organization, and the tools -- everything that lines up before the code. Is that the way to think about it?
Johnson: That’s absolutely important. Thinking about the process, Borland looks at it in four dimensions, from managing the whole process to planning everything; from what the requirements of the project are, through to verification and validation, which as most people understand, is much bigger than just testing. It’s exactly as you stated. It’s looking at the process, it’s putting in gates and checks that include peer reviews, and making changes to the process -- iteratively if necessary. So you’re right, it’s looking at the holistic view of a project as it’s delivered, and quality is essentially built-in, but it’s not independent of testing.
Gardner: I suppose when you had an environment where all of your developers were within a stone’s throw of one another, and there was a single code base to work from, with centralized check in and check out, and you could manage component-by-component activities in a tight-knit group, that would be one issue. It's one problem to inject quality into that process.
But we have a much different environment today, where we’re seeing development teams that are dispersed geographically. We’re seeing much tighter timelines where code is getting checked in and checked out, and there are implications for how that impacts architecture and infrastructure earlier in the process.
We’re also seeing distributed computing environments where we’re going to have a heterogeneous runtime environment, most likely. Now that we’ve involved ourselves with the complexity of these distributed environments, is there a team approach to this? Should we think about it as check-in and checkout from a decentralized geographic standpoint, or do we still need to have a sort of a centralized approach? Is this a monolithic quality process for a distributed development process?
Johnson: A centralized kind of quality control center is a great idea. In practice and reality, I think we're far away from that. But you hit on what's absolutely a significant pressure on organizations today. That is, we’ve actually queried prospects, customers, and partners over the last few months, and distributed development is not just coming, it’s here, and it’s one of the biggest challenges faced by development teams today.
So, what you really need is a centralization point, where everybody is getting the same view of quality throughout the whole process … whether code is being checked in by the teams over which we have very little control -- where they are either outsourced or off-shored. Or they are under our control as far as being part of the organization, but distributed geographically and across time zones. You need to be able to understand, from a development standpoint, what exactly is being checked in, and what type of quality gates have been put in. So that when code gets checked in, we know that it’s free of security risks.
We need to know that there is no open-source code, for example, that’s in there, which is going to cause problems later. Hopefully, we’ve done the right level of J unit or N unit, or even functional automation on that early-stage code, so that at least we know that when code is added to the build, that build is not at risk. So, if we’re looking at that from a worldwide perspective, it's very, very challenging.
Gardner: So a brittle sort of top-town quality approach doesn’t seem to be the right fit for today’s development environment. I suppose we need something that’s got multiple levels, multiple components with an ability to integrate, but also to pass the baton, if you will, from one aspect of development to another. I think we all refer to this sort of multifaceted, flexible, and yet controlled environment for production as Lifecycle Quality Management (LQM). Or am I missing the point of what LQM is about?
Johnson: No, you haven’t missed the point, you’ve nailed it. Lifecycle Quality Management is about exactly that, looking across the software delivery lifecycle, and thinking about quality throughout the whole process. And that includes institutionalizing methods of assuring that requirements are correct, the code is complete, and as many defects have been as minimized as possible. Again, it’s looking across the lifecycle, and not just at one specific place in time, or one specific organization that’s contributing to any of those aspects.
Gardner: All right. That sounds like it makes tremendous sense. Of course these things are easier said than done. Let’s talk to the practitioner here. Chris, tell us a little bit about Jewelry Television and what your role is there as vice president of software engineering?
Meystrik: Jewelry Television is based in Knoxville, Tenn. We are a multi-channel sales vehicle. Our biggest sales channel is our cable television programming. It’s in more than 50 million homes across the United States. We have an ecommerce-based Web sales channel also. The vast majority of our calls come into our call center here in Knoxville, and we offload a good percentage of that to the ecommerce Website, and through interactive voice response systems here at Jewelry Television.
When I came in here, my role was to basically rebuild the enterprise infrastructure, specifically around the business that Jewelry Television is in. They’ve had experiences looking at competitors, some of them they have bought -- others are still out there in the market. They believe we need a customized service-oriented solution to tackle the marketplace, and basically give Jewelry Television a strategic and tactical advantage, to be better than anybody else in our industry. And my job right now is to build that infrastructure for Jewelry Television.
Gardner: So, IT is integral to your organization, not just for the ability to take in orders and deliver them, but you also acquire. And, if I understand it correctly, you’re also in the jewelry production business in terms of buying jewelry around the world and adding custom elements to these pieces. So, you’ve got a supply chain, and then you’ve got a distribution channel you've got to manage. Is that right?
Meystrik: That’s correct. And we have an inventory warehouse that we have to manage in the middle there, as well as customer relationships from an ecommerce perspective, a call center perspective, customer service, merchant services, the whole business. One of our biggest strengths is our buying channels. Some of the best buyers in this industry are here at Jewelry Television. Some of the best show hosts that know how to sell jewelry on the television are here at Jewelry Television. It’s a world-class environment; we need world-class systems that help this company keep growing.
Gardner: So you’ve got a jewelry lifecycle quality management problem, right?
Meystrik: It occurred to me, that while Brad and you were conversing about the code, and you made the comment that it really isn’t about the code -- to me it isn’t at all about the code. All the code is doing is saying, "Our buyer’s made some decision," or is potentially going to make a decision on some piece of jewelry or gemstone. And somehow that piece of jewelry, or that bulk-load jewelry, has to make it to Jewelry Television.
When it comes, I’ve got to account for it. When we account for it, we’ve got to put it away. When we put it away, we’ve got to be able to sell it, and tag it and picture it. And then we have to be able to manage it when somebody actually buys it, which might not be for another year, depending on what we bought it for. Maybe it's instantaneous, and we’re buying it out of bulk. All that stuff has to be managed, and the code just does that. In order for me to test the quality of my software, I have to prove that that process works; I have to do a real live end-to-end test.
Gardner: Give us a sense of the scale here. How many pieces of jewelry do you guys move in a typical month, or maybe even in the fast months, like just preceding the holiday shopping season?
Meystrik: Preceding the holiday seasons, we will do on the order of 40,000 orders a day. And those are previous numbers. It may get bigger. We’re anticipating a good holiday season.
Gardner: Give our listeners a sense of the type of concern we have here. What are your annual revenues at this point?
Meystrik: We are a private company, but our annual revenues are somewhere around $500 million.
Gardner: So, how do you keep the trains running on time in your application development, and deployment IT infrastructure?
Meystrik: People are the key, it turns out here: Having high-quality engineers that really understand the landscape, and can think out a couple of years and understand where we’re trying to get to. We tried several solutions when we first got here. They didn’t have a lot of processes in place, and we went for a waterfall approach. We really wanted the business to define to us what it is they were trying to build.
If those projects were small, they were fairly successful. If they were medium-size, we could do them pretty well. In some of those bigger projects, time just ran on, and time ran on, and by the time we got to the end of them, we weren’t dealing with the same problem anymore.
When that happens, the software wasn’t necessarily satisfying the solution you intended for it. So, what we’ve done is to move to a very agile, iterative development process, where quality has got to be a part. At the very beginning of this process, from requirements even in pre-discovery, we have QA engineers, and QA managers onboard with the project to get an understanding of what the impacts are going to be. With this we can get the business thinking of quality in the very beginning, with our product managers, and project managers getting a bird’s eye-view of what a real-life project schedule might look like. From there on, our QA is heavily involved in the agile process, all the way to the end, measuring the quality of the product. It has to be that way.
Gardner: What do you look for in a vendor, in the Application Lifecycle Management (ALM) space? What is that you need to make these multi-dimensional problems manageable?
Meystrik: We need the vendors to supply us with products that are open, products that will communicate with one another at every phase in the lifecycle of our product development. We have requirements engineers, product managers, and project managers -- both in the initial stages of the project together with the project charter -- trying to allocate resources, and then putting initial requirements together.
When the engineers finally get that, they’re not dealing with the same set of tools. The requirements engineer’s world is one of documentation and traceability, and being able to make sure that every requirement they’re writing is unambiguous and can be QAed at the end of the day. That’s their job at the beginning.
When that gets pushed off into engineering, they’re using their source code management (SCM) system, and their bug and issue tracking systems, and they’re using their IDEs. We don’t need them to get into other tools. All these tools need to coexist in one ALM framework that allows all these tools to communicate.
So, for example, within Eclipse, which is very, very popular here, you’re getting a glimpse of what those requirements look like right down to the engineers’ desktop, without having to open up some other tool, which we know nobody ever does. Without that, you have this barrier to entry that you just want to avoid. The communications are heavier.
When it comes to traceability, you want traceability all the way down to the source-code level, from those requirements into Subversion, which is the tools we’re using. All the way down into generating test plans out of requirements, our QA engineers are not using the requirements tool; they are using automated regression testing tools and automated performance testing tools. They want to write their test plans, and have bidirectional input in and out of the requirements tools, so they can maintain their traceability. So, all across, it has to be communicating and open.
Gardner: Now, it sounds to me as though you’re asking for a lot here. You want openness, you want interchangeability, but you also want full visibility, soup-to-nuts. You want traceability, and in sense you want both integration and openness. Let’s bounce it back to Brad here. When your customers say that to you, how do you fulfill that sort of a need?
Johnson: Well, it’s not an easy request, but the reality is that we live in a world today where development organizations have to put together a set of very heterogeneous tools. The core of LQM is our test management framework, which was developed was to be very open and to support many types of technologies.
Specifically, we realize that there are a lot of test automation tools out there, and many companies have made investments with other vendors, as well as open source vendors. So our objective around test management, therefore, is really to be able to support other vendors' test automation as well as our own.
We’ve brought in the Silk products from Segue, and certainly the integration between our test management and test automation tools with SilkTest and SilkPerformer is the best, right. But we realize again that there are many other types of testing out there. So test management needs to be the core harness of however organizations are doing their testing.
We’ve realized one thing that’s very important: That 80 to 95 percent of testing is still manual. So we’re spending a lot of time working on how we better enable and make more efficient the manual testing process, as well as the test automation process. From an openness standpoint, we are very focused on creating a platform that supports whatever customers are doing around testing.
Expanding that further, we also realize that as far as requirements management and source-code management, and so forth, there are other solutions in the market as well. So our integration strategy around those products is to support what’s out there, and what’s leading in the marketplace. But we really make sure our holistic platform includes requirements management and SCM, and test management and is seamless and deeply integrated from the beginning to the end.
Gardner: You’ve just come out with some announcements in early October -- the Borland Lifecycle Quality Management Solution -- and it’s a framework approach where you have interchangeability, but you’re also, of course, trying to toot your own horn about what you think are your best-of-breed components within that framework. Give us a rundown, if you would, of what this Lifecycle Quality Management Solution consists of, and how it helps folks like Chris at Jewelry Television manage their complexity, while also giving choice?
Johnson: Sure. First I want to reiterate that recognizing that there’s a need for a lifecycle approach to quality is really the first step. Getting the right management buy-in across the organization, developers as well as business leaders, needs to be the first thing you do before you really think about changing the way you’ve approached this. The other thing is, as companies make decisions about going Agile, these issues need to be considered.
The process I’ve already defined is very important. We understand that, and we understand how to get there from where we are today.
From a technology standpoint, the platform that Borland is delivering allows business users, and business analysts to capture a requirement correctly from the very beginning. We use a workflow-based definition and elicitation tool within our LQM Solution that lets users do that very, very well -- and lets them write in the quality attributes of that requirement. And then they can even take that basic requirement and develop and generate -- automatically generate -- test cases to put into our test management harness. We also deliver a full enterprise-class requirements management framework that is now deeply integrated with our test management framework.
So, as Chris was mentioning, we’ve got bidirectional traceability now between a business requirement that’s driving the project, and the testing requirements for the whole QA process in organization. And then we’re integrated on the test management side with our SCM solution, so that all of the test assets that are created during the testing process can be versioned and source-controlled as well as providing a defect-management capability -- so defects are rooted out of the application throughout the whole process.
So, the technology stack is really a deeply integrated platform for traceability from the very beginning to the very end of the testing process.
Gardner: It sounds as if there is actually a continuum of suites here, right?
Johnson: There is. We have the Silk suite from the Segue acquisition, which is growing and blending into the Caliber suite for requirements definition, and management, as well as our StarTeam suite for software configuration management. Our strategy moving forward is just to continue to make the integrations more seamless, and more valuable.
Gardner: Okay, back to Chris in Knoxville. When you hear this -- and this is just been out, so I know you don’t have it in place necessarily -- does this sound like a good fit? I know you do use some of the Borland brands and products now. Does this give you a big impetus to then say, "I’ve got to have this framework in addition to these individual suites and products?"
Meystrik: It gives me an impetus to go check it out. I am not a very big monolithic purchaser or consumer of technology goods. I like very open frameworks, and to that end we bought Segue before we even thought Borland was in the picture. We thought Segue was the best tool on the market. We did a long evaluation on automated test suites, and now it’s a part of Borland.
We purchased a different requirements management tool that did not work out for us because it didn’t have the openness that Brad’s talking about. It didn’t have the integratibility of the CaliberRM product. It just turned out Caliber was Number 2 on our list. We didn’t do another evaluation. We picked the Borland product.
We had already purchased Together for IDE integration to Eclipse for all of our architects. So we are a fairly large Borland customer. But for all of the listeners out there saying, "Well this guy, he’s into Borland, so of course he is on the call," we kind of stumbled into the whole deal by making some really good decisions. And we believe that the integration between CaliberRM and Silk tool is going to be outstanding. We’ve seen it in action, and it keeps getting better. We’re installing the Caliber products very, very soon to overtake the product that we had in-house, and we’ve had the Silk tools for over a year and half now, and we love them.
Gardner: And what about the use of this framework in conjunction with non-Borland products, I assume that you’ve got some of those too?
Meystrik: We do, and I’m hoping that really works out. We’re very big users of open-source products. We have Subversion as our source code management system, and we actually have made some open-source modifications to the Bugzilla tool for tracking; what we call action request, things that we do to our system. We have heavy traceability between Subversion and the Bugzilla implementation here at Jewelry Television. And we hope to move that traceability all the way up into CaliberRM, and thus all the way over into Silk.
I would like to know when somebody -- when some senior executive -- comes to me and says, "We’ve got this high-level requirement wrong," I want to understand the impact of that all the way down to my source code, and how much quality the QA team already put into uncovering SLAs, and things like that within the code. How much rework is it going to take? I think they’ve got a solution that’s going to do it.
Gardner: Now, within Jewelry Television what group is your biggest problem? And I don’t mean that in a negative way, but I mean, if Monday morning comes around, and you go in the office, who are the people you don’t want to see? Who is your most troublesome internal constituency, and I don’t need names, but sort of a department level or something like that?
Meystrik: I think not in terms of trouble, because we just value our customers across Jewelry Television. This is an amazing place to work, and all the people here are brilliant.
But when I come in and I hear, for example, that we had a huge Saturday and that the call center had to go on paper tickets for an hour. What I know is I have 300 or so people that did not have a very fun hour on Saturday. I take it personally, and I want to fix that problem. That’s a big impact.
There are other areas too. You could have some backups in inventory that affect your customers. All this stuff is very customer-facing. I would say that right now, that’s the area we’re really, really focused. We’ve got a new order management system going out within the next 30 days.
Gardner: And come Monday morning, you can’t go to those people who are doing the paper tickets, and explain to them that you didn’t have sufficient visibility into the requirements process due to a lack of integration between two disparate tools vendors, can you?
Meystrik: No, no. In fact I’m not even sure they would even know what that meant, just because they don’t know the IT world. They'll still say, "We still ran paper tickets."
Gardner: They just want to know that it works, right?
Meystrik: Exactly. They want to know that it works, and they want to know the process is going to get better. They want to know their talk times and their queues are going to go down, and that their customers are going to be significantly happier. We’ve got a lot of repeat customers here, and we want to know we can take care of them quickly, and they can do more shopping on the phone because the systems are more efficient, because we’ve thought about quality from the very beginning. We understand the SLAs that have to happen.
Gardner: Let's look to the future a little bit. You mentioned early on, Chris, when you were describing what you do, that services orientation was important to you. It strikes me that quality, while important in a distributed environment, is absolutely critical in a Services Oriented Architecture (SOA), or distributed services environment. Do you concur with that, and where do you see the importance of quality going as you move more into these independently created services?
Meystrik: I absolutely concur with that. When you put out a SOA and you start doing B2C, and B2B, and business-to-vendor communications on a broad scale -- you basically open up the kimono and say, "You want to communicate with Jewelry Television? This is the service framework that you can use to talk with us. Have fun."
That means that any one of those components that you don’t even know about could be the centrally hit hot spot in the system. You’ve got to be able to uncover, first, what is that hot-spot going to be. And if that is a hot spot, what kind of SLAs do you have to put around that thing? You have to know as you scale up -- whether it’s a down-stream call, or an object, or a method that’s being called by more web services than you thought -- you’ve got to be able to uncover what that hot-spot is and test it, and you’ve to have SLAs around it.
Brad mentioned a little while ago that too many people are doing manual testing, and I concur. We do too much of it around here, too. If we’re doing an Agile method in iterative development cycle, we can’t replay manual testing stuff through every iteration. It doesn’t work. Our QA development step has to become iterative also, they have to be able to manually iterate the first step, and then payload that thing into a regression test in the Silk tool.
This quality becomes just paramount when you go to SOA, mainly because there is non-determinism involved. You don’t necessarily know what your customers or vendors or other businesses are going to think is the most valuable service until you deploy them and they use them.
Gardner: Okay, well, super, I think we’re about out of time. We’ve been talking about the importance of quality in application development, about the necessity for a framework that allows interchangeability, but also coordination management and visibility. And helping us along on this discussion journey has been Chris Meystrik, he's the vice president of software engineering at Jewelry Television. Thanks for joining us, Chris.
Meystrik: Thanks Dana, I appreciate it.
Gardner: And also joining us from Borland Software: Brad Johnson, the director of product marketing, and he’s been talking about the new Borland Lifecycle Quality Management Solution, and why this is relevant now. But it sounds like something that will be increasingly relevant in the near future. I want to thank you also, Brad.
Johnson: Thank you, Dana. It was my pleasure to be here.
Gardner: This is Dana Gardner. I am principal analyst at Interarbor Solutions. You’ve been listening to BriefingsDirect. Thanks for joining us.
Podcast Sponsor: Borland Software.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect podcast on application development lifecycle quality. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.
Sunday, October 15, 2006
Transcript of Dana Gardner's BriefingsDirect SOA Insights Edition Podcast with Analysts Steve Garone and Neil Macehiter
Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Oct. 6, 2006.
Listen to the podcast here.
Dana Gardner: Hello, and welcome to the inaugural weekly BriefingsDirect SOA Insights Edition. This is a weekly discussion and dissection of Service Oriented Architecture (SOA) and related news and events with a panel of independent IT industry analysts and guests. I'm Dana Gardner, principal analyst at Interarbor Solutions and your host and moderator. This week joining me on our panel is Steve Garone. Welcome to the show, Steve.
Steve Garone: Great to be here, Dana. Thank you.
Gardner: Steve is a research partner affiliated with Ideas International, and is a former program vice president at IDC responsible for web services, integration, middleware, application development, and software-enabling technologies. He has also founded his own market research and analysis firm, The Align IT Group, which is now part of TechTarget. Steve is also an independent industry analyst and I'm told weíll hear more about your plans on that front and your future, Steve.
Garone: Yes, you will.
Gardner: Terrific. Also joining us is Neil Macehiter. Neil is the research director at Macehiter Ward-Dutton, based in England. Welcome to the show, Neil.
Neil Macehiter: Thanks, Dana. Nice to be here.
Gardner: Why don't you give me a quick rundown of your previous affiliations as an industry analyst?
Macehiter: Sure, before founding Macehiter Ward-Dutton at the beginning of 2005, I was a research director with a UK-based analyst company called Ovum, where I headed up a team of analysts looking at software infrastructure research. Before that I spent 17 years working for a variety of vendors and end-user organizations like Oracle, Sybase, Sun, and a few start ups.
Gardner: Excellent. Yes, I think we all have some background in software infrastructure and enterprise software. Before Interarbor Solutions I covered these subjects as well for the Yankee Group and the Aberdeen Group. So, just for the edification of our audience, we're creating a podcast show here that will include a transcript, and us prolific bloggers will be blogging on it as well.
The notion here is that the marketplace has some IT podcasts, we've got a lot of Web 2.0 and social networking discussion podcasts, but as far as I know, we don't have any SOA-focused shows. More and more SOA news, as well as trends, are emerging. This is not just a blip on the hype curve, although there is certainly some hype involved. This is a long-term (perhaps decades long) trend in IT. So, we're going to create our own podcast show on SOA and SOA governance and related subjects. We're going to have industry analysts joining the show as our panel contributors, and we're going to invite some guests; people that are newsmakers as well as other leaders in this emerging SOA space.
So, to start us off this week, there is some fairly big news from some of the biggest players in SOA: BEA, IBM, and Borland. We are going to start with an overview of what the BEA folks have done. I want to hand this off to Neil. I assume that you will look closely at the BEA 360 announcements that emerged from the BEA World Conference in California just in the last few days. Could you give us an overview of what BEA has come out with?
Macehiter: Yes, sure. What the BEA SOA 360 is, I think, is BEA putting a stake in the ground. They see their offerings around service-oriented infrastructure platforms evolving over the next two to three years. There are a number of aspects to it.
One is that they are applying SOA principles to the wave of actual architecture beyond the learning platform, and they refer to this as the micro services architecture. What this is really all about is providing enabling capabilities which are themselves delivered as services and exporting those within the overall platform. They talk about this as a notion of a service network which is actually nothing new in the SOA-based spenders like Blue Titan, which has been acquired by SOA Software. For example, they have been talking about the service network for a significant period of time. So, that's one element of this BEA SOA 360 announcement that really spans the three broad product families: the Tuxedo platform; WebLogic, which is an application platform for service-enabling applications; and AquaLogic, which is the micro-service platform they announced about a year-and-a-half ago.
They've also announced in this part of SOA 360 the WorkSpace 360. They are trying to facilitate a more collaborative approach to SOA that recognizes the roles of the different players in any SOA initiative. All the business analysts, the architects, developers, and the operation staff will be provided the means with which to collaborate. This is really oriented around their repository they acquired with Flashline which, to some extent, addresses the requirements.
I think are predominantly focusing on targeting a broader community with this notion of the WorkSpace. There are also a couple of other announcements. It is slightly tangential ... to the platform, some consulting offerings specifically oriented toward the executive community to develop a business case for SOA and to better understand the business value of SOA, and finally to offer some support services providing automated management capabilities so that you could, for example, detect a problem in the infrastructure and apply patches. It is that service that is really oriented around the infrastructure. That really captures the 360 announcements.
Gardner: I'd like to add something before you get into the analysis on this. Just a week before, BEA came out with something they're calling SALT 1.1, which stands for Services Architecture Leveraging Tuxedo. This is a Web services stack built on Tuxedo, their transaction processing engine, and allows the users to take C and C++ and COBOL, which are long-term and costly application sets to maintain, and allows them to work within a service oriented architecture framework. I think this has clearly targeted IBM and its installed base of CICS and Z Series -- its mainframes legacy -- allowing you to expose those via Tuxedo as Web services, although you have to inject Tuxedo into this stack.
Now that we've seen a little bit of what BEA is up to, let's talk about IBM. I'll give an overview of this announcement. IBM came out with a series of five new products, a number of enhancements to existing products, and 11 service offerings. They are really focusing on giving their customers flexible entry points into service-oriented architecture through a series of initiatives.
One of the things that is rather daunting about IBM is when they come out with these announcements, it is a laundry list of things and is somewhat of a challenge to fully wrap your mind around them, but they've broken it down to four major categories on the way you would build out your architecture. They call this model, assembly, deploy, manage, govern strategy, or MADMG, and it really amounts to having a services fabric. The lingo here is quite similar to what we heard from BEA.
This is a process management capability infrastructure, and management and then governance overlay to this series of capabilities. In terms of products, they've had the IBM Information Server, the WebSphere Business Services Fabric that we mentioned. And new and not entirely unexpected is their WebSphere Service Registry and Repository product, playing catch-up with the other companies that have done this either internally or through acquisition.
IBM also produced the Tivoli Dynamic Workload Broker and the IBM Change and Configuration Management Database. Those are the new products, and there were also enhancements to IBM's WebSphere Process Server, the Rational Platform and the Workplace Dashboard Framework. They have also come out with a number of services around methodology, and the flexibility and growth of reuse to decrease costs. So, governance links to a service lifecycle management capability focused on the high-level business services framework and BPM, and then also to the underlying infrastructure, and the way to manage that.
Steve, now that Neil and I have gone over with BEA and IBM, two very big players in SOA, have come out with. From your vantage point, have they done a good job providing a "soup to nuts" or a holistic full-service SOA implementation? Or are we still looking at even the definition of what that would consist of? Do we have big holes here or are we almost complete?
Garone: Before I answer the question, let me just throw in one more little element of the IBM announcement which I don't believe you mentioned, and that is they put a lot of emphasis on business partners and on industry solutions.
Gardner: Sure.
Garone: It has always been very important for IBM to take a lead in that area or at least try to, and part of that comes from their recent acquisition of Webify. But it's part of this overall effort on the part of both vendors and other vendors to ease that transition into SOA. This specific case, looking at how to make specific industries with specific requirements with compliance issues, to make that transition easier. So, I just wanted to throw that in there.
Gardner: Absolutely.
Garone: Well, in order to answer your question, I'd like to step back for a moment and frame this in the concept of what I have traditionally called the platform. My definition of platform is a little bit different from what BEA and even IBM would say. To me, a platform is a piece of technology or functionality around which a vendor builds its community. So, for IBM it would be operating systems and hardware platforms, and for Oracle it would be their database.
The importance of understanding this is really two-fold: The first is from the adoption and sales perspective. Vendors tend to have people gravitate toward them for a solution because their infrastructure and their solutions are built on a major component or a platform that a particular vendor offers. Also, do you go best-of-breed or do you just say I've got an IBM-centric environment, Iíve got an Oracle-centric environment; I am just going to go with them for the solution?
Gardner: Yes, I think this is the big question we are now facing.
Garone: Right.
Gardner: Complete holistic, or best-of-breed -- and if you want to do both, how do you decide where to put what where?
Garone: Exactly, and in the case of BEA, they have been very strong over the last few years building a comprehensive SOA platform, either through its own development initiatives or through acquisitions.
Gardner: Right.
Garone: They have a very strong foundation and legacy in providing very good, if not the best, solutions for middleware and SOA from the technology perspective with any vendor of the industry. That is one of the ways BEA has been very successful and has overcome the platform tendency of people to gravitate toward the wrong platform and go to those vendors. BEA has been successful in fighting that because if you go with my definition of a platform, BEA does not have a platform. It is building what it calls a platform around SOA, but that's basically what it does.
Gardner: Well, doesn't SOA require a bit of a change in that definition of platform? We have design time and runtime issues, and then we have this governance or management that binds the two because of the unpredictable nature of SLAs and demands on these services in an open environment, and the ability for reuse. We are really tying together runtime and design time and the management, and then reinforcing the cycle of the feedback loop among these components. It looks different than the traditional notion of a platform.
Garone: Yes, it is, and that's where I was going with the conversation. I think ultimately there is going to be a line between the platform that is an infrastructure component like an operating system or a database, and the SOA fabric and stack that goes above it is going to be blurred. We are starting to see that now in some other cases and the best one that I can think of is the acquisition of JBoss by Red Hat.
Gardner: Right.
Garone: In this case, an open source platform that is going to incorporate the operating system components required to do SOA and the SOA stack itself, and you're not going to be able to tell the difference. That is ultimately where IBM has to go and that may put BEA at a disadvantage because it doesn't have those underlined components, it has to sit on top of someone else's.
Gardner: Okay. Let's go to Neil. Do you see this definition of platform? We have design time, runtime, and governance capabilities, among others. Do you see BEA and IBM approaching it that way? Are there major holes, and can we expect that the implementations of SOA will cherry-pick among these parts, or will they be forced to go holistic with one because there are very limited number of vendors?
Macehiter: I think BEA and IBM are definitely moving in that direction, and the reason the platform has to change is down to the notion of the service of service-oriented architecture. Service in the real world is something you experience, and in the IT terms and IT service it means the platform needs to extend from the development of the services to their deployment to their operation, and that changes the characteristics and the capability you need within the platform.
I think they are trying to move in that direction and, depending on where they are coming from, they have different strengths. IBM has strengths ... and capabilities you need from the development side. BEA has a slightly different emphasis and tends to focus more on the development and deployment, but undoubtedly we are trying to move in that direction.
The point that Steve raised was very interesting: the example of Red Hat acquiring JBoss, and the development and infrastructure platform becoming indistinguishable. Think about and pair that with where Microsoft has been coming from around service-oriented platform.
Gardner: That's a great point.
Macehiter: You know, .NET has distinguished Microsoft's historical struggle because people want to know where the applications server is, and the reply is that it is Windows; people would look blankly and say that is not an application server, but that's the way Microsoft has been pushing it. I definitely think that they have all moved in that direction.
The second point is will it be better to be best-of-breed or will people gravitate to particular dominant platforms? I think the jury is still out on that. It entirely depends on the scope of an organization's SOA ambitions. For example, if they're looking to address some particular project-level server requirements, all departmental solutions and departmental requirements, and they are adopting a SOA approach, they might as well turn to a best-of-breed vendor.
Vendors like Sonic or SOA Software have been quite successful. When organizations start to consider more enterprise initiatives, who are they going to turn to? I think their natural inclination is going to be to gravitate to the big players and then look for the gaps. There are undoubtedly gaps; for example, products of the IBM announcement. Organizations would be looking for a combination of IBM and a Systinet (Now Mercury and HP) to provide registry and repository. Similarly, they will be looking at the BEA offering and looking for gaps there. How well do those BEA [products manage] identity and security? Well, only to a certain extent, so again they're going have to look for best-of-breed capabilities there.
The enterprises will gravitate to the big platform providers and then plug the gaps with best-of-breed capabilities. We will not see this sort of wholesale method of the best-of-breed solutions to implement, to support our SOA initiatives. If you are doing it at enterprise scale, potentially there are quite significant risks. The organizations will fight, plus many organizations are grappling with their sourcing strategies and looking to consolidate suppliers. If you have a massive, significant investment in SAP or ERP backbone, it is likely that you're going to at least consider SAP NetWeaver as part of the solution, and look at plugging the gaps that exist in NetWeaver around things like governance and identity and security.
Garone: If I can just interject something here, Neil. Your point about NetWeaver is well-taken, and if you could turn the original model I talked about, and say that for those people the SAP applications are the platform, that gives a lot more clarity to the notion of platform I originally presented. You are absolutely right; if you watch the big code and cross-platform vendors like IBM and Oracle, they try to walk this tightrope between -- we've got this comprehensive set for SOA that's going to make it really easy for you develop, deploy, manage, and govern your services-based implementation, but, by way, if you have a best-of-breed solution in-house, we can easily integrate that for you, and they will use an industry standard-based argument to make that point. End users really need to look carefully; just how easy and inexpensive is it to use that level of integration.
Macehiter: Absolutely. Oracle has been working with the idea of whole pluggable and BEA probably as micro service. The architectural announcement was the blended approach that BEA has been adopting primarily around the development platform.
Garone: Although that's mostly centered on open source.
Macehiter: Indeed. I think if you know how blendable or how pluggable or just luke-warm pluggable .... You know there are some important questions to ask because itís not just about having a list of WS.* specifications. You know we can interoperate with those things. It is how well the governance capabilities you have within your platform and to exploit them; can you manage those plugged-in components in the same way that you manage the rest of the infrastructure? There are a lot of other questions you need to be ask.
Gardner: I'm developing an analysis of this I'd like to run by you. When it comes to deciding between best-of-breed and holistic-integrated stack -- and I agree that there are going to be cases where an installed base is going to have an influence on decision making. For example, if you are a big Oracle shop, if you are a big SAP shop, if you are a big Microsoft shop, those have implications on your decisions and strategy.
On a more general note, it seems that developers are really not going to give up on their need for best-of-breed. They like to cherry-pick their tools, they are increasingly involved with Eclipse, they like the idea of plug-ins. Shoving a new tool down the developer's throat is not going to work.
I'm developing this analysis that says best-of-breed is going to continue; in fact, it needs to be absolutely supported in the design-time phase and test-and-debug phase and those early lifecycle quality issues for SOA. But, when it comes to deployment, there is this move in the market for unification, for consolidation, for lowering total cost, reducing the number of data centers, modernizing your all legacy applications, taking advantage of Web services standards, moving toward SOA.
It seems it is in the runtime, the operations side, where there's that need for a single throat to choke -- this is where a large vendor can be there on a services support and maintenance capability front where it also has big ecology partners and a support infrastructure. That's where you need a single large vendor. But then there is the third component of the platform that we described for SOA, which is this governance and policy, which needs to be relayed back to the design time efforts.
We are seeing this land grab, this race, for governance capabilities. So if you have two out of these three components -- let's say you have governance and runtime -- you will be able to work with the best-of-breed approaches in design time. Governance becomes the large winner here, because it ties runtime back to design time. Hence, we've had a very fast series of acquisitions, and also announcements like the IBM Registry and Repository announcement this week, toward the governance play. Does that make sense to you all?
Garone: Yes. I think your analysis makes sense. I think you said that if you have the governance in runtime, then you will be able to accommodate the development side and the best-of-breed on that side. Well, there are a couple of things that I'd like to say about it. It is basically sound; the only thing I would say is the openness in terms of the governance in runtime is going to be a requirement. They are not going to be nice to have and they are not going to be something that allows you to do something. It's something that is going to be an absolute requirement in the eyes of users.
Gardner: I absolutely agree with that. The sooner you bring the governance into a coordinated methodological role with the development, the better your quality will be in a lifecycle rather than just developing and then throwing over the wall and hoping that deployment people can work with that. I absolutely agree.
Garone: Yes. I just want to mention quickly that the actions over the last four or five years of the major vendors we talked about earlier in terms of reaching out to developers, making all their tools and development environments validates that the developer is the one you have to make happy on the development and deployment side. They are all reaching out to do that. The vendors are actually attempting to not only put a full core press on in terms of bringing in developers, but they are also trying to impress those developers so they think they are buying best-of-breed when they buy from an IBM or Oracle.
Gardner: Right. How about you, Neil? How do you see this view I've provided?
Macehiter: Though I think your analysis is on-point, I would emphasize that the organizations need to be thinking about governance more broadly than many of the vendors have been promoting. [Governance has been] primarily focused on the development ... side, and to some extent paying lip service to the fact that those governance assets -- the assets you have in your registry-repository -- need to be exploited throughout the entire lifecycle.
This is why the acquisition of Systinet by Mercury and then subsequently by HP is quite interesting. And thinking about the gap that needs to be plugged there. For example, how does SOA registry-repository compare to a configuration management database (CMDB), which is at the heart of their management and monitoring capabilities? I absolutely agree with the analysis in terms of interoperability that is needed from the development side, but I think you equally need interoperability at the management and runtime because it goes back to this point: A service is something you experience. You don't actually experience the service when it's being developed and deployed. You experience it when it's being run and operated.
That is the other angle of governance that we need to highlight. It was interesting, for example, when IBM announced the WebSphere Service Registry and Repository product that they did not talk too much about the integration, and how activity assets, activity complexity, and application manager are going to be exploited.
Gardner: All right, now let's get to some of the blogs that went back and forth this week. You and I were in it, Neil. Some folks were saying, and I believe were playing off of recent analyst reports, that Oracle and SAP will also be shopping for registry-repository product -- only there doesn't seem to be too many of those proven vendors left.
I wrote that I thought Oracle and SAP would be more likely look to a home-grown effort, and that Oracle and SAP are probably well on their way to producing a registry-repository, or a governance capability, internally because it does need to play off of their previous or existing management, as well as their strengths and their logic and policy approaches. Now we can swing the conversation into the vendor politics, or vendor sports, side of things. Who is the demonstrating a top-ranked approach?
It seems that IBM and Microsoft are doing quite well, although that is closely tied to installed bases. We are seeing some action around these other players that are still putting together comprehensive SOA platforms. Neil, you mentioned earlier Red Hat-JBoss, and then the Mercury acquisition by HP. It seems to me that HP is coming into this rather aggressively because it has a large management capability with OpenView. It's adding on the quality assurance benefits in the early phase of the design time with the Mercury traditional products, and then with the governance from the Systinet part of Mercury. And then also there's a very close relationship (that doesn't get a lot of attention) between Red Hat-JBoss and HP. They become, in a sense, an open source software platform.
So, here's an open-ended question: Who's ahead in the SOA race here, and who is not doing so well in terms of putting this all together?
Garone: Well, I'll jump in. It is very difficult to say who is ahead. As an ex-IDC analyst, I tend to think of those things in terms of who produced the most revenue in a given year on SOA-related products, which, of course, always seems to exclude Microsoft, for the reasons that Neil stated earlier. But I don't think that's the right way to look at it -- in terms of revenue.
IBM certainly has done a lot to steal the thunder in terms of messaging around SOA. They have introduced a lot of products, acquired a lot of companies, and put together a what looks like a comprehensive solution. The "baggage" there, of course, is that a lot of this comes through legacy products that have to be brought up to date, up to speed, and relevant to SOA. The question for IBM is going to be just how well have they done that and I think the jury is still out on that. I have always been a fan of BEA, although they've always had challenges in terms of the platform issue I mentioned earlier, but also in terms of coming out of a very technology-based background and marketing itself better.
I think they are all doing a very good job in terms of filling out the platform. You positioned IBM earlier as introducing a registry-repository because everybody's got to have one, and now they do as well. One of things that you brought up was HP. One of the things that is interesting to me, and I am going to be spending some significant amount of time on in the near future, is the Venn diagram overlap between SOA and the virtualization space.
It popped into my head because you mentioned HP. HP, as we all know, left the middleware business a couple of years ago, so its relationship with Red Hat and JBoss (now that Red Hat has acquired JBoss) makes perfect sense in terms of filling that in. But when you combine the governance issues and the other issues around building and managing SOA -- and put it in the context of being able to virtualize assets, and therefore where services are deployed and how they are managed -- that gets to be an interesting problem, and one that both IBM and HP are going to be fairly well-positioned to be able to solve.
Gardner: I guess I should also toss out for the sake of our audience that the stakes here are enormous. Larry Ellison made a prescient observation a few years ago that there is only going to be three or four major IT vendors at the end of the day, in 10 years or so. I agree with that. There is going to be a fomenting level of small companies that are innovative, but when it comes to the large enterprise accounts, there is going to be a consolidation. At the same time, there are these large transitions to services in the architecture. The companies that nail this are in a position to have the continuance of their $20 billion to $80 billion a year revenue engines. For over a long period of time we're talking about a global market potential here of $40 billion to $60 billion a year when it comes to the full implementation of service oriented architecture. So the stakes here are enormous.
Neil, let's go back to you for one more take on ranking the big guys, and how they are doing.
Macehiter: I think, you know, I tend to agree with Steve. IBM has certainly done a good job of winning the mind share in terms of being perceived as a SOA leader, and has done a lot of work to promote the customer engagements it has had. On paper, it certainly has a lot of the components you need for a comprehensive SOA capability, and I use the word capability because of the services element, which I think is important to know. In fact, BEA made some specific announcements around services and ...
Gardner: You mean professional services?
Macehiter: Yes, consulting services.
Gardner: Right.
Macehiter: So, I think IBM has done a good job. Microsoft is out there really addressing a slightly different audience and building from a different point of strength, which is out from its developer community.
With Oracle there is still some confusion around Fusion, especially for their applications and middleware strategy. They have actually done a pretty good job of building out their portfolio to address a broad set of the requirements. Perhaps some management pieces are missing. They have made some very small acquisitions. I think SAP is building from its point of strength around control of the business processes, and working at a high-level within the organization. It doesn't have so much of the core infrastructure capabilities you need.
So, I think it's interesting to watch the dynamic. A lot of it depends on the comparative strengths of the vendors historically. I think there is a tier of players below that like webMethods, SOA Software, Progress-Sonic that, if you like the known big vendor alternative, I think will primarily appeal initially around this whole project level deployment. I think it's an interesting space.
Gardner: If we look at those second tier players through this taxonomy of best-of-breed in design time, completeness in run time, and then linking that together with governance and policy -- how do you see those second tier players being able to operate within that sort of framework?
Macehiter: They had seen some initial success, which is not unusual in an emerging market. But it is more about addressing the customer concerns around viability, around the longevity of that vendor. Are they going to be around? Do they have the vertical market expertise? It is going to be interesting as these markets evolve and you see the tier-one players gradually emerge as they did with client/server and client/server development tools. They gradually subsumed the mind share there, and there were a small number of players left.
Gardner: Yes, we saw the same thing with distributed Java.
Macehiter: Exactly, I think that it will be the same. This will probably allow for one of those mid-size players to really have a significant play, not at the same level as the big players, but to be recognized. You can see the companies I've mentioned, SOA Software, Progress, webMethods all vying for that place.
Gardner: Yes, another announcement this week was from Borland Software. They came out with their Lifecycle Quality Management (LQM) solution, which is a series of suites really, focused primarily on design time but with implications for working on an open basis with governance and policy. I wanted to bring that up because this has cast a new light on Borland, particularly when HP bought Mercury. Having this design time quality assurance capability, all a sudden, is much more prominent in SOA. Even though we might not put Borland in the category of a second-tier SOA provider, I think we can look at them now with more interest as a best-of-breed player within SOA nonetheless.
Garone: Yes, I think that makes sense, Dana. You know if I look at the announcement and I look at what Borland has done here. It is something that is obviously needed and necessary, and plays well in the context of a governance model. It also makes sense for Borland, given the kind of vendor they are and what their history has been. It really builds on this notation of giving developers what they need to build effective solutions but not only bringing it all the way through the entire development lifecycle in terms of quality assurance, but also bringing things back all the way and bringing the notion of governance and quality back to the requirements themselves.
Gardner: Yes, right.
Garone: I think that's really a very positive thing for Borland to do. It was probably something Borland needed to do, given the fact that everybody around them is building comprehensive SOA stacks. We all remember five or six years ago they were playing to the middleware space, which didn't go very well. So, this makes sense. There is somebody to watch. My sense is that the result from this is less a move into other areas of comprehensive stacks, and more in terms of partnerships and relationships with other vendors.
Gardner: Okay, gentlemen, I really appreciate your frankness and insights. I think we've had a really nice discussion.
As part of the BriefingsDirect SOA Insights Edition format we're going to do something different than you might get from your traditional IT industry analyst. We are going to have a little pause for disclosure here. It will be interesting to know who, for transparency purposes, we are working with on a revenue basis. I'll go first. We've mentioned a number of companies during this discussion, but I just want our listeners to know that I have a business relationship, in fact a sponsorship for my BriefingsDirect podcasts, with Borland, HP, Cape Clear and Eclipse Foundation.
So just to come clean, I wonder if you other guys want to mention the companies that you work with as well, so people better trust us.
Macehiter: Yes, I'll just quickly dive in here. In terms of the vendors that I've mentioned off the top of my head, once we had consulting engagements with and a revenue relationship with BEA, IBM, Microsoft, Systinet and Mercury.
Garone: Of the ones we've talked about today, the only two are IBM and HP.
Gardner: Terrific. Okay, I would also like to point out to our listeners that if you'd like to learn more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, feel free to contact me, Dana Gardner, at 603-528-2435.
I want to thank our panelists today. We have been discussing service oriented architecture and the SOA news of the week with Steve Garone. He is a research partner affiliated with Ideas International, a former IDC vice president, a founder of the Align IT Group, and is now an independent industry analyst working toward some other interesting goals. I hope youíll come back soon to tell us about them, Steve.
Garone: You can count on it.
Gardner: Thank you. We've also been talking with Neil Macehiter. He is the research director at Macehiter Ward-Dutton, an analysis and consulting firm in England. Thank you, Neil.
Macehiter: You are welcome, and thanks a lot, Dana. Thanks Steve.
Garone: Thank you.
Gardner: So, let me remind our listeners to come back again next week for another version of BriefingsDirect SOA Insights Edition. Thanks.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.
Listen to the podcast here.
Dana Gardner: Hello, and welcome to the inaugural weekly BriefingsDirect SOA Insights Edition. This is a weekly discussion and dissection of Service Oriented Architecture (SOA) and related news and events with a panel of independent IT industry analysts and guests. I'm Dana Gardner, principal analyst at Interarbor Solutions and your host and moderator. This week joining me on our panel is Steve Garone. Welcome to the show, Steve.
Steve Garone: Great to be here, Dana. Thank you.
Gardner: Steve is a research partner affiliated with Ideas International, and is a former program vice president at IDC responsible for web services, integration, middleware, application development, and software-enabling technologies. He has also founded his own market research and analysis firm, The Align IT Group, which is now part of TechTarget. Steve is also an independent industry analyst and I'm told weíll hear more about your plans on that front and your future, Steve.
Garone: Yes, you will.
Gardner: Terrific. Also joining us is Neil Macehiter. Neil is the research director at Macehiter Ward-Dutton, based in England. Welcome to the show, Neil.
Neil Macehiter: Thanks, Dana. Nice to be here.
Gardner: Why don't you give me a quick rundown of your previous affiliations as an industry analyst?
Macehiter: Sure, before founding Macehiter Ward-Dutton at the beginning of 2005, I was a research director with a UK-based analyst company called Ovum, where I headed up a team of analysts looking at software infrastructure research. Before that I spent 17 years working for a variety of vendors and end-user organizations like Oracle, Sybase, Sun, and a few start ups.
Gardner: Excellent. Yes, I think we all have some background in software infrastructure and enterprise software. Before Interarbor Solutions I covered these subjects as well for the Yankee Group and the Aberdeen Group. So, just for the edification of our audience, we're creating a podcast show here that will include a transcript, and us prolific bloggers will be blogging on it as well.
The notion here is that the marketplace has some IT podcasts, we've got a lot of Web 2.0 and social networking discussion podcasts, but as far as I know, we don't have any SOA-focused shows. More and more SOA news, as well as trends, are emerging. This is not just a blip on the hype curve, although there is certainly some hype involved. This is a long-term (perhaps decades long) trend in IT. So, we're going to create our own podcast show on SOA and SOA governance and related subjects. We're going to have industry analysts joining the show as our panel contributors, and we're going to invite some guests; people that are newsmakers as well as other leaders in this emerging SOA space.
So, to start us off this week, there is some fairly big news from some of the biggest players in SOA: BEA, IBM, and Borland. We are going to start with an overview of what the BEA folks have done. I want to hand this off to Neil. I assume that you will look closely at the BEA 360 announcements that emerged from the BEA World Conference in California just in the last few days. Could you give us an overview of what BEA has come out with?
Macehiter: Yes, sure. What the BEA SOA 360 is, I think, is BEA putting a stake in the ground. They see their offerings around service-oriented infrastructure platforms evolving over the next two to three years. There are a number of aspects to it.
One is that they are applying SOA principles to the wave of actual architecture beyond the learning platform, and they refer to this as the micro services architecture. What this is really all about is providing enabling capabilities which are themselves delivered as services and exporting those within the overall platform. They talk about this as a notion of a service network which is actually nothing new in the SOA-based spenders like Blue Titan, which has been acquired by SOA Software. For example, they have been talking about the service network for a significant period of time. So, that's one element of this BEA SOA 360 announcement that really spans the three broad product families: the Tuxedo platform; WebLogic, which is an application platform for service-enabling applications; and AquaLogic, which is the micro-service platform they announced about a year-and-a-half ago.
They've also announced in this part of SOA 360 the WorkSpace 360. They are trying to facilitate a more collaborative approach to SOA that recognizes the roles of the different players in any SOA initiative. All the business analysts, the architects, developers, and the operation staff will be provided the means with which to collaborate. This is really oriented around their repository they acquired with Flashline which, to some extent, addresses the requirements.
I think are predominantly focusing on targeting a broader community with this notion of the WorkSpace. There are also a couple of other announcements. It is slightly tangential ... to the platform, some consulting offerings specifically oriented toward the executive community to develop a business case for SOA and to better understand the business value of SOA, and finally to offer some support services providing automated management capabilities so that you could, for example, detect a problem in the infrastructure and apply patches. It is that service that is really oriented around the infrastructure. That really captures the 360 announcements.
Gardner: I'd like to add something before you get into the analysis on this. Just a week before, BEA came out with something they're calling SALT 1.1, which stands for Services Architecture Leveraging Tuxedo. This is a Web services stack built on Tuxedo, their transaction processing engine, and allows the users to take C and C++ and COBOL, which are long-term and costly application sets to maintain, and allows them to work within a service oriented architecture framework. I think this has clearly targeted IBM and its installed base of CICS and Z Series -- its mainframes legacy -- allowing you to expose those via Tuxedo as Web services, although you have to inject Tuxedo into this stack.
Now that we've seen a little bit of what BEA is up to, let's talk about IBM. I'll give an overview of this announcement. IBM came out with a series of five new products, a number of enhancements to existing products, and 11 service offerings. They are really focusing on giving their customers flexible entry points into service-oriented architecture through a series of initiatives.
One of the things that is rather daunting about IBM is when they come out with these announcements, it is a laundry list of things and is somewhat of a challenge to fully wrap your mind around them, but they've broken it down to four major categories on the way you would build out your architecture. They call this model, assembly, deploy, manage, govern strategy, or MADMG, and it really amounts to having a services fabric. The lingo here is quite similar to what we heard from BEA.
This is a process management capability infrastructure, and management and then governance overlay to this series of capabilities. In terms of products, they've had the IBM Information Server, the WebSphere Business Services Fabric that we mentioned. And new and not entirely unexpected is their WebSphere Service Registry and Repository product, playing catch-up with the other companies that have done this either internally or through acquisition.
IBM also produced the Tivoli Dynamic Workload Broker and the IBM Change and Configuration Management Database. Those are the new products, and there were also enhancements to IBM's WebSphere Process Server, the Rational Platform and the Workplace Dashboard Framework. They have also come out with a number of services around methodology, and the flexibility and growth of reuse to decrease costs. So, governance links to a service lifecycle management capability focused on the high-level business services framework and BPM, and then also to the underlying infrastructure, and the way to manage that.
Steve, now that Neil and I have gone over with BEA and IBM, two very big players in SOA, have come out with. From your vantage point, have they done a good job providing a "soup to nuts" or a holistic full-service SOA implementation? Or are we still looking at even the definition of what that would consist of? Do we have big holes here or are we almost complete?
Garone: Before I answer the question, let me just throw in one more little element of the IBM announcement which I don't believe you mentioned, and that is they put a lot of emphasis on business partners and on industry solutions.
Gardner: Sure.
Garone: It has always been very important for IBM to take a lead in that area or at least try to, and part of that comes from their recent acquisition of Webify. But it's part of this overall effort on the part of both vendors and other vendors to ease that transition into SOA. This specific case, looking at how to make specific industries with specific requirements with compliance issues, to make that transition easier. So, I just wanted to throw that in there.
Gardner: Absolutely.
Garone: Well, in order to answer your question, I'd like to step back for a moment and frame this in the concept of what I have traditionally called the platform. My definition of platform is a little bit different from what BEA and even IBM would say. To me, a platform is a piece of technology or functionality around which a vendor builds its community. So, for IBM it would be operating systems and hardware platforms, and for Oracle it would be their database.
The importance of understanding this is really two-fold: The first is from the adoption and sales perspective. Vendors tend to have people gravitate toward them for a solution because their infrastructure and their solutions are built on a major component or a platform that a particular vendor offers. Also, do you go best-of-breed or do you just say I've got an IBM-centric environment, Iíve got an Oracle-centric environment; I am just going to go with them for the solution?
Gardner: Yes, I think this is the big question we are now facing.
Garone: Right.
Gardner: Complete holistic, or best-of-breed -- and if you want to do both, how do you decide where to put what where?
Garone: Exactly, and in the case of BEA, they have been very strong over the last few years building a comprehensive SOA platform, either through its own development initiatives or through acquisitions.
Gardner: Right.
Garone: They have a very strong foundation and legacy in providing very good, if not the best, solutions for middleware and SOA from the technology perspective with any vendor of the industry. That is one of the ways BEA has been very successful and has overcome the platform tendency of people to gravitate toward the wrong platform and go to those vendors. BEA has been successful in fighting that because if you go with my definition of a platform, BEA does not have a platform. It is building what it calls a platform around SOA, but that's basically what it does.
Gardner: Well, doesn't SOA require a bit of a change in that definition of platform? We have design time and runtime issues, and then we have this governance or management that binds the two because of the unpredictable nature of SLAs and demands on these services in an open environment, and the ability for reuse. We are really tying together runtime and design time and the management, and then reinforcing the cycle of the feedback loop among these components. It looks different than the traditional notion of a platform.
Garone: Yes, it is, and that's where I was going with the conversation. I think ultimately there is going to be a line between the platform that is an infrastructure component like an operating system or a database, and the SOA fabric and stack that goes above it is going to be blurred. We are starting to see that now in some other cases and the best one that I can think of is the acquisition of JBoss by Red Hat.
Gardner: Right.
Garone: In this case, an open source platform that is going to incorporate the operating system components required to do SOA and the SOA stack itself, and you're not going to be able to tell the difference. That is ultimately where IBM has to go and that may put BEA at a disadvantage because it doesn't have those underlined components, it has to sit on top of someone else's.
Gardner: Okay. Let's go to Neil. Do you see this definition of platform? We have design time, runtime, and governance capabilities, among others. Do you see BEA and IBM approaching it that way? Are there major holes, and can we expect that the implementations of SOA will cherry-pick among these parts, or will they be forced to go holistic with one because there are very limited number of vendors?
Macehiter: I think BEA and IBM are definitely moving in that direction, and the reason the platform has to change is down to the notion of the service of service-oriented architecture. Service in the real world is something you experience, and in the IT terms and IT service it means the platform needs to extend from the development of the services to their deployment to their operation, and that changes the characteristics and the capability you need within the platform.
I think they are trying to move in that direction and, depending on where they are coming from, they have different strengths. IBM has strengths ... and capabilities you need from the development side. BEA has a slightly different emphasis and tends to focus more on the development and deployment, but undoubtedly we are trying to move in that direction.
The point that Steve raised was very interesting: the example of Red Hat acquiring JBoss, and the development and infrastructure platform becoming indistinguishable. Think about and pair that with where Microsoft has been coming from around service-oriented platform.
Gardner: That's a great point.
Macehiter: You know, .NET has distinguished Microsoft's historical struggle because people want to know where the applications server is, and the reply is that it is Windows; people would look blankly and say that is not an application server, but that's the way Microsoft has been pushing it. I definitely think that they have all moved in that direction.
The second point is will it be better to be best-of-breed or will people gravitate to particular dominant platforms? I think the jury is still out on that. It entirely depends on the scope of an organization's SOA ambitions. For example, if they're looking to address some particular project-level server requirements, all departmental solutions and departmental requirements, and they are adopting a SOA approach, they might as well turn to a best-of-breed vendor.
Vendors like Sonic or SOA Software have been quite successful. When organizations start to consider more enterprise initiatives, who are they going to turn to? I think their natural inclination is going to be to gravitate to the big players and then look for the gaps. There are undoubtedly gaps; for example, products of the IBM announcement. Organizations would be looking for a combination of IBM and a Systinet (Now Mercury and HP) to provide registry and repository. Similarly, they will be looking at the BEA offering and looking for gaps there. How well do those BEA [products manage] identity and security? Well, only to a certain extent, so again they're going have to look for best-of-breed capabilities there.
The enterprises will gravitate to the big platform providers and then plug the gaps with best-of-breed capabilities. We will not see this sort of wholesale method of the best-of-breed solutions to implement, to support our SOA initiatives. If you are doing it at enterprise scale, potentially there are quite significant risks. The organizations will fight, plus many organizations are grappling with their sourcing strategies and looking to consolidate suppliers. If you have a massive, significant investment in SAP or ERP backbone, it is likely that you're going to at least consider SAP NetWeaver as part of the solution, and look at plugging the gaps that exist in NetWeaver around things like governance and identity and security.
Garone: If I can just interject something here, Neil. Your point about NetWeaver is well-taken, and if you could turn the original model I talked about, and say that for those people the SAP applications are the platform, that gives a lot more clarity to the notion of platform I originally presented. You are absolutely right; if you watch the big code and cross-platform vendors like IBM and Oracle, they try to walk this tightrope between -- we've got this comprehensive set for SOA that's going to make it really easy for you develop, deploy, manage, and govern your services-based implementation, but, by way, if you have a best-of-breed solution in-house, we can easily integrate that for you, and they will use an industry standard-based argument to make that point. End users really need to look carefully; just how easy and inexpensive is it to use that level of integration.
Macehiter: Absolutely. Oracle has been working with the idea of whole pluggable and BEA probably as micro service. The architectural announcement was the blended approach that BEA has been adopting primarily around the development platform.
Garone: Although that's mostly centered on open source.
Macehiter: Indeed. I think if you know how blendable or how pluggable or just luke-warm pluggable .... You know there are some important questions to ask because itís not just about having a list of WS.* specifications. You know we can interoperate with those things. It is how well the governance capabilities you have within your platform and to exploit them; can you manage those plugged-in components in the same way that you manage the rest of the infrastructure? There are a lot of other questions you need to be ask.
Gardner: I'm developing an analysis of this I'd like to run by you. When it comes to deciding between best-of-breed and holistic-integrated stack -- and I agree that there are going to be cases where an installed base is going to have an influence on decision making. For example, if you are a big Oracle shop, if you are a big SAP shop, if you are a big Microsoft shop, those have implications on your decisions and strategy.
On a more general note, it seems that developers are really not going to give up on their need for best-of-breed. They like to cherry-pick their tools, they are increasingly involved with Eclipse, they like the idea of plug-ins. Shoving a new tool down the developer's throat is not going to work.
I'm developing this analysis that says best-of-breed is going to continue; in fact, it needs to be absolutely supported in the design-time phase and test-and-debug phase and those early lifecycle quality issues for SOA. But, when it comes to deployment, there is this move in the market for unification, for consolidation, for lowering total cost, reducing the number of data centers, modernizing your all legacy applications, taking advantage of Web services standards, moving toward SOA.
It seems it is in the runtime, the operations side, where there's that need for a single throat to choke -- this is where a large vendor can be there on a services support and maintenance capability front where it also has big ecology partners and a support infrastructure. That's where you need a single large vendor. But then there is the third component of the platform that we described for SOA, which is this governance and policy, which needs to be relayed back to the design time efforts.
We are seeing this land grab, this race, for governance capabilities. So if you have two out of these three components -- let's say you have governance and runtime -- you will be able to work with the best-of-breed approaches in design time. Governance becomes the large winner here, because it ties runtime back to design time. Hence, we've had a very fast series of acquisitions, and also announcements like the IBM Registry and Repository announcement this week, toward the governance play. Does that make sense to you all?
Garone: Yes. I think your analysis makes sense. I think you said that if you have the governance in runtime, then you will be able to accommodate the development side and the best-of-breed on that side. Well, there are a couple of things that I'd like to say about it. It is basically sound; the only thing I would say is the openness in terms of the governance in runtime is going to be a requirement. They are not going to be nice to have and they are not going to be something that allows you to do something. It's something that is going to be an absolute requirement in the eyes of users.
Gardner: I absolutely agree with that. The sooner you bring the governance into a coordinated methodological role with the development, the better your quality will be in a lifecycle rather than just developing and then throwing over the wall and hoping that deployment people can work with that. I absolutely agree.
Garone: Yes. I just want to mention quickly that the actions over the last four or five years of the major vendors we talked about earlier in terms of reaching out to developers, making all their tools and development environments validates that the developer is the one you have to make happy on the development and deployment side. They are all reaching out to do that. The vendors are actually attempting to not only put a full core press on in terms of bringing in developers, but they are also trying to impress those developers so they think they are buying best-of-breed when they buy from an IBM or Oracle.
Gardner: Right. How about you, Neil? How do you see this view I've provided?
Macehiter: Though I think your analysis is on-point, I would emphasize that the organizations need to be thinking about governance more broadly than many of the vendors have been promoting. [Governance has been] primarily focused on the development ... side, and to some extent paying lip service to the fact that those governance assets -- the assets you have in your registry-repository -- need to be exploited throughout the entire lifecycle.
This is why the acquisition of Systinet by Mercury and then subsequently by HP is quite interesting. And thinking about the gap that needs to be plugged there. For example, how does SOA registry-repository compare to a configuration management database (CMDB), which is at the heart of their management and monitoring capabilities? I absolutely agree with the analysis in terms of interoperability that is needed from the development side, but I think you equally need interoperability at the management and runtime because it goes back to this point: A service is something you experience. You don't actually experience the service when it's being developed and deployed. You experience it when it's being run and operated.
That is the other angle of governance that we need to highlight. It was interesting, for example, when IBM announced the WebSphere Service Registry and Repository product that they did not talk too much about the integration, and how activity assets, activity complexity, and application manager are going to be exploited.
Gardner: All right, now let's get to some of the blogs that went back and forth this week. You and I were in it, Neil. Some folks were saying, and I believe were playing off of recent analyst reports, that Oracle and SAP will also be shopping for registry-repository product -- only there doesn't seem to be too many of those proven vendors left.
I wrote that I thought Oracle and SAP would be more likely look to a home-grown effort, and that Oracle and SAP are probably well on their way to producing a registry-repository, or a governance capability, internally because it does need to play off of their previous or existing management, as well as their strengths and their logic and policy approaches. Now we can swing the conversation into the vendor politics, or vendor sports, side of things. Who is the demonstrating a top-ranked approach?
It seems that IBM and Microsoft are doing quite well, although that is closely tied to installed bases. We are seeing some action around these other players that are still putting together comprehensive SOA platforms. Neil, you mentioned earlier Red Hat-JBoss, and then the Mercury acquisition by HP. It seems to me that HP is coming into this rather aggressively because it has a large management capability with OpenView. It's adding on the quality assurance benefits in the early phase of the design time with the Mercury traditional products, and then with the governance from the Systinet part of Mercury. And then also there's a very close relationship (that doesn't get a lot of attention) between Red Hat-JBoss and HP. They become, in a sense, an open source software platform.
So, here's an open-ended question: Who's ahead in the SOA race here, and who is not doing so well in terms of putting this all together?
Garone: Well, I'll jump in. It is very difficult to say who is ahead. As an ex-IDC analyst, I tend to think of those things in terms of who produced the most revenue in a given year on SOA-related products, which, of course, always seems to exclude Microsoft, for the reasons that Neil stated earlier. But I don't think that's the right way to look at it -- in terms of revenue.
IBM certainly has done a lot to steal the thunder in terms of messaging around SOA. They have introduced a lot of products, acquired a lot of companies, and put together a what looks like a comprehensive solution. The "baggage" there, of course, is that a lot of this comes through legacy products that have to be brought up to date, up to speed, and relevant to SOA. The question for IBM is going to be just how well have they done that and I think the jury is still out on that. I have always been a fan of BEA, although they've always had challenges in terms of the platform issue I mentioned earlier, but also in terms of coming out of a very technology-based background and marketing itself better.
I think they are all doing a very good job in terms of filling out the platform. You positioned IBM earlier as introducing a registry-repository because everybody's got to have one, and now they do as well. One of things that you brought up was HP. One of the things that is interesting to me, and I am going to be spending some significant amount of time on in the near future, is the Venn diagram overlap between SOA and the virtualization space.
It popped into my head because you mentioned HP. HP, as we all know, left the middleware business a couple of years ago, so its relationship with Red Hat and JBoss (now that Red Hat has acquired JBoss) makes perfect sense in terms of filling that in. But when you combine the governance issues and the other issues around building and managing SOA -- and put it in the context of being able to virtualize assets, and therefore where services are deployed and how they are managed -- that gets to be an interesting problem, and one that both IBM and HP are going to be fairly well-positioned to be able to solve.
Gardner: I guess I should also toss out for the sake of our audience that the stakes here are enormous. Larry Ellison made a prescient observation a few years ago that there is only going to be three or four major IT vendors at the end of the day, in 10 years or so. I agree with that. There is going to be a fomenting level of small companies that are innovative, but when it comes to the large enterprise accounts, there is going to be a consolidation. At the same time, there are these large transitions to services in the architecture. The companies that nail this are in a position to have the continuance of their $20 billion to $80 billion a year revenue engines. For over a long period of time we're talking about a global market potential here of $40 billion to $60 billion a year when it comes to the full implementation of service oriented architecture. So the stakes here are enormous.
Neil, let's go back to you for one more take on ranking the big guys, and how they are doing.
Macehiter: I think, you know, I tend to agree with Steve. IBM has certainly done a good job of winning the mind share in terms of being perceived as a SOA leader, and has done a lot of work to promote the customer engagements it has had. On paper, it certainly has a lot of the components you need for a comprehensive SOA capability, and I use the word capability because of the services element, which I think is important to know. In fact, BEA made some specific announcements around services and ...
Gardner: You mean professional services?
Macehiter: Yes, consulting services.
Gardner: Right.
Macehiter: So, I think IBM has done a good job. Microsoft is out there really addressing a slightly different audience and building from a different point of strength, which is out from its developer community.
With Oracle there is still some confusion around Fusion, especially for their applications and middleware strategy. They have actually done a pretty good job of building out their portfolio to address a broad set of the requirements. Perhaps some management pieces are missing. They have made some very small acquisitions. I think SAP is building from its point of strength around control of the business processes, and working at a high-level within the organization. It doesn't have so much of the core infrastructure capabilities you need.
So, I think it's interesting to watch the dynamic. A lot of it depends on the comparative strengths of the vendors historically. I think there is a tier of players below that like webMethods, SOA Software, Progress-Sonic that, if you like the known big vendor alternative, I think will primarily appeal initially around this whole project level deployment. I think it's an interesting space.
Gardner: If we look at those second tier players through this taxonomy of best-of-breed in design time, completeness in run time, and then linking that together with governance and policy -- how do you see those second tier players being able to operate within that sort of framework?
Macehiter: They had seen some initial success, which is not unusual in an emerging market. But it is more about addressing the customer concerns around viability, around the longevity of that vendor. Are they going to be around? Do they have the vertical market expertise? It is going to be interesting as these markets evolve and you see the tier-one players gradually emerge as they did with client/server and client/server development tools. They gradually subsumed the mind share there, and there were a small number of players left.
Gardner: Yes, we saw the same thing with distributed Java.
Macehiter: Exactly, I think that it will be the same. This will probably allow for one of those mid-size players to really have a significant play, not at the same level as the big players, but to be recognized. You can see the companies I've mentioned, SOA Software, Progress, webMethods all vying for that place.
Gardner: Yes, another announcement this week was from Borland Software. They came out with their Lifecycle Quality Management (LQM) solution, which is a series of suites really, focused primarily on design time but with implications for working on an open basis with governance and policy. I wanted to bring that up because this has cast a new light on Borland, particularly when HP bought Mercury. Having this design time quality assurance capability, all a sudden, is much more prominent in SOA. Even though we might not put Borland in the category of a second-tier SOA provider, I think we can look at them now with more interest as a best-of-breed player within SOA nonetheless.
Garone: Yes, I think that makes sense, Dana. You know if I look at the announcement and I look at what Borland has done here. It is something that is obviously needed and necessary, and plays well in the context of a governance model. It also makes sense for Borland, given the kind of vendor they are and what their history has been. It really builds on this notation of giving developers what they need to build effective solutions but not only bringing it all the way through the entire development lifecycle in terms of quality assurance, but also bringing things back all the way and bringing the notion of governance and quality back to the requirements themselves.
Gardner: Yes, right.
Garone: I think that's really a very positive thing for Borland to do. It was probably something Borland needed to do, given the fact that everybody around them is building comprehensive SOA stacks. We all remember five or six years ago they were playing to the middleware space, which didn't go very well. So, this makes sense. There is somebody to watch. My sense is that the result from this is less a move into other areas of comprehensive stacks, and more in terms of partnerships and relationships with other vendors.
Gardner: Okay, gentlemen, I really appreciate your frankness and insights. I think we've had a really nice discussion.
As part of the BriefingsDirect SOA Insights Edition format we're going to do something different than you might get from your traditional IT industry analyst. We are going to have a little pause for disclosure here. It will be interesting to know who, for transparency purposes, we are working with on a revenue basis. I'll go first. We've mentioned a number of companies during this discussion, but I just want our listeners to know that I have a business relationship, in fact a sponsorship for my BriefingsDirect podcasts, with Borland, HP, Cape Clear and Eclipse Foundation.
So just to come clean, I wonder if you other guys want to mention the companies that you work with as well, so people better trust us.
Macehiter: Yes, I'll just quickly dive in here. In terms of the vendors that I've mentioned off the top of my head, once we had consulting engagements with and a revenue relationship with BEA, IBM, Microsoft, Systinet and Mercury.
Garone: Of the ones we've talked about today, the only two are IBM and HP.
Gardner: Terrific. Okay, I would also like to point out to our listeners that if you'd like to learn more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, feel free to contact me, Dana Gardner, at 603-528-2435.
I want to thank our panelists today. We have been discussing service oriented architecture and the SOA news of the week with Steve Garone. He is a research partner affiliated with Ideas International, a former IDC vice president, a founder of the Align IT Group, and is now an independent industry analyst working toward some other interesting goals. I hope youíll come back soon to tell us about them, Steve.
Garone: You can count on it.
Gardner: Thank you. We've also been talking with Neil Macehiter. He is the research director at Macehiter Ward-Dutton, an analysis and consulting firm in England. Thank you, Neil.
Macehiter: You are welcome, and thanks a lot, Dana. Thanks Steve.
Garone: Thank you.
Gardner: So, let me remind our listeners to come back again next week for another version of BriefingsDirect SOA Insights Edition. Thanks.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.
Subscribe to:
Posts (Atom)
