Transcript of BriefingsDirect[TM] podcast with Dana Gardner, recorded Sept. 19, 2006.
Listen to the podcast here.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions and you're listening to yet another edition of BriefingsDirect. Today, an overview discussion on calendar interoperability and how open calendars are increasing productivity. Joining us is Scott Mace, editor of Calendar Swamp. Welcome to the show again, Scott.
Scott Mace: Hi, Dana.
Gardner: You are an aficionado and an expert looking into the issues around calendar and calendar interoperability.
Mace: Yes, I have used a whole bunch of them but I’m mostly interested in getting them all to talk to each other.
Gardner: Right. Well, let’s just dive in and talk about a couple of things on a level-set basis happening in the industry, such the pending drop of the final version of Microsoft Office 2007 -- about three four months from now. People are monkeying around with the betas, developers are getting used to what they can do with their tool set and Office 2007 and the burgeoning chorus of Microsoft Live products. Why don’t you give us a quick overview and a catch-up on the Microsoft stuff?
Mace: Well, Microsoft has made progress on iCalendar support, which will be very useful for getting the information in and out of Office 2007. As you know, the current version of Office hasn’t always been very friendly as far as getting your calendar data out to some other format. So, this support is going to be very solid.
The only challenge facing Microsoft is that the bar is moving. It has not stayed still while they have been finishing Office 2007. The new standard to watch is called CalDAV, which is an iCalendar extension that kind of makes iCalendar into a more of a service -- a Web service, if you will. And it’s easier to publish and subscribe to, as opposed to just import and export.
Gardner: What do you mean by publish and subscribe? How does that relate to interoperability in calendars?
Mace: The same way that you can subscribe to an RSS feed today -- such as this podcast -- you will soon be able to subscribe to a particular calendar. There is a mechanism to do this in iCalendar but it’s often not fully integrated, and so what you end up with is that you pull down an iCalendar file and it comes to you as a file. You don’t have a sense of flow.
If a new event is added, you might have to go pull it down again. In a way, CalDAV makes it a more "pushy" kind of phenomenon. It’s a way of more fully automating and integrating the flow of calendar information back and forth, especially when we start talking about specialized extensions like free-busy information. CalDAV is really the cutting-edge, and we are seeing that become a focus of great interest.
Gardner: Who is behind this particular standard? Is this a neutral third-party body? How does this standard become ushered into the mainstream?
Mace: The group that’s championing it is called the Calendaring and Scheduling Consortium, or CalConnect for short. Dave Thewlis is the executive director. I recently interviewed him at my Opening Move podcast over at www.gigavox.com, and there you have a variety of interesting participants. Most recently, Apple Computer joined CalConnect and announced that their Leopard server would include a full implementation -- in open source -- of CalDAV. So, they are promising to do an iCal server that will be open source that will support CalDAV fully.
Gardner: Just for the edification of our listeners, Leopard is the next version of the OS X Macintosh operating system that’s due, I believe, in April of 2007.
Mace: That sounds right.
Gardner: As an OS X user myself, I am somewhat familiar with calendar subscription and publishing. In fact, my wife and I trade calendars; I can see her calendar and she can see mine, because we both subscribe to each other’s. We can also get the Red Sox calendar, which you know has game times, which is kind of neat -- and also U.S. holidays, which get embedded into your calendar. So, there is some of this already going on. Now, what’s going on within OS X in this calendar? Is that the same as the standard-based iCal, or is that something that Apple did on it’s own?
Mace: No, Apple is implementing the standard as currently defined by CalConnect. We have work to do on other clients to support CalDAV. One of the most famous clients that’s supposed to support CalDAV out of the box is the long-awaited Chandler client from the Open Software Application Foundation, which is Mitch Kapor’s project to reinvent the personal information manager (PIM).
Gardner: So, now back to Microsoft and Office 2007. With the Outlook client within Office 2007, we’re going to see iCalendar supported, but not CalDAV. Is that right?
Mace: Not at first -- at least as far as I can tell. We may see some support forced in Microsoft Exchange. It seems like whenever Microsoft can go no further, they at least begin to throw support for such things into Exchange, which is fine if you are a corporate customer and an Exchange shop. As far as the more standalone Outlook client, I wouldn’t be surprised if it takes some amount of time for Microsoft to support iCalendar. It's still the case that they support some of these standards somewhat grudgingly and somewhat later in the game than others, and now iCalendar is a good example.
Gardner: I certainly would find the use of iCalendar in Outlook productive because there are folks that I work with who are using Outlook -- that’s your calendar -- and I am using Mac OS X, and, as I said, I can subscribe to my wife’s calendar because she is an OS X user too. But when it comes to some of my contract workers and other friends, I can’t do that. I think that will be an important productivity boost if we could get that level of interoperability. Or am I overstating the case?
Mace: No, I think you are stating it correctly. Here is the other problem: Microsoft is not as focused anymore on following Apple’s lead on every little thing. I think you know this. The participant that needs to embrace some of these standards more fully is Google. I’ve heard it said by various knowledgeable people that if Google supported CalDAV in their calendar tomorrow, you’d very quickly see a response from Microsoft -- at least a commitment or a statement of direction -- because they’re simply so much more competitive with Google on the whole Office suite.
I believe that it probably would be less challenging for someone like Google to support CalDAV than for Microsoft, just because they don’t have all that legacy to pull behind them. But so far, Google has not committed to supporting CalDAV. I recently for the first time met Carl Sjogreen who runs Google Calendar and I asked him if they were going to join CalConnect and support CalDAV, and he was noncommittal. So, they have a lot of different things on their plate and won't get around to all of them, but I think that would be the ultimate leverage on Microsoft -- for Google to embrace it.
Gardner: Okay, I suppose another pivot point in terms of leverage with Microsoft -- in terms of their going to more standards -- would be from the other big player in enterprise messaging and calendar, and that would be IBM Lotus with Sametime and Notes/Domino. What’s the status of what IBM is doing vis-à-vis calendar?
Mace: IBM is a participant in CalConnect and, unless I am mistaken, they were involved in the interoperability demonstration this summer, where a variety of different vendors demonstrated interoperable calendar free-busy information between various calendars. I believe that the IBM Lotus offering was one of those participants. So, they are staying up with the standards.
Gardner: I suppose another interesting aspect of Sametime and Notes is the increased usage of RCP, the Rich Client Platform -- the Eclipse Foundation project -- as a basis for more and more of their client architecture. Does that have a relationship to calendar interoperability that you are aware of?
Mace: Well, it’s interesting. I went to OSCON this summer and it wasn’t clear to me whether Eclipse was going to embrace within some their own projects any of the calendaring standards, or whether perhaps there would be some further effort at Eclipse. I think maybe there is interest there, and the Eclipse folks are watching this, but right now I haven’t heard vis-à-vis RCP anything about calendar support per se.
Gardner: It certainly sounds like a powerful and interesting thing to bring a publish-and-subscribe calendar function into a rich client standard. Even if it doesn’t become your main PIM, it could be something that would be of value, as well as an embedded RSS capability into some of these clients. Do you agree with that?
Mace: Yes, and the thing is, if people don’t go whole-hog for standard support, what they will sometimes do is create a plug-in. I don’t know if that exists yet, but I could speculate that there could be an Eclipse plug-in that supports the Google Calendar API. This wouldn’t be the hardest thing in the world to build, and you are seeing a lot of effort and lot of activity around standards like the Google Calendar API, which is it’s own de-facto standard. It reaches out into lots of different communities: the Java community, the .NET community. Those kinds of things are going to be built every day.
Gardner: So to look at the current landscape a little, we’ve got IBM and Apple in the CalDAV camp; we’ve got Google apparently assessing this, and we have Microsoft as recalcitrant in terms of adoption on a leading-edge basis. It seems, though, that Google is the important player. Is that how you view it?
Mace: That’s how I view it. But Google still has a lot of other things on its plate. Again, I talked to Carl Sjogreen at Google, and one of the things that they are most focused on is creating a great user experience for groups of people trying to arrange get-togethers. And so, this might mean -- I am guessing -- maybe half a dozen or a dozen people trying to coordinate a calendar, which is one particular kind of calendar interoperability problem.
I think, knowing what I know about Google and the whole social dynamic that it’s been responsible for, I can see very well that they might be focused on that. My particular focus tends to be on two people -- or bilateral kinds of calendar communication -- where you might really just want to have everything very closely in synchronization. The problem of getting a dozen people in the same place at the same time -- it’s a different problem. So, because Google is trying to solve the problems that they see their users having, they may not get around to solving these other problems until later. It’s just a prioritization issue, and even at Google they have to prioritize.
Gardner: When we last spoke, Scott -- probably three or four months ago, when we did a podcast on some of these issues -- we were both intrigued by the prospect of Google becoming a focal point for calendar interoperability. They might be able to draw inferences from what people do with their calendars in order to augment their existing business model around contextual advertisements. Do you still think that they are heading in that direction, and wouldn’t their being somewhat neutral vis-à-vis the standards help them toward that goal?
Mace: Well, I think they are heading in that direction. Whether they are making the kind of progress that people expected to make by now is an open question. There’s certainly lot of developer interest around this. Every day I see something interesting. There has been a recent thread about implementing the Google Calendar API on pocket PCs, which really gets my interest, but this isn’t quite a panacea because what they are really trying to do is just properly display Google Calendar on their device.
Once you have got something like that, then people start trying to make it sync with what’s already on the device. So, there is lots of developer interest and more so, with the Google community than Yahoo! or any of the other online calendars. I have gotten some flak for not talking about other online calendars, but they are all good. It's really just a question of who’s got the momentum in terms of the developer interest -- how many developers are poking around with any particular calendar.
Gardner: It seems to me there might be some parallel here between what went on in the instant messaging space, where we had a lot of different companies with unique instant messaging clients, and perhaps their own service. But it wasn't until Jabber came along, and people had to eventually go in with that [as an interoperability standard]. Do you see a similar path or progression with calendar interoperability?
Mace: I don’t know. I think there are different characteristics. For example, the way Apple has come out with such a wonderfully elegant solution early on. In a way, I think they outdid what AIM [AOL Instant Messenger] was able to do.
I mean, iCalendar on the Mac is just a truly wonderful solution. The problem is, it hasn’t been openly adopted. I think that we also don’t have the kind of phenomenon in calendaring that we did with Jabber. A lot of people are wondering just how long it really is going to take, because it's already been several years. I’m still waiting for something to come out that’s as viral as Jabber and that just completely starts to spread. You can find Jabber on all sorts of devices.
That’s still not the case with any open source or open standards type of calendar. I also would like to throw a rock back at the mobile phone people, who really have been behind the curve here. If you manage to get any data out of your mobile phone calendar, it's probably going to be in vCal, which is essentially an extinct format at this point. You may be able to pull it into something else but it’s really the lowest common possible denominator of calendar interoperability.
Gardner: I've solved that problem. I stopped using the calendar and address book in my mobile phone altogether, and I usually take my iPod with me wherever I go. So, I have my iPod in one pocket and my cell phone in the other. And whenever I want to look for my calendar or my addresses or phone numbers, I use my iPod, which of course, syncs back to iCal and the address book on OS X. Then I simply punch in the number on the cell phone. Now, I'm using wet-ware -- or sneaker-ware or thumb-ware, whatever you want to call it -- to go from my iPod to my cell phone, but it’s the best solution.
Mace: Yeah, I think that is a great solution for a lot of people. Also there are just people who are going to use a browser. For them, any browser-based online calendar will do. They often don’t care that when they are away from the Internet, their calendar is something they have to print out or remember -- whatever. There are still a lot of people in the final analysis who will want it in the palm of their hand, even in an offline mode. I’m just going to continue to probe and press the industry for solutions that can work in every possible situation. So, really I deal with that as a no-compromise solution.
Gardner: Speaking of mobile, what about what Dave Winer has done with his Web content readability benefit on mobile devices? Does that have any impact on someone who has got a Web-based calendar? Would they be able to use his approach to reading that on a mobile device?
Mace: You know, I don’t think so. I haven’t read anything about what he is doing that has any impact on calendaring. It sounds like great technology, though.
Gardner: It might be an interesting thing to look into. Going back to Google, I recently began receiving emails from people using Google Calendar, and the email consists of nothing but an attachment or two that look like little hash boxes but that end up automatically populating my OS X calendar with events that were taken out of a Google Calendar. Is it because of iCal? What is allowing this to happen, and what is going on here?
Mace: Yeah, there is some iCalendar support. It’s very encouraging to hear that people are using it. It doesn’t synchronize anything necessarily, and I wonder what happens if that same person then sends you an email or to change the time of that appointment. You might end up with two different appointments in your iCal and have to remember to delete the first one you got. But, every little bit helps.
I mean, what we are all trying to get away from is the kind of wet-ware, where you just get an email and you have to laboriously cut and paste from that email into your calendar. So, any kind of structure helps. It’s not that I begrudge the things that are low-structured. It’s just that I think we can do better. And it’s also a cultural thing when somebody gets something like that and it’s an attachment. How acclimated are people to knowing what to do with that? I think on the Mac, people are more acclimated to it. I work with a learning curve, because I am sure when people first get Outlook 12 [part of Office 2007], they don’t quite know what that is, and have to learn how to deal with it.
Gardner: Now, let's look toward the opportunity for doing commerce and new business activities through this calendar interoperability function. I am thinking about what Skype, as a division of eBay, has been doing with the equivalent of Yellow Pages and click-to-talk when it comes to ecommerce, or mobile commerce, or looking for new retail types of commerce.
It certainly seems to me that having a calendar function is an important element within this move toward automated commerce -- one that joins the element of the temporal, of the time and space, to sort of a virtual commerce activity online. And it would seem to me that people like Amazon, eBay and Yahoo!, among others, would be significantly advantaged in a progression toward this vision, if there was this level of calendar interoperability. Therefore, they should be somewhat of an impetus or force to make this happen sooner. Why is it that folks like Yahoo!, Apple, Amazon, and eBay are not moving the big players like the Googles and Microsoft on calendar interoperability?
Mace: Well, Yahoo did make a move. They bought Upcoming.org, which does provide this sort of public-facing calendar service that you are talking about. And there is a player, which has not been acquired yet, and as far as I know is not for sale. It is EVDB, which provides the Eventful service.
I had a nice chat this summer with Brian Dear, who runs that. They’ve cracked the code for TicketMaster, so all the TicketMaster events have been exposed as calendar objects within the Eventful Service. I think that’s the beginning of something that can be much, much bigger. I totally agree that some of the players involved haven’t really stepped up to the bar. I can see Amazon doing lots of interesting things with calendar information, but so far I don’t see any movement there. eBay -- I have no real idea what their consciousness level is about calendaring, but Yahoo certainly gets it. I think eventually, probably somebody is going to snap up EVDB and then that will probably represent some of the cutting-edge on this.
Gardner: The migration path for this could be on local commerce. For example, it’s nice that I can go and locate a pizza parlor in my neighborhood and I can click on a button and get into a VOIP discussion with them to order a pizza. What I’d really like to do is click on an icon that would get me into the calendar of a plumber or a landscaper, or even a doctor or a veterinarian, so that I can shop and do errands. If someone can take my dog for a haircut next Wednesday at 2 p.m., when I am available, and there are three vets in town -- the one that’s open to me on my time gets the business. I know that’s a little bit of a pie-in-the-sky idea, but the technology certainly seems capable of that. On a local level, it could it be really a much more automated way for local small businesses to generate additional sales.
Mace: Sure, and when you think about all the junk mail you get saying, "Come to our sale for one week only," or, "This coupon expires on such and such date," that information ought to be able to be fed right into a calendar. We have to worry about calendar spam, of course, so that’s something to be thinking about. But why shouldn’t the consumer of this information, if they so desire, have all that flow right into their calendar in the appropriate way, instead of forgetting about it.
Gardner: Not to mention the travel industry -- when it comes times to be booking things while you are on the road, another interesting aspect of time-oriented commerce.
Mace: Yeah. Did you notice -- I think the company was called FareChaser -- and what they do is they’ll predict when the sale for particular sites can be lowest based on a bunch of information they collect. And so that would enable people not only to get the best price, but to know when to get that best price. It’s kind of fascinating.
Gardner: I think I may have stumbled upon an interesting acronym here, Scott. When I said, "time-oriented commerce" -- well that comes out to “TOC.” So maybe we could also do “TIC,” which could be "the interoperable calendar, " which would give us TIC TOC. What do you think?
Mace: Okay. Sure.
Gardner: Sorry. All right, Scott, I appreciate your time and your depth of knowledge and for updating us on calendar interoperability. And I certainly hope that more of the capital “I” in interoperability becomes apparent among these major players. And if not, then that some of these other smaller players that you mentioned start to increase the adoption of these standards.
Mace: Well, tell you what. When Office 2007 ships and I install it, we’ll arrange one of our future phone calls by spinning calendar objects back and forth rather than emails.
Gardner: That will be a very nice thing. Okay, we have been talking with Scott Mace, the editor of Calendar Swamp and an expert on calendar interoperability and standards. You can find out more information on Scott and his services at www.calendarswamp.com. You have been listening to BriefingsDirect. I'm Dana Gardner, principal analyst at Interarbor Solutions. Thanks so much for listening.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect podcast on calendar interoperability. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.
Wednesday, September 27, 2006
Sunday, September 10, 2006
Full Transcript of Dana Gardner's BriefingsDirect Podcast on Network Services and SOA Convergence with Cisco's Bill Ruh
Transcript of BriefingsDirect[TM] podcast with Dana Gardner, recorded Aug. 23, 2006.
Listen to the podcast here.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a podcast discussion on a mega convergence point, the intersection of advanced intelligent network services and applications as services, otherwise known as Services Oriented Architecture (SOA). And joining us to discuss this rather weighty topic is Bill Ruh, the vice president of Advanced Services at Cisco Systems. Welcome to the show, Bill.
Bill Ruh: Dana, thank you very much.
Gardner: Let me provide some more background on you and what you do at Cisco. You've been 20 years plus working in enterprise middleware and integration, and you are currently leading the Services Oriented Network Architecture (SONA), as well as the Application Oriented Networking (AON) services teams worldwide at Cisco. Previous to that, you were a senior vice president and CTO at Software AG, and you’ve worked at Mitre and IBM.
Furthermore, you’re an author, and in July of 2004 published a book called, "Enterprise Integration: the Essential Guide to Integrations and Solutions." Previous to that came, "Enterprise Application Integration, " as well as "Inside CORBA" and previous to that, "IIOP Complete. " So it sounds like you’ve got a pretty good handle on integration, Bill.
Ruh: I’ve seen a lot of the trends and a lot of the technologies come and go over the last 25 years to help us solve this problem.
Gardner: Based on some of the presentations I’ve seen you deliver, we are at this mega-tipping point -- not something that is just a continuum of what’s happened in the past, but something that seems quite different. This is largely due to SOA, virtualization, network convergence, intelligent network services, a higher level of standardization and open source. This all seems to imply a bit more than the typical roadmap, something that is quite new. I think you called it "integration for everyone." I wonder if you could start our discussion by sort of explaining what you mean by "integration for everyone."
Ruh: It certainly does feel like we’re about ready to enter and move up to another plateau in technology. In my experience it’s like client-server, or certainly like the Internet age. Then, we went up to a new plateau with the technology, and this has that same feel. I call it "integration for everyone" in that previously when we have talked about integration, it has been very much technical, the very technical integration of tying together systems.
But, when we start to look at where we’re going now -- in both the number of things and the kinds of things -- what we’re trying to do with those things in tying them together now is very different. In fact, we’ve got a movement from where we used to just have a few devices to where we have the Internet. We’re tying together RFID tags. We’re tying together sensors. So we’ve got a real change in the kinds of things that we’re tying together, where it’s not just technology things. It’s things that are going to be more business-oriented.
The idea of sensors, the idea of tags, the idea of "what is the device on the network" -- that is changing. We also see that the kind of things we want to do with integration is changing. It used to be that integration was really about taking information from one system and integrating it with information from another system. The kinds of integration we’re talking about now is also fundamentally changing, because what people want to do now is more about interactions than about production and transactions.
Now that I know that a temperature gauge in a refrigeration unit has gone off, well, what do I want to do with that? I want to not only sense it, but I want to respond to it. I want to tell somebody about it. This idea of collaboration means that I’m not just integrating applications in a technology sense. I’m integrating people and processes into this. So, when you look about "integration for everyone,” what we’re really talking about is not just technology integration. We’re now integrating all these devices and all these sensors and all these people and all these cell phones.
We’re now taking those integrations and its not just transferring information. We want to collaborate. We want to bring in this idea of communication. When I talk about "integration for everyone," it means that it’s integration for me. It’s integration for my son or daughter. It’s integration for everyone so that they get all the services and capabilities they need through whatever device or channel or whatever they’re interacting through. And that’s a fundamental re-definition of what integration is about.
Gardner: Okay, it sounds like this portends a great deal of opportunity, albeit with quite a bit of complexity. So, if I’m a CIO in a corporation and I’m trying to be strategic, work with the business side of the house in formulating how we’re going to take advantage of these trends and this new plateau of integration, how do we manage the complexity? What are some of the priorities that you see facing today’s CIO?
Ruh: I think you hit on the major challenge here. Software is always complex, and systems are complex, so it’s great for me to say, "Wow, we’re going to take all these sensors and plug them in, and you’re going to be told when some sensor goes off in your house or some sensor goes off in your business, and your business processes are going to be suddenly kicked off and you’re going to respond to things much quicker." But the fact is that we all know that trying to do that in real time is difficult.
The CIO is the one who is going to bear the brunt of why we can’t do this. The last time I remember, "Why can’t I do this," was in the PC era. You remember everybody had dumb terminals, and suddenly it was easy for people to go buy PCs through the finance department, etc. The CIOs suddenly had all this complexity and they had to tie it all together. Suddenly, they had networks showing up everywhere, all different flavors of networks, all different kinds of protocols -- and that became a nightmare to manage. Cisco was actually born out of that era in solving the problem of how to integrate and network together all these different PCs into different applications.
We’ve moved up that stack and the CIO is going to see that people are going to be building sensors and cell phones, and people are going to be saying in their businesses, "Why can’t you do this? I can go buy this capability." This will happen in the same way we saw the PC coming in the back door 20 years ago. Fortunately -- and maybe it’s really driven by this complexity -- the dialogue has turned to SOA.
SOA isn't really new. I was involved in Smalltalk and CORBA and the object-oriented movement back in the mid-1980s. A lot of these techniques and approaches have been talked about for a long time. What makes it different is that we’re now starting to get where the protocols are being made that allow standardization to occur. This idea of protocols is the same thing we saw with Internet protocol (IP). What we’re seeing is a movement up the stack to things that ride on top of IP that allow services to actually communicate, coordinate, and collaborate better -- in the same way it used to be hard to connect two things together and send data from one device to another, which is less of a problem today.
We’re going to see that protocols and services in the network are really going to allow us to communicate easier and reduce some of the complexity. So, the network’s going to tie into this movement of SOA. It’s going to provide services, infrastructure-level services, to take some of the complexity away from CIOs in terms of the infrastructure and allow them to focus on the business processes.
Gardner: We’ve discussed some of the technical integration issues, but it seems to me that in a typical enterprise today, there also is going to be the need for a cultural or organizational integration. For example, the application development and deployment folks are in one group or one culture. Network services and administration in another, and then voice telephony (VOIP) and communications in another. It seems to me that that won’t stand, that disintermediation between these different groups is not conducive to this larger integration proposition that we’re discussing. How do we bring application and network services together? How do Cisco’s AON, the Application Oriented Networking, and SOA relate, both technically and organizationally?
Ruh: You know, I think you hit the nail on the head. I don’t think this is necessarily being driven by Cisco. This is being driven by this larger services-oriented trend. When you look at it, we’ve organized our IT and our businesses that integrate with IT around the Internet model and the client-server model.
When you move to a service-oriented model and you start to move more intelligence in the network, certainly you’ve got the need for the networking person to become more cognizant of how they play and support the applications -- and it’s no longer a black box. We see the need for the networking folks to take on a larger responsibility in that intelligence, and provide services that may have been more traditionally built into our applications -- duplicated in many instances -- so people have multiple identity services, instead of one that logically probably fits in the network.
What we see is that the networking folks have to come up and deal with some of the complexity of the services being put in the network. At the same time, the applications folks within an IT organization have to think of the network not as plumbing. They can't just say: "I’ve opened up a socket," or "I open up some communication mechanism and the network takes care of getting the bits from here to there." They have to realize that there are services inside the network. We’re going to see that the organizational dynamics that you suggest are going to change because of that.
I’d add one other thing. As we get to more services or other organizational dynamics, we’re going to see that the end users are going to want the tools that they have on their desktops to allow them to quickly and easily utilize those services in the network as well as on our servers, so that they can apply them and connect them into their desktop applications. We see this in the case of Google, which has done mash ups and other things out there.
It’s not just the networking administrator or the networking person. It’s not just the applications person. The end user is going to start taking advantage of services and that changes the dynamics entirely. So, we’re going to see a real change in the dynamics between these organizations. And that’s why the network is so important. It’s the one thing that connects them all -- and those services have to be there to reduce that complexity.
Gardner: Another trend that’s afoot today that we haven’t mentioned, but has an impact, is the social networking phenomena, characterized often as Web 2.0, where we're seeing communities and collaboration and particularly interactivity. This back-and-forth nature of a discussion, of sharing of knowledge, is growing prominent, not only in blogging, but more mainstream in enterprises and in how people do business. Given that interactivity is a buzzword, and I don’t think just a short-term one, how does the network play in a modern, advanced sense in supporting interactivity solutions?
Ruh: Within Cisco, we talk about unified communications -- all the different mechanisms that people use to communicate and collaborate, and that communication is certainly changing. You just outlined that. We go from Voice-over-IP (VOIP), to instant messaging, to collaborative applications, sharing documents, and then we get into blogging.
This whole idea of communication is fundamentally being re-written overnight. Unified communications is going to be the focus for these next-generation applications that are going to support that environment. When you really look at the vision for where unified communications will go in the next five years, it includes the idea: "Why can't I take my blogs, and why can’t I take something like Google Earth and then plot where the blogs are?" Maybe I want to look at blogs that are from a certain part of the world, or that talk about a certain part of the world.
Communication is fundamentally changing to be IP-based. So, the network has provided services to allow those individuals to integrate with everybody. If I’m on a blog and I want to talk to someone and I want to collaborate with someone, I can bring up my collaboration tools. I can bring up my VOIP capability -- all of these things that are integrated. Those services allow me to take all of the services like Google Earth and start to use those tools as a part of the collaboration.
The idea that services can get integrated to the communications is important, and the network becomes the focal point for the services that support that infrastructure, as well as IP being the basis for all these different tools working together.
Gardner: It sounds like what we’re gaining here is the opportunity to not just view communications, applications, and data as separate, but that we need to pull together with our own brains -- with our wet-ware. How do we take this intelligent information network and manage it? It sounds like we have this opportunity, but I think people are still stuck thinking about these things as separate and unrelated.
Ruh: That’s obviously going to take some time, in the same way the Internet took time. I remember in 1994 and 1995 putting up Web sites. At the time I was with the Mitre Corp., and we did a lot of early work there. A lot of folks looked at this and asked, "What use was it?" and, "Who is going to manage it?"
Between 1994 or 1995 and 2000, organizations suddenly had a change, and now they have Web administrators and Web servers and everything else coming in. The organization had to morph to support that, so there’s always this chicken-and-egg relationship. What do you do first?
The important thing is that you don't decide to put the organization in place and then the technology. What happens is that the business begins to be driven by some of these external forces. So, external forces -- sensors, unified communications, and moving to VOIP -- and all these IP services -- are starting to come together, and they’re coming into the organization. With the PC, the user said, “Well, I’ve got this spreadsheet, and this is how I want to interact with things.” People start to focus on what the application is.
"If I can go home and do all the things I’m doing at home, well, when I go to work, I want to have exactly the same thing." That’s the thinking that drove the PC. That’s what drove the Internet, and that’s what’s going to drive this whole era. People can do this at home, and they’re going to say, "Well, why can’t I do that at work, and why can’t I have that same capability?" And they start bringing it in the back door. What happens then, of course, is that the IT world has to respond to that.
What we’ll see is that organizations are going to have to decide whether they want to get a little ahead of the power curve here. They know this is all happening, and that means they have to look at their network, look at their systems and say, "I’m going to do services-oriented here. I’m going to do SOA, and I’m going to do services-oriented infrastructure. Let me figure out a few of the core elements I need to put in. Security is a network service. That’s great, and I’ve got to put that in there. I’ve got to start looking at what kind of services go where."
You get a few core elements in and from that what is going to happen is that IT organizations are going to learn what they need to do to really fit into this wave or this trend. Number two, is that they are going to be viewed as being responsive to the business side of things. This is the approach that people have to look at. "What are some of these core services that I can put in the network? What are some of the core services that I’ve got within my servers and how can take advantage of this trend and support what is certainly going to be a wave that is going to hit?"
Gardner: We’ve had quite a few acronyms in our discussion, and we could probably come up with a couple of hundred more. Help me out with Services Oriented Network Architecture (SONA). I’ve got a pretty good handle on SOA, and I’ve got a pretty good handle on AON, but I’m a little bit less clear on SONA. What do you all mean by that?
Ruh: SONA is a Cisco-defined architecture. We recognize that we have a very diverse product set, and those products fit together. So part of SONA is to show how all of our products that we bring to market fit together into an overall network. And rather than the network as just the transport, it's the network as a platform.
With that you can understand how unified communications fits with mobility, data center, networking, and security. How does all this fit on top of your network infrastructure and work together? One piece of this is to show how the entirety of what we’re doing in terms of our products fits together as a single, integrated platform.
In addition, what SONA is about is for us to show how these are not only just products with features and functions, but that they provide specific services in the network -- identity services, VPN services, presence services from mobility -- so that the applications people can begin to understand it. If they're going to use a presence service within the SONA architecture, when the networking people provide those mobility services, and there is a presence service in there, they can take advantage of that presence service for their application.
SONA is about how the entire Cisco product line fits together. It’s also about how those products then provide services and how those services fit with the application. Finally, it really lays out the vision for how we’re taking our portfolio going forward and how these things are going to continue to evolve, how they’re going to continue to work together. As an architecture, we show how we can create an infrastructure that can improve your overall SOA investment.
As you invest in SOA, the infrastructure through SONA is there to allow you to scale. How are you going to do bandwidth and manage bandwidth and quality of service? How are you going to provide a converged network? How are security and mobility going to fit in? Which standards and protocols are going to be used? How do you get the ability to virtualize your storage and your compute environments and other devices? SONA really is an architecture, and it’s a way for the customer to see how the network plays in their overall service-oriented architecture and what services we believe really belong in the network going forward.
Gardner: Help me understand, if I put myself in the role of the developer. Traditionally as a developer I probably haven’t been too concerned with the network and I probably feel that’s up to the operations people to deal with. I’m focused on the logic, on the presentation, on the access and integration. But it sounds to me as a developer that I may have a palette of different objects and services to choose from as I’m crafting my application. And increasingly I’m going to have more on that palette in the form of network services.
Is that the way I should be thinking as a developer -- that I should be looking toward network services as part of my typical library of resources when I’m putting together an application? Or is there some other intercept where these network services as you described them will come into play with applications?
Ruh: We don’t want developers to look and say, "Oh, I’m programming the network." Obviously that’s not the intent here. In fact, to them, these services should just exist and be available to them as part of their overall palette, as you described.
The issue that we’re trying to educate people on is that some of these services do belong in the network. From a developer’s perspective today they may think about identity services or mobility services. They need to be aware that decisions need to be made about it. Maybe this ought to be in the network, and they need to work with networking folks and architecture folks. If we need these as common services, hopefully they’ll also say, "Yeah, we know that they should be in the network."
And this has happened before. VPN used to be in application code -- and it has migrated down to the network. Multi-cast is another great example: Programmers used to build multi-cast and now they know it’s in the network, and they expect it to be there. Firewalls used to be at the application layer. It's the same with quality of service, replication, back-up, and encryption -- all these things. We’re really continuing down the path of educating developers that these services belong in the network.
From a programmer’s standpoint, it either just happens, which is the best case, or they can configure it as a service. The way we’re moving is to open up and provide some of our functionality to services that a system’s architect or an application person can take advantage of as they build out their applications.
Gardner: Perhaps I had it a little bit backward. Instead of my seeing more items on my palette, perhaps I should expect to see fewer, as components that have perhaps traditionally been part of an application or middleware layer, migrate to the network layer. Then, I really don’t have to worry about them, and so perhaps the reuse and integration of these services into a platform reduces my options as a developer. Do you think that’s right?
Ruh: I think it's absolutely right, and I think you’ve got the point there, which is: Should every application implement virus detection and virus management? No. Should it be implemented for them? Yes. Should there be some ability for the applications to control other set policies? Those are things that should happen, but the fact is that there are a lot of things that are infrastructure that should just happen, where programmers don’t have to worry about them as they do today.
Gardner: In wrapping up, why don’t we try to get into some more of the reality side of this in terms of implementation? If I’m a CIO, or if I’m a developer, or architect beginning to see the logic of bringing services from middleware and from a siloed basis onto a more ubiquitous platform for reuse, how do I get started, where do I put the pencil on the paper first to start in this direction?
Ruh: What we’ve been doing in working with customers down this path is, and -- as strange as this is going to sound -- it really does start with a strategy and roadmap. The IT organization really needs to make sure that they have their strategy for their IT environment laid out, as well as the kind of roadmap they have to get there. That's what allows the dialogue to take place at the next level.
What you don’t want to do is to say, "Okay, I need services. Let me go buy services, put them in;" to do the Field of Dreams thing ... and they will come. In the past, as we’ve learned from object oriented, building common services, and having the Field of Dreams approach doesn’t work.
What does work is if you’ve got your strategy and your roadmap for your IT organization, such as where your investments are going to be made, what applications you’re going to be building. The best strategy is to come in and say, "Okay what is the best approach -- architectural approach -- to get there?" Now you can begin to integrate with the architectural group to say, "We know that we want to start to put in place certain B-to-B capabilities or certain other applications."
Maybe the best place to start is with identity services within the network or maybe the best place to start is with mobility services in the network. Or maybe really, I want to improve the data center. If I take a retail operation, if my strategy and roadmap is really that, I’m going to invest in the store operations in the stores. I may really focus on identity management and wireless services in the network. Maybe I’m going to move to wireless POS (point of sales).
Maybe I’m going to do e-learning. Maybe I’m just going to just change the nature of the store. If I've already invested in the stores, what I really want to do is I want to save money in my back-ends and I want to improve my data center operations. Then, it may be that putting in storage networking services, putting in a compute services in the network to virtualized storage and servers, maybe those are much better approaches.
The fact is you want to tie bringing in new services to the investments you plan to make that will be tied to the business problems that are out there. Then, very naturally, over the course of three years, as you execute that strategy and roadmap, you end up with these services being built in and being paid for as a part of that natural investment. Where we have been coming in, interestingly enough, is we are now getting involved with those strategies and roadmaps by doing a lot of workshops and planning with them, and then bringing in what SONA can provide in tying down to a real ROI analysis. Then, you get into the architecture and the technology and how it fits in. And, the part everybody really loves-- you finally get down to buying specific products that implement that capability.
Gardner: So I guess two takeaways from that would be: The good news is that I can do this incrementally; that I don’t have to build it all and then throw a switch one day. It can start on a crawl-walk-run basis. But, in order to make that plausible, there also has to be a top-down mandate for these cultural silos. And all of these different parts need to act in some concert toward an iterative build-out and adoption. There has to be some word from on high that this is our strategy, this is the roadmap, and this is what we’re going to do. Does that sound about right?
Ruh: That sounds about right, and it’s getting people to realize that this can be done incrementally. It makes the most sense to have the discussion around a business problem that you’re going to invest in anyway. And then very naturally the network folks, the app folks, and the architecture folks are sitting around the table and having the right discussions -- which is: which services really belong in the network, which services are going to give us the biggest bang for the buck, and which services quite naturally belong in the other parts of the IT infrastructure? So, it really starts the dialogue down the right path.
Gardner: Well, thanks very much. We’ve been discussing mega-trends and convergence, network services, application services, and SOA. Joining us has been Bill Ruh, the vice president of Advanced Services at Cisco Systems. This is Dana Gardner, principal analyst at Interarbor Solutions for BriefingsDirect. Thanks for joining us.
Ruh: Thanks a lot.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect podcast on network services and SOA convergence. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.
Listen to the podcast here.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a podcast discussion on a mega convergence point, the intersection of advanced intelligent network services and applications as services, otherwise known as Services Oriented Architecture (SOA). And joining us to discuss this rather weighty topic is Bill Ruh, the vice president of Advanced Services at Cisco Systems. Welcome to the show, Bill.
Bill Ruh: Dana, thank you very much.
Gardner: Let me provide some more background on you and what you do at Cisco. You've been 20 years plus working in enterprise middleware and integration, and you are currently leading the Services Oriented Network Architecture (SONA), as well as the Application Oriented Networking (AON) services teams worldwide at Cisco. Previous to that, you were a senior vice president and CTO at Software AG, and you’ve worked at Mitre and IBM.
Furthermore, you’re an author, and in July of 2004 published a book called, "Enterprise Integration: the Essential Guide to Integrations and Solutions." Previous to that came, "Enterprise Application Integration, " as well as "Inside CORBA" and previous to that, "IIOP Complete. " So it sounds like you’ve got a pretty good handle on integration, Bill.
Ruh: I’ve seen a lot of the trends and a lot of the technologies come and go over the last 25 years to help us solve this problem.
Gardner: Based on some of the presentations I’ve seen you deliver, we are at this mega-tipping point -- not something that is just a continuum of what’s happened in the past, but something that seems quite different. This is largely due to SOA, virtualization, network convergence, intelligent network services, a higher level of standardization and open source. This all seems to imply a bit more than the typical roadmap, something that is quite new. I think you called it "integration for everyone." I wonder if you could start our discussion by sort of explaining what you mean by "integration for everyone."
Ruh: It certainly does feel like we’re about ready to enter and move up to another plateau in technology. In my experience it’s like client-server, or certainly like the Internet age. Then, we went up to a new plateau with the technology, and this has that same feel. I call it "integration for everyone" in that previously when we have talked about integration, it has been very much technical, the very technical integration of tying together systems.
But, when we start to look at where we’re going now -- in both the number of things and the kinds of things -- what we’re trying to do with those things in tying them together now is very different. In fact, we’ve got a movement from where we used to just have a few devices to where we have the Internet. We’re tying together RFID tags. We’re tying together sensors. So we’ve got a real change in the kinds of things that we’re tying together, where it’s not just technology things. It’s things that are going to be more business-oriented.
The idea of sensors, the idea of tags, the idea of "what is the device on the network" -- that is changing. We also see that the kind of things we want to do with integration is changing. It used to be that integration was really about taking information from one system and integrating it with information from another system. The kinds of integration we’re talking about now is also fundamentally changing, because what people want to do now is more about interactions than about production and transactions.
Now that I know that a temperature gauge in a refrigeration unit has gone off, well, what do I want to do with that? I want to not only sense it, but I want to respond to it. I want to tell somebody about it. This idea of collaboration means that I’m not just integrating applications in a technology sense. I’m integrating people and processes into this. So, when you look about "integration for everyone,” what we’re really talking about is not just technology integration. We’re now integrating all these devices and all these sensors and all these people and all these cell phones.
We’re now taking those integrations and its not just transferring information. We want to collaborate. We want to bring in this idea of communication. When I talk about "integration for everyone," it means that it’s integration for me. It’s integration for my son or daughter. It’s integration for everyone so that they get all the services and capabilities they need through whatever device or channel or whatever they’re interacting through. And that’s a fundamental re-definition of what integration is about.
Gardner: Okay, it sounds like this portends a great deal of opportunity, albeit with quite a bit of complexity. So, if I’m a CIO in a corporation and I’m trying to be strategic, work with the business side of the house in formulating how we’re going to take advantage of these trends and this new plateau of integration, how do we manage the complexity? What are some of the priorities that you see facing today’s CIO?
Ruh: I think you hit on the major challenge here. Software is always complex, and systems are complex, so it’s great for me to say, "Wow, we’re going to take all these sensors and plug them in, and you’re going to be told when some sensor goes off in your house or some sensor goes off in your business, and your business processes are going to be suddenly kicked off and you’re going to respond to things much quicker." But the fact is that we all know that trying to do that in real time is difficult.
The CIO is the one who is going to bear the brunt of why we can’t do this. The last time I remember, "Why can’t I do this," was in the PC era. You remember everybody had dumb terminals, and suddenly it was easy for people to go buy PCs through the finance department, etc. The CIOs suddenly had all this complexity and they had to tie it all together. Suddenly, they had networks showing up everywhere, all different flavors of networks, all different kinds of protocols -- and that became a nightmare to manage. Cisco was actually born out of that era in solving the problem of how to integrate and network together all these different PCs into different applications.
We’ve moved up that stack and the CIO is going to see that people are going to be building sensors and cell phones, and people are going to be saying in their businesses, "Why can’t you do this? I can go buy this capability." This will happen in the same way we saw the PC coming in the back door 20 years ago. Fortunately -- and maybe it’s really driven by this complexity -- the dialogue has turned to SOA.
SOA isn't really new. I was involved in Smalltalk and CORBA and the object-oriented movement back in the mid-1980s. A lot of these techniques and approaches have been talked about for a long time. What makes it different is that we’re now starting to get where the protocols are being made that allow standardization to occur. This idea of protocols is the same thing we saw with Internet protocol (IP). What we’re seeing is a movement up the stack to things that ride on top of IP that allow services to actually communicate, coordinate, and collaborate better -- in the same way it used to be hard to connect two things together and send data from one device to another, which is less of a problem today.
We’re going to see that protocols and services in the network are really going to allow us to communicate easier and reduce some of the complexity. So, the network’s going to tie into this movement of SOA. It’s going to provide services, infrastructure-level services, to take some of the complexity away from CIOs in terms of the infrastructure and allow them to focus on the business processes.
Gardner: We’ve discussed some of the technical integration issues, but it seems to me that in a typical enterprise today, there also is going to be the need for a cultural or organizational integration. For example, the application development and deployment folks are in one group or one culture. Network services and administration in another, and then voice telephony (VOIP) and communications in another. It seems to me that that won’t stand, that disintermediation between these different groups is not conducive to this larger integration proposition that we’re discussing. How do we bring application and network services together? How do Cisco’s AON, the Application Oriented Networking, and SOA relate, both technically and organizationally?
Ruh: You know, I think you hit the nail on the head. I don’t think this is necessarily being driven by Cisco. This is being driven by this larger services-oriented trend. When you look at it, we’ve organized our IT and our businesses that integrate with IT around the Internet model and the client-server model.
When you move to a service-oriented model and you start to move more intelligence in the network, certainly you’ve got the need for the networking person to become more cognizant of how they play and support the applications -- and it’s no longer a black box. We see the need for the networking folks to take on a larger responsibility in that intelligence, and provide services that may have been more traditionally built into our applications -- duplicated in many instances -- so people have multiple identity services, instead of one that logically probably fits in the network.
What we see is that the networking folks have to come up and deal with some of the complexity of the services being put in the network. At the same time, the applications folks within an IT organization have to think of the network not as plumbing. They can't just say: "I’ve opened up a socket," or "I open up some communication mechanism and the network takes care of getting the bits from here to there." They have to realize that there are services inside the network. We’re going to see that the organizational dynamics that you suggest are going to change because of that.
I’d add one other thing. As we get to more services or other organizational dynamics, we’re going to see that the end users are going to want the tools that they have on their desktops to allow them to quickly and easily utilize those services in the network as well as on our servers, so that they can apply them and connect them into their desktop applications. We see this in the case of Google, which has done mash ups and other things out there.
It’s not just the networking administrator or the networking person. It’s not just the applications person. The end user is going to start taking advantage of services and that changes the dynamics entirely. So, we’re going to see a real change in the dynamics between these organizations. And that’s why the network is so important. It’s the one thing that connects them all -- and those services have to be there to reduce that complexity.
Gardner: Another trend that’s afoot today that we haven’t mentioned, but has an impact, is the social networking phenomena, characterized often as Web 2.0, where we're seeing communities and collaboration and particularly interactivity. This back-and-forth nature of a discussion, of sharing of knowledge, is growing prominent, not only in blogging, but more mainstream in enterprises and in how people do business. Given that interactivity is a buzzword, and I don’t think just a short-term one, how does the network play in a modern, advanced sense in supporting interactivity solutions?
Ruh: Within Cisco, we talk about unified communications -- all the different mechanisms that people use to communicate and collaborate, and that communication is certainly changing. You just outlined that. We go from Voice-over-IP (VOIP), to instant messaging, to collaborative applications, sharing documents, and then we get into blogging.
This whole idea of communication is fundamentally being re-written overnight. Unified communications is going to be the focus for these next-generation applications that are going to support that environment. When you really look at the vision for where unified communications will go in the next five years, it includes the idea: "Why can't I take my blogs, and why can’t I take something like Google Earth and then plot where the blogs are?" Maybe I want to look at blogs that are from a certain part of the world, or that talk about a certain part of the world.
Communication is fundamentally changing to be IP-based. So, the network has provided services to allow those individuals to integrate with everybody. If I’m on a blog and I want to talk to someone and I want to collaborate with someone, I can bring up my collaboration tools. I can bring up my VOIP capability -- all of these things that are integrated. Those services allow me to take all of the services like Google Earth and start to use those tools as a part of the collaboration.
The idea that services can get integrated to the communications is important, and the network becomes the focal point for the services that support that infrastructure, as well as IP being the basis for all these different tools working together.
Gardner: It sounds like what we’re gaining here is the opportunity to not just view communications, applications, and data as separate, but that we need to pull together with our own brains -- with our wet-ware. How do we take this intelligent information network and manage it? It sounds like we have this opportunity, but I think people are still stuck thinking about these things as separate and unrelated.
Ruh: That’s obviously going to take some time, in the same way the Internet took time. I remember in 1994 and 1995 putting up Web sites. At the time I was with the Mitre Corp., and we did a lot of early work there. A lot of folks looked at this and asked, "What use was it?" and, "Who is going to manage it?"
Between 1994 or 1995 and 2000, organizations suddenly had a change, and now they have Web administrators and Web servers and everything else coming in. The organization had to morph to support that, so there’s always this chicken-and-egg relationship. What do you do first?
The important thing is that you don't decide to put the organization in place and then the technology. What happens is that the business begins to be driven by some of these external forces. So, external forces -- sensors, unified communications, and moving to VOIP -- and all these IP services -- are starting to come together, and they’re coming into the organization. With the PC, the user said, “Well, I’ve got this spreadsheet, and this is how I want to interact with things.” People start to focus on what the application is.
"If I can go home and do all the things I’m doing at home, well, when I go to work, I want to have exactly the same thing." That’s the thinking that drove the PC. That’s what drove the Internet, and that’s what’s going to drive this whole era. People can do this at home, and they’re going to say, "Well, why can’t I do that at work, and why can’t I have that same capability?" And they start bringing it in the back door. What happens then, of course, is that the IT world has to respond to that.
What we’ll see is that organizations are going to have to decide whether they want to get a little ahead of the power curve here. They know this is all happening, and that means they have to look at their network, look at their systems and say, "I’m going to do services-oriented here. I’m going to do SOA, and I’m going to do services-oriented infrastructure. Let me figure out a few of the core elements I need to put in. Security is a network service. That’s great, and I’ve got to put that in there. I’ve got to start looking at what kind of services go where."
You get a few core elements in and from that what is going to happen is that IT organizations are going to learn what they need to do to really fit into this wave or this trend. Number two, is that they are going to be viewed as being responsive to the business side of things. This is the approach that people have to look at. "What are some of these core services that I can put in the network? What are some of the core services that I’ve got within my servers and how can take advantage of this trend and support what is certainly going to be a wave that is going to hit?"
Gardner: We’ve had quite a few acronyms in our discussion, and we could probably come up with a couple of hundred more. Help me out with Services Oriented Network Architecture (SONA). I’ve got a pretty good handle on SOA, and I’ve got a pretty good handle on AON, but I’m a little bit less clear on SONA. What do you all mean by that?
Ruh: SONA is a Cisco-defined architecture. We recognize that we have a very diverse product set, and those products fit together. So part of SONA is to show how all of our products that we bring to market fit together into an overall network. And rather than the network as just the transport, it's the network as a platform.
With that you can understand how unified communications fits with mobility, data center, networking, and security. How does all this fit on top of your network infrastructure and work together? One piece of this is to show how the entirety of what we’re doing in terms of our products fits together as a single, integrated platform.
In addition, what SONA is about is for us to show how these are not only just products with features and functions, but that they provide specific services in the network -- identity services, VPN services, presence services from mobility -- so that the applications people can begin to understand it. If they're going to use a presence service within the SONA architecture, when the networking people provide those mobility services, and there is a presence service in there, they can take advantage of that presence service for their application.
SONA is about how the entire Cisco product line fits together. It’s also about how those products then provide services and how those services fit with the application. Finally, it really lays out the vision for how we’re taking our portfolio going forward and how these things are going to continue to evolve, how they’re going to continue to work together. As an architecture, we show how we can create an infrastructure that can improve your overall SOA investment.
As you invest in SOA, the infrastructure through SONA is there to allow you to scale. How are you going to do bandwidth and manage bandwidth and quality of service? How are you going to provide a converged network? How are security and mobility going to fit in? Which standards and protocols are going to be used? How do you get the ability to virtualize your storage and your compute environments and other devices? SONA really is an architecture, and it’s a way for the customer to see how the network plays in their overall service-oriented architecture and what services we believe really belong in the network going forward.
Gardner: Help me understand, if I put myself in the role of the developer. Traditionally as a developer I probably haven’t been too concerned with the network and I probably feel that’s up to the operations people to deal with. I’m focused on the logic, on the presentation, on the access and integration. But it sounds to me as a developer that I may have a palette of different objects and services to choose from as I’m crafting my application. And increasingly I’m going to have more on that palette in the form of network services.
Is that the way I should be thinking as a developer -- that I should be looking toward network services as part of my typical library of resources when I’m putting together an application? Or is there some other intercept where these network services as you described them will come into play with applications?
Ruh: We don’t want developers to look and say, "Oh, I’m programming the network." Obviously that’s not the intent here. In fact, to them, these services should just exist and be available to them as part of their overall palette, as you described.
The issue that we’re trying to educate people on is that some of these services do belong in the network. From a developer’s perspective today they may think about identity services or mobility services. They need to be aware that decisions need to be made about it. Maybe this ought to be in the network, and they need to work with networking folks and architecture folks. If we need these as common services, hopefully they’ll also say, "Yeah, we know that they should be in the network."
And this has happened before. VPN used to be in application code -- and it has migrated down to the network. Multi-cast is another great example: Programmers used to build multi-cast and now they know it’s in the network, and they expect it to be there. Firewalls used to be at the application layer. It's the same with quality of service, replication, back-up, and encryption -- all these things. We’re really continuing down the path of educating developers that these services belong in the network.
From a programmer’s standpoint, it either just happens, which is the best case, or they can configure it as a service. The way we’re moving is to open up and provide some of our functionality to services that a system’s architect or an application person can take advantage of as they build out their applications.
Gardner: Perhaps I had it a little bit backward. Instead of my seeing more items on my palette, perhaps I should expect to see fewer, as components that have perhaps traditionally been part of an application or middleware layer, migrate to the network layer. Then, I really don’t have to worry about them, and so perhaps the reuse and integration of these services into a platform reduces my options as a developer. Do you think that’s right?
Ruh: I think it's absolutely right, and I think you’ve got the point there, which is: Should every application implement virus detection and virus management? No. Should it be implemented for them? Yes. Should there be some ability for the applications to control other set policies? Those are things that should happen, but the fact is that there are a lot of things that are infrastructure that should just happen, where programmers don’t have to worry about them as they do today.
Gardner: In wrapping up, why don’t we try to get into some more of the reality side of this in terms of implementation? If I’m a CIO, or if I’m a developer, or architect beginning to see the logic of bringing services from middleware and from a siloed basis onto a more ubiquitous platform for reuse, how do I get started, where do I put the pencil on the paper first to start in this direction?
Ruh: What we’ve been doing in working with customers down this path is, and -- as strange as this is going to sound -- it really does start with a strategy and roadmap. The IT organization really needs to make sure that they have their strategy for their IT environment laid out, as well as the kind of roadmap they have to get there. That's what allows the dialogue to take place at the next level.
What you don’t want to do is to say, "Okay, I need services. Let me go buy services, put them in;" to do the Field of Dreams thing ... and they will come. In the past, as we’ve learned from object oriented, building common services, and having the Field of Dreams approach doesn’t work.
What does work is if you’ve got your strategy and your roadmap for your IT organization, such as where your investments are going to be made, what applications you’re going to be building. The best strategy is to come in and say, "Okay what is the best approach -- architectural approach -- to get there?" Now you can begin to integrate with the architectural group to say, "We know that we want to start to put in place certain B-to-B capabilities or certain other applications."
Maybe the best place to start is with identity services within the network or maybe the best place to start is with mobility services in the network. Or maybe really, I want to improve the data center. If I take a retail operation, if my strategy and roadmap is really that, I’m going to invest in the store operations in the stores. I may really focus on identity management and wireless services in the network. Maybe I’m going to move to wireless POS (point of sales).
Maybe I’m going to do e-learning. Maybe I’m just going to just change the nature of the store. If I've already invested in the stores, what I really want to do is I want to save money in my back-ends and I want to improve my data center operations. Then, it may be that putting in storage networking services, putting in a compute services in the network to virtualized storage and servers, maybe those are much better approaches.
The fact is you want to tie bringing in new services to the investments you plan to make that will be tied to the business problems that are out there. Then, very naturally, over the course of three years, as you execute that strategy and roadmap, you end up with these services being built in and being paid for as a part of that natural investment. Where we have been coming in, interestingly enough, is we are now getting involved with those strategies and roadmaps by doing a lot of workshops and planning with them, and then bringing in what SONA can provide in tying down to a real ROI analysis. Then, you get into the architecture and the technology and how it fits in. And, the part everybody really loves-- you finally get down to buying specific products that implement that capability.
Gardner: So I guess two takeaways from that would be: The good news is that I can do this incrementally; that I don’t have to build it all and then throw a switch one day. It can start on a crawl-walk-run basis. But, in order to make that plausible, there also has to be a top-down mandate for these cultural silos. And all of these different parts need to act in some concert toward an iterative build-out and adoption. There has to be some word from on high that this is our strategy, this is the roadmap, and this is what we’re going to do. Does that sound about right?
Ruh: That sounds about right, and it’s getting people to realize that this can be done incrementally. It makes the most sense to have the discussion around a business problem that you’re going to invest in anyway. And then very naturally the network folks, the app folks, and the architecture folks are sitting around the table and having the right discussions -- which is: which services really belong in the network, which services are going to give us the biggest bang for the buck, and which services quite naturally belong in the other parts of the IT infrastructure? So, it really starts the dialogue down the right path.
Gardner: Well, thanks very much. We’ve been discussing mega-trends and convergence, network services, application services, and SOA. Joining us has been Bill Ruh, the vice president of Advanced Services at Cisco Systems. This is Dana Gardner, principal analyst at Interarbor Solutions for BriefingsDirect. Thanks for joining us.
Ruh: Thanks a lot.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect podcast on network services and SOA convergence. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.
Subscribe to:
Posts (Atom)
