Planning a move to cloud-centric applications and governance should start with thinking about cloud architecture, not application architecture. This tip offers advice on cloud architecture decisions, the need for rethinking what service-oriented means and orchestrating compliance in real time.
Application architectures typically build on a static set of basic tools (database management systems or big data, for example) and augment canned components with self-developed components. In the cloud as it's developing, this model doesn't work because platform services are evolving quickly and traditional software vendors are still coming to terms with the shifts in the market.
Responding to cloud market shifts
All applications should be considered top-down, of course, but with the new cloud model this is critical. The goal is to create a cloud model of user experience that does the following:
- Starts with the user
- Links to presentation policies that govern how information is conveyed
- Moves down to business-specific policies and functions
- Ends with core technology-generic or industry-generic services
This process will reduce your risk of having a new platform service that's hard to integrate with your cloud application because the service doesn't match the component structure of the software. Cloud services are always consumed hierarchically, with user-specifics at the top and the generic things at the bottom. This way changes at one end won't drive complex adaptations at the other.
The cloud is its own application environment, not just a place to host an older one.
This process demands a re-thinking of what it means to be service-oriented. Most SOA composition treats components as co-equals because most SOA applications consume tools like DBMS as application program interfaces (APIs) inside components rather than as components themselves. In the cloud, an API is more likely to point to a discrete, remote component or platform service. The middleware for cloud applications are also services, and it's critical they be treated as such.
Part of this extension of the notion of service-oriented architectures is considering all application tools as services, which means a total re-evaluation of what a software component is and what workflow might mean. As APIs become service links in the cloud, application overhead increases and there's also a dynamic coupling of information at a level deeper than most compliance/governance practices accommodate.
Nobody thinks of making a middleware API governable; the goal is to make the application components/services compliant. That's not enough in the cloud because workflows are exposed at many more levels.
One of the practical consequences of the two steps above is the creation of a much looser coupling of application elements and an opportunity to use this to customize worker interactions. Cloud architectures can be more personalized, but this usually demands a more dynamic coupling of components.
Orchestration by way of metadata
Enterprises report that cloud application designs are shifting sharply toward RESTful principles and away from workflow or service bus integration. That means worker interactions with components are likely orchestrated through metadata that links processes into a sequence each worker finds optimal. All of this metadata has to be reviewed for compliance.
This may not be as difficult as it seems if a true cloud-architecture approach is taken. If all worker interactions are metadata-modeled and orchestrated, compliance processes only need these models to review how information is being used and distributed.
To be sure, there are many more points of orchestration than there would be service busses in traditional SOA workflows. However, those traditional workflows are typically described by Business Process Execution Language (BPEL) that has to be decoded and evaluated for compliance/governance. It evens out in the end, and the cloud model is more customizable, making it a better choice for optimizing worker productivity.
Another interesting point about orchestration via metadata is that worker-specific metadata descriptions of service relationships in an application can easily be expanded to include compliance/governance links. Things like data persistence can be included in metadata orchestration so that an audit trail of changes and activities can be imposed on a process. This is facilitated by the fact that cloud architecture promotes deeper componentization and renders even middleware services visible to governance applications.
Cloud application specifics
In cloud-specific applications of the future, it's almost certain that governance based on BPEL or other SOA frameworks may be less effective or even ineffective. Metadata-based orchestration of services will demand new practices and perhaps even new tools. Anytime applications are componentized, it's necessary to co-orchestrate data and process elements.
More cloud model headlines
How to manage a hybrid cloud model
Advice for choosing a cloud model
Benefits of using a private cloud model
The cloud's reliance on metadata to describe workflows means that this orchestration will have to be incredibly effective. Cloud users will have to explore service orchestration, data organization and data-to-service mappings to ensure compliance and application performance doesn't vary unacceptably depending on where components reside in the cloud.
Finally, cloud contracts need to be reviewed as application architectures transition to cloud architectures. Every platform service consumed and every API turned into a workflow has to be properly secured and audited, steps almost never taken for middleware elements.
These services and flows are internal to the cloud provider, so necessary information on and access to these elements for compliance and security will have to be guaranteed by the cloud service contract. Failure to do this will make it much harder to take full advantage of the move to cloud.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in January 2014