Home of the Resource Oriented Enterprise



Why is it compelling?
The REST Business Case

26 Oct 2009

Direct link to conclusion and SWOT analysis.



According to a recent study of the Burton Group[burton1], developing a business case for any SOA initiative is complex, because the development of social capital and strong relationships between business and IT are decisive for SOA’s success within an enterprise. But these parameters decide if (massive) financial investments will have a positive ROI one day.

Fundamentally, there is no doubt that SOAs are the way to go in enterprise architecture. As mentioned in my introductive article, mergers and acquisitions, general organizational restructuring and, in today’s contracting economy, short-term changes in product-lines ask explicetely for an agile enterprise software architecture.

Business decisions are obviously made by the business departments – whereas SOA initiatives are typically driven by IT departments. This specific constellation requires a high degree of mutual willingness to drive SOA initiatives to success. The IT side is challenged to co-operate closely with business to solve their issues – on the other hand, business is required to recognize the chances it is getting with SOA and to fund SOA projects.

That’s a big point. Businesses have always been quite pessimistic about new IT developments. No wonder, because more often than not it was difficult for the non-tech-people to recognize the advantages of the latest IT hypes. And SOA has done no better, so far.


Closing the gap

So, the question for the ROE was “How can we close the gap between business and IT, or at least narrow it?”, and “How can we make SW-development more efficient and agile?” No doubt, these have been longtime issues in SW-architecture, not only since Gartner’s latest hype, the “Emerging Architecture”.

In the eighties, business and IT gathered around relational data models, later around object- and UML-models. Discussion circled around objects like “customer” or “claim”.  Of course, that discussion was not about SW architecture, but more about modelling single problem domains. Entities and objects were given primary keys, but they have been “primary” only within one collection of, let’s say, customers. What this really meant within the enterprise remained unclear, as only at a very late project stage, i.e. at the deployment into production test or production, the new solution was exposed to its enterprise environment. At max, application-scope data models tried to adhere to “enterprise-wide data models”, usually with little success. Remote procedure call techniques (RPC) just had been a logical addition, they made DB tupels or objects remotely callable. As the name implies, they offer procedural interfaces that enable clients to call a certain table’s entry by primary key.


The better pivot

With the advent of the WWW and REST, a new focus point appeared on screen: the resource. Let’s recall what a resource is:

  • It can be basically everything
  • It has an address that identifies it on a potentially enterprise-wide scale, the URI
  • It can have different representations in the form of hypermedia formats (they also form the interface contract)

(More details on resources found here)

These qualities make the resource become a perfect pivot for communications between business and IT.

For business:

  • Business can describe, in their words, what a resource is. This might include state, but also behaviour. Describing behaviour means describing the resource’s reaction upon HTTP’s basic requests (GET, POST, PUT, etc.).
  • Business is not limited to define an ID within the limited scope of a collection, but can classify the resource into an enterprise-wide taxonomy, with the help of the URI.
  • They can reference (link) to potentially any other resource in the enterprise
  • Business can define complex views easily (mashups), by linking to other resources
  • They can ask for certain representations of the resource
  • Defining security constraints (authorization)

IT can essentially pickup the business description and implement the different resources and resource types:

  • Understanding the requirements
  • Design and implement the new taxonomies and nodetypes incurred by the business spec.
  • Plumbing of the logical taxonomy trees with legacy systems

Thus, there is a direct path from business spec to IT design and implementation. Instrumental for this direct path is a resource oriented middleware that allows for implementing the hierarchical taxonomies and the nodetypes in a straightforward way.

This approach generally facilitates and eases communication between business and IT. E.g. functional testers can exactly describe, by the means of an URI, where they experienced problems. Workflow implementations can exactly define which resources they manipulate and under which conditions.


With or against HTTP

And on the technical side?  The preferred protocol for today’s intranet communications is HTTP. One reason is that it is an “approved protocol” by security departments. Consequently, many protocols “tunnel” their protocol through HTTP, pretending they are HTTP.  In reality, they make very poor usage of HTTP. They use it as truck, HTTP is only to carry their “load”.  But why use such an approach, if HTTP is already by itself a complete protocol on the application level that is supported by the enterprise’s network infrastructure such as routers, firewalls, caches and other protocol sensitive equipment?

The cost of “transport-protocols” is considerable. Not only put they additional load on the infrastructure, worse they don’t leverage it. For instance caching: because WebServices tend to address only a few endpoints (URIs), request responses cannot be cached and thus, all requests have to go to the final endpoint. Additionally, instead of going through HTTP libraries only, WS requests get parsed and processed by a manifold of software layers who make interpretation of WS envelops and content.

All that needs to be controlled by developers and administrators, so additional training and programming effort is necessary. The WS protocol stack is a complex specification that is overseen and understood by only a few. Opposed, HTTP is common place, understood by most, even by business-people in its basics, and there is an outstanding number of software components and libraries available. HTTP as an application protocol covers all but a few of WS* features, and it is applicable for most cases in business IT.


The risky parts

However, the ROE comes with costs and risks, too. Tool-support for developers is not as good as it should be, in particular on the client side. Architects and developers experienced with repository- and hypermedia oriented systems are (yet) harder to find. Hypermedia exchange formats such as microformats or ATOM need to be defined first (for the particular enterprise). Especially the programming model, HATEOAS (Hypermedia As The Engine Of Applicaiton State), will be a challenge to them for the startup period, until they understand that this concept will give them so much power on server’s side programming like hardly anything before. It will take a while to change IT’s mindset. That’s a considerable risk.

The lack of support for short 2-phase-transactions is considered a risk, but one relatively easy to mitigate. They are needed only in distributed transactions involving multiple resource managers. Typically, this type of transaction takes place when interacting with legacy systems; in this case, the resource implementation will assume the role of the transaction originator.


The bottom line

There is only very little doubt that SOA is the way to go in today’s business environments that ask for quick and agile adoption of enterprise systems. REST is the SOA style that is adopted by the ROE.


  • Improves dramatically communications between business and IT, because it introduces a new “pivot” between them, the resource. Requirements get more precise and are easier understood by both parties.
  • IT know how (in development and data centre engineering) on a standard protocol such as HTTP is far more spread than for any other protocol.
  • Already today, the company’s whole network infrastructure supports HTTP. It is all about leveraging this fact.
  • HTTP/REST leverages. Reference: the WWW.


  • New challenges arise mainly because developers must change their mindset and experienced people are harder to find on the market
  • Systems integration poses challenges, because most legacy systems do not offer REST interfaces. This might change in the future, especially with the advent of CMIS and other REST-interfaces, but for the moment, that’s a fact.
  • Developer tools, in particular on the client side, are not yet there where they should be.

After all, advantages far outweight the risks. For a more detailed list, see the following SWOT analysis.


The ROE SWOT-Analysis





  • extremely well tested through the world's largest IT system, the World Wide Web
  • architecture based on well-defined architectural style (REST) and industry standards (HTTP, hypermedia formats)
  • Wide-spread know-how in the enterprise, so steep learning curve is possible
  • “open source”, i.e. architectural foundation is openly available and widely discussed
  • Massive simplification of systems integration expected
  • Uniform communication scheme among the entire enterprise
  • Includes uniform security architecture
  • better search through systematic information structure
  • Same architecture/programming model for intra- and extranet applications
  • Extremely easy testing
  • Little experiences (also from external consultants) with REST as enterprise architecture
  • Media types and hypermedia exchange formats need to be agreed on
  • Taxonomies and nodetypes must be very well thought, as they should remain stable, potentially over decades (might be also a strength, eventually)


  • HTTP runtime infrastructure already completely available in the enterprise à no further investments required
  • Optimal usage of infrastructure by “pure” HTTP usage
  • HTTP is a lightweight protocol, avoiding unnecessary/overhead levels of software as in other protocols
  • HTTP is ubiquitous, so uncountable software components are available, for all platforms and programming languages
  • Support for “long” transactions already included
  • Excellent SOA infrastructure support for REST concepts, including governance and security
  • Many excellent testing tools
  •   Most legacy systems need still be “equipped” with REST-/HTTP-style interfaces
  • Tool support for developers not as good as with RPC WebServices, in particular on the client side; poor BPM-tool-support, BPEL extension request still pending
  • Lacks support for short transactions; security concept not as refined as with RPC WebServices
  • not suitable for extremely time-critical real-time applications


  • Common vocabulary facilitates communication between business and IT
  • More efficient and faster application specification writing through concepts like URI and resource; mashups easily describable
  • Simplified user testing
  • More efficient support calls, owing to better defined issue entries
  • Change mindsets of all involved
  • Training efforts, for both, business and IT personnel
  • IT need to take gap with new programming model



  • Industry seems to be moving towards REST architecture style, too, e.g. with JCR and CMIS standard
  • Eases access for external partners via powerful yet simple REST-based APIs à makes our eCommerce portal more attractive
  • HTTP and REST are here to stay
  • HTML 5 better considers needs of enterprises
  • Industry direction not as clear as desired à CMIS not yet in final version (incl. REST bindings), and for document management systems only


burton1 "Building the Business Case for Service Oriented Architecture Investment", by Richard Watson and Chris Haddad (and noteably co-authored by Anne Thomas Manes), Sep. 18, 2008