Showing posts with label Jason Bloomberg. Show all posts
Showing posts with label Jason Bloomberg. Show all posts

Tuesday, August 18, 2009

BriefingsDirect Analysts Discuss Software AG-IDS Scheer Acquisition and Prospects for Google Chrome OS

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 44 on Software AG's acquisition of IDS Scheer and the implications of the Google Chrome operating system.

Download the transcript. Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Take the BriefingsDirect middleware/ESB survey now.

Dana Gardner: Hello and welcome to the latest BriefingsDirect Analyst Insights Edition, Volume 44. I'm your host and moderator Dana Gardner, principal analyst at Interarbor Solutions.

This periodic discussion and dissection of IT infrastructure related news and events, with a panel of industry analysts, comes to you with the help of our charter sponsor, Active Endpoints, maker of the ActiveVOS visual orchestration system, and through the support of TIBCO Software.

Our topic this week on BriefingsDirect Analyst Insights Edition, and it is the week of July 13, 2009, centers on Software AG's bid to acquire IDS Scheer for about $320 million. We'll look into why this could be a big business process management (BPM) deal, not only for Software AG, but also for the service-oriented architecture (SOA) competitive landscape that is fast moving, as we saw from Oracle's recent acquisition of Sun Microsystems.

Another topic for our panel this week is the seemingly inevitable trend toward Web oriented architecture (WOA), most notably supported by Google's announcement of the Google Chrome operating system (OS).

Will the popularity of devices like netbooks and smartphones accelerate the obsolescence of full-fledged fat clients, and what can Google hope to do further to move the market away from powerhouse Microsoft? Who is the David and who is the Goliath in this transition from software plus services to software for services?

Here to help us better understand Software AG's latest acquisition bid and the impact of the Google Chrome OS are our analysts this week. We are here with Jim Kobielus, senior analyst at Forrester Research. Hi, Jim.

Jim Kobielus: Hey, Dana. Hello, everybody.

Gardner: Tony Baer, senior analyst at Ovum.

Tony Baer: Hey, Dana, good to join you again.

Gardner: Brad Shimmin, principal analyst at Current Analysis.

Brad Shimmin: Hi there, Dana, and hi, everyone out there.

Gardner: Jason Bloomberg, managing partner at ZapThink.

Jason Bloomberg: Good morning, everybody.

Gardner: JP Morgenthal, independent analyst and IT consultant.

JP Morgenthal: Hey Dana, and for you fellow people, that's @JPMorgenthal for you.

Gardner: There you go. Also, Joe McKendrick, independent analyst and ZDNet and SOA blogger. Welcome, Joe.

Joe McKendrick: Hi, Dana, glad to be here.

Gardner: Let's start on the whole Software AG bid. JP, I just learned this morning that you were an architect there at IDS Scheer. Tell us a little bit about why you think this is a big deal.

Morgenthal: No, I wasn't at IDS. I was at Software AG. I was there prior to the webMethods acquisition.

Gardner: Yes. My mistake. Sorry.

Morgenthal: No problem. It's really interesting. When we first started thinking about building out a SOA platform and making Tamino the heart of it, the metadata repository, it was one of the key applications we saw for Tamino in a SOA platform. I actually was looking for different metadata partners.

I looked at IDS Scheer back then and that's what they were sowing a while back, so I had lost track of them and come back to find that now they're driving the whole concept of business process design, which is really interesting.

It seems that the general consensus on the acquisition, though, seems to be focused heavily on their association with SAP, and that the move seems to be driven by more of a business relationship than a technical relationship. If you look at the platforms, there is some overlap between the webMethods platform and the ARIS platform.

So, it would make sense that, if they were going after something, it wouldn't be just more design functionality. There has to be something deeper there for them to grow that business even larger, and certainly SAP is a good target for going after more additional business.

Gardner: So, is this an acknowledgment that SAP needs a SOA partner and that this is Software AG's move on the dance floor to sort of step up the music a bit?

Morgenthal: SAP probably doesn't believe that they need an SOA partner, but I think that the fish are starting to nip around the outer boundaries. SAP customers are to the point now, where they are looking for something more immediate, and obviously the redevelopment of SAP as a complete SOA architecture is a long-term endeavor.

So, how do you start moving there in an incremental fashion? A lot of SOA platform vendors are starting to identify that there is a place for them on the outer edges, until SAP gets to make its full transformation.

Gardner: Hey, Jim Kobielus, do you agree that this is more than just a technology acquisition? What do you think? Does SAP need a SOA dance partner?

Kobielus: Does Software AG?

Gardner: No, SAP, and that Software AG is perhaps an intermediary step.

Kobielus: Wow, that's an interesting question. Honestly, I don't think SAP needs another dance partner here. Let's say, hypothetically SAP acquired Software AG. What could Software AG with IDS Scheer on board offer SAP that they don't already have? There is the BPM. There is the enterprise application integration (EAI). I don't really see anything obvious.

Gardner: JP, help him out. Why did you make that statement?

Feeding at the outer edge

Morgenthal: Well, I made the statement that the groups, like the combined effort of a Software AG with webMethods and IDS Scheer actually becomes one of the feeders on the outer edges of the SAP market. While SAP is in its cocoon, it needs to turn from caterpillar into SOA butterfly, and heaven knows whether that will actually survive that transformation.

There are a lot of SOA platforms starting to eat at the outer edges of the cocoon, feeding off of that, and hoping the transformation either fails or that there will be a place for them when the SOA butterfly emerges.

Kobielus: I don't think that necessarily Software AG would be a good fit for SAP. There are a lot of redundancies. I don't think that this notion of a Teutonic hegemony has legs here.

What's really interesting here is that, clearly Software AG is on a tear now to build up their whole

I think it goes both ways. You can't separate the technology from the strategic implications of this deal

SOA stack. I blogged on this under Forrester. People didn't realize that IDS Scheer is actually now a business intelligence (BI) vendor. They've got a self-service mashup BI product called ARIS MashZone, in addition to the complex event processing (CEP) product and an in-memory analytics product.

IDS Scheer, prior to this acquisition, has been increasingly positioning themselves in the new generation of BI solutions. That's been the one area where Software AG/webMethods has been deficient, from my point of view. In these SOA wars, they're lacking any strong BI or CEP capabilities.

Now, IDS Scheer, their BI, their CEP, and their in-memory analytics is all tied to business activity monitoring (BAM), and all tied to BPM. So, it's not clear whether or when Software AG, with IDS Scheer on board, might start turning all of that technology or adapting it to be more of a general purpose BI CEP capability. But, you know what, if they choose to do that, I think they've got some very strong technologies to build upon.

Gardner: Tony Baer, how do you come down on this technology, filling in the cracks, as Jim Kobielus believes, or the larger strategic implication that JP was alluding to?

Baer: I think it goes both ways. You can't separate the technology from the strategic implications of this deal.

For one thing, I don't think SAP itself thinks it needs a partner, in that, through NetWeaver, it has tried to control the middle tier in addition to the application tier, but they've not been that humongously successful in the market.

The other thing is that, yes, they have essentially defined an architecture for exposing their processes as services. They keep changing the names of it, so I forget what the latest acronym for it is. But, from the SAP standpoint what they lack is SOA governance. They lack a lifecycle there. SAP has always been very much around its own internal governance, and that's been a really interesting omission.

Other dimensions

More broadly, there are other dimensions to this deal, which is that Software AG's webMethods business gets a much deeper process-modeling path. I don't know how redundant it is with the existing modeling. I don't think there are many BPM modeling languages that are deeper than ARIS, and that's selling pretty awesomely. As a matter of fact, you can look at Oracle, which uses it as one of the paths to modeling business process, along with the technology they picked up from BEA.

Gardner: So what's the theory there, Tony, that the tool and its popularity will drag in some more on the infrastructure side?

Baer: For Software AG, what it’s going to drag in is immediate access to the SAP base, and that's huge. It also basically lays down a gauntlet to IBM and Oracle, especially Oracle, which has an OEM agreement. All of a sudden they have an OEM agreement with a major rival, as they're trying to ramp up their fusion middleware business in their SOA governance story.

Gardner: There is a lot of that going on nowadays.

Baer: Oh heck, yes, and so I see this as being incredibly disruptive, and I think a very smart move for Software AG.

Gardner: Let's go to Brad Shimmin. It seems like we've got some jockeying going on, and there aren't really too many mid-tier SOA infrastructure players left that these other behemoths can play chess with, their little pawns that they can move in front of their other players and play one OEM's agreement deal off of another, as they all try to come up with the total stack. What's your perspective, Brad? Are we almost at the end of the SOA consolidation process?

Shimmin: I don't think so. When you look at the big players, just as you said there, Dana, with their little OEM games -- reindeer games -- that get played, those are becoming less and less of an issue.

Look to the governance. About two years ago, most of the vendors are OEM. That certainly has turned around, such that these vendors, the big players we're talking about here, are very much providing in-house stacks. That speaks to what Tony and JP have been saying about getting some governance and SAP and getting better middleware and SAP customers. That's why I think this is such a big deal, and, as Tony was saying, why it's so disruptive.

It's not just that they have a fuller stack now, but there is a more complete stack for SAP customers. NetWeaver has been hanging in there. SAP definitely thinks it is middleware, but then why else would there be so many players on the outside, providing integration services for SAP applications running on not NetWeaver

But, back to your question about the smaller players, Dana, it seems like it's now a class society, where you have the big players -- the IBMs, Oracle, SAPs, and now Software AGs of the world -- and then you have the rogue players in these open-source space that are coming up, that have room to play.

We're talking about the Red Hats, the -- I'm blanking on the others here. There are probably three or four software vendors out there that are playing just in the open-source middleware space that has a great player like WSO2. Another one that's really good is MuleSource, although they're kind of limited.

Bifurcated environment

The point is that, when you have this really bifurcated environment, it gives you fewer acquisitions and more competition, and that's what's going to be great for the industry. I don't see this as leading to further consolidation at the top end. It's going to be more activity on the bottom end.

Gardner: Jason Bloomberg, isn't there no small dose of irony that the SOA landscape is being driven by folks trying to do it all? I thought the whole notion of SOA was being able to include more players and more components to interact and interoperate. What's going on?

Bloomberg: That's a important point to bring up. This IDS Scheer announcement really doesn't have anything to do with SOA. That is surprising, in a way, but also consistent with some of the fundamental disconnect we see within Software AG, between the integration folks on one hand and the BPM folks on the other.

There are some people within Software AG, typically the CentraSite team, Miko Matsumura and his strategy team, who really understand the connection between SOA and BPM. But, for the most part, basically the old guard, the German staff, just doesn't see the connection.

This fundamentally confuses the marketplace, because you have the integration-centric SOA

Whoever wrote the press release doesn't even understand that SOA is architecture. It makes you wonder where the disconnect is.

message out of Software AG. You have the metadata-driven CentraSite message that tries to pull it together, but doesn't have a dominant position within the context of the Software AG marketing. Then, you have the BPM folks, who just don't understand that SOA has anything at all to do with BPM.

If you read the 'BPM For Dummies Book' that Software AG put together, for example, they don't even understand that SOA has any connection to BPM. Software AG released a press release a few weeks ago that described SOA as a technology. Whoever wrote the press release doesn't even understand that SOA is architecture. It makes you wonder where the disconnect is.

With the IDS Scheer acquisition, if you read through what Software AG is saying about this, they're not connecting it with their SOA story. This is part of their BPM story. This is a way for them to build their vertical BPM expertise. That's the missing piece.

They have this BPM capability that they got from webMethods, and there is some Fujitsu technology in there as well. Poor Fujitsu, I guess, is the odd one out on this one. Software AG is looking to add some vertical capabilities, but because they're not tying it with the SOA story, they run the risk of continuing to be the outlier player, when it comes time to compete against Oracle and IBM.

They don't understand

Kobielus: Let me butt in a second, because in Forrester we've been discussing this. We don't think that Software AG understands fully who they are acquiring, because they don't really fully understand what IDS Scheer has on the SOA side. They don't understand the BI and CEP stuff.

So, I agree wholeheartedly with what Jason is saying. They're acquiring them just for the BPM, but that really in many ways really understates what IDS Scheer potentially can offer Software AG.

Bloomberg: Yeah, that's a good point. It's worth highlighting that IDS Scheer does have some pretty solid SOA capabilities within the context of their BPM focus.

Now the question is what Software AG will do with that part of the story. Will it get lost in the shuffle or will it really be integrated into the overall SOA stack in a way that enables them to have a better process-driven SOA story?

That's going to be a challenge for them, because that involves some shifting of thinking, not

They're acquiring them just for the BPM, but that really in many ways really understates what IDS Scheer potentially can offer Software AG.

across the whole organization, but within this sort of old guard Software AG folks who have been resistant to this part of the story.

Morgenthal: Just to add a little more fodder, if I haven't lost track of who's who in Software AG, isn't the person who ran this acquisition Dr. Kürpick, if I have that name right. Didn't he come out of SAP, and isn't he more focused on the business process end of things than the SOA end of things?

Bloomberg: Who wants to chime in on that one?

Kobielus: It is Kürpick, but I don't know what his background is.

Morgenthal: I believe he came out of SAP, and I believe his background is on integration and BPM.

Gardner: So, JP, to your point, we seem to have a mixed understanding of whether BPM is the source or a larger infrastructure benefit. I think you were making the point that the BPM could be perhaps a point on the arrow. If you've got your tool embedded, if you've got business process expertise, and you are moving down the stack from the process level, that that could be something that would drag in other aspects of a SOA environment.

Morgenthal: This is funny, because this keeps coming up over and over. Early on, I used to work with BrainStorm Group on their SOA BPM shows, and, at the height, the BPM show got up to like 600 people. I was doing the SOA side of the story in the track.

Driving the business

At the breaks, I would go talk to these people, and the BPM people would all look at me like I was talking another language, and say, "I don't deal with that." These are people who were doing BPM initiatives in their organization, they were like, "That's for the IT guys. I'm the business." So, time and time again, I found out that the BPM people were the ones driving the business.

Now, the number of people who have been attending BPM conferences has been dropping significantly, saying basically that if training went out to the business people, the business people are doing the business analysis. They are using the BPM tools like IDS Scheer more than webMethods, which would be the IT stuff.

At the BPM level, a lot of the initiatives are still, I believe, with the business and hasn't translated down into IT dollars and IT deliverables. That's a big issue now with regard to this acquisition for Software AG. Before, they could only play on the IT side of this shop. They had no story to play with the business. Now, they can go back to all those people who are still doing this at the business initiatives and have a story for them, with a roadmap, for how to bring this into IT. I think that sells well. I think IBM uses that, but I still find IBM’s tools very IT-centric.

Baer: JP, you're right on the mark there. There has always been a huge cultural divide between

The question, then, for the vendors is which vendors can really support that story in a way that doesn’t defeat the purpose by a self-serving software sales pitch.

the business folks, who felt that they own BPM, versus the IT folks, who own the architecture or the technology architecture, which would be SOA. What’s really interesting and what's going to stir up the pot some more -- and this is still on the horizon -- is BPMN 2.0, which is supposed to support direct execution.

When I was over at Oracle a few weeks back, they were talking about their strategy. They were saying, that unless a business process, as you model in BPMN, is transactionally complex, you could theoretically make that model executable and essentially ace out IT. I'm a little cynical about that, but it's going to be an interesting thing that stirs up the pot in coming months.

Bloomberg: It's interesting you mention SOA as technical architecture, because that's a fundamental misconception of what SOA is about. SOA is really more of a style of enterprise architecture that pulls together both business and IT.

But, you're right that a lot of organizations still see SOA as technical architecture, as something distinct from the BPM, and those are the organizations that are failing with SOA. That part of the "SOA is dead" straw man is that misconception of SOA as about technology. That's what’s not working well in many organizations.

On the plus side, there are a number of enterprises that do understand this point, are connecting business process with SOA, and understand really that you need to have a process driven SOA approach to enterprise architecture.

The question, then, for the vendors is which vendors can really support that story in a way that doesn’t defeat the purpose by a self-serving software sales pitch. That's always difficult, because the software sales people are there to sell the software. So you don't buy SOA. You do SOA, and doing SOA includes business process work, as well as technology work.

Telling the story

The prize goes to the vendor who really can tell that story properly. That's difficult for all of them and they're all are struggling with this. That's the story for 2010. Will it be IBM, Oracle, or Software AG who tells an architecture-driven BPM/SOA/enterprise architecture (EA) story in a way that really does help organizations solve their problems, as opposed to just pushing the software and letting customers figure out how to use it.

Gardner: Thanks, Jason. Let me go to Joe McKendrick. Joe, it sounds like something we don't talk about too often is the importance of the sales function, the sales department, and how these things enter the market. It sounds as if the sales department is selling to the business side of the house, and that's how their strategy perhaps lines up.

Or, if they've got another product set that they're going to sell to the technology side of the house, well, then that's how they're going to continue to enter the market, because that's the side where they get the PO.

But, isn’t that self-defeating, when it comes to SOA as an architectural paradigm shift, as we've mentioned here? How do we that? Is there another step that we need in bringing SOA into the market that educates or changes the sales culture so that they don't simply go after the short-term product sale, but look for more strategic sale?

McKendrick: Yeah, Dana, that's a big challenge. You're right. The sales people from the vendors have specific relationships with individuals within companies. They may tend to be IT people on one hand or you may have some folks on the business process side, depending on the types of products, and usually the paths don't cross.

I wonder, too, with SOA. That's been the challenge, as we've been discussing about SOA. It's been confined somewhat to the technical side of the house, perceptually, and the proponents of SOA tend to come from the IT side.

Gardner: I guess what I was getting at, Joe, is that the separation between SOA and products seems to be taking place not just on the buy side. It's probably taking place on the sell side as well, as is demonstrated perhaps by what we're hearing today about the IDS Scheer buy being absorbed by one part of Software AG and not across the board.

McKendrick: Absolutely. You really can’t sell SOA. Theoretically, you don't need to buy any products to start SOA in your organization. It's ludicrous to try to sell SOA, the package itself. That's something that's been discussed for years -- selling SOA in a box. You can sell individual products.

Let’s face it. It's a tough environment, and vendors are on these quarterly cycles. They need to push the product out there, and they'll call it whatever they need to call it to get the product out. Maybe SOA is even diminishing as a sales term. It's cloud nowadays.

Gardner: Jim Kobielus, do you agree that this might be what we're up against? In a down economy, sales people need to sell, and, product-by-product, that's what they're going to go after. At the same time, they do an injustice to this larger architectural shift.

Shifting the focus

Kobielus: Yeah, for sure. What gives me hope on the Software AG-IDS Scheer merger is the fact that what I heard on the briefing is that Software AG realizes they need to shift from a technology and sales driven model towards more of a solution and consulting driven business model. First of all, that's the way that you lock in the customer in terms of a partnership or an ongoing relationship to help the customer optimize their business and chief differentiation in their business.

What I found really the most valuable thing about the briefing on the acquisition that we got from them the other day was IDS Scheer adding significant value to Software AG. Software AG pointed to the business process tools under ARIS. That's a given. They focused even more on the EA modeling capabilities that IDS Scheer has, and even more on the professional services on the vertical solution side and the BPA consulting side -- consulting, consulting, consulting, relationship building, solution marketing.

I think Software AG knows that they need to put the IDS Scheer solution focus first and foremost. In a down economy, that's the way to lock in these premium engagements and these

It's interesting hearing about the BPM and SOA disconnect, and it certainly doesn't surprise me.

ongoing relationships that will be essential for Software AG to differentiate themselves from vendors like IBM, Oracle, and SAP, who have been solution focused for quite some time in the SOA sphere.

Gardner: Tony Baer, we need to wrap up on the Software AG acquisition. Are there any other takeaways that we've missed on this one?

Baer: It's interesting hearing about the BPM and SOA disconnect, and it certainly doesn't surprise me. I totally agree with Jason. The problem is that it's a perception that those business stakeholders view SOA as the technology architecture and, more specifically, business process execution language (BPEL) as that bastardized execution language, which I think is probably a little bit of envy on their part.

I can sort of understand that there is a degree of creative tension within Software AG in terms of understanding the connection between BPM and the SOA.

I very much agree with Jim -- I'm Mr. Agreeable today -- that it really is all about solution sell. I was just up doing consulting yesterday with a vendor in the tools industry and telling them that they have to do more of a solution sell.

That's a really tough nut for vendors to crack, because, as the CEO was telling me, "I agree with you, but our sales guys still have quarterly numbers that they have to meet, and if customers want product, we're not going to say no." That's a tough one.

Gardner: Brad Shimmin, do you agree that the solution sell is a multi-year process, but right now these companies need to get some POs signed? Perhaps that's what at work here in terms of filling in of the cracks with this acquisition?

Pre-sales and post-sales

Shimmin: There is pre-sales and then post-sales, and the post-sales is very separate. You have your services organization, and as everyone has been saying here, that's the key to this IDS Scheer acquisition by Software AG.

Software vendors like IBM, Oracle and SAP, which are solution based, have these well established organizations, but do nothing except go out and say, "You know what? You really need to lead with BPM, and by the way, in order to make BPM work, you need to have this great infrastructure and architecture underneath and that happens to be using our SOA components." Those guys know how to do that.

Software AG, as we said, is going to take some time to get that up to speed. In the meantime, it's all going to be driven by the numbers. You're selling infrastructure, you're selling webMethods' software endpoints to the IT folks, and you're selling ARIS to the business folks. To bring those two together is going to take quite a bit of time.

Baer: I think it's kind of important to look at IDS Scheer's numbers. They've actually flattened out. The SAP market is pretty mature. Within the webMethods space, it's younger, dynamic and growing. That could be a way to give IDS Scheer and ARIS a bit of a jolt, if Software AG can deal with those structural issues.

Gardner: Okay. In the second half of our show, let's take a look at this WOA drive. I was

Everyone thinks this is an attack at Microsoft. I'm looking at it as a Mac user and see a huge hole in the market.

impressed with the Google Chrome OS, not necessarily on its technical merits -- we don't know too much about it yet -- but the idea that Google is willing to go toe-to-toe with Microsoft and sees the marketplace is ready to absorb an OS designed of, for, and by the web.

Does anyone else share my impression that this is a harbinger of a larger shift towards the web?

Shimmin: I just think it's reflective of the shift that's already underway. When you look at Google Chrome OS, it's Linux, which is a well-established OS, but certainly not something you would call a web-oriented OS. Chrome OS is really something akin to GNOME or KDE running on top of it. So, technologically, this is nothing spectacularly new.

I think that what Google is doing, and what is brilliant about what they're doing, is that they're saying, "We are the architectural providers of the web, people who make the pipes go, and make all of you able to get to the places you want to go in the web through our index. We're going to build an OS that's geared toward you folks. We're going OEM and through vendors that are building netbooks, that are definitely making a point of contention with Microsoft. Because Microsoft, as we know, is really not pleased with the netbook vendors, because they can't run Vista or eventually Windows 7."

Gardner: Not only that, but they can't charge the full price that they would have liked to charge for an OS, because these things only sell for $400.

Shimmin: Exactly.

Morgenthal: I have differing opinion, and of course an opportunity to tick off the entire Slashdot audience. Everyone thinks this is an attack at Microsoft. I'm looking at it as a Mac user and see a huge hole in the market. I've got to pay almost $2,000 for a really good high-powered Macintosh today. All they did was take BSD Unix and really soup it up so that your basic user can use it.

Out of the slime

People on the Linux side are like, "Oh, Linux is great now. It's really usable." I've got news for you. It's no way nearly as usable as Windows or the Mac. As far as usability, Linux is still growing out of the proverbial slime.

But, if you take that concept of what Apple did with BSD and you say, "Hmm, I'm going to do that. I'm going to take Linux as my base and I'm going to really soup up the UI. I'm going to make it really oriented around the network, which I already did, and I have a lot of my apps in the Cloud, I don't necessarily need to build everything large scale. I still need to have the ability to do video, tie things in, and make that usable, but I'm also going to be able to sell it on a $400 netbook computer."

Now, you're right down the middle of the entire open market, because people can't stand Windows XP running on these netbooks. As was previously said, you can't yet run Windows 7 yet or Vista. We don't know what Windows 7 is going to look like, as far as usability, and the Mac is costing way too much.

There is a huge home run right through the middle. You just run right up the center and you've

First of all, it's vapor, because this is not going to be released, I think, until the second half of 2010.

got yourself a massive home run. It doesn't have to be about going after the enemy. It's not about hurting the enemy. It's about going after your competitors.

Gardner: If Mac OS stays in the top tier and something like Google Chrome OS comes in, the only other player to suffer is Microsoft. Isn't that who gets squeezed out?

Morgenthal: No, I actually think you're starting a grass-roots effort that could knock Apple out, because Apple's maintained its proprietary nature. If you can deliver the equivalent of an Apple-based set of functionality and the usability of the Mac on a $400 netbook, or a bigger if you want, you hurt Apple. You don't hurt Windows.

Gardner: I appreciate your point, but I think that Apple is okay at the top tier. I think this is more aimed at the bottom of the Windows tier, and the price-sensitive audience, both in the consumer and business spaces. What do you think Jim Kobielus?

Kobielus: I think it is, exactly what you said, Dana. First of all, it's vapor, because this is not going to be released, I think, until the second half of 2010.

Gardner: Yes, second half next year.

Kobielus: And, they haven't announced any real features. They haven't announced any final pricing. It will probably be nil or nothing. There's so much that has yet to be defined here. How long ago was it they introduced Android, and how much adoption does Android have in the mobile space?

Gardner: Well, it's got developer hearts and minds, which is probably important.

"Google hegemony"

Kobielus: Yeah, yeah. People keep expecting the big "Google hegemony" to evolve or to burst out, so everybody keeps latching onto these kinds of announcements as the harbinger of the coming Google hegemony and all components of the distributed internet-work Web 2.0 world. I just don't see that happening.

I think this is exciting. They've got all these kinds of projects going, but none of them has even begun to deliver for Google anything even approximating the revenue share that they get from search-driven advertising.

So, this is interesting, but a lot of Google projects are interesting. Google Fusion Tables are interesting for analytics, but I just can't really generate a big interest in this project, until I see something concrete.

Gardner: Okay. Tony Baer, are you ho-hum on this as well, or do you think that this signals that the OS gets buried underneath that layer that is your Web interface and your ability to coordinate with cloud services level?

Baer: I vote for the ho-hum. I agree with Jim. Their business model has been, so far, throwing

Some may need netbooks. Some may want smartphones. Some, like myself, still deal with regular brick computers. It's just a diversity.

as much mud at the wall as possible and seeing what sticks. To date -- and this is one place where I would actually agree with Steve Ballmer -- they've really been a one-trick pony.

You've got to put this in perspective, The Microsoft Office base is not a growing base. It does indicate, though, that there are many types of alternative clients that are emerging, and I don't think anybody has claimed those emerging clients. So, JP has an interesting point in terms of that. It basically fills the hole that Apple is not trying to fill.

Gardner: What about the iPhone. Doesn't the iPhone fill that hole? It's a low entry at $200 and does a lot of what a PC does.

Baer: Well, iPhone, compared to a computer, is low entry, but its expensive compared to a smartphone.

Shimmin: I am sorry to interrupt you, but Apple has netbook coming out in October too, so they're trying for that market as well.

Baer: I'll grant you that point. The important thing mostly is that it does point to a new diversity of clients. Some may need netbooks. Some may want smartphones. Some, like myself, still deal with regular brick computers. It's just a diversity.

So, I think that's really what Google's move heralds. As to whether Google really actually shoots in the long run, I'm waiting for the evidence.

Gardner: Okay. Jason Bloomberg, how about you, a ho-hum or a shift?

Mostly irrelevant

Bloomberg: At ZapThink, we're focused on the enterprise. We talk primarily to enterprise architects who are really trying to figure out the big picture of how enterprise IT resources can meet the ongoing changing business needs. From that perspective, Google is mostly irrelevant. So, I'm definitely in the ho-hum category.

Sure, maybe they will carve out a niche in the netbook OS market, but from the perspective of the enterprise, that's a very small piece of what they're worried about.

Gardner: Let me go to Joe McKendrick. Joe, does what Google has brought to the table have an impact on the enterprise?

McKendrick: Eventually it does. The Google Chrome OS is kind of a marker on the road. I think back to why I started using Google several years ago, and I think why a lot of people started using it. It was so fast. I used AltaVista, Yahoo, Lycos, and all these other search engines, and I just liked Google, because it was real fast. It got me to where I was going in a very fast and efficient manner.

I don't know about Chrome delivering this capacity, but I think what's happening is that the OS is becoming more something that's getting in the way of where you want to go.

I use XP and Vista both. I'd rather just get on the computer and get immediately to where I want

Why can't everyone have a client computer, a device that simply has some kind of very thin OS and the browser connecting them to all the cloud services they need?

to go on the Web and not have to fuss around with all these features with the OS - booting up, security features, updates, patches, and so forth.

I think the world is moving that way. Why can't everyone have a client computer, a device that simply has some kind of very thin OS and the browser connecting them to all the cloud services they need?

That's what's great about smartphone. I love the smartphone because it just goes to where you need to go very rapidly. You're not fussing with the OS. It's more of an embedded, invisible, thin capability, and that's what enterprises are looking for as well.

Gardner: JP, we talked about OEM agreements and how important they are behind the scenes in the technology industry. The OEM agreements that Microsoft has with their hardware vendors are perhaps seeing some strain.

Microsoft didn't do any favors for their hardware vendors with the debacle that Vista was, particularly as that came during the precious year or two before this recession. That could have driven a lot of sales that now will probably never happen.

Do you think that Google, not only has an opportunity to come into the market, as you mentioned, with a technology, but perhaps is going to be a friend of the enemy for these hardware people. They'll probably give this thing away and allow these hardware developers, distributors and creators to benefit from the services marketplace of advertising in a sort of backhanded way, and they get basically free software from Google as a result?

Who'll win the desktop?

Morgenthal: For them, it comes down to who is going to win with the desktop applications. That's what it comes down to. The only reason these hardware vendors are making the investment in Microsoft is because customers want a Microsoft platform, most likely because they are running Office or some other Microsoft application. It's what they're trained on and still comfortable with.

There's a great video out there that Google did asking people on the street, like a Jay Leno walk by, what is a browser? About 92 percent of people didn't even know what the browser was. They're like, "The browser is Google. Yeah, I go to Google." They don't understand it's an application that renders HTML. They don't know that. They have no clue.

It's very easy in this day and age, we get on a phone, we talk, and we know the stuff inside and out. You've got to realize that 92 percent of people out there don't get it. It's easy for Microsoft to go put up a video that shows how great Vista is and how people were snookered into, "Wow, that's the next version of the OS. Look how cool it is. No, it's really Vista." Of those 92 percent of people, you don't think at least 50 percent of those are still going to come in and say, "I want a Vista machine," after seeing that? Of course they are. That's why the hardware vendors don't have a choice.

Microsoft doesn't have to worry. Yes, they want to make good friends with these people, but

I don't know what Google really wants. Basically . . . they're going to throw as much mud against the wall and see what sticks.

ultimately it's the consumers who are coming in and saying, "I want this type of machine, I don't trust that Linux stuff. I don't know anything about that. I don't want to go there. I was told if I go there, I'd better know how to actually get to a command line and work." That's what they still hear.

Gardner: Tony Baer, JP says that the hardware people don't have a choice. Does Google want to give them a choice?

Baer: I don't know what Google really wants. Basically, as Jason and I were saying, they're going to throw as much mud against the wall and see what sticks. I like Jim's metaphor on them being the Xerox PARC for Web 2.0.

If Google were serious, in other words, if they really did have a more of a strategic business plan for this, I would say yes. But, as long as it's just, "Let's just throw something else out there, and by the way, this is not going to come for another 12-18 months," I have a hard time taking this seriously.

Gardner: Brad Shimmin, suppose I'm HP, Dell, or I'm Acer, and I need to sell these $400 netbooks, because that's my only growth area right now and might be for the next two years, before these corporate budgets start growing again. I could sell that thing for $400. Microsoft is going to take $150-200 just for the OS, and Google wants to give a free OS. What am I going to do?

Let the user decide

Shimmin: I would have both of them on there, and let the users make a choice. I'm still thinking about the price tag.

Gardner: For the Microsoft OS.

Shimmin: That's what I'm saying. They want to make a buck and they'll do it the best way they can. If they're getting it free from Google, they'll put it on there as a option, but they'll still pay homage to Microsoft, because, as we've been saying, it has to be. They still have ownership of the desktop.

In my mind, the curious thing about all this is that what's made the iPhone and the BlackBerry so successful is that they're self-contained machines. The OS and the hardware are very tightly controlled and very tightly integrated. What's made the PC and the Windows OS such a pain and so detrimental to productivity is that it's very much the opposite of that.

The Mac -- and I'm a Mac user too by the way -- is that it makes us more productive. The OS

The Mac . . . makes us more productive. The OS doesn't get in the way of the Internet. It actually makes the Internet better.

doesn't get in the way of the Internet. It actually makes the Internet better. It's because it's a controlled environment, but it's really expensive to do the things that way as a company, due to costs in manufacturing.

If Google Chrome is going to go out there the way Android has gone out there, which is, "Let's look for some OEM vendors to make this work and it's going to be based on Linux," I don't ever see it actually doing what the BlackBerry and the iPhone have done in terms of making the 'net better.

I think that it's going to be for those Slashdot folks, who really like that kind of thing and want to make it go. I see this taking a lot longer for the white label stuff to really make things work as well as the closed environments have.

Gardner: Well, I'm afraid we will have to leave it there. I appreciate everyone's input.

We've been talking about the acquisition by Software AG of IDS Scheer, and also the possible impact that the Google Chrome OS could have in the market. It seems most of our people think, that's not such a big deal.

I also want to take this opportunity to thank our sponsors for the BriefingsDirect Analyst Insights Edition Podcast Series; they are Active Endpoints and TIBCO Software.

I also want to thank this week's panelists, Jim Kobielus, senior analyst at Forrester Research. Thanks, Jim.

Kobielus: Always a pleasure.

Gardner: How about a little excitement there, Jim?

Kobielus: I am still overstimulated. That's a redundant statement.

Gardner: Are you overstimulated too Tony Baer, senior analyst at Ovum?

Baer: I really love these podcasts, Dana.

Gardner: Nicely done. Brad Shimmin, principal analyst at Current Analysis.

Shimmin: Still here, and not even caffeinated.

Gardner: Jason Bloomberg, managing partner at ZapThink, thanks for joining.

Bloomberg: Come to our new SOA and Cloud Governance course.

Gardner: Excellent. JP Morgenthal, independent analyst and IT consultant. What plug do you have for us JP?

Morgenthal: Until next time.

Gardner: Joe McKendrick, independent analyst and ZDNet and other web property blogger extraordinaire in SOA and BI and all sorts of things, right?

Morgenthal: Call me Joe "not a slave to fashion" McKendrick.

Gardner: Thanks very much. This is Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening and come back next time.

Download the transcript. Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 44 on Software AG's acquisition of IDS Scheer and the implications of the Google Chrome operating system. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

Take the BriefingsDirect middleware/ESB survey now.


SPECIAL PARTNER OFFER

SOA and EA Training, Certification,
and Networking Events

In need of vendor-neutral, architect-level SOA and EA training? ZapThink's Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.

Advanced SOA architects might want to enroll in ZapThink's SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.

Wednesday, October 03, 2007

Analysts Debate IT Management and Monitoring Needs for the SOA Era

Edited transcript of SOA management trends and analysis discussion with Interarbor Solution's Dana Gardner and ZapThink's Jason Bloomberg, recorded before a live audience at the Harvard Club of Boston on Sept.14, 2007.

Listen to the podcast here. Sponsor: Tidal Software.

Welcome to a special BriefingsDirect presentation, an IT industry analyst panel podcast created before a live audience at the Harvard Club of Boston. Our sponsored discussion centers on the role of management on Service Oriented Architecture (SOA) use and operations.

Our panelists consist of Jason Bloomberg, managing partner and senior analyst at ZapThink, and Dana Gardner, president and principal analyst at Interarbor Solutions. Moderating the discussion is Martin Milani, chief technology officer at Tidal Software. The in-depth presentations from the analysts are followed by questions from the live audience.

Listen as these SOA experts explore how IT management will evolve in the world of service-based applications. They delve into issues of new standards, how SOA demands that performance management and change management augment and elevate the role of systems management, and how the integrity of services delivery requires a deep and wide approach to management in total across a services lifecycle.

Now, let's hear from our moderator, Tidal Software's CTO Martin Milani.

Martin Milani: Thank you. I guess it's no secret to anyone that SOA has finally arrived, and that SOA deployments are increasing rapidly -- and far more mission critically -- in the past couple of years. It's one of the fastest-growing segments of the software industry as a whole.

So, with that I want to see if the analysts could share some of your thoughts on the industry, and then some of the challenges with SOA in general. Jason?

Jason Bloomberg: Well, thanks a lot, Martin. It’s great to be here. I’d like to start with the definition of SOA for a level-set. SOA is essentially an approach to organizing IT resources to better meet the changing needs of the business. Fundamentally, it’s an architectural approach, a set of best practices, for leveraging IT in a flexible way.

The core business motivation for SOA in most organizations is business agility, to be able to respond to changing business requirements and to leverage change for competitive advantage as well. As a result, one of the key challenges, if you are looking to architect your IT organization in terms of flexible services to meet this business agility benefit, is being able to create, manage and evolve these services over time.

One of the core challenges we’ll be talking about today is loose coupling, where you want to build services that you can control and manage independently of the consumers of those services. That’s a key part of the business agility benefit of SOA. That’s how you would actually achieve business agility in practice.

In turn, the way you achieve loose coupling is through management, and that’s something we’ll be talking about as well. Management then becomes the critical enabler for loose coupling, which is the critical enabler for business agility. That’s how it all fits together.

Milani: Dana?

Dana Gardner: Thanks Martin, and thanks to Tidal Software. I agree with Jason. I think also that SOA has some catalytic implications for companies that begin a journey toward this architecture. It can foster change, and perhaps also benefit agility, but if they have not done their homework, if they are an organization that’s very much in silos, both in technology as well as practices, there could be a lot of risk involved.

There's going to be a period of time, where people look at SOA and find that the opportunities are going to depend on how they’ve done their preparation. We've had a lot of work toward service enablement of data, cleansing data, and putting it into a form in which it can be delivered across multiple applications and processes.

We’ve seen companies begin their journey toward better integration that’s open, that fosters interoperability, and we’ve seen management, but mostly on the level of "speeds and feeds," of how to make sure that the trains run on time, when it comes to delivery of data, whether transactions are going to be fulfilled in a timely manner and if application performance is maintained.

But management for SOA needs to go a step further and take into consideration many systems and interdependencies -- perhaps involving services coming from outside the organizational boundaries, be it partners across the supply chain, even hosting organizations and commercial-services providers.

So management is going to be, as a topic, very important to SOA in a traditional sense, but also management in a new sense. If SOA benefits technology, as well as the business goals and objectives and agility, then business management, IT management, and SOA management need to have some commonality.

Relying on individual people -- "wetware," if you will -- to bind these together and to hand off one to another isn’t going to scale. It’s going to be expensive. So I'm hoping that management is propelled through SOA into a more advanced concept that bridges a gap between organizational management, IT systems management, and the management of services themselves.

Milani: It sounds like SOA is affecting the application assistance management landscape as we know it. Would you agree with that?

Bloomberg: It definitely is. The key thing to keep in mind about SOA in this context is that services are an abstraction. That is, they help to provide flexibility to the business, but they don’t actually simplify the underlying technology. Many architects are a bit surprised by this, that SOA doesn't make their jobs easier or make the job of IT any easier. If anything, it’s more complex. There's more of a challenge for IT to meet the business requirements for flexible, agile, composable, and loosely coupled services. As a result, you have this need for the IT organization to rise to the challenge of services.

This is especially true in the management area because the services essentially have to behave as advertised. These are contracted interfaces to various application functionality of data across the organization. They have to do what they're supposed to do.

That's the core of the loose coupling. So, any consumer can come along and leverage a service, and it does what it is supposed to do. If there is a problem with the service, then it’s not loosely coupled. The core challenge is essentially saying, "Well, we want to make sure these services do what they're supposed to do." That’s fundamentally a management challenge.

Gardner: The performance of applications has been problematic, particularly the transition from mainframe to client-server and then to the Web. Waiting for an application performance issue to crop up and then chasing down the core problem has unfortunately been the norm. I'm not sure that that’s going to continue to be possible.

It’s never been the preferred way -- firefighting as the means to application performance. When you take this to the step of decoupled applications or services, you recognize that so many different systems are now supporting processes. It's not just a single model of a stack of support and platform beneath a specific application. You need to start working toward a predictive, analytical approach to the management of performance.

The implications for those dealing with applications is that you are going to service-enable those applications, decouple, and decompose them into essential core services, and then repurpose them by cross-compositing processes. What is that going to do to you, if you think you are going to go to firefighting mode when you have performance issues? It’s simply not going to work.

You need to rethink management and support, and you need to try to get proactive in how systems will be supported to head off performance issues and create insurance policies against blackouts, brownouts or other snafus. SOA is really a catalyst toward a different approach to the management and support of the services.

Bloomberg: That’s an important point. In the context of SOA, we're thinking in terms of business processes that are implemented by composing services. What’s happening here is that the definition of an application is beginning to shift, especially from the perspective of the business.

The business doesn’t want to think of an application as some big huge piece of software that costs them a lot of money and introduces a lot of risk, that doesn’t directly meet business needs, that’s not what they are asking for, but is what they’ve had to buy because it's what was available.

In the context of SOA, though, an application is what you do with the services. You compose them into composite applications or service-oriented business applications that implement processes in a flexible way to meet the needs of the business as they continue to evolve.

From the business perspective, this notion of application is whatever you are applying the services to. The root word of "application" is to apply something, and, as a result, the management challenge, especially the application management challenge, in particular, is an entirely different set of challenges.

It’s not saying, "Well I have this big enterprise application, which is some monolithic suite. I need to manage that." If you have those, you still need to manage those. So, that’s not going away, but SOA introduces this whole new concept of flexible, composable business process-based applications, which now have to be managed as compositions of services.

Services are obstructing functionality across various systems and various applications, and the management challenge becomes immensely more complex. If anything stops working, then the whole thing falls apart. Management now becomes even more important. You can’t just have a firefighting approach, and when there's a problem, you send an alert to the poor systems administrator, who has to wake up in the middle of the night to fix it. That just not going to cut it anymore.

Gardner: One more factor in this is that we are not just talking about SOA in a vacuum. We're not just moving toward SOA or services-enablement. We are also dealing with application modernization, pulling them off older more expensive platforms and putting them on standards-based or commodity platforms. We're talking about virtualization where we are going to create containers and try to get higher utilization and efficiency rates off of our underlying investment for the support of these services.

We're talking also about business continuity issues where we are going to try to have replication of services in the event of disruptions, be it natural disasters or otherwise.

So when you think about SOA, it’s happening at a time when there are many other IT mega trends under way, and the management needs to be considered within that context as well.

Milani: Obviously, SOA is a disruptive event. There is a radical change in the architecture of the applications, as we know them. There are far more points of failure, far more pieces of the application that could reside across separate systems, separate technologies and perhaps across enterprise silos.

So the traditional management approach has been used for the past 15-20 years, and is very client-server centric. Can these traditional monitoring and management approaches handle the SOA deployments of today and tomorrow? Dana?

Gardner: You're not going to throw out the baby with the bath water. You're going to continue to leverage your previous investments. Just as we’ve seen with storage and application deployment strategies, it’s about elevating to a higher abstraction -- perhaps through metadata, perhaps through standards -- so that you can increase outputs qualitatively and quantitatively from your systems.

Therefore, you can offer a management overview, whether it’s a dashboard, or even the equivalent of screen scraping one management view with another. At least, you can assimilate them in a such way that you can start to get a total view, a comprehensive view of systems.

I do think that you are going to continue to leverage existing management approaches. I'm sure that the older-line management vendors are going to continue to augment and support more advanced processes or more complex interactions between elements of infrastructure and applications.

It needs to be looked at not just as management of discrete parts, not just trees within the forest that each stand on their own -- but the forest itself. I'd like to see that get to the point where it becomes something that can be assimilated further than just the systems -- with the business objectives as well.

Furthermore, one of the things that’s been unfortunate about systems management up until now is that it tends to be binary -- on or off, green- or red-light, it’s working or not working. SOA is going to require more of a blended approach to management.

That is to say, you are going to want to tune how your applications and services are delivered, perhaps to live up to service level agreements, or perhaps so that you can give priority to certain data, application, or services streams over others. You're going want to be able to fine tune, rather than just throw a switch on or off. That’s going to require a different level of management. It’s really about leveraging the old, finding ways to assimilate and then put a more operator- or policy-driven -- perhaps even automated -- approach on top of it.

Bloomberg: It's interesting that you say SOA is disruptive, because SOA is disruptive -- but not in the way you might think. It’s not really that disruptive on the technology side. In fact, from the technology perspective, SOA helps leverage existing technologies. It has a heterogeneity story that says, "Well, you don’t have to replace. You can leave and abstract as needed."

So, if SOA is architected properly, it doesn’t have to be disruptive on the technology side, but it is most definitely disruptive on the organizational and political-cultural side, on the human side, because what SOA tells the IT shop in particular, is that we can’t do business as usual.

We can’t simply have a siloed approach -- here are the operations people that run this, here are the Windows people that do this, here are the application people that do this. That’s not going to work anymore. In order to think about services properly and to get the benefit of SOA at all, you have to think in a more cross-functional, comprehensive, architected, best-practices way about how IT does what it's supposed to do. How IT is going to meet with the needs of the business is shifting in a broad way, and that’s how SOA is disruptive.

When it comes time to think about management at all levels -- whether it’s networks, systems, application management or the business service management -- these are being reworked, because you can’t think of any of them in the narrow silo.

It’s like saying, "Well, I have this application; I have to manage this application. I have my TCP/IP network; I have to manage the network." You still have those technologies and you still have to manage them, but now we also have this whole notion of services cutting across different parts of the IT shop, meeting different needs of different parts of the business.

A single service might abstract multiple databases, multiple underlying applications, and multiple platforms. That same service might serve multiple lines of business and might serve the needs of internal as well as external users. So, in that context, what it means to do management is being entirely disrupted by the service-oriented approach.

Milani: Traditionally, the way people have looked at the Web services in SOA management today, has been to manage or monitor the interfaces, which are actually an interface to a runtime environment that holds some sort of service.

What do you think is required to deeply understand how to monitor these services beyond what the interfaces are doing, and finding out what’s under the tip of the iceberg? Dana?

Gardner: Well, with SOA you need to gather information about your systems both deeply and broadly: deep and wide. You can already get a fire-hose of data from your systems, log files, and agent- and agentless-based approaches already on the market. You get a ton of data.

It’s working with that data in the context of a horizontal business process that’s the hard part. The type of applications that we’re going to be seeing in the future, as Jason mentioned, cutting across different aspects of the organization, are going to require redundancy. If one aspect of a process goes down, that’s the weak link in that chain, the whole chain could be at disadvantage.

In the past, you might have one application down, but people could go off and do another task, because that mainframe would be backup at two o’clock. You can live with that. If your entire supply chain is disabled for a period of time, that’s a higher price to be paid. So, we're looking at a different level, and I don’t think we’ve seen the solution yet.

Bloomberg: It’s important to note that in the context of SOA, monitoring is just not good enough anymore. It’s not good enough to simply say, "We need to find out when we have a problem." It’s like, "Great, okay, now we know that Titanic has sunk." That’s not going to do it for you. You need to have preventative and corrective management. For a service to be loosely coupled, it has to behave the way it’s supposed to behave, regardless of what’s going on beneath the cover.

So it’s not good enough simply to say, "My management tool is telling me my service is down." You need to have a way of understanding that problems are brewing, that they are in the works. You have to be able to identify a potential problem before it actually impacts the behavior of the service and you need to take corrective action, ideally before the consumers of the service are impacted.

This is a high bar to set, an enormous challenge, and it’s not likely anybody is going to be able to do this perfectly. There is nothing perfect in this world and there will always be instances where there are some problems that a preventative, active management tool won’t be able to catch, but it’s critical for the architect to plan for this level of management, preventative corrective management.

That’s something the architect has to think of ahead of time, when they plan how they are going to build and implement those services. You can’t let it go for later. It’s not like you say, "We're going to launch our software and then let operations deal with management." There has to be something that’s part of your initial thinking when you are putting together the plan for your SOA.

Gardner: Fortunately, the way we’ve seen SOA evolve in the marketplace has been more on the crawl, walk, run basis. People aren't going out there saying, "We're going to switch over to SOA on Monday and all systems will be services." That’s just not the way.

There is an opportunity to learn as you go to encounter problems and then to put into place the management feedback and create the feedback loop into the remediation. Another important aspect of this is to start finding commonality between pre-production and post-production when it comes to applications and services development.

We're beginning to see some products in the market that try to take data that’s collected in the development phase and make it available to post-production to start feeding a loop of communication. So, when something is amiss in production, you can not only look to what is at issue in the systems and operation, but also look to how could we make this service or application better. So, the requirements for service and application are being impacted by operations.

For a long time, there was a significant wall between these facets of IT. It’s still very problematic, but if we can create a management feedback loop, so that -- as we get into faster iterations of development, when the test-debug cycle and build cycle is faster due to agile and lean practices -- we can start saying, "Let’s find out what’s going on in the field when something is wrong."

Do we just throw more hardware at it? Do we just add more servers? Or, do we say, "Can we actually design and engineer the service to be better," and then make that happen with a matter of weeks or months?

Milani: It sounds like the playing field again is far more complicated and complex with SOA, and is going to get more complicated from here on. You have business processes that go across multiple technology silos, multiple enterprise silos, and probably to other enterprises. So, you have different constituents, different organizations, different groups, and many different types of technologies.

This area was pretty hard to monitor and manage in even a simple three-tier architecture. Now, you have an N-tier architecture which you could almost call an "N-to-the-N-tier" architecture. Now, you have different types of services that you could be calling on, depending on the quality of service and security, trust and policy, and so on. So, it’s a different game. If you were to fast-forward five years or seven years, what do you think monitoring a management system, which could address all the issues we just talked about, would look like?

Bloomberg: It’s important to understand that management is not a practice in isolation. It’s really part of a family of capabilities that includes governance and quality, as well. You mentioned policy, security, and a variety of issues. All these are part of the SOA infrastructure story. So, to answer the question where things are going over the next several years, it’s really maturing the family of SOA infrastructure capabilities, broadly speaking.

We like to call that the governance quality management, or GQM, suite, which handles design time as well as runtime issues, creation and communication of policies in the context of governance, management in the context of runtime. It's not just thinking of runtime, in and of itself, because runtime is only part of the story. We have the full lifecycle now with design time creation of services, as well as publication and discovery of services.

The runtime part, which is the current focus of management, as well as the change time part, where you reconfigure and recompose services essentially in runtime context without any underlying co-changes, that’s where we see a lot of the activity going on in a mature SOA environment, is at that change-time configuration, composition level. So more and more of what has to happen there, from the infrastructure perspective, is this pulling together of the quality management in governance roles into full lifecycle quality management governance suite and that’s what we see happening already today, with a lot of the products in the space.

Gardner: In five to seven years, we're going to continue to see an increase in the pressure on businesses to adapt in markets. We’ve got globalization well under way and it’s going to continue. We have lower barriers of entry to companies, where digital assets are made available. We are going much more from bricks to clicks. Therefore, companies need to adapt readily and they can’t go to their IT departments and say, “We need to change; how long will it take?” They need to say, “Here’s the change; implement it.”

Let’s take an example of something from recent business history. Let’s say you’re a manufacturer of toys and you're told that a portion of these toys are now in the field with toxic paint that is an violation of the regulations in your country. You need to take quick action. You need to find out through your supply chain where the problem is. You need to find new suppliers. You need to go back out to the field and conduct a recall, and coordinate this with your marketing and your PR department and your investor relations department, so that you don’t lose the entire value of your company overnight.

How are you going to do this? You might do this through your IT systems. So you’re going to need to examine what’s going on in your supply chain and find out where the problem is and stop it. You’re going to say, “We don’t want to just keep the trains running on time. We want to pick up the tracks and move them somewhere else.”

IT is going to have a great opportunity to become far more valuable to their parent organizations, to be the real partnership that they should be, through the exploitation of SOA and through the proper management of IT and processes.

To answer your question: The value of IT here can be much greater. It can be an enabler, not a cost center. It can be the way in which not only is information relayed about what’s going on, but can determine what we want to happen. We want to change that supply chain. We want to change that distribution, recall these products, get a list of every single product and every serial number, and we want to relay that to our sales force.

That sounds straightforward, but if you try to do that with a lot of IT systems today, you’re going to find yourself up there with the equivalent of mimeograph and crayons, doing it by hand -- and that’s just not acceptable. So in the future, a company’s very existence could be at stake if they don’t have agility in these processes.

Bloomberg: This is a really important point. SOA is really not optional. Companies that don’t get this right will suffer the consequences. They will suffer lawsuits and suffer a competitive disadvantage. They are going to go out of business. This is an important thing to keep in mind. IT is not playing around here. You can't say, "Maybe we will do SOA, if we can figure it out, or maybe we won’t. We’ll just do things the old way, where we are siloed and we keep on going."

If you keep doing things the old way, you are going to lose out one way or the other, whether it’s some sort of regulatory or competitive pressures, some disaster like lead paint, or credit card numbers getting out on the Internet. Whatever the problem is, it’s going to happen, and you have to be prepared. Organizations that don’t get this right are not going to survive.

Milani: SOA, again, is very business-driven. One could say it’s totally business-driven. It gives business agility and adaptability. Often people call it agile enterprise, real time enterprise. Inherently, SOA means real time integration across separate applications and separate technologies.

Something we touched on a little earlier was preventative automation and correction. Can you guys elaborate on that a little bit, why it’s very important. If you’re talking about an agile, active enterprise or real-time enterprise, then that automatically means that the management cannot be reactive and the management cannot be an afterthought. Dana?

Gardner: I recently read a book on SOA that I found very useful. Dr. Paul Brown is the author, and it’s called, Succeeding with SOA: Realizing Business Value Through Total Architecture. A lot of the book has to do with this concept of "Total Architecture."

It’s the architecture of the business and the architecture of IT having some relationship to one another. We can borrow from this concept and say that this should be a "total management" approach as well, so that we have this ability to manage processes and infiltrate the systems in such a way that it becomes a two-way street.

Preemption is really about latency. You can be reactive, if you can do it in a nanosecond. But, preemptive means that you’re going to come to a time where the lights are blinking and there is something wrong, and, before you’re totally out of business or some process is brought to its knees, you want to take remediation. It’s really about balancing the latency of reaction toward a point of preemption. That's very hard to do, however.

When we have system redundancy, we have all this log data. There are probabilistic approaches. There is looking at performance states that are normal, when you compare that over time, but when we get into this area, there are many unknowns, many more variables across the supply chain. When we are dealing with services that are coming from organizations that you don’t have authority or control over, it’s going to be a difficult approach.

I don’t have a quick answer to it. I do think that the latency issue needs to be addressed -- the amount of information that's shared. As we get toward this concept of total management, we need to bring in what incentives are being applied to people and systems.

Are we going to pay for systems based on a steady stream, are we going to start putting in incentives that penalize people for down performance, while paying them higher prices for greater performance? As we see services that are acquired on a subscription basis or a pay-as-you-drink basis, we are also going to start seeing a lot more monetized incentives around performance.

So whether the systems react or not, the price could be so high that you’re going to have to make the investments. I think economics and the concept of total management need to be brought to this.

Bloomberg: There is no magic wand here. Systems aren’t perfect. Software is never a 100 percent bug free, computers are never 100 percent operational, and networks are never up 100 percent of the time. There are always problems. There are problems on the business side as well. Secrets sometimes do get out, and products sometimes are defective and whatever it is, there are always problems. This is just the way of the world, the reality of life on earth.

How do businesses deals with this traditionally? Well, you hope there aren’t any problems, and you have certain plans in place, but fundamentally, when there are problems, you step away from your technology and you deal with it however the people can deal with it. So, you run around and try to fix the problem.

We are looking at SOA, saying, "We can do a bit better with our technology in terms of dealing with the reality that there will be problems." As far as agility, we want to be able to respond to change, including changes we don’t want. That include problems with systems, with the business, with regulation, competition, or global disasters -- whatever it is.

Instead of just saying, "We can’t rely upon our technology, when problems come along," we want to say, "Yes, we have a more flexible way of dealing with problems, even though we can’t predict what they are.” That’s part of the benefit of SOA, part of the agility benefit. We are dealing with unexpected change, including various problems.

Instead of just running around and not being able to use technology, we want to have a governance plan in place, saying “This is how we’re dealing with problems. Here is how the technology will rise to these challenges." And, we make it a matter of policy. So now, instead of just having to wing it when you have some sort of issue, there is an infrastructure in place for helping you deal with issues as they come about.

A key to this is the management challenge. As management technology improves, it is less and less about just monitoring stuff, and more and more about being able to deal with issues as a matter of policy, where your policy is in place for dealing with problems that you can’t predict -- and those are the most challenging ones. That’s what we see happening over time.

Technology is getting better at dealing with these unpredictable situations. A core part of what we need from agile IT is being able to deal with the unpredictable.

Milani: Great point. It dovetails to my next point, which is businesses are moving to standard policies and standard practices in the form of a business process. More and more, they are moving the way they do business into a well-defined practice of business processes. So, using technology such as BPEL and business process management systems, why wouldn’t the management of some of these technology and software resources look like how processes are handled on the business side of the equation?

Bloomberg: Actually, they might be. You want to think about business process in the context of whatever the business does, and that applies to IT as well as it does to the business. IT should be run as a business, as part of the business. So, it’s not like IT is some different world. It’s just part of the business, one of many divisions, and it has a certain role within the context of the business.

Management, to the business side, means a whole range of things, of which technology is only a portion. It means making sure that you have a management hierarchy within the organization. It means that your business is running properly and that the business process is running properly. All of this is part of what the business means by management.

Part of that is IT enabled and part of that is specifically IT centric, but from the business perspective, it’s not like they are drawing a line and saying, "This is the stuff we mean by management in the business context, and this is the stuff we mean by management in IT context," as though they were different things. There is a spectrum, and as we move to SOA, we’re seeing that IT is becoming more of an enabler of the business in many more flexible ways. So, the term "management" now becomes much more of a business-centric context, of which IT is now an enabler, as opposed to two different kinds of management, one for the business and one for IT.

Gardner: If you could meaningfully and successfully divorce IT from the organization, you would have seen a lot more outsourcing. Companies tried to outsource lots of aspects of their IT. Some are successful, but in many cases it was brought back in.

IT and business are intrinsically bound. It’s a competitive differentiator: The way in which you do IT better than your competitors. I don’t think we’re going to see a divorce here. We’re going to see more assimilation. But the management of IT is relatively new, compared to the practice of business management.

The modern corporation is over 100 years old. Mercantile economic activities are 600 years old. You can find other aspects even older than that as to how people are governed and operate as teams or individuals.

If we have things like Balance Scorecard, Six Sigma, Design for Manufacturability, Simultaneous Engineering -- these concept have evolved on the business side, and on the manufacturing side. We should expect to see the same aspects for IT, and perhaps have the same overview of a Balanced Scorecard on how the business is operating, as well as how the IT is operating -- someday, maybe even together.

What we're really talking about here is the maturation and the natural process for IT to become more like business, and not be off in its own corner. It takes time. These were complex things that happened very, very quickly. We used to call it Internet Time. It’s probably, in some respects, even faster now, when you think about Enterprise 2.0 Time.

These IT systems have evolved so quickly, and companies have implemented them in such a haphazard way with lots of different heterogeneity involved, that it’s natural that it’s going to take time. Ultimately, we're going to get to a maturation where IT catches up to the business. Then they can be governed very similarly.

Milani: Are there any standards required sooner than later? Is there any specific standard that you think can enable the deployment of these SOA environments?

Bloomberg: There are standards in the works; there is Web Services Distributed Management (WSDM) and WS-Management and a variety of others. There are some that are datacenter centric, others that are more network centric. But, by and large, I agree with Dana that this is still the early days in terms of management standards.

What’s happening in the management standards world is a pissing match between the big vendors. You have the Java guys wanting to this and then Microsoft guys wanting to do that, and nobody listens to them, because they can't agree with each other. So, they'll realize, "Hey, all of our customers are ignoring us. We'd better get our act together." It’s become this big political thing that’s just slowing whole thing down.

From the enterprise perspective, you don’t have to wait around for the vendors to grow up. You can get stuff done today. This isn’t going to stop you from being successful with SOA initiatives today. It might mean that two products you buy off the shelf might not interoperate as well you like. That has to be part of your plan. It might mean you have to come up with your own internal standards for the time being.

Lots of organizations are doing that as well, because the open standards are just not mature enough to do everything you wanted to do. But that doesn’t mean you can’t be successful. Interoperability is part of the story, but a lot of what you need to get SOA to work are other challenges that you can work on. You can get SOA business value.

Gardner: We need to see standards at a higher level. It's not just about systems level, and it’s not just about framework level, like Java or .NET. It’s really at the level of how the people who are responsible for a business process get a view into that entire process.

Ultimately in these organizations, we're not going to have people responsible for a server farm, a database, or an SAP implementation. They're going to be responsible for a order-to-bill capability. For those people to get a view into all of the aspects for which they are responsible, they're going to need a management view at a higher elevation. That’s where standards need to be applied, so that they can get that view, so that there is interoperability, sharing of data, and a canonical view of management.

Milani: We're almost out of time. I want to thank you for your time and quickly ask you if you want to close and sum up what you think people should consider, as they deploy more and more SOA implementations, and what they should consider with respect to management.

Bloomberg: SOA is not just about the technology that you can't buy from a vendor. It’s not something you buy. It’s something you do. It’s a set of best practices that are still relatively loosely defined.

You can be successful with SOA by taking it a step at a time, achieving real business value. You don’t have to set the bar so high that it becomes impossible. But, that being said, even if your SOA initiative is relatively modest and you have a few services in the context of that architecture, management is something that you have to think about very early on. In fact, you need to think about management with services even before you get to SOA.

If you just have a few services and they are not managed, then they could be redundant or they could be incompatible. Worst of all, they could be rogue services, services that are not on the radar of anybody who is running these services. They could expose confidential information or bring systems down. Who knows what the problem is?

A rogue service is one that you just have no idea what sort of damage it can cause. This is a real risk, because, if you’re building a Web service, in particular, it might just run over Port 80. It might just expose information over the firewall, and you have to think about this very early on in your services initiative, even before you get SOA.

As you get SOA, you have to think about all the services you already have and plan for loosely coupled services in the context of your architecture. All of that has to be done in the context of management, as well as governance and quality as well.

Gardner: As companies move closer to SOA, it forces them to grow up. It forces them to think across boundaries. In the past, complexity has forced companies to divvy up issues into small compartments, put a box around them, and assign people to that item of complexity.

But that has stifled the ability of interoperability and of addressing things holistically, of being fleet and agile. It’s made them brittle, has made them slower, and has made things expensive. SOA forces companies to start binding what happens in pre-production to post-production, what happens in an application with what happens in an infrastructure, and what happens on a service level from an outside provider to what happens as a shared service internally.

There are great risks if you try to do SOA without growing up, but there are super opportunities if it’s done properly. It can elevate IT as a function within the organization from being an inhibitor to the absolute enablement for new business and growth and opportunity.

If you’re inside an IT department, if you are a vendor, if you’re a consultant -- consider that if you do the diligence, if you come up some standardization, it’s the methodological approaches that work. SOA will make the company better and will make IT indispensable in the best possible way.

Rod Butters: I want to thank all of you for the discussion. It’s actually ranged all the way from the value of SOA to the business and the kinds of business opportunities that enables how management keys into that and feeds into that from a technology standpoint, and the interesting ideas you shared today about how management ties with the actual SOA architecture to provide agility to the business.

So, with that, thanks very much for this great discussion today and thanks to everyone here who has attended our live debate and discussion on SOA management. At this point, we’re going to open this up for questions.

Question: I'm from Bank of America, and I was really glad the way you guys started to talk about the management top-down approach to addressing the changes that the organization will face. You also talked about agility and business demands and bringing IT management bit closer to the business management side. Business, for all intents and purposes, doesn’t really care what’s underneath the covers, right?

They have a business value proposition, they have business ideas and perhaps a very cool looking interface, if one may just look at the Internet only, a Web 2.0 experience. For them, agility and latency has a lot more meaning than what we are talking about with respect to SOA. With so much organizational change, there’s going to be some time before these things are going to get settled. How do we really achieve agility in terms of business demands and SOA, which is lot more organizationally heavy it seems? That’s one question.

Second, there is one notion of introducing and implementing SOA, which is going to take some time, and we are talking about management needs to get together into a common consensus of implementing SOA in a most efficient fashion. Now again, talking about agility in terms of maintenance and regular changes to the environment, from the business perspective, they want change to be implemented faster.

The owners define pretty much for the entire organization enterprise wide. How does business still achieve agility into their maintenance mode, when they want to make small change to an application which is now going to require a lot more changes on the back-end side?

Bloomberg: You’re quite right; the business doesn’t have visibility into the inner workings of things, but they also don’t want to know. They want SOA stuff to work the way it’s supposed to work. They will have a change. They want it to happen. They don’t want to hear about any problems. They don't want to hear a bunch of tech-speak in response to some request that they have. That’s one of the core challenges of SOA, thinking about services in the context of the business. It’s a role of IT to build and support business services that abstract the underlying technical complexity to provide the business with that flexibility that they need.

If you can achieve this with individual services, then you can achieve this with the compositions of services. You have to build services to be composable. You’re trying to enable the business to build and evolve business processes by composing, recomposing, and reconfiguring services. If you do this right, if you get the architecture and the implementation correct -- it's a big “if” because it’s a challenge -- then you can build big services out of little ones, because you can compose services into composite applications and expose that as a service as well. So, this big exposed composition of services as a service gives you two core things.

One, it’s recursive, if I can build big ones out of little ones. Second, if you were to see some sort of business service, you don’t know if it’s actually abstracting a process or not. So, in telco, you could have a user-provisioning service, where it’s actually in multiple steps. Or, in banking, you could have an open-account service. That might involve six or eight steps, whatever it is. From the business perspective, from the customer prospective, they don’t want to know.

They want to open an account. If they can push a button and the account is open, that’s great. If you can build loose coupling, not only into individual services, but into how you compose services as well, then you’re able to build flexibility into the processes themselves. So, it’s a challenge, but that's the goal -- to build this level of flexibility into the processes, because that gives the business now the ability to have the agility at that business level.

Gardner: If the business side of house wants to have buttons and levers that they can push and pull, then it's up to IT organization to take those inferences and those instructions and then make that into something that changes. It’s a change management function. And, as Jason said, if the processes are composed of individual services, you can rearrange those services, and you could not only rearrange your service within a process, but you can create new services rapidly.

If you have a service that needs to be changed, you don’t necessarily have to rip and replace. You don’t have to shut things down. It’s not a three-year replacement cycle. You can actually recreate that service, make the changes you wanted and then slowly bring that service into production across more processes.

While one of the benefits of SOA/services enablement is reusability, you can also get redundancy. You can create services that are rather similar. You might want to not let anyone be that prolific and write too much, because then you’ve got multiple slices and dices of services. But, it allows for the ability for moving functional sets without having to recreate the entire application.

You’re going to have more iterations, smaller changes within services. You can have services that are similar, and you might well combine them to be a fuller set of requirements within a single service. Then, you can bring that into production across more and more of the organization. It’s just a more flexible approach. You cannot do this when you have brittle applications on a single silo.

Bloomberg: From the business perspective, what you’re saying is exactly right, but, from the business perspective, you can abstract a set of redundant services or revolving services. Think of those that are at a lower level. From the business perspective, they’re all just one service. You have your account-opening service, it’s just the one service, and it works the way it supposed to work.

Behind the scenes, you have redundancy. You have versioning policies. You have management infrastructure. You have all the stuff going on behind the scenes, from the perspective of the business, to get that service to be flexible, so as business requirements change, it does what it’s supposed to do.

From the business perspective, it’s an account-opening service. It opens accounts, and it works for all my lines of business, for all my different kinds of accounts, and it continues to work even if the requirements for that service change. It’s not easy, right? But, you can make it simple for the business by taking these infrastructure and architecture steps within the context of IT.

Question: You talked a lot about the active aspects of SOA management. How is that different from an enterprise service bus (ESB)?

Bloomberg: If you noticed, we didn’t talk about ESBs. Normally, we don't talk about ESBs. We didn’t talk about integration infrastructure at all. We didn’t talk about middleware at all, and that was intentional. When I talk about SOA infrastructure, ESBs are not high in the list. Middleware, in general, is not high in the list. I talk about governance quality and management as the core infrastructure capabilities that SOA requires. From the context of middleware, most organizations already have a lot of middleware. They don’t necessarily need a lot more.

Now, if you’re getting into SOA implementation and you have your architecture, you have your service design, you have your governance, and you’ve thought about governance quality and management, you may find that you need middleware at some point, because whatever middleware you have is not to the task. Then, there may be a requirement for an ESB, or other middleware solution.

But, you don’t want to start there. If you start with the ESB, because some vendor came and said, "Well, to do so you need to buy an ESB," you’re not going to end up with SOA. You’re going to end up with an ESB, actually what the blogosphere is trying to call an ESB-oriented architecture. The point is that if you start with ESB, you end up with something other than SOA. You end up with a traditional middleware-driven architecture with service interfaces.

Now, that being said, there are some perfectly good ESB products on the market, and lot of them offer management capabilities as well. So, when you get to the point of considering what management infrastructure you need, you may turn to an ESB for that capability, but you don’t want to start there. You want to start with the architecture, the business problem, the business processes. Use those two to derive your services. Look at your infrastructure, solve the governance quality management problems, and at that point an ESB might come into the story.

Gardner: ESBs can be very powerful, and, as you are on the journey to SOA activities, integration has been problematic, brittle, expensive, and time consuming. Any productivity benefits that you can bring to integration to me makes sense to me, but an ESB can be more powerful in the management sense, because you can manage the ESB, the way you’ve been further managing your processes or your services or the integration of resources and assets that contribute to the production of your services.

So ESBs do play an important role in management, and we’ll need to see more flexibility and ease of managing ESBs and what they do in applying rules and policies to ESBs. It’s just another important part of the infrastructure.

We’ve had busing and messaging for some time. The idea of trying to make that inclusive of more transport protocols and technologies makes a lot of sense, but how do you manage them? So, again it’s about bringing intelligence from a higher abstraction across more systems. So, I think ESBs will be important, and I think managing ESBs will be important.

Milani: I would add that ESBs are a very powerful piece of this puzzle, and I believe that what they really do today is interconnect multiple types of different systems, and they facilitate and orchestrate the interaction and exchange of data. So, in many ways all they’re doing is exposing existing interfaces, and they facilitate interaction within those interfaces. But, I think what's missing from the ESB picture, from the monitoring and management perspective, is they don’t have deep visibility into the runtime of the interfaces that in fact they are exposing.

So, one piece that you don’t have visibility into is the runtime of those services within ESB, but I do think ESBs will play a major role going forward to marry passive management, which is to manage and monitor what you have, with active management which is constantly "correct and adapt." And I think that’s an area where an ESB could be extremely powerful in the next few years.

Butters: I thank everyone for joining us today. This has been a very enlightening discussion. Again, thank you to our panelists and thank you all for joining us here at the Harvard Club. Have a great day.

Gardner: Thank you.

Bloomberg: Thank you.

Listen to the podcast here. Sponsor: Tidal Software.

Edited transcript of SOA management trends and analysis discussion. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.