Time to Rain on the “Cloud Service Model” Parade

The Cloud community have been talking recently about Everything is a Service; they call it EaaS. At first hearing it’s an interesting idea, another acronym to complement IaaS, PaaS and SaaS. Unfortunately it’s rather like the tail wagging the dog!  The Cloud community use the term Service liberally but with minimal consistency.

It must be said that the NIST reference architecture document has been incredibly helpful in sorting out the three Cloud service models of IaaS, PaaS and SaaS. However in order to read the document you have to suspend all your knowledge and belief of services and read the document interpreting all references to service as “provision or access to some capability”. In other words as a generic IS service of some sort.

Actually most Cloud infrastructure resources are provisioned as well formed services governed by interface and SLA contracts. There are a few SaaS providers that have implemented an SOA – in compliance with generally accepted principles of loose coupling, separation etc. However most Cloud services are multi-tenant application resources with integration capabilities delivered as Web services. Yet perceived wisdom generally says that SOA is essential for Cloud!

I noted an interesting paper from Intel recently[i]; the thing that really struck me was the way the paper describes how Cloud development as the Wild West (my words), and the author is advocating ideas that amount to rediscovering the SOA wheel!

SaaS and PaaS providers are circumventing traditional enterprise architecture. Compliance and visibility has decreased. Simply put, your enterprise is likely already part of the app economy. The question is, how are you managing your API traffic? Do you have a control point to manage that participation? Enterprise APIs are not science projects; they’re conducting enterprise-class business and require enterprise class visibility and control. What path can enterprises take to prepare for secure use of APIs? Dan Woods, Chief Analyst, CITO Research and Colleagues, May 2012

And the author goes on to describe how Cloud needs to move beyond point to point integration to introduce something that sounds very much like an ESB! So the notion that de facto Cloud practices should form the basis for EaaS sounds fanciful.

Yet despite this, I believe we should look closely at the idea of Everything as a Service. It’s the vision that CBDI and other pioneers painted years ago. What’s really required is a convergence of business and IT service concepts that would provide consistent views for all the various stakeholders in both IT and business domains including the service owner, business service designer, IT service architect, IT service designer, service security architect, provider, IT service manager, service broker, service consumer and so on and so forth. Today we have disparate service models in both business and IT that positively encourage silo disciplines.

To produce some form of unified service model wouldn’t be just an academic exercise.  First it might just facilitate better understanding of service architecture across business and IT stakeholders. Second it might assist in better service design, delivered services that are fully integrated with people, product, process and technology and engineered to deliver individualized services to customers that are architected to be responsive to business change!

But the place to start is to understand the needs and opportunities in a unified service model. This will leverage the Cloud, and hopefully cause more service owners to demand their services are first class software services in order to deliver better customer service. Maybe this will encourage NIST to revisit its reference architecture and give the service perspective a little more integrity.

In this month’s CBDI Journal we publish an article exploring how such a unified model might look, and the business value that it might deliver. We welcome feedback and comments.

CBDI Journal Report: Everything is a Service?

Abstract: The Cloud movement is discussing the term Everything as a Service (EaaS or XaaS).  In principle this is a welcome development, encouraging business and IT participants to adopt services and service oriented concepts everywhere. However it appears that the E/XaaS initiative may be more about marketing than reality. In this article we suggest how this very promising idea might be developed to clarify Cloud Service taxonomy and deliver convergence of business and IT perspectives in a Unified Service Model.   

---

[i] Enterprise-class API Patterns for Cloud & Mobile

RBS Crash - Management Prefer Offshoring to Modernization?

When you slump into your aircraft seat you don't give a seconds thought to whether the aircraft is properly maintained. Same on the Eurostar or TGV, and you don't worry either about the air traffic control systems or the railway signalling systems. We certainly don't give any consideration to our bank's systems . . . until last week when the RBS core banking system fell apart. Tens of millions of customers in the UK and Ireland were unable to draw cash, pay bills, check balances. And most of them found they relied on their bank more than they realized as mortgage payments were not paid, credit limits were exceeded and individual's credit ratings were downgraded.

The bank responded with good PR but abysymal action. A week later many customers are still in trouble. The PR spin on the cause of the crash has been attributed to a misapplied patch. On the Internet, the cause is being attributed to:
- Total lack of investment in modernizing ancient core banking systems because of perceived cost and risk by the Leadership Team too busy counting their huge bonuses  . . .
- Who instead cut costs by outsourcing the core banking systems support to India to be supported by people with weeks of experience at best . . .
- To be trained in a few weeks by highly skilled staff that have decades of experience who are now being made redundant . . .
- Who will now be blamed (because they are no longer there) for the totally inadequate change control, contingency planning, fall back procedures . . .
- The absence of which will be effeciently swept under the carpet so that . . .
- The regulators inquiry will find the management's explanation of the "Act of God" as entirely believable and will report same so that . . .
- Levels of government funding (this is a bailed out bank) will be continued and senior management bonuses will be paid as usual.

We live in a real time world. Core banking systems (and other businesss domains also ) should be managed in the same manner as aricraft and air traffic control systems. They should be architected and designed to undergo constant change and supported by security, contingency and fail safe systems that are tested by independent experts on a frequent basis. Continuous investment in modernizing core systems and the surrounding ecosystem is  necessary housekeeping. Further modern architecture approaches and methodology enable progressive modernization and continuous evolution in a properly managed environment. Continued investment in skills is equally important by maintaining continuity of personnel and investing in their education in the new architectures and methodology to complement their deep, core business expertise.

Outsourcing and or offshoring just just save money is analagous to finding ways to keep the Boeing 747 running for another 20 years by bringing in maintenance engineers skilled on single engine turboprops and expecting them to acquire 30 years of experience in weeks. Similarly architecture led application modernization is a new IT discipline that banks and other organizations need to understand and deploy. You don't find this level of expertise by offshoring to a company that advertises on the open market in February 15th 2012 for "4 - 7 years experience of Batch Administration using CA7 tool. Urgent Requirement by RBS." Location: Amberpet, Hyderabad, India.  Nuff said!

Is Outsourcing the Cause of the RBS Debacle?
RBS Collapse Details Revealed