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:
(More details on resources found here)
These qualities make the resource become a perfect pivot for communications between business and IT.
IT can essentially pickup the business description and implement the different resources and resource types:
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.
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.
After all, advantages far outweight the risks. For a more detailed list, see the following SWOT analysis.
The ROE SWOT-Analysis