Just as many IT shops are starting to get their arms around the service-oriented architecture (SOA) approach now that Web services standards are emerging, there's already a "next big thing" on the development horizon, according to Gartner.
Four years from now, "mere mortals" will begin to adopt an event-driven architecture (EDA) for the sort of complex event processing that has been attempted only by software gurus building operating systems or systems management tools, and sophisticated developers at financial institutions, predicted Roy Schulte, an analyst at Stamford, Conn.-based Gartner, which held its Web Services and Application Conference here this week.
Fortunately for IT shops, the EDA approach is complementary to SOA, which forward-thinking IT shops are starting to employ in greater numbers as they forge ahead with Web services. Taking an SOA-based approach, developers build an application by assembling "services," or software components that define reusable business functions.
One of the main advantages of the SOA approach is that by building standards-based interfaces between components, developers can incrementally construct applications and swap out, reuse and modify components without having to concern themselves with their inner workings. Those who build Web services typically describe the interfaces using the Web Services Definition Language and send XML-based messages between components using SOAP over HTTP.
But Schulte said connecting services occurs in a linear, predictable sequence, whereas an event-driven architecture allows for multiple, less predictable, asynchronous events to happen in parallel and trigger a single action.
Simple event-driven processing has been in common use for at least 10 years with technology such as IBM Corp.'s or Tibco Software Inc.'s message-oriented middleware and, in the past few years, message-driven Enterprise JavaBeans, he noted.
But Schulte predicted that complex event processing (CEP) will start to become mainstream in 2007, as application developers and systems and business analysts strive to do more business in real time. Paving the way for the trend will be faster networks, the arrival of general-purpose event management software tools and the emergence of standards for event processing beginning in 2005, he said.
Hints that CEP will become mainstream include Palo Alto, Calif.-based Tibco's acquisition of Praja Inc. and IBM's work on event-broker technology, Schulte claimed. "It's obviously the first step for IBM, and the next step will be complex event processing," he said.
David Luckham, a professor of electrical engineering at Stanford University and author of a book on CEP, The Power of Events, said the goal of CEP is rather simple: delivering understandable information about what's happening in IT systems. That information, in turn, can be used for a variety of purposes, such as detecting unusual activity, improving security and recognizing advantageous scenarios in CRM and supply-chain systems.
"The events in IT systems contain untapped information. CEP lets you extract it and use it in ways you want to," he said.
Luckham predicted that CEP will start creeping into Web services, middleware and application servers in 2005. By 2008, he foresees the emergence of CEP standards, languages and complex event-pattern search engines. Ubiquity of CEP will come in 2012, he forecasted.
To prepare for EDA, Schulte advised companies to look at their application requirements to see if there are places where they could do simple event processing instead of SOA to design part of an application. Leading-edge companies should also look to implement complex event processing for applications that bring a competitive advantage, he said.
Meanwhile, users who still haven't adopted SOA are trying to sort it all out. "Before you get time to deploy one thing, the next thing's already out," said Vito Iannuzzelli, a senior systems architect at New Jersey Manufacturers Insurance Co. in West Trenton, N.J.
IT Managers Still Working on SOA
Gartner Inc. may see event-driven architecture as the "next big thing," but plenty of IT managers are still struggling to lay down the foundation for the current one -- service-oriented architecture (SOA).
Gartner analyst Daryl Plummer estimates that no more than 30 percent of IT shops are doing SOA-based development by design, and among that group, less than half are doing it consistently well. But he predicted that 85 percent will be building applications using SOA concepts five years from now.
"It's too early for us," said Glyn Crocker, e-business applications manager at Shell Oil Products US in Houston. But he said he does see opportunity "to bring quick business value without having to rewrite legacy applications."
Robert McCarlie, a group manager in the e-business group at Royal Bank of Canada in Toronto, said his company is in the "education phase," still figuring out what it might do with Web services. "But the concept of being able to loosely couple legacy applications is quite interesting," he said, even though Web services security is still immature and loose coupling and the "verbosity of XML" cause performance hits.
The SOA concept isn't new, but SOA has become a buzzword now that Web services are hitting the mainstream. Services are exposed to one another through standards-based interfaces, and SOAP is used to send XML-based messages between them. Because components are loosely coupled, developers can easily swap them out and, in theory, gain the benefit of code reuse.
But several IT managers said they won't be holding out high hopes for code reuse. "It's a major culture change because people have to be willing to share and use someone else's code," said David Wei, application development manager at SDG&E, a unit of San Diego-based Sempra Energy.
"It's an ego thing," said Xavier Soosai, a senior manager and IT architect at Farmers Insurance Group of Companies in Los Angeles. He said he would expect no more than 60 percent reuse -- "100 percent reuse is not realistic." Soosai said Farmers will use the SOA approach "just where it makes sense" and won't replace existing code with new Web services because that would be expensive.