What does Cisco's AON announcement really mean for your SOA roadmap? A lot of enterprise architects must be scratching their heads over that question, now that Cisco has revealed details of AON, its application-oriented networking pitch, which I previewed last week. I'm working on a detailed assessment of the impact of AON to be published in the July 2005 Loosely Coupled monthly digest, but in the meantime here are some immediate thoughts about AON and how it's likely to fit into an enterprise SOA. (By the way, the subscription price of the Digest is going up by $100 as soon as we get around to updating our online ordering pages, so if you want to read my analysis, now is a good time to get your order in.)
First of all, let me run through a quick overview of AON as presented by Cisco. There's much more on Cisco's website in a dedicated AON section, so think of the next few paragraphs as a brief executive summary.
Cisco defines AON as A Network Embedded Intelligent Message Routing System: "Cisco AON natively understands the content and context of application messages, such as purchase orders or stock trades, and conducts operations on those messages in transit according to business policies." It is described as having five core capabilities:
Intelligent messaging translation and routing of information
Application-level security access control and data protection
Business event visibility capture, aggregation and forwarding of event information
Extensibility Open interfaces for third-party and custom extensions
Probably the most compelling items on this list for the first wave of customers are numbers two and three. By taking security out of the hands of application developers and putting it on the network, AON allows enterprises to enforce consistent security policies throughout the infrastructure. Similarly, achieving visibility of business events at an infrastructure level makes it much easier to consolidate information and view what's happening in aggregate. A short video by Cisco's CIO Brad Boston exemplifies this in the context of Cisco's own IT infrastructure (yes, Cisco really is eating its own AON dogfood).
But both these outcomes are achievable by establishing an SOA with or without Cisco AON. What makes AON so different from existing alternatives, according to Cisco, is that it's embedded in the network, right there in or alongside the Cisco IP routers and other network gear. Why exactly this makes a difference isn't something the Cisco guys are particularly good at articulating. I think that's mainly because the benefits only become self-evident when AON is pervasive throughout the architecture. At present, that's possible for only a small subset of customers with specific requirements and implementations: there's only a small set of products to choose from, and even those are on restricted availability until later in the year.
Cisco has a three-phase strategy for establishing AON (which, by the way, is itself phase three of Cisco's Intelligent Information Network vision). Mainstream pervasiveness only materializes once phase three is well under way:
Phase one is simply to introduce the category, begin integrating it with other Cisco products, get some customers and partners on-board, and produce an initial set of horizontal and vertical solutions.
Phase two focuses on "building out the ecosystem." Cisco believes it's vital to AON's success that it gets broad industry support from both hardware and software vendors. It will be looking to other network hardware vendors to develop custom hardware for the AON platform, while working with software vendors to develop AON-based solutions and integrations. At the same time, it's going to be building out the product set.
Phase three will be a drive for mainstream adoption, with Cisco delivering an entire family of AON products for everything from home networking up to enterprise and service provider environments. The AON team ultimately envisages "self-discovering networks of AON systems," which sounds a bit creepy but is probably benign and not sinister at all ...
If you're happy to wait until mainstream pervasiveness arrives, then you can afford to sit back and relax for a few years yet. But Loosely Coupled readers tend to be the more adventurous early adopters, so the question for them now is, how does AON change things?
I think the answer is that you need to start looking at the application infrastructure as something that straddles software and hardware rather than being a wholly software artefact. Instead of thinking of hardware appliances as special-case anomalies that are relevant only for point functions such as accelerated XML processing or XML firewall, look instead at how they might fulfil certain layers of functionality within your infrastructure. And instead of viewing enterprise service bus or enterprise integration as just a software layer, consider performing elements of inter-application messaging within a layer of hardware. Some hefty cost and maintenance benefits can certainly be achieved by taking that approach, as I'll be discussing in my July report.
A case in point is cited by Actional, which did well to feature as the only SOA management vendor named by Cisco as an AON partner at launch (given Cisco's commitment to partnering on AON, it won't be long before others are added to the list). Actional's lightweight "Ghost Agent" is being used in a couple of early AON deployments to feed back information on application infrastructure and business events to Actional's Looking Glass management console. Its press release highlights that "customers can now perform business analysis at network speed without sacrificing CPU capacity from application hardware."
By the way, if any readers have experienced the benefits of deploying XML messaging hardware in their own SOA projects, please share what you've learnt, either by commenting here or by emailing me privately (use our feedback form and tick the private box before submitting).