Again, we're delighted to have you with us. We're very excited actually to have the deputy secretary and the undersecretary for acquisition with us today. Let me say first of all that Dr. Hamery and Dave Briteau both apologize for not being here. They were unavoidably detained for a variety of reasons which are unfortunately turned out to be more important. We're thrilled to be able to continue the open dialogue today between the department and industry and the public on this better buying power initiative that the department has been leading to improve the efficiency of the acquisition system. Always important, but more important than ever in the budget times that we're facing. The format we're gonna use today is the deputy secretary is gonna have a few remarks and then we'll introduce the undersecretary. And then when the undersecretary comes up, he will make a presentation, then we'll have questions. What we'd like to do is for the questions, the format will be, we'd like you to write your questions down, there are people in the room. If you just hold up your hand, they'll give you a card to write your questions down. They'll bring them forward to John Etherton and I and then we'll answer those questions unless it seems appropriate to do it otherwise. Let me just say the norm. If you have a cell phone on, please make sure it's off. Anything that makes noise. And then finally, Dr. Carter, we're delighted to have you with us. You don't need an introduction to this crowd. They know you enormously well. We appreciate the efforts you're making at DOD and all the difficult decisions that you're facing and the country's better off to have you leading us. So thank you very much and we appreciate you being with us today. Thanks, Kim, for that introduction, for the opportunity to be in this great organization and forum for everything you do for the Department of Defense and have done over years for national defense. Much appreciated. To Dave Bertot, I know he's not here, but to him and his family, we wish you strength and send you our condolences. This is really an initiative that is to the credit of Frank Kendall. It's his show and I'm just the warm-up act here. But I'll give you a little background on this. First of all, I'm delighted to see all my colleagues from the acquisition community here, good friends and very skilled people. Let me take you back. It was two years ago at the Eisenhower Library that then Secretary of Defense Gates spoke presciently, turns out, about the days of ever-increasing defense budgets soon coming to an end, as our elected leaders grappled with our fiscal circumstances. What he said at the time famously was the gusher has been turned off and will stay off for a good period of time. And in acknowledgement of that coming fiscal reality and in an effort to minimize the impact of it, Secretary Gates launched an initiative across the department to ensure that the department would not be forced to sacrifice wherever possible an ounce more force structure than was necessary. Better buying power, which was now, we have to call it better buying power 1.0, which was introduced in September 2010 by me and my partner, Frank Kendall, was the acquisition systems contribution to this overall initiative. And it was directed at the approximately $400 billion a year that the department spends in the acquisition of goods and services. Better buying power's goal was, as we said then, more capability for the warfighter and more value for the taxpayer by obtaining greater efficiency and productivity in defense spending, what economists call productivity growth. To achieve these objectives, we directed 23 principal actions in five major areas. First, to target affordability and cost growth in our programs. Second, to incentivize productivity and innovation in an industry through profit and partnership. Third, to promote real competition wherever we could. Fourth, to improve our tradecraft in the acquisition of services as opposed to goods. And fifth, to reduce non-productive processes and bureaucracy in the government as well as in industry. And I won't go over each of these areas but it's worth noting that over the past two and a half years we've worked hard and with some considerable success in some major programs to implement these directives. But at the same time though, we acknowledged at the time we released Better Buying Power 1.0 that we wouldn't get everything right, that we hadn't captured every good idea that was out there, that we knew that in some cases the data sets upon which we were basing decisions were still incomplete and we knew that we would need to adjust based on initial implementation experience. We also knew that industry would continue to come to the table with good ideas and constructive criticism. And in this regard, let me address a few industry concerns that I share and I think our leadership shares that we've learned up front. The first, I recognize that industry needs profits and margins to be successful. While incentivizing cost consciousness will continue to be centrally important to our work, we need to do also to pay more attention and be attentive to best total value and program risk so that transactions are successful for both parties. Second, I share industry's concerns about an excessive oversight culture. I've long been concerned that the number of pro-pro-chers was a, I'm sorry, that the number of watchers was approaching the number of doers in the department.  And we may in fact be reaching that threshold, especially with respect to things like audits. And we're trying to work internally and work with industry to address these issues. And third, we've listened to and are addressing industry concerns about contracting practices and so with where it's possible for us to do that. More broadly, a notable feature of Betterbind Power 2.0 as Frank will explain in more detail is improving the professionalism of the total acquisition workforce which encompasses program management, engineering, contracting, and product support disciplines. We know that the quality of our people is an essential ingredient to our success as an acquisition enterprise. As we continue to implement Betterbind Power, we look forward to working with our industry partners and our acquisition workforce to do more and more each and every year to get more value for the taxpayer and the warfighter. In fact, that's what Betterbind Power 2.0 is all about just like Betterbind 1.0 and I salute Frank who is my partner then and is now the leader of this effort and his team which is here for their excellent work. Now, achieving Betterbind Power would of course be an important goal in any budget environment but its importance has only grown given the strategic and budgetary challenges we now face. Since Betterbind Power was first unveiled, Congress passed the Budget Control Act which required the department to cut $487 billion from our defense plans over 10 years. A year and a half ago, we did that first by devising a new defense strategy to guide us as we turn a strategic corner from the post 9-11 era dominated by the wars in Iraq and Afghanistan to an era defined by new challenges and new opportunities. While the budget that we derive from our new strategy absorbed significant reductions in defense spending, it made important strategy driven investments in the Asia Pacific region where so much of our future economic and political interests lie in special operations forces, in future focused domains such as cyber and space, in countering weapons of mass destruction and in certain areas of our science and technology portfolio including electronic warfare and command and control. It's still true today as it was then that every dollar not wasted is a dollar that can be invested in these new capabilities. At the same time as we have made reductions to our base budget spending plans, our overseas contingency operations funding which is not included in the base budget and which is largely for Iraq and Afghanistan is also decreasing. Taken together, these reductions in base and OCO compare and pace and magnitude to historical cycles, excuse me, in defense spending the nation has experienced in the past, either after Vietnam or after the Cold War. However, as this audience well knows due to the collateral damage of political gridlock here in Washington, we are now also operating under sequestration which requires us to subtract an additional $37 billion from our budget for the remainder of fiscal year 2013. Sequester presumes that we take equal or proportionate shares from each and every part of the budget which is the worst managerial approach possible. Sequester is not only regrettable in its own right but it distracts from the true strategic and managerial tasks before us. Secretary Hagel and I and the entire leadership of the department are doing everything we possibly can under this deliberately restrictive law to mitigate its harmful effects on national security. But as the joint chiefs have emphasized repeatedly the impacts on our readiness are real and in many cases irreversible. Now, while the sequester for FY13 ends October 1st there's no way to know what's for sure what's next here in Washington. Virtually no one believed that sequester what sequestration would actually go into effect in the first place. Now we in DOD can adjust and adapt to a wide range of contingencies but this will be easiest if we have stability, time and flexibility. The president has submitted a budget that meets these goals as part of a balanced deficit reduction plan. For defense it contains $150 billion more in 10-year cuts compared to last year's plan. In addition to the $487 billion reflected in the Department of Defense's fiscal year 2013 budget. Most of these cuts occur beyond 2018 which gives us time to plan and adjust. While no agency wants to cut its budget the president's plan is much more practical than the cuts that could occur under persistence sequestration. Cuts that could amount to $52 billion in FY14 alone and could cost $500 billion over 10 years. We urgently need Congress to grant us stability, time and flexibility. The House budget resolution, the Senate budget resolution and of course the Budget Control Act actually have a wide range of future scenarios for our budget, not the stability we seek. For this reason, in March Secretary Hagel asked me, working with Chairman Dempsey, to conduct a strategic choices and management review to examine the choices that underlie our defense strategy, posture and investments including all past assumptions and systems. The review will define the major choices and institutional challenges affecting the defense posture in the decade ahead that must be made to preserve and adapt our defense strategy and the department's management under a wide range of future circumstances that could result from a comprehensive deficit reduction deal or the persistence of the cuts that began with this year's sequester. Everything's on the table, roles and missions, war planning, business practices, force structure, personnel and compensation, acquisition and modernization investment, how we operate, how we measure and maintain readiness. We plan to complete our work and tee up decision points and recommendations to Secretary Hagel and the President in the coming weeks and months. The choices that are made will inform how we execute our FY 2014 budget, our FY 2015 budget submission and will serve as the foundation for the quadrennial defense review due to Congress next February. And I hope that one of the principal benefits of the review for our acquisition programs and correspondingly for industry will be to bound the uncertainty that we currently face. Uncertainty is anathema to good management for us and also for our partners in industry. It discourages investment, it causes the hoarding of capital, prevents the natural rationalization of our industrial base and harms growth. Should also mention that in conducting our review we have been very mindful of how the choices we're considering will affect industry, which is the basis of the CSIS forum we speak to today. As I've said many times before, the success of our better buying power efforts and the defense enterprise for that matter is clearly dependent on having a healthy, robust and vibrant industrial base as dependent upon that as it is getting best and superior value for the taxpayers dollar and for the warfighter. Let me close again by congratulating Frank, the entire acquisition team that has worked so hard for the taxpayer and for the warfighter, does it every day and so hard on this important effort. Frank, especially to you my friend, my partner for a long time, has done a tremendous job of implementing better buying power 1.0 and a fantastic job of moving beyond that to an improved version of better buying power, which he'll outline today. Frank and the rest of the team here, you've made a tremendous difference, thank you. Come on up, Frank. I wanna thank Secretary Carter, it's terrific to have a boss who really understands what you're doing and supports you as much as he does and it was a great partnership, I miss it, but I'm carrying on the work as you can see and thank you for your support. I wanna thank CSIS for hosting this afternoon, thank Kim Wynkup for emceeing. Beyond that, I of course wanna thank my team, people who made this possible today and did all the work that went into this, starting with Katrina McFarland and Jim Thompson who carried on their work from better buying power or what we're now calling 1.0 into 2.0 and putting all of this together for me. Service acquisition executives represented by Heidi Shue from the Army, major contributors to this, OSD staff people, I'm not gonna go through all the names, I've got a lot of you here today. And industry, industry provided us with a lot of inputs for this version of better buying power, this upgraded version if you will. That dialogue continues, I just got a letter today from AIA with some additional things they'd like to talk about and we're delighted to do that and carry on that dialogue. That conversation's gonna continue, we learn a lot from industry and a lot of industry's inputs are reflected in the things that are on this chart. I'm not gonna walk through 34 bullet points with you, that would take more time than we have. I'm gonna hit a few of the wave tops, but before I do that, I'd like to say a little bit about sort of this initiative overall and how it fits into what we're doing. Someone asked me not too long ago if I was a transformational or an evolutionary leader. And the answer I gave after thinking about it for a second was that I'm more evolutionary. Part of that is that I don't believe there are simple fixes. I don't believe there's one or two policy changes we can make which are gonna fix if you will defense acquisition. We're in a very, very complicated business. And we had 23 initiatives in better buying power 1.0, there are about 34 here. There are another 100 things at least that we're working on that aren't on this chart. It's a very complicated business that covers a wide range of products and services that we acquire in a number of organizations which all have their own cultures, technologies that are difficult, cutting edge in many cases, services that we need to produce more efficiently. It's a very, very big scope that we're trying to address here. And the way to improve it, I think is not with one or two policy changes or even five or six. It's with continuous effort to understand the results that you're getting, why you're getting them and where you can make improvements on the margin. And that's what this is all about. Another important feature of this is that sub-bullet up at the top, a guide to help you think. When Dr. Carter and I put out 1.0 and went around the country talking to the workforce, one of the things we told them was that we really wanted them to think that the guidelines we had put out in 1.0 were not hard rules written in stone to be followed in every occasion. They had to be applied with judgment. And that's what the thinking part is about. The range of things that we do is so diverse that each problem has to be approached and assessed on its own rights. That's a process that our people have to go through. That's one of the reasons there's a new category up here about professionalism in the workforce. That's not an easy job. It takes professionals and it's the key to success. Getting those little decisions right. Getting the acquisition strategy right. Really understanding the technology maturity in your program. Really understanding what makes industry perform better for you. What incentives work and which ones don't. And those are threaded all through this. So what do you see in the guidance that I just put out implementing 2.0 is a combination of some general guidance and then some specific actions that people take. Many cases that's to provide more thorough and more complete guidance to people to help them through the process of deciding how to actually implement this. There is a stronger emphasis on the our workforce and government in this set of initiatives than there was I think in 1.0. And we're moving towards a direction where we do much more to improve our workforce to make it more capable of making the judgments that have to be made to be successful and to improve outcomes. So evolutionary yes, but transformational over time. If we continue to make improvements on the margin and that's what this is all about we will transform our results. Now I want to give Ash credit for this because I think we're seeing some things that show some evidence of improvement. I don't want to make too much out of a couple of data points. We're sending our selective acquisition reports to the Congress today. First time in my memory there are zero non-McCurdy breaches neither critical or significant in that report. And I think that we give credit to Dr. Carter I think in large part for the leadership that went into moving us in that direction and the whole team for continuing the things all the including industry by the way. So there is some evidence that things are getting better. We're getting some complimentary reports from the GAO for the first time in my memory. But we have maybe not the first time we're going in the right direction but there's still a lot of room to do better. And that's what this is about. Finding those things on the margin where we can do better. Let me walk through a few of the specifics. Affordable programs. Ash mentioned how much pressure we're under right now and the uncertainty that we're dealing with. There's I think there's always a lot of motivation in the department and outside the department to get as much into the budget as one can possibly put in. And to be optimistic about our outcomes. And what affordability is about is trying to constrain those and be more realistic in our expectations. It's about not starting programs that we can't afford. So that was part of 1.0. It was an important part of 1.0. I put it into a separate major bullet here. The difficulty I'm gonna have right now after we've been doing this for about two and a half years now is to enforce these caps. So we're putting affordability caps on our programs. The idea being to force the requirements community to sit down with the acquisition community and do trade-offs between cost and capability. And where they have to to get down to a cost that we can afford, reduce the requirement to stay within that level. That's easy to start out to do. It's hard to finish. It's hard to get to the end when people have to give up things that they want. But that's what we're going to have to do if we're gonna recapitalize and modernize the force structure that we have. That's what that first one is all about. Controlling costs throughout the life cycle. One of the things that we've tried to do and this shows up later on on the list is to change our culture a little bit within the Defense Department so that cost becomes a much greater factor in how we do business and how we think about our jobs. I saw a Defense Business Board report the other day that talked about the Defense Department being different than the commercial world in this regard. In the rest of the world, and I've been in the industry, I know what it's like to be out there, people worry about cost a lot. They try to drive cost out all the time.  It's a very different way to think about what you're trying to do. One of the key initiatives up here that I think it's really caught fire was in 1.0 is the idea of should cost. That our managers need to go out and understand their costs thoroughly. Look at all the elements of cost that they're dealing with and determine where they can make reductions in those costs, set targets for themselves, and then manage to that. Manage to the cost and try to reduce the cost as opposed to just spending the money and feeling that that's your fundamental mission. And that goes across almost all of the things that we do. And I think we've made a lot of progress in that, but we're gonna reinforce that and continue to do that. Strong partnership with the requirements community, another one I'll mention, working very closely with the Vice Chairman of Joint Chiefs and the JROC on this, that has to happen throughout the services as well. And a lot of these are like that. There's a top level piece of this, which involves myself and my staff and some of the senior leadership of the department. But a great deal of this goes down through the entirety of the many layers that we have in the department. And that's one of them. That has to happen for all they get programs. It has to happen for things beyond products as well. I'm gonna turn to productivity, innovation and industry and government. Mention a couple of things there. One of the things that Dr. Carter and I put out in 1.0 was the idea of using more fixed price incentive fee contracts. That was a good initiative. But my feeling and I think Ash would agree with this is that there was a bit of an overreaction of that. People started thinking that was what they should use all the time and use it for everything. So the guidance here modifies that a little bit. It says use the right type of contract for the job. We have a range of contracts for a good reason. One place in particular though, and it's still up there, where we wanna use fixed price incentive more is in early production. It turns out that we're pretty good at predicting the cost of production. We're not nearly as good as that at predicting the cost of development. So there the risk is inherently higher. It may not be as appropriate to use a fixed price vehicle, but in early production it makes a lot of sense. If we're gonna overrun by an average something less than 10% that's well within the window we can cover with a fixed price incentive fee contract. And that's what we're doing. We're doing a lot of that. I think it's paying off for us. We've moved in programs like said the F-35 and when Ash was leading acquisition in that direction and I think it's done a lot to get that program's cost under control. Best value. One of the things that I've been working with on the services is the idea of defining value. As we got with the solicitation, let industry know what we're willing to pay for increased performance. I had an experience many years ago where I was trying to sell a product to the government, to the Air Force, which we were absolutely certain was a superior design to our competitors. Would give much, much better war fighting performance. And I could not find a way to get my customer to put any credit in the source election for that value. And then we didn't obviously win the competition because of that, because we were more expensive. We had an inherently more expensive design. So when we established threshold requirements and objective requirements, there's no point in putting down the objective requirement unless you're willing to pay a little bit more for it. If all you're willing to pay for is that threshold, then that's all you should ask for. So what I've worked with the services on is the idea of defining value. This is an impetus to innovation. If industry knows what we're willing to pay for higher performance, then industry has a reason to go out and try to reach that performance and get it to us at a cost that we're willing to pay. So the idea of best value is to reinforce that and to make it clear to industry so industry can bid and decide how they want to approach a particular product more intelligently. One of the errors that we've gotten a lot of feedback from industry on is something called LPTA, lowest price technically acceptable. And after moving in this direction, we've got a lot of feedback that suggests that there are places where this really is not the right vehicle. The problem is that there are some types of services in particular where it's very difficult to write down an objective standard. The people reviewing proposals need some room to maneuver to determine value in a more subjective way. In those cases, LPTA is probably not the right vehicle. And I'm talking in particular about certain types of professional services where expertise is really what you're after.  And what happens in those cases is we tend to default to the cheapest bidder independent of the quality of the bid. And that's not the outcome we want. That is not the best value for the government. So we're backing off a little bit from the use of LPTA in those cases. Again, people, this is another case where our people out there in the workforce have to use their judgment and decide what's the best way to proceed. DCA audits is a longstanding concern of industry. We're working closely with, and this is one that we had on 1.0 as well. We're making some progress. I'm a little concerned about as our budget shrank and as we have to do things like furlough people, whether we'll be able to continue that progress at the same pace. But we're working closely with DCIA and Pat Fitzgerald, who's the leader there, has been very involved in better buying power and this whole initiative works with us closely. So we're working to get the backlog out. A lot of benefits to everybody to do that. Also mentioned up here is the superior supplier program where we're gonna start recognizing our better suppliers in industry. And one of the things we can do for our suppliers if they make a certain category and show good results in their audits consistently is to reduce the frequencies and the depth of the audits that we do and tie that to their performance and answer and we're working to initiate that. Unproductive processes and bureaucracy, I'm waging a continuing war against non-value added activities. It's a harder fight than you might imagine. In a letter I received from AIA with some ideas, they asked me about an item that was in better buying power 1.0 that didn't fit on the PowerPoint here. When I put out the initial guidance in November, I did a, what happened to the 1.0 initiatives and that was one of the initiatives that I said we were continuing. It just didn't manage to get it fit on the chart. But we will continue to work with industry to identify things that are non-value added that we impose on industry that really don't provide any value. And AIA sent me a letter. I think the board of governors actually watching this so this is a shout out to them. I've got your letter and we're gonna react to that. We'll set up a team to work those things with you. But that item is not disappeared at all. A lot of this is about internal processes. I had a conversation with one of our program executive officers once who said that when he had a multi-year program, he was the most effective program manager he could possibly be compared to any other time in his career because all he had to do was work on his program and work with his suppliers to get more for the money for the taxpayers and for his warfighters. And I thought about that, I took that to heart. The burden that we put on our people to come do things for oversight reasons, well it may not cost that much and it may not delay programs that much. It takes managers away from something else that they really should be doing. So that's an important thing. We're gonna start tracking this. We're gonna start tracking how much time our people spend giving briefings to the staff and getting coordination and going around doing the things that they need to do just to work their way through the process and then go attack the things that we could push back on. This will be a collaboration between the Secretary of Defense's office people and the service people because a lot of this bureaucracy exists in the military departments as much as it does in OSD. Effective competition, a firm believer that competition is the most effective way to reduce cost and we're continuing something we did, same emphasis was in 1.0, we're gonna continue that and we will find creative ways and the idea here and what we want people to think about here is creative ways to create competitive environments for industry. So that there is a reason for people to work harder to keep the business that they have. Ash mentioned profits. Every speech we ever give on this I think we talk about profits. We're not trying to take out profits to cost but we do want to tie profits to performance and this is an area where we can do that and competition helps us drive down costs as well. I'll mention this because I think it's important and it gets back again to the professionalism of our workforce and the requirement to think. It's the assessment of technology readiness. We had a kind of a bureaucratic system that we put in place to assess the readiness of things to move to the next phase and as I was reviewing programs I had a program come into me that was advertised as low risk because it had met a certain technology readiness level had a label on it and I was told that we had done competitive prototypes and therefore the risk in that program was low. So I asked the engineers to come in and go through the designs for me and what I found out was that the demonstration part of the phase of the program had done competitive prototypes. It had a TRL assessment of TRL six which is kind of our standard but that that design that was demonstrated was not the design that was gonna be developed and produced. There was zero correlation almost between the two designs and the light bulb went on that what was going on was that industry wasn't trying to reduce the risk. It was trying to get the contract. It was trying to win and I had Bob Moore who's a former deputy director of DARPA colleague from the past go out and look at about a dozen programs and sure enough this was happening fairly routinely. We were checking the box for a certain label that we put on things and we were taking a process and doing something we had said was part of success in terms of reducing risk. We were not looking at the real risk in the product we were gonna build and industry was responding as you would expect industry to. The motivation for industry is to win the next contract and get the job. That's what comes first. I was an industry and that's exactly the way I behaved and that's what we should expect. So the message of that was that we have to understand more thoroughly we have to require industry to actually reduce the risk in the product. So that's what that one's about. And like a lot of others here this is about making sure our people understand thoroughly what it takes to ensure success as they manage their programs and their service contracts and so on. Okay the next category up there is acquisition of services. This is almost lifted from the better buying power 1.0 without many changes. What we're doing here though is building on what Ash and I did in 1.0 and expanding our management of services. We're moving it beyond just the contracting side of this to the management of services. My deputy who couldn't be here today is gonna be the leader for the department in contracted services. Alan Estevez, if I can ever get him confirmed. Alan's gonna take this on. There's gonna be a senior manager in OSD, a senior manager for each of the major categories of service contracting. And they're gonna be working to identify with the services and the agencies best practices in each of the different areas of service contracting and implementing policies that go down to that level. This includes things like information technology services, facility services, maintenance services and so on. Knowledge based services, et cetera. There's some standard categories that each is a professional area in its own right. Each has its own characteristics. So we're gonna continue that process. I'm working on a draft DODI that Dick Jimin has been working on that'll cover services contracting that's gonna go down that path and make those policies more clear. A lot to be done there. We spend more money on services than we do on products. If there's a place where I think we can gain greater efficiencies in department and make major inroads and savings and I can contribute them to what Ash is now leading for the secretary, that's the place I think we're gonna be able to do it. Professionalism, the acquisition workforce, I've alluded to that as I've gone through these. Establishing high standards for our key leaders, program managers, chief engineers. Ash mentioned the list generally. Contracting people of course, logistics support, life cycle support people, and testers as well. These people that run either a program or a major portion of a program or a multi-billion dollar service contract have huge responsibilities. They need to be qualified for that job. They need to be prepared for it. They need to develop the skill sets, get the education, get the training, get the experience. A lot of this is the right experience. We have a system within our workforce which is a little bit of a check the box system for DAWI categories of hierarchy, if you will, of professional levels, which doesn't go far enough. We need to strengthen that and we need to make sure that people who are labeled ready to take on one of these major key leadership positions truly are. It's not fair to them to put them into a position that they're not prepared to take on. Cause consciousness, a cultural thing. I mentioned it earlier. I'm gonna close with that. In the climate we're in today, there is nothing more important for us. I delayed ruling this out a little bit. I initially announced it in November. We worked for a few months on it. We went past the first of the year. It became pretty apparent we were headed for sequestration after that. It was a difficult time for the department. We're now into implementing sequestration. There's no reason to stop doing our job and there's every reason in the world to do it better. We have less resources to work with now. The cuts that we're taking are hugely inefficient. Absolutely to that. We didn't have a cyclone or a hurricane arrive the day sequestration was implemented. What happened was the rain started to fall and it's still falling and the water's rising. And that's what we're dealing with. I read the weekly we get a summary of the things we're doing because of sequestration. And if you leave that list, there's some things out there that you kind of shake your head and say, well, that's not, if the blue angels can't fly this weekend at the Naval Academy graduation, that's not the end of the world. But if I can't repair the runway and I have an increased chance of fire damage on the runway, if I can't buy any furniture to put into the building I just paid for and therefore I have to stay at least space longer, if I can't do the maintenance on my major end items, if my units aren't training, these things add up. And what we're essentially doing right now is taking a huge number of inefficient actions. All of our investment accounts in production are coming down in terms of quantities to less economic quantities. All of our research and development accounts are being stretched out, less efficient production, our research and development profiles. We're carrying more overhead longer because of that, basically the fixed costs go on longer. All of this is inefficient, all is opposite of what I'm trying to accomplish here. And that's going on and that water keeps rising. And if Ash's scenario plays out, we're gonna go into a very similar situation in FY14, which I think, I've used the word devastating before, I'm not gonna back down from that. That's the sort of impact this is having on the department. And anyway, more pressure than ever on us to get as much value as possible for the money that we have. And that's what our workforce is dedicated to doing and will continue to do. And a big part of this is to ensure that they have the knowledge base and the tools and the freedom to do what they need to do and they're empowered to do what they need to do. So thank you very much for your attention. I'll be happy to take a few questions. I guess I'll start. Other folks can get their questions ready. The department has made a number of legislative proposals as part of their submission for the FY14 National Defense Authorization Act. Yesterday afternoon, the department posted on the Office of Legislative Affairs website the proposals for limiting executive compensation on cost type contracts to $400,000, which is the president's current salary level. So essentially what the department is proposing to do is limit reimbursement for a compensation at one level of compensation, or one element of compensation that's essentially set for an elected official in the political process. There are some folks that are concerned about the ability of the industry with that sort of limitation and the downward pressure on cost generally over time to be able to continue to attract the talent both on the technical side as well as the management side. Could you comment on that and how you see that in relationship to what you're trying to do in better buying power? No, this actually came from the Department of Defense. No, no, this was... In general, we have a free market, a competitive market that supports us. An industry has to compete for talent in that market. They need engineering talent, they need management talent, et cetera, and they have to go out and compete with the commercial world. And I think if we're gonna have high quality people in the defense industry, they need to be competitive. So I'm gonna have to take a look at that and see where we are. Maybe a result of an attempt to compromise with a more stringent restriction that Congress was going to put on that I was aware of, or at least was discussed in Congress at one point. There are questions about the British idea, a concept that they're considering about changing their acquisition approach to a government-owned contractor operated. The questions revolve around how that's gonna interface with the U.S. on the existing programs that the U.S. and U.K. are involved and how FMS will work and generally, what do you see or think about? Yeah, I've been aware of this for some time. Bernard Gray is the right counterpart in the U.K., and he and I have been discussing this for about three years now, ever since I met him. He has a slightly different situation in a different, well, he has a similar situation in some ways, but I think it may be more severe and he has a different solution to the problem. He's concerned about his organic capability to manage programs and how that is atrophied in the U.K., management talent, technical talent, and so on. And his solution to that, and it's more quantity than it is of people who he has to do the things he needs to do. So his solution to that, which has been proposed, and there's not been a decision yet in the U.K. on this, is to hire someone to help him with that job, bring in a commercial entity of some type, may look a little bit more at the end like I'd have already seen in an actual normal business, but in any event, he wants to basically hire management talent to help him manage his defense programs, which puts contractor people, essentially, in a role that traditionally might have been filled by government people. So we're gonna have to work through how that happens. I'm very aware of this. I suggested to Bernard about a year ago, several months ago, that we put together a joint team to go try to figure out what problems would arise because of this, because there are certain things that need to be government to government, and identify those. So that team's been working for a while. I do not think at the end of the day that this will be a major impediment for us. It's just a problem we're gonna have to go figure on how to solve, and there are certain roles where I think the U.K. is gonna need to put government people in to do it, to do, make certain types of arrangements in cooperation with the United States, for example, where it needs to be government to government, and we don't want it to be government to contractor. But that's a work in progress. We're not having any disagreement about this or his path. The path I've chosen is to try to strengthen our existing workforce. I think we have a lot of talent in our workforce, but I want to build on that and make it stronger. People at the end of the day in leadership, just as in an operational unit, are more important than anything else for success. All these policies are nice, but people are what really makes a difference. And so I'm taking a slightly different path than he is. He has a reason to go in the direction he's going in. He's thought about it very carefully. We're gonna work together to make it work as a bottom line. Mr. Secretary, you mentioned that LPTA has been a very controversial issue, and you've heard a lot from industry about it. Do you have any comments as to how you intend to deploy the approach that the department tends to take on LPTA contracts as you further clarify what technically acceptable means, how that will get out to the field and what process folks will understand their policy. We're writing some additional guidance for people. There's some general guidance on the implementing memorandum, but many jobs are suitably LPTA. If I want somebody to cut my grass, for example, I can specify what that means in a fairly objective way, and I can hold someone responsible for that when they do it. I just want the cheapest firm that's gonna cut the grass to my specification. But if I want specialized advice in a very specific area, what I really care about is the talent that is offered to me. And I have to judge that somewhat subjectively in a source election. So for different types of work, it's easier. The guidance of the workforce is don't use LPTA if you can't define an objective standard to measure successful performance. It's too hard to implement that. The concern comes out of a lot of people who are out there and feel that they have built up expertise in a certain area and don't know how to get credit for that in a source election. I think there's some merit to that argument for some types of work, and that's why we're changing the guidance. Partners seem to have a number of questions of you. And the one in particular is what's your view on the role non-U.S. defense companies could have in reducing costs, promoting innovation, and providing access to mature, ready-to-use technology. Do you have any general guidance that you're indicating in this regard? And there was sort of a further refinement of that. Given all that, explain how cutting the foreign cooperative testing program makes sense. I'm the latter subject to the cooperative test program. We're in a situation where we're not cutting anything that we don't want. We're cutting things we do want. It's just which things that we, you know, what's the least bad thing to do. So that's a good program. It's an important program. But as we look at all the other things we have to do in past budgets, it's had to come down a little bit. I very much believe in competition. That includes allowing our partners to have foreign firms from our partners to bid for things. We do fair competitions here. And we're open to sources from, often in partnership with U.S. firms, but we're open to bids from our partners, particularly our closest partners, and we'll assess them fairly and objectively. And we have some cases in point where people have reacted to the appearance of things. I'm thinking about the tanker competition right now. We have other cases where, you know, I'm thinking now about the light attack competition the Air Force did recently, where it's quite clear that we're willing to go with foreign suppliers. I like competition. And I think there is now a global marketplace out there. We don't have a monopoly on technology. We don't have a monopoly on good ideas. And we're open to competitors. We've had to, in an area that's related to that, we've had to make some of our source elections more open to other people and releasing information to other people in order to make that happen. And we've kind of pushed back on that. And this is an area, by the way, where industry needs to talk to us. If you see something that is restricted in some way and you think that's inappropriate and you want to let us know about that, please do. Because there are times when people do that more than they should, frankly. One of the, over time, a number of different rapid reaction, rapid equipment programs and accounts have been set up. And many of those have been proven to be good sources of innovation and acquisition. How do you see those accounts being integrated into some of the things you want to do, especially on the affordability side and not better buying part 2.0? That leads into a fairly, this is gonna be a little longer discussion than the question would suggest. I'm concerned about the health of the industrial base as we take significant cuts. In particular, I'm concerned about our research and development base. And the way we're taking cuts in the department right now, largely because of the uncertainty, what Ash talked about this, but first of all, sequestration and the cuts associated with sequestration happen very quickly. There's no phase in of those cuts. It's boom, $50 billion. We took $40 billion this year. If we go into 14 and we're looking at sequestration in 14, which politically certainly looks possible, it's a $50 billion yet. And we're sitting here not knowing. One of the reasons the uncertainty is such a problem for us is we don't know what forest structure to design the department around. We don't know what ultimate level of budget we expect to be at. Everything else that we do flows from forest structure. Once you have a forest structure, then you need a certain level of money to keep it ready, to keep the people trained, to keep the equipment ready to be operating. Then you need a certain level of money to modernize that forest structure and to recapitalize it as it wears out. So it all flows from the forest structure. And when the department gets out of balance, when we have too much forest structure for the other accounts to support, bad things start to happen. One of the bad things is readiness crisis. I live the readiness crisis of the 70s in Germany. I was in a unit that had no spare parts. And we were essentially non-operational for parts all the time. You can have a readiness crisis because of training too. You can stop training. You know, we're doing too much of that right now. You can have a readiness crisis because you didn't invest in technology or you can have a hollow force because you didn't invest in technology that you needed to stay technologically superior. So you have to have a balance. But the balance flows from an understanding of what your forest structure is. So as we go into 13 through 13 into 14, if we don't have a good feel for where we're going to end up, we're gonna be tempted to hang on to forest structure rather than let it go and then have to try to get it back later. Well, if you have to take $50 billion out and you can't, A, you can't get it out fast out of forest structure because it takes a while to get the people out. And you wanna hang on to the forest structure anyway because you're not sure where you're gonna end up. The place you're gonna pay for that $50 billion tends to be the investment accounts. To a certain extent readiness so you can only take so much out of readiness. We're still engaged in Afghanistan. So we get a disproportionate hit. And you see this in our FY 14 submission, I think. What happened is under the Budget Control Act, actually it's in the 13 submission, R&D and production dropped pretty precipitously. Production recovered to a large extent over the five years. R&D did not. So I'm worried about R&D and what's gonna happen there. One of the things we can do is something that's kind of related to the rapid acquisition idea. It's the idea of rapid prototyping. It's a way to hedge against an uncertain future but we're not gonna be able to afford to do an awful lot of that. It's a way to protect the industrial base and do things. It's going from our standard acquisition processes to something which is more like, say, the MRAP program which I think is also implied in that. The MRAP program is a very interesting program. It shows how we can do things quickly of a certain type. The MRAP is essentially, took a number of commercial components, mostly from trucks essentially, and put them together into a new package that we could feel very quickly. And then once we can, we did a lot of them in a hurry. That's a different job than a cutting edge new fighter or a cutting edge new missile system which is a very intricate, complicated design which extends our capability. There is nothing technologically sophisticated particularly about MRAPs, right? But if I'm gonna stay ahead of a peer competitor out there or anybody out there who's challenging me and there are people who are challenging us in military technology today, challenging us very effectively I would add, we're gonna have to go to designs that are complicated and take longer to do. We took, I've taken a hard look at whether or not, and I have a number of people looking at this from different perspectives but if you look at the data on how long it takes us to do things, over the last 20 years, we've added about nine months to a year to our time in development. It's not as much as many people would think. There are exceptions where some programs have taken a very long time but on the average we haven't added that much time. Now that may be due to complexity, it may be due to other factors. That's something we're gonna have to do some more work on to try to understand. And I would like to get the cycle time down. One of the things we're trying to do in 1.0 and carrying on and still even, I don't remember if it's on the chart and I think it is, is to reduce cycle times continuously. So we're looking for ways to do that. But we gotta get a deeper understanding of what actually is causing those cycle times. Is it, you know, is it our processes, how we do milestone approvals and the documentation associated with that? Is it how long it takes to get a requirement approved? Is it the amount of testing we're doing? Is it we're gonna have to dig deeper in order to get at that problem? Okay. It's a bit of a, it's a follow-on to what you were just talking about but it talks more about the using recent guidance that you've talked about about a pilot program using a Skunkworks type approach to whatever elements you think's appropriate. Yeah, let me comment on that. Did that make the list it did? I've got about 50 other things that aren't on the list that I'm doing. I'm not sure if everything's up there. The idea of a Skunkworks is a, there's a long history of this. It goes back, I think to the 60s originally and even before that, certainly after World War II. Kelly Johnson's a famous name in defense industry if you look at the history of defense acquisition. And he was the first leader for Lockheed, the Skunkworks. The idea in its essence is that you have very small professional teams on the government side and on the industry side. You have a fairly well-defined requirement and you have people that work very closely together to go develop a product that meets that requirement. And that team is empowered. It works again very closely with a set of rules by which they operate. And there's a fair amount of trust involved in the organization that does that. That's a little different than the way we do business today. The idea is to try to do something like that. Now if we're gonna do that, and I'd like, I've asked each of the services to propose a program that they would like to take that kind of approach with. And what I would do is relieve them of many of the formal documentation requirements with all the staffing that goes with that that we do today. And instead use intense on-site reviews by, first by the staff and then by myself and the SAE service acquisition executives for the milestone decisions. We simplify that process enormously and we focus on the substance of what's being done. And we have people doing it who really do understand it. What I need is a criteria to have this kind of a program. First of all is an assurance that both sides of government industry will have a truly professional team that the requirements are well-defined and that those teams will work together. So I'm gonna be looking at resumes of people from both sides. I want people who really understand the work. Where you get trust in an arrangement like this is from that understanding. Because both sides really know what's the right thing to do. They know what needs to be done to get the product developed, tested and fielded. So there's no, nobody's worried about the other guy doing something that doesn't need to be done or no fooling around. It's right into the nuts of the design, nuts and bolts of the design and the process to test out and prove out the product. So I think this is an experiment worth trying. And if we can have some successes with it, we may be able to broaden it. But it's related to that last major bullet there about improving the professionalism. If we have people who are just doing a checklist, and my earlier discussion about the TRL levels and having had competitive prototypes goes right at this. If I had had a skunkworks-like quality team and a government industry side, that would not have happened. We would have had a test of the tests and demonstrations of technology that actually reduced the real risk on the program. Because both sides would have understood exactly what it took to do that. And that's what I have to have to make that work. It's also gonna be a program that entails some risk and is probably in a cost plus environment. Because of the close interaction, it's necessary between government and industry. If you have a fixed price environment, essentially the government has defined the specification, turn it over to industry and let industry go ahead and do the best to do the job. It's simplifying it too much, but that's the basic idea. So that's the idea of the skunkworks. I think it's something to aspire to. I think it's worth the experiment. We can have some successes and people who are successful at it will get to do more of it. And I think in the end, it could be a very, very efficient way to do work. But it just depends upon those criteria that I talked about. The concerns that many in industry have had is how will the companies of the trade association stay engaged with the process of implementing and deploying the results of the better buying power work that we'll be going on over in the department. Some of the areas that will be addressed in this new effort will, volunteers that are already covered by the FAR, the DFARS, other areas you've already got existing guidance. And so I guess there's a general question. What can industry look forward to in terms of engagement or the opportunity to comment on proposals, whether it be through a public rulemaking process or some other method? Now that'll vary by the initiative. Most of these have some specific actions associated with them. So we'll continue the dialogue. I interact with individual, some industry constantly, Brett Lambert is here. He's my lead for industrial-based relations, basically. He's manufacturing industrial-based policy has a very strong connection with the industry. The service acquisition executives all do. We will organize some ways to have a more structured way to get at some of these. Some of them will be DFARS changes that'll go out for comment. Others will be documents that will give the industry to give a chance to comment on as more general policy guidance as opposed to specific directives like a DFAR. So we'll continue to engage with industry. And if industry has ideas about how to expand that and how to make it more effective, I'd be happy to hear them. So you mentioned the selected act of position reports that you're sending over today with no non-McCurdy breaches, congratulations. Several people have asked the question about what metrics are you using to judge these various initiatives that you have? That's a terrific question. I've been talking about this report I've been producing for about a year and a half now and I think people are tired of me saying things about it. One of the things that I felt coming back in the government three years ago was that it was time we started measuring our own performance. And I've been working to put together a body of data. I have a sign outside my door that says, in God we trust all of this must bring data. So that we can start to actually look in the mirror and see how we're doing. I used to ask the question as I talked to different groups of acquisition people, can anybody in the audience tell me how well we're doing today compared to how well we were doing five or 10 or 15 years ago? And nobody ever knew the answer. I think it's time we started measuring. It's not, if you don't know where you are it's kind of hard to tell how to get to where you want to go. So we'll be looking at the obvious things first. We have the SARS and air bases for a lot of data on original baselines and where we ended up. We also have a lot of data from the federal procurement data system on contracts. And if we start out to do development of a certain program, how much money we end up adding by the time we get the contract completed and that sort of thing and what kind of changes we do. We're fine, I've seen a couple of very good studies on past performance that have gone into excruciating detail on what actually happened in a program. Often by going back and interviewing people who were there when decisions were made to try to understand why the decision was made, which is often a very big part of the equation. So we'll look at the top level metrics of cost and schedule performance relative to initial plan. That tells us how well we're executing our plans, essentially. It doesn't tell us what we should have done. We'll also look at policies and what effect policies have on results. And there's so many variables I mentioned earlier in the acquisition business that it's very hard to pull out and correlate specific things. And a good example is fixed price contracting. Is fixed price contracting gets you better results or not? The answer is it depends. It depends on what phase of development you're in and what kind of work you're doing. Does some kinds of products seem to inherently have poorer performance, poorer results? The answer is yes. C3I programs don't do very well, for example, compared to others. Does some of the services do better? Does some of the buying commands do better than others? And this isn't about pointing fingers that people are blaming people. It's about understanding what works so that others can emulate that and do it. So my long way to report, I've got a stack of data about what Katrina about that thick that I'm trying to get into a format that I like and get that out to everybody to look at and think about because it's gonna be something that's gonna be very thought provoking. It doesn't tell you the answers. It tells you much more than you know right now about what's really happening. The next step in this, and this will be updated annually, as we get more insights and we collect more data and become more knowledgeable of what really is affecting what. We'll look at things like non-McCurdy's, what's happening to non-McCurdy's over time. Cost and schedule and performance changes over programs. We'll look at whether we're passing operational tests or not. We'll look at how many programs that we start and then kill. Those are the sorts of things that are gonna be in this. We start, one of the reasons that first bullet up there on affordability is there is because we've started too many programs and then shot them, usually because we got far enough down the road that we figured out finally we couldn't afford them. That's why now we're going back. So we're learning from our experience there. There are lots of other opportunities. We'll look at industry. We'll look at how some firms, are some firms consistently better at delivering products as they promise they will than others. And that'll be of interest I know to industry to see how they're doing on that. So we're moving the direction of trying to measure that. For each of these specific things, we haven't tried to come up with a specific one for each of these. Some of them probably lend themselves more to that than others, but it's something that's worthwhile for us to take a look at. Terry, what, as far as the, in the various initiatives, what thought is being given to and sent greater participation by the commercial sector in a DOD acquisition as budgets draw down and we can take advantage of investments made in the market and through other sources? There's some sectors where commercial technology is moving very quickly. And one of the things we can do to make it easier for people to get in and into defense businesses by establishing open systems and open standards, that's mentioned up there. One of the areas where we're doing something like that is our tactical radios. We have had a long troubled program for a long time called Jitters Joint Tactical Radio Systems, which I spent the first couple of years, I was back in the Pentagon, working with Heidi and with others to try to get those on track. And I think we've gotten to a point now where we recognize that for some of those products, industry had done some investing on its own and it actually, you know, come up with products that were competitive that would meet our requirements and we ought to give people the chance to bid those products. So we're going to a more commercial like acquisition strategy for some of those products. So where there are opportunities like that, we're very open to them. But commercial electronics, particularly in the RF domain is one area in the information systems area in general. And a good example of that is a combat system on the Virginia, which is largely an open architecture using commercial products. So that's one of the ways we can bring competition, of course. It's also a way we can get much cheaper products, at least at that level, maybe not. I'm not going to get a commercial fighter plane, but some of the things that I put in the fighter plane may be commercial. This question has a judgment inherent in it, but I'm going to ask it the way it was posed because it does raise an interesting question. How do you optimize your industrial base when you have little or no control over the government depots? Depots provide a lot of value to us, okay? And there's a reason to have some organic capability to do certain things, maintenance mostly and upgrades. You know, it's a very sensitive political subject. Right now, with the situation we're in the department, we are looking at creative ways to try to save money and to have more competition. We're not allowed to have competition, I think, on the law between the depots and the commercial world at the moment. I don't know that we're going to be able to go so far to try to take that one on politically. It's something we should think about. There's very strong caucuses you're well aware that supports the depots since anybody in the room, I think, is well aware. And we do need some capacity there. So the question is what's the right balance? I think we need to be sure that our depots are giving us value and we need to have competition where we can, but I'm not sure that we can move very far away from the situation we have right now in terms of the balance. Barry, to what extent are the Better Buying Power 2.0 initiatives and their expected outcomes or other acquisition initiatives that you might be looking at as follow on influencing or informing the strategic choices and management review? We are looking at seeing things in the strategic choice and management review to improve efficiency. Ash and I worked together in a meeting just before we came over here looking at some of those. As the original Better Buying Power was part of Secretary Gage's official initiatives, this is a continuation of that. Where we can identify savings, we will. What I think will come out of this work, though, is a little different than that. Our average development program for an ACAT-1 program overruns by about 30%. Our average early production lots for most of our ACAT major programs overrun by about 10%. That's not in our budget. If we can just get to where that doesn't happen. We can avoid a lot of problems we're going to have downstream. Our budget does not assume overruns in our programs. That's a built-in problem for us if we don't address it. I don't expect to be perfect in development in particular, but I think we can do better in both of those areas. On the services side, I think there are some things we can do on the services side to improve efficiency and drive down cost. We did put some assumptions about that into earlier budgets. Ash and I worked that together, and we moved up to the deputies position. So we may be able to do some things in the IT area, for example, where we can see some efficiencies. I don't think anyone should fool themselves that if we take $50 billion a year out of the future budgets that there's a free lunch in there somewhere. We're at the end of... I'm just back in government three years. I walked into the Pentagon in March of 2010 after having been gone for about 15 years and very shortly after that, Secretary Gates made the Abilene speech and he and I sat down and said, you know, this is serious business. We've got a big part of this. Let's get to work. The Better Buying Power 1.0 initiatives came out of that. As did a Hill host of things that were not part of Better Buying Power that the department did to improve efficiency. We did some consolidations, closed organizations. We went through another exercise when we took $50 billion a year out after the Budget Control Act was posted to try to get efficiencies. There's not a lot of fat left where there's easy places to cut. I mentioned earlier that we're not making choices of things, you know, which thing would we like to have that's on the margin to what we want. We're not cutting anything at this point in time. You know, we're getting rid of... we're doing the least worst things. I'll put it that way. That's the kind of choices we're having to make now. And you mentioned foreign... earlier question on foreign comparative tests. Good program. I had a lot of good programs. I had a lot of things I'd like to invest in. And as all these things we could do to build products and to make money and improve efficiency, but they all require upfront investments, you know. A good example of that is BRAC. BRAC requires some upfront investment and, you know, you get a good return on that. We put a BRAC proposal into our 14th submission. We put one in our 13th submission and it got a very warm reception from the Congress. We put it into our 14th submission and the first time around we didn't assume any savings and we didn't assume any cost. We didn't actually do it. The second time around in 14 we did assume some savings, but we put in the cost to try to get those savings. If you look at the return on the first few rounds of BRAC it was very high. The last round is not really representative of all of what can be done with BRAC, the 05 round I guess. The rounds before that got a great return on investment. But we need some cooperation from the Congress if we're going to go down that path. There are a few other areas like that, but we're not able to make some of those upfront investments to get reductions later on. We don't have the capital. We don't have access to the resources to do that. So it's unfortunately a situation in which we can't make all the upfront investments that we could to save money. Even some of the best ones. It's not a good situation for us to be in. Close to the end of the time that you're available. So maybe we should end this or get close to ending it with one that has an acolyte at least to start in the question. I'm in favor of that, Kim. That's a good idea. And then the points they would like to make is how are you getting the word out to your workforce that whoever this individual still sees it being used as the first choice in service acquisition, even being used in, even also being used in cost reimbursable contracts? I have a major task and my service acquisition executives have a major task. And Katrina and Jim and the rest of the team have a major task of communication. There's continuity from 1.0 here. A lot of continuity. There's some change here. And there's a equal and a recognized lesson, I think, from 1.0 was the importance of communication.  My key leaders are going to be getting out and talking to the workforce. We're going to be putting guidance out to people. We're going to be doing things at DAU at the university, the defense acquisition university to train people. Partly because a lot of this is on teaching people tools and guidance so that they can use their judgment. Communication is crucial. And the DOD, just the acquisition part of DOD is a vast enterprise. It's huge. As all these different organizations, many, many layers as you go through the hierarchies, I mentioned the PEO, PM, SAE chain up there, something we're emphasizing for the major programs. But most people aren't involved with those. Most people are working somewhere in one of the buying commands or maybe on an installation. We're working for some work. There are a lot of layers away from the senior leadership. And we really need to make sure we communicate at all levels. And anything like this that involves change, clear communication is hugely important. And it just requires continuous reinforcement and tenacity to make people sure that people get the message. So it's a huge job to doing that. We're well aware of that. The follow-up is what matters here. It's not announcing these things or putting out the policy. It's the follow-up to get out to the people to understand what you intend for them to do and how to do it. So it's good, good, good. Very much for, first of all, just the dialogue, your willingness to conduct this dialogue. It's enormously beneficial. We appreciate your coming to CSI to do it. And we thank you for what you're doing in your service to the government and particularly in this, this is so important to the budget, what you're doing. So thank you very much for being with us today. Thank you, Kim. Thank you everybody.


Hello friends. Good morning. Welcome. My name is Zane Bidder. I'm one of the core developers of heat in the form of PTL My co-conspirators this morning Renaka Murav from Nokia. He's the PTL of Mistral and Feilong Wang from Catalyst. He's the PTL of Zaka And we're here to talk to you today about how to build a self-healing application with aid Zaka and Mistral There will be a live demo at the end of the session So if anyone kind of came with the the hopes of seeing the live demo crash and burn You'll have to wait for the end of session. I'm sorry, but Stay tuned because I think we've got some good stuff for you in the meantime Also, if anyone in the audience has a dead chicken, could you please come see us up front? So these guys are going to talk to you a bit about what aid Zaka and Mistral are But the one word answer is they're the alarming messaging and Workflow services for OpenStack, but I'll let them fill you in with some more details But before then I wanted to talk to you all about Kind of the big picture here and why What we've done in this in the Newton cycle is built some integration between Zaka and Mistral So I respect for that with so long and in renard and so long and time I have a from my team at red hat For my heat PTL as well implemented it And we think this is a big deal and we want to tell you about why So to do that I'm gonna start at the beginning By answering the big questions. Why are we here? I'll let myself to why we here at the OpenStack summit What are what are clouds? I'm sure all of you working on OpenStack have had the experience of trying to explain what OpenStack is to layperson One time I had to try to explain it to an economist, which led me to to start thinking about how how could we explain OpenStack and cloud in economics terms and The answer I came up with was it's it's kind of the culmination of a culmination so far of a trend to reduce transaction costs that that Prevent us from transaction cost prevent us from Utilizing our resources efficiently basically so if you cast your mind back to the bad old days of When you had to buy physical service run your application on You want to do a new application the first thing you do was you you called up your your server vendor and you said hey I need some servers And he was like sure We can build those for you and take a couple of weeks and then we'll put them on a truck and shut them out to you Or really it's purchase or you be like sure I'll fax that right over to you. It's primitive stuff and Once the service finally arrived on a truck, you know Your IT department would have to rack them hook them up to the network and so on and finally you could deploy your application And This whole process could take you know a month if you're lucky So the result of that was you bought a lot more service than you needed You bought them a lot earlier than you needed them Because otherwise you were going to end up You know if you had a load spike or something you couldn't handle it because you you're a whole feedback loop here is a month long And think that really changed this in the industry was virtualization So with virtualization you your developer can go into your ticket tracking system I was going to put an open source project logo here, but let's face it. It's probably Jira Open a ticket with your IT department and say hey, I need a server Your IT department could could go into over it because open source. Yes Provision your server send it back give it to the developer success, right? We've reduced the fever. We've taken the the really slow things like trucks out of the loop And we've reduced it down to you know this this could easily happen in one day So we're for it took a month and you might you might go through that process once every six months Here it takes a day and and you might go through it every few weeks So that's great But we still have a problem here we still have a person in the loop And that's slowing things down more than it needs to And that's where I can say it kind of comes into the picture one day. I'll figure out which direction is which on this click So those take it becomes self-service right So you don't often can go to over stacks. They get me a VM and I'm stuck return it and you've got it straight away There's no waiting and you can easily do this 20 times a day without a second thought So that's great success, right? We took the developer out of the loop. Sorry, we took the person out of the loop Or did we? Because I still see one there. There is a big loop and there is a developer sitting there So you may have noticed that I did not put a title on this slide I Think a lot of people would would say this is cloud we've got open-stack. We're running cloud, right? To me that's not not really the case like if you put this up up as a service on the internet and Said yeah, I'm a I'm a cloud people would kind of laugh at you a little bit like this is not comparable to AWS or Azure or or Google Compute Engine It's it's more comparable to a VPS hosting service like Digital ocean or something like that It's great. It's better than then the non-self-service version But It's not really a cloud to my way of thinking So everyone's entitled to their own definition of cloud, but my my working Working hypothesis which I'm sharing with you today is is this cloud is when the application itself is managing its infrastructure So the developer might initially deploy the application But once it's deployed The application itself decides when it needs more servers It decides when it needs less servers it decides when a server is died and it needs to be replaced And all this stuff can happen autonomously not only during the eight hours of the day when you have a developer sitting in front of horizon clicking on So that's my working definition of a definition of a cloud and The key thing about this is that You really really really want this to be open source Because we saw your application is now Relying on the cloud API is there it's part of the platform against which your application is running So we saw in the 90s like what happens when you we write your application against a proprietary API's You don't want to go back to that So I think it's really critical that That I think opensack is the only project that can be this thing right now So I think it's really critical that we support this open stack and that it Will give people the option to to write autonomous applications against open-source clouds and By the way, if you're if you're a higher achiever You can replace the developer in this with a continuous delivery workflow. So that's the Jenkins logo there You can have Jenkins deploying to open stack. There's a couple of other options Zool is what the second for team has written That that is also a good way to continuous delivery There's also the solemn project in the open stack Is also aiming at the same kind of thing? So that's kind of the what we're trying to achieve here The the two challenges with this for having your application talk to the and by way by application here, I mean Not necessarily just code running on another server on a container or whatever it's it's also Cloud services like aid and and zikar and what have you become part of the application? So your application is basically could be defined by say a heat template Rather than think of it as a software package So the two big challenges here are When the cloud is talking to your application We need that to be asynchronous because the cloud can't wait for your application The cloud has to be because we made it self-service the cloud has to be multi-tenant so It can't block on anyone Tenant and that communication has to be reliable because you don't You know, you don't ever want to lose a message And zikar is the answer to this because it is an asynchronous cue that with reliable delivery for open stack So that's that problem solve. The other health problem is you want To have all your calls authenticated of course and and you want to lock down the authorization to only the things that you need to do and It's time to pass this one is when it's the open-sets services talking to each other on your behalf And we're using keystone trusts for that and the other half is when you have Code actually running on another server and container or whatever and that has to call the other stack APIs and that has been historically a bit of a problem because we don't really have a good way of Creating credentials for another server and locking them down to own the APIs we want them to access So that work is kind of ongoing and we're hoping to push that in but I was when I made the slide I was planning to tell you all that that was kind of still a work in progress and we had to wait for that but In the process of doing the talk I I realized that we've actually solved this problem as well with the zikar master integration So talk about that in a moment So here's what we're trying to build or in fact what we have built and and basically so zikar is in the center there And it's kind of the hub where so we've got Messages going through zikar and there are various sources of messages and there are various syncs where the messages can go so for example a lot of a Lot of projects were not a lot of projects, but Heat for example is able to send as a car notifications on certain events like when you hit Resource hooks, so you can set a hook in your heat template saying Break before this resources created or updated and you can send a as a car message at that point There's also Solometer and aid also notifications You can trigger alarms off of notifications They're called event alarms and aid there are of course other types of alarms from aid that based on whatever data salameter is collected and so these can all target zikar as a As a message Q and you can pump messages into there the application can also send messages to zikar And in fact as I was mentioning before about the the authentication there are pre-signed URLs in zikar, so you can give your application code running on another server a pre-signed Zikar URL and the only thing you can do with that is pump messages into that one zikar queue and Then we have the message sync so the main one we want to talk about here today is menstrual And that's what we've implemented in Newton is is the menstrual message sync So basically these messages coming out of this car queue can trigger a workflow in menstrual to start So that that's how it also solves our authorization problem Because you can you can only pump messages into one to car queue if you've got the pre-signed URL for that queue And the only thing that can happen as a result of that is running that one workflow, so it actually gives you a extremely fine-grained way of of Locking down the permissions to running that exact workflow so That's that's basically the system. I'll let you guys these guys give you some some more details, but Basically menstrual can call any API an open stack and so this this whole kind of loop here gives you an extremely flexible way of of Taking actions based on events in the cloud So if you know we're demonstrating a self-healing today You can totally get self-healing if your application is running on Kubernetes That's fine like if if that fits your use case you should probably you know buy open shift or whatever But It's not very flexible.  You can you can do just about anything in here. So Lastly before I hand over to these guys. I just want to say That It's we're turning over to y'all, right? It's really up to you We will get the open stack that we deserve. It's an open source project So please Go out there try this out Try the demo out Figure out what what your own application needs start putting together your own workflows your own your own message kind of setups and Try it out use it be vocal in the community say, you know, this is this is What we want open stack to be we want it to be a real cloud not just to be PS hosting service if you buy from a distributor Call them up and say you know Please put more resources into this especially if you buy from red hat Call them up say I saw Zane these talk. Why aren't you giving them more time to work on this? If you don't buy from a distributor one will call you So yeah, just That there are people in the community who Don't think who think this is a distraction and I don't think it is and and it's really up to People who are developing applications on open stack the users of open stack to say hey, yeah, this is this is something we need We what we want to see more of this. So thank you very much I'm gonna turn over to for a long who's gonna tell you a bit about aid and Zaka Okay Next I'm going to introduce a little bit about aid and somebody called it old out her ALDH whatever and I want to be surprised, you know, if there is another pronunciation about it It is an open-stack alarming service and it's looped out from Celerometer So I leave some aid features, but you know, there's not all the features of it I just leave some features related to this topic So it can support event alarm and threshold alarm and in in this topic for our case we only Care about the event alarm so we can so when Celerometer collects the event from, you know The other stories and forwarded to aid and then we can I mean Zaka can get that that event so about About one or two cycles ago. I was asked to reveal a patch in aid that is a Zaka driver it looks very interesting because you can with that case you can You can get the event notification collected by Celerometer and forwarded to to Zaka I Say I'm excited because you know for The old way Celerometer can can collect all the notifications, but those notifications Can't be consumed by the end user When I say end user, I mean the tenant user so yeah, I I Have heard about for example another stories like searchlight Also doing this the similar thing to collect you know the notifications from From the rubbish ruby. I'm killed message bus and then forwarded to darker so Is a really good feature and that's one of the main part of this of this demo and Then what is darker? So I I talked with then about you know when we try to Propose this idea because just because I I don't want to propose another Ducker introduction topic in open-stack summit. We have talked about you know those kind of Topic a lot. So we would like to do some Some real things some interesting thing Anyway, so I would like to give a very short introduction about darker Doctor is a multi-tenant cloud messaging service for web and Mobile development you can you can imagine this, you know the same service in AWS is ice QS and SNS to queue service and not vacation service so the features of Dr Currently dr. Can't suppose Messaging service and you can call it to queue service or there are all and notification service for for the messaging service is like a pops up and Producer consumer the traditional way and notification service you can create some Subscriptions on a queue. So when there is a message posted in the queue The subscriber will be notified automatically and currently we support the databases from We have two layer sorry We have two layer Layers of database one is a measurement database and one is the message database for message database We support mongo DB and Redis for minimum database with support mongo and So Calcami So for transport layer, we also have a transport layer transport layer We support whiskey that the you know the traditional HTTP way and the web socket and For notification driver currently we support email So for example when you post a message in the queue if you create a subscriptions on the queue Based on an email address Then the message will be forward, you know send to the email address and we also support web hook for sure and The trust driver. That's my favorite driver. I didn't buy Tom's so the trust driver is a you know the case long the the key part of of this demo Yeah, so now I will pass away Okay. Yep. Thanks So just to provide a little bit more details on to that big picture that they described so I'm gonna talk a little bit about mistral and So essentially what what is mistral so mistral is a workflow service workflow engine or in other words we can call it like process automation and state management tool and I can say a couple of words a little bit later Why I choose chose actually This name state management tool So mistral is also a language to design distributed processes In fact, so they will we call them workflows actually workflows kind of a general term but term but in our case we Call workflows essentially distributed some distributed processes that involve a lot of things And a distributed environment actually a lot of calls So and it's also an Opus tech service, of course with the rest API and It's scalable. We can scale it almost like linearly and What's important in the context of this demo? Mistral helps wiring Opus tech services together. So it works sort of like a glue and This is something I will tell a little bit about later So like What does mistral do essentially so it allows you basically to Describe a workflow template workflow file and you can upload this workflow template into Mistral into the service and Essentially, you can start this workflow manually or in our case. It started based on some event happening in the cloud somewhere and When it's running it allows you to track the process the progress of this process actually so that you can see What's already completed? What's not what is still running? So that's why I chose that name State management tool because state is like really important concept here because it's persistent allows you to do all kind of monitoring like Manual intervention human intervention actually something failed you can Actually go fix the problem and start from the same point So that's why I think state is so important here and eventually when the workflow completes you can extract the workflow result through the API and You can also navigate through execution history so that you know exactly what was happening before Just a couple words about Mistral language, so it's actually pretty simple like a couple of hours to learn. I believe so at least I'm biased a little bit, but I Really believe that so and it's the amal base because we all love the amal in Opus tech and So what it allows you to do is it allows you to design workflows or distributed processes essentially consistent of tasks so task is like a key like a Basic element that you can build your workflows out of and you can define transitions between tasks So essentially what you do here is you can represent your distributed process distributed scenario is a graph essentially and when it's running the workflow engine actually makes decisions about what should be running next and that actually Shapes the path in the graph how the workflow is proceeding and Tasks are associated with actions. So Mistral goes with a lot of actions like Zen mentioned Mistral can actually call any open stack services and this is provided this in the form of actions So and when it comes to wiring multiple open stack services, it's essentially The interesting point so we can flexibly Define what should be done on a certain event that just happened in the cloud So and basically you can build a scenario of how to heal your application how to other scale it do something else And it's extremely flexible You can have a set of workflows for like any kind of situations essentially and when you design this workflow It's some certain steps of this workflow actually Mistral can call open stack. That's how it Helps wearing it. So more specifically Mistral provides you with all the actions so you can build this kind of graph describing this process and It combines all this like service calls into one distributed process and what's important here. It's actually It helps with passing data bit data between the services So for example, you call one service and you need that the output of the service to be the input of the next service. So And in order to do it reliably Mistral is a really helpful tool here and It's it also helps passing security contacts, but Like Zen said It's kind of a work in progress thing in many in many ways, but it helps anyway. So basically it like determines Defines the context of this whole scenario of this whole distributed process involving like multiple open stack calls Yeah, and like I said before it's also important that Mistral allows to do to make this scenario like state state stateful and suitable for monitoring. So you can See this persistent state by like connecting it to it from like any tools Like CLI something else And that's basically that's can we go to the demo. Thanks Okay, so before we show the crazy demo, let me Get a little bit introduction about how it works Then help gave a very good graph about how it works, but basically This is a pre steps how to set up the the application actually So firstly we need to create a stack in heat the stack actually the stack is your application for example auto scaling auto scaling instance and Create a workflow in Mistral based on the stack information for example the the instance ID the stack ID the stack ID and Then Create a pre-signed queue in Docker so that you can get up, you know the prison accused and create and The alarm in 8 and before that we also need to create a subscription in Docker based on the workflow. We just created so that when there is a notification in Celerometer celerometer will notify 8 and 8 for world For words a message to zucker and zucker notify Mistral to as cute to workflow So yeah, and the last step is create an alarm in 8 Based on the pre-signed queue information, so you don't have to worry about it, you know the authentication issue And precisely I just mentioned how it works So I'd like to Okay, so firstly I will yeah Initialize the environment just clean some out results. I just created just give it a new key That I really just because I'm using Docker for heat to To listen the you know the heat stack create Changed status instead of just pulling heat again again to check if the stack has been created completely Okay, the first step is create the stacking heat Okay So now the stack has been created successfully and we are going to the next step So the next step is Create the creating the workflow in mistral just based on the information we just got from the stack We need the instance ID and the stack ID So, you know at later we can we can mark the instance as unhealthy and call heat Stack update to update the entire stack And then we create a pre-signed queue in backer You will see the the information the pre-signed queue information You just create subscription. You can see the first subscription is based on So the the workflow ID of mistral so that you know when there is a Notification an alarm from 8 to darker darker will create the execution in mistral and we also create Subscription based on an email so that you know when they're in alarm you will be notified based on the email Okay, so We just create all the stuff we need the last step. We just create an alarm in 8 Just not finished. So now let's Take a look at The instance we just create two instance Is an out of scaling group. So there are two instance and that group and for now We can try to ping it works Works so now I'm going to stop one instance, I know the the Noa stop status is not a perfect Status you can trust to you know to do the auto healing, but I think it's good enough, you know to show the idea Okay, so we can take a look at the no status So what we are expecting is there should be a new instance create and The old one will be Yeah, just leave it at a status. Come on. Well, I've never got strike again actually that's one of the the issue I I See when I you know to prepare the whole demo the the in one of Our salameter to aid is not really Really stable I would say try shutting down the other one Okay, it's not really easy to Try again. No As I tried it before before the session I will try the other one to see if it works Okay, I now I'm going to restart the The salameter agent notification to see if the notification can be forward Oh We're almost out of time. Do you want to play the video? Oh, yeah, maybe we can we can actually in the meantime Maybe we could take some questions. Yeah, you might have questions. I'm happy to ask Excellent question. So the question was can we use the heat stack to create all the stuff that we see in the script here? I'm still missing one. Yeah, short answers. No, we're missing like two resource types of needed heat One is so we can create aid alarms and heat but not the aid event alarms So I've raised a bug for that. We will we will get that implemented in our car The other thing is there's no way to create a pre-signed as a car queue and heat at the moment Again race bug will fix that in a car So I would expect in the next couple months. We'll be able to Put this whole thing in a single heat template and and you can define your whole application one heat template and say bam There we go. Self healing Application in one template. Yeah Yes Yes, yes, it can Yeah, actually you can yeah, so It can be well the only integration point actually with OpenStack is OpenStack actions Available in the workflow language and they're available only if you authenticate against guest keystone But if you disable it, it's fine to use it anywhere else. So actually most of our like real Big use cases right now Have nothing almost have nothing to do with open stack. Yeah, so you're we're detecting and the Vm stops or fails or whatever and and what you're detecting you can change it depending on what events you set up alarms on Yes, so you're so if you want your application to be the one detecting foes instead of Someter and aid You can you can post messages to the zikaku directly from your application or you can post Your application can post Statistics into Solometer and you can have alarms coming up based on that as I said before it's it's very very flexible But yes, if you've got you know, no girls monitoring your thing you can have that post messages to the car Pretty much anything you can think of Yeah, you can set it up. Okay. I have pulled the the script I'm using on GitHub so you can Grab the link to take a look. It's at the whole floor. But yeah, as Tim mentioned after all we created those Missing results in he's we can basically create, you know all of the things in one hit template and yeah So I guess we ran out of time I don't believe there's anything special you need to enable I know there is a couple I think bugs that we fix that may not Be unstable in the end yet the only thing the only thing you may need to enable is enable the event event alarm in Celerometer's configuring file test. Oh, yeah, thank you very much. Thanks everyone