It's technology that fits inside routers and switches, and works synergistically with Layer 2 and 3 networks. But the goal is to understand the traffic that flows through the network, and what a customer is trying to do.
For instance, we want the network to figure out when a purchase order is moving over the network. The network then asks, 'What does the customer really want to do with this purchase order? What security needs to be applied to it? What kind of format should it be in?' and is able to speak the language of the applications. You've said that AON represents the logical evolution of the network to improve communications. Can you elaborate on that?
The role of the network is to help things -- from your desktop to your Web server or back-end apps -- stay connected. We provided that basic pipe on which to exchange information. But how do we make that more valuable? So we decided to put more intelligence into the network. Everyone understands that it now makes absolute sense to put things like security and load-balancing in the network, so the network is becoming more intelligent anyway. You've also said that AON "simplifies today's overly complex application infrastructure." What systems are AON designed to replace?
I wouldn't say replace so much as displace other systems. Not everyone in the value chain wins when things become more efficient. But if you look at the problem of connecting applications, some estimate that 40% of all IT spending is not actually adding real business value, but making things work with each other.
It's not so much about one product replacing another, but we want to strongly partner with application companies. We don't want to repeat or redo things that others have done. We want to work with the industry. If we can reduce the complexity of working together, we all benefit. That way, if you're a middleware vendor, you can focus on providing more value in middleware.
Let's say that you have two applications -- yours and a customer's -- and they exchange information. Then let's say the applications exchange a purchase order, and for all purchase orders you have security in place, but for this particular one you decide you need a higher level of security. If you want your applications to handle that, there's a lot of complexity involved.
On the other hand, if the customer has an AON router in a branch office and I have an AON switch in my data center, you can use the devices to ensure that a purchase order is digitally signed and verified. What's been added? You may have to put in an extra router or a blade, but you're taking away all the complexity the IT staff would have managed in reconfiguring applications. That's how it will take away a lot of the complexity. With this kind of functionality moving into the network, will network admins be forced to become application experts?
We've carefully addressed that issue. The application infrastructure group is responsible for defining the business-level policies. They would use a tool called AON Development Studio and create these policies. But the way we built the system, they don't actually control what goes into the router. The network admins would then, without deeply understanding the policies, would push these rules to all the switches in all the branches using the AON Management Console. We've defined the rules clearly so there is a handover that happens between groups. The network pros don't have to understand everything about the apps, but they'll begin to understand things as they go along. Others suggest the hidden costs of deploying AON -- such as implementation and configuration services -- could be staggering. How do you respond to that?
I think obviously if you're going to be deploying any technology, there is a cost of deployment. But the reason you do it is because it can offer you more value than if you didn't do it. So your alternative might be to go about this some other way, either by hiring IT staff who will either program, install and customize it themselves, buying a lot of software and some servers and integrating all that technology successfully, or you buy an AON system and obviously invest in customizing and deploying it. So deployment costs are always offset by the cost of not having this level of automation. Then it comes down to economies of scale, where it's cheaper if someone does it on behalf of a lot of people.
Part of it is that we're selling at a senior level to both groups, and executives understand the efficiencies from having their groups working together. We also connect to the application groups, and we go in demonstrating an understanding of their problems. We've recruited what one analyst called a team of seasoned middleware veterans that can go in and demonstrate that we understand the network side and the application side. Microsoft was noticeably absent when you announced your list of AON partners during the initial launch. Do you foresee Cisco and Microsoft collaborating on AON?
Cisco and Microsoft have a lot of common interests and we talk regularly. Our partner strategy for AON is that it's not about exclusive relationships; it's where it makes sense. Where it makes sense for us to work with [Microsoft] on custom problems, we definitely intend do to so. Microsoft is welcome to provide value-add technologies that would plug into AON just like other vendors could. The technology is there for that already; it doesn't involve us having to do a lot of things. Discussions happen continually between Cisco and Microsoft, and we're definitely willing to work together. You've already announced plans to incorporate AON technology in routers, switches and network appliances. What comes next?
There is also going to be a set of solutions as part of the AON family that cover intelligent message routing, RFID, B2B and a number of other solutions that we haven't announced yet.