I always worry when the introduction starts out with "he gets it" because now I'll probably prove Donna wrong.
It's a privilege to be here this afternoon and close your first day. I know this is a busy conference, and I'm going to try to keep it short because I think if you're like me, at this point you've been over-caffeinated, and you're ready to have a different kind of liquid refreshment.
So what I wanted to do (I'm not an IT expert, this is not my background, I'm a physicist), and when I first took this position now and started working with Donna and Cita and Dawn on cloud computing, I have to tell you it was fascinating, and it remains fascinating. But I was struck by several things. And what I wanted to do is address this from a perspective where I'm a little bit more comfortable, and that's sort of just the federal perspective in terms of what we're dealing with.
So you heard from Vivek this morning about cloud in terms of the tremendous advantages of cloud computing as an approach. Again, from the president's CIO perspective, the tremendous advantages this would confer on federal agencies, if they would adapt this type of computing. And this audience knows better than I all of these advantages, and I think you've heard them as the conference has gone on.
But as is often the case with something that's so different as a model, at the same time this approach is conferring all of these advantages, it's highly disruptive. And one of the reasons it's so disruptive is that it's breaking policy and practice. And when I started to look at this--and I'm wearing a NIST hat--and NIST as an agency has several key responsibilities--and two of them actually come into play in the context of cloud computing.
One of the responsibilities NIST has--we are as a technical, non-regulatory agency, and one of our primary missions is to work with industry to support consensus standards activities that will facilitate the development of advanced technologies. Clearly, you can see the role on the cloud here as we work with many of you in defining and working on standards issues and so forth.
The other responsibility that NIST has by law that you may not be as familiar with, reflects the fact that in the United States, standards efforts are not a government function. We're one of the few countries in the world that turns to industry to lead in these standards issues, and in fact, by law the government, for its own use, is to prefer industry-developed standards. And that raises an interesting question: What's the interface? How does industry know what government's needs will be in these technology areas?
And actually what happens is NIST has been put into this middle position. It's nice because it leverages the fact that we work with you anyway supporting technology standards development, but we are the coordinator of federal agencies and their use of standards.
So in the context of cloud, as I started to look at this and you look at all of the advantages and you start now digging under the hood and ask, "What are the barriers?"
You know, Vivek is already pushing as hard as I think you can push. We have the president's CIO, a brand new position, calling for a federal cloud computing strategy, which specifically urges federal CIOs to look to cloud preferentially. And one of the barriers that comes up is this breaking of practice and policy.
And so I think as I look at the NIST role in this context, it's choreographer. It's beginning this translational discussion between cloud users--procurers and the agencies--and the cloud industry. And I don't think this is an automatic communication where we just put the people in a room and close the door and go away. I think actually this is a tough discussion. And the reason it's tough is that cloud itself is such a broad set of possibilities. This is a broad set of architectures. And so our approach in terms of providing this choreography is what we're here today and tomorrow to work towards.
The idea was basically to have a dialogue. What I was envisioning was that we would have a discussion, and the discussion would start with the federal community saying "Hey, this is what's driving us to cloud. These are the drivers, these are some specific examples of how we envision that this approach can bring, can advantage our role as federal agencies." And I think today you've heard some business cases, examples of this.
And if you're doing scenario-based design, you have to start with a scenario. You have to know where the agencies are trying to go. Unfortunately, it's not going to be enough. You can't craft everything around the scenario. I think now what you have to do is start exploring the ramifications of those scenarios. And for me, I think part of that is further defining what cloud computing is.
And so I think the notion of looking at architectures, of looking at the service models, the deployment models; now you have to start getting under the hood and looking at how a particular scenario might be built out. You know, what's the tenancy? Is this a private cloud? Are these hybrid, are they public, what happens, what's the scope?
And it's in that context that we're going to turn to you. And here's the fundamental question: How do we facilitate or enable these federal officials to use these types of services?
In the previous panel there was a discussion about the notion of accountability and responsibility. Well, one of the disruptive things in this policy is that it breaks the traditional models. In enterprise-based computing it was all there. You could assess. You were managing risk. You would make the risk acceptance decision. You would apply the controls. You would manage, and the accountability stayed clear. In these cases where now these functions are being provided by your cloud providers, how does this map out? Because the accountability will stay fixed. Even if this is, you know, procured services, we have to enable the Federal CIOs to meet their very real obligations to the public.
And I think the answer isn't known by the federal government. This is not a case where we're asking you to guess the answer. It's not sitting in our hip pocket.
What I think NIST can try to do is to try to act as an interpreter, saying, look, here are the use cases. These are the drivers in the agencies. Here is the framework in which we can turn that into requirements. And now we can have a discussion about how we address those requirements, whether those are configurational product requirements, whether those are management and operation requirements, whether those are verification and monitoring requirements. And ideally, ultimately I hope, bake those into the actual cloud products and services.
So, I can't imagine a more important discussion, I think the only--and I'm delighted you're all here in this conference to work on this--the only complicating factor, and I'll sort of leave this time bomb on you as we end the day, is we're also going to break another approach.
Normally, when you're designing something, you think about your requirements, you design, and then you build. In the case of cloud, we're building the plane while we're flying it. And this is going to be an interesting challenge because we're going to be dealing with solutions on multiple time scales. Some are going to be bailing wire and duct tape where we're going to try to stretch existing policy approaches into new areas. And we'll need to define the limits of these areas. Not all things may be doable using, just stretching existing policy, but they're worth doing. And so we need to identify those low-hanging fruit, those activities that are doable, and we need to decide how we're going to stretch existing policies so that it's acceptable.
But long-term, we also have to redesign the approach. I think we all see the intrinsic advantages in functionality and interoperability and security to this new, this model of computing. But I think it's going to take a pretty considerable redesign and how we think about it from a policy and operational performance. And that's worth doing as well. And what we have to be careful about is we don't confuse ourselves with a short-term solution being mistaken for the longer-term goal.
And so I know tomorrow I believe the discussion is moving quite a bit more towards looking at some of the reference architecture discussion and also looking at the standards issue where I think a lot of the rubber is going to hit the road in terms of, you know, agreed-upon practices that will facilitate federal agencies. In the end, since this moves some of the responsibility as well within an agency out of the CIO to procurement, right? This is something you have to think about. They don't have a capacity for doing active risk management in our procurement shop, so there will have to be replacements for that in terms of how do we recognize products, services? How do we recognize qualified service providers that operate with the needed transparency and under the appropriate controls? We have to find ways to facilitate that because this is operating internally in the agencies in a very distinct way.
So the promise is very real. The excitement by the agencies is actually very high. This is not something that takes an enormous amount of encouragement or salesmanship to convince the agencies that this is what they want to do. The benefits are very real. We see that. What I think you hear if you talk to a federal CIO, what they're struggling with is how they do it under these other requirements that they have. And I think we have to really facilitate that.
So I'm delighted you're all here. I hope this translational effort that we have is, will work out. I know with your help it will. And on top of that, in what would probably already be a very difficult challenge, we're going to throw on top of it great urgency. Really, the sooner the better, right? Because we're driving adoption, and if you do it backwards and let the adopted base define where you're trying to go, it's very difficult.
And also the other complication is we're going to be dealing with is solutions on different time scales. We're going to be dealing with ad hoc solutions that we've cobbled together to get some early deployment. We don't want to confuse ourselves with some of these longer-term standards and practice issues that we need your help defining.
So it sounds like a big task to me, but I know you're up to it. And at NIST, our job is to facilitate this. So if there's anything we can do to help drive this, accelerate it, I certainly want to know. I know Dawn and Cita as well in the ITL team really want to know as well.
So, again, thank you very much and I look forward to seeing you at future events as we do this together. Thank you.