The Link Between Services and Events
Events are the eyes and ears of the business expressed in technology - they detect threats and opportunities and alert those who can act on the information. If services make enterprise architectures more flexible and responsive, events make them more alert and better prepared to sense problems before they become disasters (and sense opportunities before they're lost). Using events to drive architecture design brings IT closer to having a direct impact on the business's P&L.
And, like services, events can be expressed in terms that businesspeople understand. "CEOs and CFOs are event-driven people; it's how they solve problems," says David Luckham, professor emeritus of electrical engineering at Stanford and one of the leading lights of event-driven systems. "When problems get pressing enough, they begin looking at the series of events that led to the problems to see what happened and what they can do about them."
IT needs to begin architecting systems in the same way, say the event gurus, starting with events that matter to the company (supplier shortfalls, long wait times in the call centre) and building IT systems that monitor and respond to those problems. For example, when the system that monitors a credit card transaction processing system sees a $10,000 charge come in on a credit card with a $2000 limit, the system sends an alert to a credit supervisor and automatically shuts down the account.
Though, traditionally, they have been viewed as separate technologies, services and events are converging. Because service-oriented applications and workflows are so loosely linked, with developers writing links to services whose design and application composition they may not fully understand or control, developers need to consider events in their designs.
For example, Lydian Trust's enterprise architects designed a service called "get credit" that is used by several different product divisions within the company for different loan application workflows (cars, mortgages and so on). "Get credit" is a Web service that seeks out credit ratings over the Internet from the major credit bureaus.
One day, one of the credit bureaus' Web servers went down for hours. When Lydian Trust's "get credit" service tried to make the call, there was no answer. Because the connection to the server was loosely linked, the system didn't know what to do. "Get credit" hadn't been built to make more than one call. So while it waited for a response, hundreds of loan applications stalled.
Loan officers had to work overnight to make sure the applications were completed within Lydian Trust's promised 24-hour response window to customers. Customers never felt the pain, but CIO Studdard and enterprise architect Barbato certainly did. "There are many more dependencies in a services environment," says Studdard. "The system has to be able to deal with the existence of certain events - or the lack of an event - in a way that doesn't interrupt the overall flow."
For example, "get credit" is now programmed to keep calling the credit bureaus' servers for 22.3 hours before giving up. If the service hits a snag, an e-mail alert goes to an IT manager and automatically gets sent to a higher authority if that person doesn't respond. "This is not the kind of stuff that's available out of the box," jokes Barbato.
EA Magic
Very little having to do with enterprise architecture is available out of the box. It is a competency that must be built from within, unique to each company and that company's culture. But developing that internal capability is critical to bridging the value gap that persists between IT and the business today. Internal IT groups simply have to become faster, more responsive and more flexible to survive in this era of automation and outsourcing. "If I had a wand and I could wave it, I would make everything happen a lot faster in IT," says Alan Buckelew, president and CIO of Princess Cruise Lines.
Building an enterprise architecture based on services and events is the best wand Buckelew - or any CIO - could wield today.
EA Needs Governance
If enterprise architecture is about the business (and it is), you need to get the business involved.
An EA group is most effective when it knows more about the business than individual application project managers do. That means building governance mechanisms to get that knowledge.
At T-Mobile, the central EA group is divided into four clusters, according to key technologies across the company. In addition to the four technology clusters, there's a business cluster composed of businesspeople from strategic planning, marketing and sales. This business group focuses mostly on developing ideas for new products that can be delivered through the enterprise architecture. It provides a crucial link between IT and business strategy that is part of, rather than separate from, the EA process itself.
That's the link missing from most EA efforts; certainly it was missing from earlier efforts at T-Mobile, says Hossein Moiin, vice president of technical strategy for T-Mobile International. "You need to consider who the customer of the architecture is," he says. "In the past, our efforts have suffered because we failed to engage the right people."
Governance is the way to reach (and keep reaching) the right people.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.