X
Business

Not all SOA services are, or should be, created equal

System resources need to be applied differently to a large customer with a multi-million-dollar order, versus multiple customers with small orders.
Written by Joe McKendrick, Contributing Writer

In a talk delivered at the recent InfoQ conference in London, Udi Dahan delved into his experiences planning and building service-oriented systems to discuss a critical link to meeting business requirements: the robustness and system requirements called for in services.

Service orientation needs to be applied differently to a large customer with a multi-million-dollar order, versus multiple customers with small orders, he says. Often, SOA-enabled services are put together at design time with uniformity and consistency in mind. The ability to configure systems resources to meet a large order is what Dahan refers to as "runtime coupling" of components and services. However, few architects and planners look at the impact of runtime coupling on business requirements.

That makes it difficult to shift capacity as new business opportunities roll in, he says. "When the business says 'we're signing up Steve Jobs as a customer,' you need to able to say 'okay, we have the ability to dedicate IT assets for specific customers. We are able to turn around business dollars to have an impact on what the business cares about, and not have the hardware wasted on a whole bunch of other users we don't care as much about.'"

This has been the problem with the standard layered step built into SOA-enabled systems, Dahan says. "It all looks the same, it serves everybody."

The ultimate form of IT-business alignment is this ability to dynamically divert resources to situations that are important to the business. By emphasizing this runtime coupling of services, and de-emphasizing design-time coupling which assumes all customers will have equal requirements, organizations can also "reduce dependency on specific technologies, and get a lot of the benefits that were under the banner of SOA -- but in a slightly counter-intuitive manner, not in a straightforward Web services manner," Dahan says.

He also provided this nugget to ponder:

"Anyone who thinks they can just think about architecture but not think about technology has not yet put a system into production. Then are people that don't think very much about the business, so you get a very well designed system that the business doesn't use."

(Photo: Udi Dahan, from www.udidahan.com)

Editorial standards