Based on my professional activities, I have been faced to explain the advantages of Resource Oriented Architectures (ROA) to a number of customers. Some of them with technical, but most with business background. Granted, you don’t want to provide the link to Roy’s dissertation to a business person… nor tell them, what great infrastructure we have to implement the architecture. Personally, I came to a conclusion, which I am glad to share here. This article tries to elaborate what the number one business driver for ROA is, IMHO.

Back at BEA eWorld 2002, BEA co-founder/CEO Alfred Chuang had somebody to steal his car during his keynote. The car was found again - courtesy to a car-locating-system, which communicated with registered cars via the latest technology hype of the coming era: web services. The car was hot, the show was fun, but one big question remained: what difference made the web services? To make this story short: none. Because the same could have been achieved with any other RPC-based technology. From the viewpoint of the business – in this case the car owner – web services did not add any specific value, so business can remain essentially agnostic about the current communications fashions in IT. IT is simply perceived as a cost center.

With almost 3 decades in IT, I have seen many of those fashions come and go: bare-boned socket connections, DCE (yes, I do mean distributed computing environment), transaction monitors, CORBA, component models such as EJBs and DCOM, WebServices... Have any of these evolutionary RPC-steps made us, information systems developers, more efficient? Not much comes to my mind. It generally was rather an exercise to move bytes from A to B in the hypest fashion.

Even corporate intranet projects were driven by rather weird, heavyweight technologies like portal/portlets or "document-driven collaboration solutions". In particular, they appeared overly complex in comparison to that system that has been growing at light speed for 15 years now: the WWW. Moreover, it has exactly the qualities we’ve been looking for in enterprises: scalability, flexibility, reliability, speed. In 2009, the prime time for the "Enterprise Web" seems to come, thanks to progresses in web oriented middleware technologies and standards, but also owing to a common gut feeling that WS* have somehow failed to fulfil their promises.

So, what's the ROA advantage?

Many will happily cry: Web 2.0 support! I won’t. Sure, information exchange can improve with blogs and wikis, thereby smoothing the biggest nightmare of the information age, I mean the tons of emails that flood our mailboxes every day.

But I think that ad-hoc information generation is rather the exception than the rule in the enterprise. The typical enterprise is highly process-driven, hopefully by well-defined ones, but more often than not by ones that have been defined informally. Many of these processes, even the well defined, are not well implemented: they lack access to related information, either intentionally (too costly to access data on different systems) or un-intentionally (process designers have been unaware of other relevant information). Both reasons may have their origins in one of RPC’s major deficiencies: services still are not really loosely enough coupled and they lack a truly overall addressing scheme.

It is primarily the latter where I see the biggest advantage of ROA, and that advantage has a name: URI, the Uniform Resource Identifier. With it, we are able to give any chunk of information a unique identity and a location - on an enterprise wide level. The "chunks" can be anything, from small to large, from a database record to an image in some DMS, from pure data encapsulations to function-only resources. Consequently, we give process designers the opportunity to integrate any relevant information into their "process space". And vice-versa, the process’ output will be as easy available to others, no matter where else in the enterprise the consumer resides.

Thus, Resource Oriented Architectures promote an enterprise addressing scheme that is truly re-usable. Instead of building, like in RPC-based architectures, thousands of point-to-point, tightly-coupled connections between systems, business analysts are asked consume information out of large, business-oriented classification trees, and store their outcomes back into some specific position into this tree.

Consider an old-fashioned cash withdrawal at a teller’s window. This process consumes base information about you, your account, the teller, and may require viewing an image containing the scan of your signature for verifying your identity. Each of these information fragments might come from different systems, i.e. different information silos, but the addressing/classification scheme acts as glue here.

On the other end, the process produces information about your withdrawal, which might include the data (time, amount, …), and perhaps a physical receipt you had to sign. These artefacts can be stored in a well defined place in the information tree, e.g. at //mybank/privateCustomers/4711/accounts/checking/transactions/20090510-1/details, and .../20090510-1/receipt respectively.

As you may have noticed, I have not mentioned IT in the description above. REST comes with inherent concepts that help the enterprise to run its business simpler and with more transparency.

The concept of an overall addressing scheme that makes information directly available via uniform resource identifiers, comes as a direct advantage to businesses.

Of course, the engine that empowers this uniform access has to come from IT. But unlike its RPC-style predecessors, this is not something that happens under the covers in some obscure manner; the introduction of ROA impacts directly on how businesses and their knowledge workers will operate.

This is the main message we have to carry on to the management and business levels of companies. Still noteworthy though that the technical implementation of ROA can happen on relatively simple and low priced infrastructure. The same time, we can simplify our SW stack by leaving alone many unnecessary SW layers. This might be considered a side effect; however, it improves the Return-On-Investment of ROA, a "hard" argument, which will be paid much attention these days.