News

Technology-agnostic approach to Service Oriented Architecture: back to the essence of SOA?

Posted by Sadek Drobi on Sep 26, 2007 12:07 PM

Community: Architecture,; SOA
Topics: Business Process Modeling,; Enterprise Architecture,; Design
Tags: Business Architecture,; SOA Adoption

Service Oriented Architecture has become one of mainstream practices in enterprise software development. However, according to Dan North, the adoption of SOA has been shaped by tools offered by software vendors whose interest is "to emphasize the complexity of SOA and then provide a timely and profitable solution.” As a result, decisions of many SOA architects have been driven by technological considerations instead of focusing on mapping and modeling core business scenarios, which is the essence of SOA approach.

In his article, Dan North shows how to design an SOA in “a technology-agnostic” way. In order “to remove any reference to computers or modern technology”, he chooses to use the example of vacation booking process as it “would have occurred in a 1950s company”. In this business scenario, an employee Bob proceeds with his vacation booking that has to be approved by the personnel department. Step by step, Dan North illustrates how to identify SOA requirements based of a thorough mapping of business processes:

In SOA terms, the personnel department is a service provider. One of its services is scheduling annual leave. Bob is a client or consumer of the service. The vacation request form describes a service contract. The filled-in form is then an asynchronous message—Bob doesn’t suspend his activities waiting for the reply to come back; instead he gets on with his regular work.
The internal mail is a message transport — an unreliable one in this instance. Luckily, Bob has an error-handling protocol, namely a timeout. After a week, his calendar alerts him to call the personnel department. The telephone call is a synchronous interaction—he is on the telephone in real time. He then implements an error-correcting strategy, which is to resend the message.

While talking about the error-handling strategy, North provides even more examples of SOA requirements defined through business process modeling. If someone updates vacation records to reduce the number of leave days before the vacation approval and then the request goes missing - as in Bob's case - it could result in inconsistencies with the records. Understanding this drives to the conclusion that “the vacation-booking service has to be transactional”. A request may also fail for some business reasons, e.g. the allowance is used up, a signature is missing, etc. In SOA terms this is referred to as “semantics” or “business rules”. In this case a response should be sent back to the person concerned returning the reason of the failure. In a similar way, North shows how the business context defines SOA requirements for correlation of responses, availability of services, security or service evolution.

According to North keeping focused on real business issues allows “to separate the “what” from the “how””:

In fact, a true service-oriented architecture should only have services with a direct counterpart in the business; otherwise they cannot possibly be modeling a business process.
Abstract technical concepts, such as a “data service” or a “replication service,” don’t make any sense in business terms. (There may be shared modules or libraries to provide common technical functionality, but these should not be implemented or referred to as services.)

In the same line, North argues that architects should avoid defining a universal domain model if in the reality there are two separate domains. For instance, “vacation” doesn’t mean the same thing to Bob and to the personnel department clerk in charge of leave requests. For the former it relates to “palm trees” and “long walks on the beach”, while for the latter “it refers to the business process around booking that time”. North believes that these two domains should be represented as such whereas “vacation” should be used as a business concept that “ties together all of the finer-grained domain models behind each service”. Not only would it better reflect the reality but it would also have advantages in terms of architecture:

The service contract is then expressed in terms of enterprise-level business concepts, such as a vacation or a dispatch or a sales order, which again decouples the service consumer from the service provider and allows them to evolve independently, while still able to communicate in a common language.

Dan North is fully aware that designing an SOA through business processes modeling is "only the first step to implementing a fully working SOA". However, focusing on business issues helps “to understand [the] intent of the service [and] to investigate any business complexity independent of technical issues”. This way, SOA requirements are defined without being constrained by technical decisions, which can always be "mapped back to identifiable business value in terms of the business process" that is being modeled.