By BobGourley
When I was on active duty, I had the privilege of working for ADM Willard while he was the Seventh Fleet Commander. One thing he constantly drummed into each of his warfighters was the concept of carefully and meticulously identifying the SUPPORTED Commander and the SUPPORTING assets for each task force. Because all the rules change -depending on which you are. And believe it or not… sometimes it’s not immediately evident which role you have.
ADM Willard worked very hard to instill that concept into my team of information techies, with mixed results. This was a new way of thinking of how the electrons flowed, much different than the architecture approach we traditionally clung to. It took me a while to completely understand the relevance to my IT world. Now with the emergence of cloud concepts, it’s an even more critical distinction that transforms how technologies are fused together.
Last year, the National Institute of Standards and Technology published their recommendations for cloud computing terms to attempt to standardize all the terminology bantering around with cloud solutions. This is a much-needed effort in general, but the part that caught my eye mostly is the definitions of the roles: cloud consumer, provider, auditor, broker, and carrier.
When developing a cloud solution, some of these roles fall neatly into place and remain fixed. But the “consumer” and “provider” roles will change depending on the mission. Much like ADM Willard’s Supporting vs. Supported discussions, identifying these roles are crucial to setting up the right cloud architecture. The cloud “broker” (responsible for negotiating everything between these two) will vary depending on who has what roles. The broker position might be quite simple, in the case of connected high bandwidth shore nodes, or extremely complicated, as when ships at sea are in the mix. Ships come laden with legacy architectures that are traditionally difficult to stitch together.
Naval Postgraduate School is working with SPAWAR to develop a User Centric Cloud (UC2) Service model to do just that. Levels of interoperability are measured by not just how the data can be exchanged, but by how usable the data is once exchanged.
In maritime technology parlance, complexity is death. When dealing with the intermittent and sometimes disconnected, low bandwidth user, the IT architecture must be clear and simple. To reduce the complexity, the user-centric approach will consider humans and machines at all levels as users with connections that can be managed and data that can be analyzed.
The roles between “cloud provider” and “cloud consumer” will dictate who prepares the data and who receives the data, as in ADM Willard’s Supporter and Supported Commanders. The “cloud broker” role, however, has all the hard work to make sure that as these roles shift, based on the contingency, the data flows smoothly. Under the UC2 approach, the data will be usable and relevant to the operation.
Leave a Reply
You must be logged in to post a comment.