InterCloud Records Management

One of the more powerful underlying aspects of Cloud Computing is what is called the ‘InterCloud’, referring primarily to interoperability between Clouds but also encapsulating other critical aspects like Portability.

As the scope of this interoperability expands to include areas like Records Management it will act as a huge stimulus to meet the needs outlined for this area recently by President Obama.

Modernized records management will also help executive departments and agencies (agencies) minimize costs and operate more efficiently. When records are well managed, agencies can use them to assess the impact of programs, to reduce redundant efforts, to save money, and to share knowledge within and across their organizations.  In these ways, proper records management is the backbone of open Government.

The InterCloud

InterCloud fundamentally refers to the evolution of the Internet, reflecting the expansion to include software service delivery as well as HTML web content, email, etc.

In short becoming a “computer of computers” in the same way the InterNet is a “network of networks”.

Automation of the procurement between Clouds will be one of the practical short-term areas, as this will streamline service provider processes yielding efficiency gains for customers, and it will also enable higher tiers of services – Increased business continuity through multi-site replication and so on.

Being able to “shop” your IT workloads around different Cloud Providers is the ultimate benefit of this trend, with a fluid exchange of information between Clouds in this InterCloud the same way web browsers, email and other apps exchange content via the InterNet.

The equivalent standards to TCP/IP, HTML and so forth are currently being developed, with a round up available from the OMG gov event where there was a powerhouse combination of different standards organizations all converging on these Intercloud standards in different ways.

This included the OASIS TOSCA standard, the IEEE Intercloud, and the DMTF Interoperable Clouds.

Their combined focus defines an exciting vision of an overall interconnected Cloud system, addressing all manner of Cloud interoperation features such as VM packaging and distribution, software licencing issues, TOSCA for application portability design as well as a system of Intercloud-enabled Gateways and Exchanges that the IEEE P2302 Draft Standard proposes.

InterCloud Service Brokers

Where the standards will enable the technical portability, the actual shopping around and automation of the workload involved will be one of the primary activities of the Cloud Service Broker.

Common standards here will enable vendors to present their products (servers for IaaS, apps for SaaS etc.) into a common catalogue that grows more uptake overall for every one, via “Everything-as-a-Service” abstractions.

They will offer services that enable business transformation such as:

  • Solution Design – A collaborative process for IT staff to define the technical architectures required for moving apps to the Cloud, and dashboards for ongoing management.
  • Cloud Sourcing – Compare and contrast Cloud Provider quotes for workloads.
  • Service Catalogue – Add a myriad of service options like VPN, shared storage and backup,
  • Procurement Process – Automation of all aspects of Order Management, including Approval Workflows, Spend Analysis and other reporting.
  • Governance – Demand and Capacity Management, Resource/ Performance/ Cost Control

InterCloud Records Management

“What do these low level telco methods have to do with Records Management?” I hear no-one ask.

The answer to that and the practical ways in which these capabilities will be implemented within the short-term is well defined in the NIST Business Use Case for the E-Discovery-as-a-Service scenario.

In this document not only do they call for the use of common, USA Government-approved Cloud Computing standards, but also the scope of this expands ‘higher up the stack’, specifically to include Records Management. The document states:


The e-discovery system must be interoperable with of the FAA’s target cloud email service, current traditional email solution, and potentially external E-Discovery services. In the future, if the FAA were to change its email provider, the new provider would need to be supported as well.

As discussed previously, mailboxes and email archives located on any number of servers and local machines within FAA network must be able to be scanned by the e-discovery system.

While the FAA has determined that no current open standard supports e-discovery and FOIA applications in existing email systems, it identified three records management standards that might form the foundation of an e-discovery standard.

The three standards in question are the Content Management Interoperability Services (CMIS) specification from the Organization for the Advancement of Structured Information Standards (OASIS)4, the Records Management Services (RMS) standard from the Object Management Group (OMG)5, and the DOD 5015 Design Criteria Standard for Electronic Records Management Software Applications6. Overall, the FAA felt that a standard combining and extending CMIS and RMS would be the most desirable path.

CMIS is a vendor-driven standard for content management interoperability services. The FAA determined that this standard’s focus was too broad to be immediately useful for use in e-discovery solutions.

RMS is a records management specification, whose definition was led by the National Archives and Records Administration through the Object Management Group. The OMG standard focuses on records management, and not necessarily email; as a result, the FAA feels that the standard falls short of its requirements.

The DOD 5015 is a Department of defense standard focusing on records management. In reviewing the standard, the FAA felt that the standard was cumbersome and a lighter weight version of the standard was desirable.

The Business Use Case (based on requirements for the FAA) also stipulates requirements for other Cloud standards to be implemented by the Cloud Provider, such as Cloud Identity as well as core Cloud methods like the NIST deployment models.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: