Good afternoon and welcome to today's Energy Seminar. We have a real treat with us today, a former student in the Management, Science, and Engineering Department, Ryan Ledek from the Brattle Group. He's a principal there now. I do remember Ryan as being very precocious. I think he had come from Charles River Associates and worked with some people we work with pretty closely and he came back to school. The way I remember it is those on the faculty spent the whole time he was here trying to talk him into going into the PhD program, but he was wise enough to turn us down and very productively went and now at Brattle, which is probably one of the most highly regarded consulting firms in the energy space. Oftentimes, consultants are either thought by the academics is not being sound enough on the theory side and thought by practitioners is not being practical enough for them, but I think Brattle, in my way of thinking and understanding what they do, has been able to strike that balance perfectly and that leads to his topic today, which is one of several methods people have thought of to try to get more renewable energy on modern electric rates as we now seem to want to do very urgently. If I read his bio, he's worked on all the other options and now he's going to talk to us with a clever dual meaning title about increased reliability using virtual power plants. So he'll describe to you what that means and how it fits in with all the things one could do to keep the reliability up and reduce the cost of pushing for a very high penetration of renewables on electric rates. So with that, Ryan, take it away. Great, well, Dr. Wyatt, thank you very much for the introduction. It's great to be back here. Just to give everyone maybe a little more background on the Brattle Group. So we were started in 1990. Our first office was in Harvard Square in Cambridge, Massachusetts. The first office was at the intersection of Church Street and Brattle Street and the founders of the firm wanted to name the firm after the street that our office was located on. So that gave them two options, either the Brattle Group or the Church Group and they opted for the Brattle Group. So that's little history. We have a large energy practice which is the practice that I'm in. And as Dr. Wyatt was just describing, the focus of my consulting practice is on regulatory and planning and strategy matters that have to do with all the really exciting stuff that is happening on the customer side of the electricity meter. So electrification, EV adoption, rate design, energy efficiency, demand response, rooftop solar adoption, distributed generation, all the really exciting stuff that's starting to happen when consumers start to become more active participants in the energy ecosystem is what I'm focused on. So today what I'll be talking about is a study that we released in the spring at some work that we did for Google. And they came to us and we're looking for some help really articulating the value that you can get from being able to manage consumers, utility customers, electricity consumption in a more flexible way to provide services to the power system. And so this is a summary of that study. Maybe just to kind of quickly calibrate here, just in terms of a quick show of hands, how many of you have already heard the term virtual power plant and feel generally familiar with the concept? Okay, so maybe half, maybe more. And really in my view, we're talking about virtual power plants today. It's really an evolution. This is to an extent something that's been happening for decades. Years ago it was referred to as demand response. Then more recently we started referring to it as demand flexibility. And now that we've introduced the idea that customers could push electrons onto the grid as well as consume them more flexibly, the term has now become virtual power plants or VPPs. So just to make sure we're all talking about or thinking about the same thing, just to start I'll give you a quick overview of how we've defined virtual power plants in our study. So the way we defined it is a portfolio of distributed energy resources that are actively controlled to provide benefits to the power system, to consumers, and to the environment. So what you can see in the green box here are just a few different examples of potential elements of a virtual power plant. Could be smart thermostats, electric vehicles, smart grid interactive water heaters, rooftop solar PV, distributed batteries, or on the commercial side, automated commercial building energy management systems. So the idea is to take some portfolio of those resources and then either the utility or a third party aggregator will bundle those together and control them in order to provide benefits to the power system. Could be the bulk power system, could be the more local distribution system. And by providing those benefits to the grid, ultimately the goal here is either to reduce the cost of providing power to consumers or to reduce emissions. And if those are achieved then ultimately what we should be able to do is take all of those benefits and share them between the utility, the program administrator, the participants in the program, and hopefully there's enough left over to benefit all consumers within the greater power system as well. And there are a variety of business models that exist for basically carving up that pie and determining who gets what. But that's the idea at a high level. When I presented this slide recently, some people have asked me, why isn't energy efficiency part of your definition? The definition explicitly says actively controlled resources. And if your goal with a virtual power plant say is to reduce demand during peak hours of the day, if there are energy efficiency measures they can do that very cost effectively and you know will provide you with energy savings during those peak hours, why wouldn't you include those in your definition of virtual power plants as well? And in my view that's a really good point. I think taking a broad view of virtual power plants and trying to make all of this happen more effectively is an important thing to think about. So just wanna give you a couple examples of virtual power plants that I think are kind of interesting innovative ideas to be aware of. The first is a program that's been run for a while now by a utility in Vermont called Green Mountain Power. And this is a program that's focused on deploying distributed batteries to individual households. Basically the way it works is the consumer leases a battery at Tesla Powerwall from the utility for about $55 per month, which is very discounted price relative to what they would pay if they were buying the battery themselves. And in return for receiving that discount under very specific predefined conditions, Green Mountain Power, the utility gets to operate that customer's battery in a way that will benefit the power system by relieving grid constraints or producing energy from that battery at times when it otherwise could be really expensive to generate the electricity themselves or buy it from the market. So the really interesting aspect of this program is the customer who's participating gets the resilience benefit of having that battery basically as a form of backup generation. They get to use that battery however they want during most days of the year. And then when it really makes sense from the utilities perspective, the utility gets to use the battery to reduce costs or improve reliability for all their customers. So it's a really interesting way to sort of stack all of those different benefits that you can get from one single distributed energy resource. And then on top of that, what's a really interesting feature of the Green Mountain Power program is they're specifically targeting the deployment of these batteries in this program to areas of their grid that tend to have customers with lower than average incomes and parts of their grid that have less lower than average reliability. So that's just further compounding the benefits that you can get from this really unique type of program. The other example is a program that's offered by Excel Energy in Minnesota. This is a topic I've become particularly interested in. And it's the idea of bundling this virtual power plant model with something called subscription pricing. And what Excel Energy is doing is they're going out to customers that have electric vehicles and they're saying you can basically pay a fixed monthly subscription fee for unlimited EV charging. So basically you're paying for electric vehicle charging at your house the same way that you're paying for Netflix or Spotify or any other streaming services, for example. So from the customer standpoint, that's really interesting because it's very simple, very straightforward, you can plan around it exactly what you're gonna pay. The catch is the charging of the electric vehicle has to happen during off-peak overnight hours. So in return for giving customers this simple, very transparent pricing structure, the utilities benefit is that they're ensuring that that electric vehicle charging is happening during those off-peak hours when it's less expensive to serve energy and when those EVs are less likely to be contributing to congestion or capacity constraints. So pretty interesting model and part of that subscription fee from the customer's perspective also includes a utility-owned electric vehicle charger. So that's kind of the other commonality between these two programs is they both involve the utility actually owning a resource that's located on the customer side of the meter and being able to earn a return on that investment, which is, I think, potentially a way to get utilities more engaged in this. Those are a couple examples. There are a lot of other case studies that we could talk about later on. So I think it's a really important time for us to be talking about virtual power plants because it really seems like we're at an inflection point when it comes to consumer adoption of all these different distributed energy technologies that are going to be the backbone for making all of this happen. And there are a lot of reasons that we're seeing, we're expecting adoption of these technologies to pick up rapidly. The cost of distributed energy resources is coming down, particularly as you've seen with batteries and EVs. Technology is advancing quickly, particularly when it comes to the algorithms that are needed to manage all of these different technologies in a coordinated way. The Inflation Reduction Act is reducing the price of a lot of these technologies to consumers. Something called FERC Order 2222 is designed to open up wholesale electricity markets to make sure that distributed energy resources can participate and basically compete against larger scale supply side resources in the same market. There's been an explosion of model availability of a lot of these different technologies. We've seen it with electric vehicles, but the same applies to other technologies as well. And then lastly, behind all of this is the decarbonization imperative. Consumers, policymakers, regulators, utilities, so much of what's driving their activity right now is decarbonization, that that's basically the foundation for making a lot of this happen. So the statistics that you're seeing on the right hand side of this slide, these are just various analysts' projections of the likely adoption of these consumer technologies by 2030, relative to where we are today. And what you can see is, depending on the technology, in most cases, relative to current adoption levels, the forecast is in the next few years, we could see an increase in adoption of anywhere between three times and 10 times the level at which these technologies are adopted today. So very timely to be thinking about these issues. So now thinking a little bit more specifically about our study and what we set out to do. Really what we're looking at with this study is to try and understand the extent to which virtual power plants can provide resource adequacy or capacity to the power system. 120 billion dollars has been invested in capacity over the past decade. And our view is that's likely to continue. So the chart that you're seeing on the right hand side of this slide is just showing the capacity that's been, the generation capacity that's been built in the US for purposes of providing resource adequacy to the system. It's been about 110 gigawatts over the last decade, mostly gas, peak or power plants. But recently you can see that utilities and power developers are starting to build large scale transmission connected batteries to provide this service as well. We think this need for capacity is gonna persist into the future. It's gonna be driven by a combination of electrification driven load growth, retirements of coal and gas units, and then our growing dependence on renewables, which are a great source of decarbonized energy but don't always provide a lot of capacity at the times when it's needed. So with our study we really set out to answer two questions. The first one was can VPPs provide the same capacity, the same resource adequacy that we've been getting from these traditional options? And then if they can, what do the economics look like? Are VPPs economically competitive with gas peakers and with batteries? So those are really the two questions that define the study. I'll spend just a couple minutes talking a little bit about some of the modeling that we did and then we'll jump straight into the results. So with this analysis we conducted the analysis at the utility level and it was done on an hourly level and we compared the ability of the VPP, a gas peaker and utility scale battery to contribute to reliability. So we defined our utilities having about 1.7 million customers as kind of a mid-sized utility in the US. This is a forward-looking study and we assumed that by 2030 half of this utility's load would be served from renewables. So this is a decarbonizing power system. And partly because of that because of the load characteristics of this utility, ultimately what that meant was that this utility would have a need for capacity or for resource adequacy in both the summer and the winter. So this utility now has a year-round need for resources like VPPs. And then to define the need for resource adequacy we just sort of looked at the load data of the utility and said, all right, let's assume that by 2030 this utility is gonna need 400 megawatts of new resource adequacy on its system and that could be due to replacing retirements or load growth or other things. And in order to provide that 400 megawatts of resource adequacy, the resource, the VPP, the peak or the battery needs to be able to serve in any hour all load that is contributing to those top 400 megawatts of peak demand over the entire year. And so what you can see on the chart is this is just an hourly chronological plot of this utility's net load. It's net demand for electricity. So that's the utility's electricity demand minus generation that it's already going to be getting from wind and solar resources. And you can see that in order to serve those top 400 hours of load, the resources need to be able to operate in 63 different hours of the year in order to provide this benefit. So now we'll jump into the results that we found in terms of whether or not VPPs can actually provide resource adequacy. What you're seeing on this chart is the utility's net load profile on a peak net load day in the summer. So the navy blue line is showing you what that utility's net load looked like before the VPP was dispatched. And then the dashed orange line is showing you what that utility's load looked like after the VPP was dispatched. The different colored segments are the four different components of the VPP that we modeled. As we were talking about a minute ago, there are a lot of different ways to define or create a VPP. We focused on four commercially available residential technologies. So behind the meter batteries, like a Tesla power wall, for example, managing the EV charging of the customer's electric vehicle at home, kind of like the Excel case that I was describing. Smart or great interactive water heaters, so controlling the heating element in a water heater, or smart controlling the customer's cooling and heating through a smart thermostat. So there are a couple of things that I think are important to note here. The first is if you look at the evening hours when the utility's peaking, when we simulated the dispatch of those technologies, we were able to reduce the load by 400 megawatts in any hour when that load reduction was needed. And then what you can also see is some of that load is being shifted into the middle of the day when on a utility system like this, you might have excess solar generation and actually a need to curtail solar output. So building load in those hours can help as well. This is just the peak day. What we actually found with the analysis was in order to provide this benefit over the entire year, the VPP would need to be dispatched in both the summer and the winter in seven different months of the year for 63 hours of the year, and in the case of this day in particular for seven consecutive hours. And so one question that comes to mind is, that's very different than the way utility demand response programs have been operated historically. And so one question is, can you actually get that level of performance given various constraints around, from the customer's perspective, their willingness to actually let you tinker with their thermostat or tinker with their EV charging? And the answer is yes. All of our modeling took into account what we've seen as being real world constraints around customer willingness to have the load of various end uses controlled. So just to kind of give you a sense of how we modeled this, what I'm showing here is the average charging profile of a fleet of home electric vehicles before a virtual power plant event is called and then after the virtual power plant event is called.  And then the solid teal line is showing you how that changes when a virtual power plant event is called. So the first thing that I'll note is, we account for limits on customer tolerance for the number of interruptions. In the case of EV managed charging because there's a lot of flexibility there, we assume that you could shift the EVs charging load on a daily basis. For something like a smart thermostat program where you're managing the customer's cooling demand, there we impose limits and I think assume that you could only do that 15 times per year. So that limit on the number of events did vary depending on the program. You also can see that when EV load was charging, it didn't drop to zero when a VPP event was called. It dropped to something less than above that. And the reason for that is typically the way these programs are designed, customers will be given the option to opt out of an event. If this is a smart thermostat program and you wanted to manage the customer's air conditioning, if they were having a party that day, they probably don't want you turning up the temperature in their home, even if it's just by a couple degrees. So customers are given the ability to opt out of these events. And we take that into account in terms of the load reductions that we model. So that's what you see there. We are also accounting for the fact that we're only looking at the actual available load. So if some EVs aren't plugged in and charging during those peak hours, we aren't assuming that every EV is plugged in and charging at the same time. You know, we're also accounting for the fact that if you're gonna curtail a customer's charging load during evening hours, you're gonna need to charge the EV after that or before it, depending on the customer's needs. So there is load building increasing in demand, increases in demand that's happening around these events to make sure that you're maintaining that level of service to the customer. And then lastly, well, the primary goal here is to demonstrate the reliability benefits of VPPs. We also, as you'll see in a second, are accounting for other benefits that VPPs can provide at the same time. So when we're modeling how you would curtail a customer's air conditioning load or how you would shift their EV load, we're taking into account not just the need for reliability, but also the benefits that that can provide to the system in terms of avoiding energy costs or reducing emissions. So all that gets factored into how we've modeled the dispatch of each one of these technologies and we have a specific set of parameters or assumptions like that for each of the technologies in the VPP. So that was kind of the story around how we modeled reliability. And now the next question is economics. What do the economics of the VPP look like compared to these other resources? So first we'll just start by showing you what the economics look like for the gas peaker. This dark blue bar that you're seeing on the left, this is the total annualized cost of building a gas peaker and running it to provide 400 megawatts of resource adequacy. So that's gonna cost $70 million per year over the life of the peaker. But when you build a new efficient gas peaker, you're gonna get some benefits as well because that new gas peaker, when you build it and you run it, it's gonna displace older, more expensive, less efficient units that otherwise would be running. So that gas peaker is going to provide you with an overall reduction in energy costs on the system. And that's what's represented by the green and teal bars. Those are benefits that you get from building this new gas peaker beyond the reliability benefit. And when you subtract those energy benefits from the cost of building and running the peaker, you're left with a net cost of $43 million per year. So that's the net cost of getting 400 megawatts of reliability from gas peakers. We did the same thing for utility-scale batteries. Here you can see that to get 400 megawatts of reliability from utility-scale batteries, costs on the cost side, things look pretty similar to the gas peaker. But because of the economics of the way batteries work and the fact that they're gonna be running more frequently than you would see with a gas peaker, in our specific case, the utility-scale batteries provided greater energy and ancillary services benefits to the system than the gas peaker did. So in the case of the utility-scale battery, we're left with $29 million of net cost to get the same 400 megawatts of reliability. So those pictures look similar with the economics looking a little bit more attractive for the batteries. Then we get to the virtual power plant. And here, the picture looks pretty different. So first, on the cost side of things, you can see that just that annual cost of building the peaker, basically getting customers enrolled in this program and paying them to be able to control their various technologies, that cost is lower than the cost of building and running the battery or the gas peaker. It's coming in at, I guess, let's call it 40 or 50 million instead of 70. Then in addition to those costs being lower, we're also seeing that you can get a broader range of benefits from a virtual power plant than you can get from the transmission-connected utility-scale battery or the gas peaker. And the reason for that is virtual power plants are located basically at the edge of the grid. And when you're controlling load, that's all the way at the edge of the grid, what that means is you have the potential to be able to avoid expensive upgrades to the distribution system and capacity investments that would need to be made all the way down to the customer's meter. So that's a big chunk of the additional benefit that you get from VPPs is that potential to defer or avoid investments in both the transmission and the distribution system. And then on top of that, if you look at kind of the purple colored bar at the top, our analysis also did take into account the social benefits of reducing carbon emissions. So in this case, we just went with a round number of $100 per ton as the social cost of carbon and it factor that into the analysis as well. And in particular, what we see driving that is the efficiency benefit of smart thermostats, the fact that they can be more easily programmed, some of them have learning capabilities that program, so the thermostats actually program themselves. We saw that those energy savings actually result in a pretty significant environmental benefit. When you stack all of those up and subtract them from the cost, including the societal benefits, you're left with a net cost of only $2 million per year associated with getting 400 megawatts of reliability from the VPP. So that's pretty remarkable. I think when we went into this analysis, I was expecting to see the economics working out for VPPs. I didn't think that we would actually see the net cost dropping all the way down to zero and essentially getting free capacity from the VPP. So just to put these numbers into context, as I mentioned earlier, we did this analysis at the scale of an individual utility. We also just wanted to think, what could this mean at the national level? So RMI, Rocky Mountain Institute, in a paper that they put out recently, estimated that there's the potential to deploy 60 gigawatts of VPPs in the US by 2030. And if we just extrapolate from these results out to 60 gigawatts of national buildout of VPPs, what we're finding is that VPPs would save between $15 and $35 billion in resource costs relative to the alternatives over 10 years. And so resource costs is just referring to those things that are actually recovered through utilities rate, building out the transmission and distribution system and buying capacity. If we also factor in those societal benefits of avoided greenhouse gas emissions, that adds in an additional $20 billion of benefits associated with VPPs. So the story here is pretty remarkable, right? I mean, that's a pretty striking opportunity when it comes to doing this. And as I mentioned earlier, everything, all of the technologies that we modeled here are commercially available. You can get smart thermostats today. You can get electric vehicles today. So the big question is, why isn't this happening? I guess before I get to that, one other quick point I'll make is we also did a lot of sensitivity analysis. That was just kind of our base case result. We did want to understand how robust those findings were. So we ran, I think, a dozen different sensitivity cases, testing higher and lower avoided costs, different assumed costs of carbon emissions and things like that, and found that these results held pretty consistently across all of those cases. There are a couple of things that I want to just highlight. So these blue bars are the net costs that you were seeing on the prior chart. The teal bars are just showing you the spread of the outcomes of those different sensitivity cases. So the first thing to highlight here is there is a point where the net cost of the VPP is higher than the net cost of getting capacity from batteries. And so the economic competitiveness of those two resources in particular, virtual power plants and batteries, is something we'll want to keep an eye on going forward because that's going to depend a lot on the specific characteristics of a given market and also the pace at which the cost of these technologies declines as we move forward in time. The other interesting thing that we saw in the sensitivity analysis was the low end of the VPP bar actually drops into negative territory. So you could actually get resource adequacy from a VPP, not just for free, but with all of these other benefits actually outweighing the cost of the VPP. Okay, so that's the positive story. And then the question is, if it's so good, then why isn't it happening? And we do need to spend a little time talking about that. I have one more slide in here. Okay, I'm gonna keep talking about the benefits for two more minutes, then we'll get into why this isn't happening. The benefits just keep coming. So there are a few other benefits that we didn't quantify in the study, but I do think are important to highlight. And just in the interest of time, I won't talk through each of these individually, but there are a couple that I just want to point to because I think they're really important considerations today. And the first is this benefit that we refer to as faster grid connection. For large-scale utility resources to come online, the resource has to get developed, you need to get financing in place, you have to actually put steel on the ground. But what has become a major barrier to bringing capacity online and meeting our urgent need for resource adequacy has been something that's referred to as the interconnection queue. And basically, utility-scale resources need to get approval to connect to the transmission system. That hasn't always been an easy process. I think some statistics that I was seeing were suggesting that that could take a year historically, maybe a little bit longer than that. We're at a point now where there's so much capacity that's trying to come online, it's gotten so complex for the transmission system operators to manage that it now on average can take about four years for new resources to make their way through that interconnection process. That is a huge lag when you have locations of the grid that have a pretty immediate need for new capacity. Virtual power plants don't face that same constraint. Basically, you can build a virtual power plant as quickly as you can sign customers up to the program. So in locations where you do have an urgent need to get capacity quickly, I see that being a huge underappreciated benefit of virtual power plants and demand-side distributed resources in general. The other benefit that I wanna describe is what we refer to as flexible scaling. Right now when we think about forecasts of the rate of growth in electricity demand, looking out five, 10, 15, 20 years, I think this is, we're probably at a point of pretty unprecedented uncertainty in our ability to predict what the demand for electricity will be over that timeframe. There are so many assumptions that are going into the rate at which customers are gonna be adopting electric vehicles, customers are gonna be adopting electric heating through heat pumps, customers are gonna be adopting rooftop solar, that I don't think we've ever seen a broader spread of the uncertainty in these load forecasts. So what that means is we need to mitigate the risk associated with that uncertainty. And when you're going out and making a decision to invest in a large scale, traditional grid capacity investment, that's a 20, 30, 40 year decision that you're making once the steel's in the ground, right? Once the resource is built, you're committed to it and now you just need to sort of live with that decision. If it turns out that your forecast was based on an optimistic expectation around the extent to which electrification would grow load and that doesn't materialize at the rate that you expected, you're stuck with having a lot more capacity than you potentially needed. And VPPs give you more flexibility because basically you can scale the growth of a VPP with growth in load. And then on top of that, to the extent that you've overbuilt with something like a VPP, like demand response, you actually can scale it back. And if you discover that you're overpaying for that capacity, you can reduce the incentives in that program. You can't do that on an annual basis because customers aren't gonna really wanna live with the uncertainty of those incentives necessarily changing every year, but you do have that ability to right size the VPP in a way that you don't with other resource types. So those are the benefits. And now we will talk about some of the challenges in making this all happen. So we, as we kind of conclude this study, we focused on I think four areas in which we wanted to define conditions under which we really would see the value of virtual power plants being maximized. And in a lot of cases, these are conditions that don't currently exist today. So the first area is market design. When it comes to market design at the wholesale level, we need wholesale markets that provide a level playing field for demand side resources, for VPPs, for energy efficiency to come in and compete with large scale supply side resources. There's a lot of work that's been done in this area already. I mentioned FERC Order 2222 earlier. That's also designed to make sure that there is, you know, apples to apples treatment of both resource types in wholesale markets. At the retail level, we need programs and rate designs that will incentivize participation in these programs in innovative customer centric ways. So the Green Mountain Power program, the Excel energy program that I mentioned earlier, those are two really interesting, innovative examples. And I think if there's anywhere that we need to see more innovation in this space, how we design the programs in a way that counts for a lot of the interesting sort of behavioral constraints and nuances of engaging customers is where we need to see some development. Then there's technology innovation. So DERs are increasingly available. I mentioned costs and prices of these technologies are coming down. We also need these technologies to be able to communicate with each other and also with the grid. And there are improvements that are being made in that area but increased standardization around communication is gonna be important as well. And then the algorithms that optimize the use of these technologies while maintaining customer convenience and comfort, that's critical as well. There are a lot of companies that have entered this space and are developing software that can manage and integrate all of these technologies. And this is an area that's changing very quickly. But those algorithms, particularly as they relate to making sure that this is a positive experience for customers are gonna be key. Policy support, codes and standards that can promote the deployment of these end uses will be really helped to sort of get them deployed. And then R&D funding that supports the removal of some of these technical barriers will be key as well. And we've seen recently the US Department of Energy being very active in this area. Some of you probably know the name Jigar Shah. He's at the DOE loan programs office and has become a real advocate for making sure that this happens and also making sure that loans and other forms of funding are available for this market segment to grow. And then lastly, the regulatory framework for myself as someone who does a lot of regulatory work with utilities at an economic consulting firm. To me, this is the key and probably in my mind the biggest barrier that has kept a lot of this from happening today is that utilities just don't have the same incentive to go out and build the VPP that they do to make conventional investments in grid infrastructure. They're in a return on capital investment to build out the grid. They don't have, typically have that same profit opportunity when it comes to paying their customers to use less. So the other key area in my mind where a lot of innovation is needed is around those regulatory business models. And I think if we can get that right and I don't think we've gotten it right yet but if we can sort of crack that code then I think we will start to see utility resource planning initiatives sort of more fully accounting for the potential benefits of VPPs. So the study that we did, there's a link to it at the bottom of this slide. It concludes with, that was a lot on the last slide so it concludes with just kind of three low risk actions that we think utilities and regulators can take today to start moving forward with VPPs. The first is to conduct a jurisdiction specific market potential study to really understand the opportunity. Those results that I showed previously as I mentioned, we ran those sensitivity cases and those findings were pretty robust but the benefits of a VPP in a market where your need for capacity is being driven by retiring coal plants, that story can look different than a market where you need the VPP because your goal is to really integrate a bunch of intermittent wind and solar generation. So getting a utility level or a state level view of the benefits is key here and then establishing some procurement targets around the results of those studies would be important. Also establishing a VPP pilot and I think the key here is a lot of times a pilot is kind of seen as a way to check the box, prove that you've done something and then kind of go back to building out the power grid. So I think two things, one is when we see utilities or other companies piloting VPPs, doing that with an assumption that it will succeed and a plan to scale after the pilot has completed is really important to making sure this happens. And then additionally, these pilots are typically used to demonstrate that a technology will work and make sure that everyone's comfortable with the technology. I think also using the pilot as an opportunity to test out some of these new business models and regulatory models that I was describing. That's kind of an opportunity that we've missed so far and is something I'd like to see as these pilots move forward. And then lastly just reviewing and updating existing policies to make sure we're comprehensively accounting for the value of VPPs are important. Sometimes we'll see a smart thermostat program being treated as an energy efficiency program in energy efficiency analysis, a demand response program in demand response analysis. And the cost of the thermostat is being counted twice in both cases rather than a single resource that's providing both of those benefits at the same time. So ironing out some of those wrinkles in the way we think about the value of these programs is key as well. So that's it. I think I'll stop there. Definitely would encourage all of you to take a look at the report. It's got a 30 page technical appendix for any of the modeling nerds like me that really wanna see the modeling detail that's behind all of this. And I guess to conclude just the last thing that I'll do is make a very shameless recruiting plug for Brattle. We're hiring, definitely would love to bring in anyone here who has an interest in energy economics, regulation, the types of issues that I've been discussing in this presentation. Find me on LinkedIn, come see me afterwards. I have been to this cards, but would love to talk to all of you about that. So I guess I'll stop there and we have a few minutes for a Q and A. Thank you. Thank you. Thank you so much. I can't believe that you were saying such an easy to understand way. I personally really appreciate that. And I was gonna ask you where the students could apply for a job, but you beat me to the punch here. So now we have about 10 minutes for questions. Do you have any student questions? Here we have a student entrepreneur right in the third row. Imagine that who works in part of this business that you talked about, Fulham. Hi, thanks for such an incredible presentation, Ryan. I have like four pages of questions. I'm like trying to choose which one to ask first. I'm glad you asked. But I'm curious to hear more about the customer profile composition of some of those results that you showed. And you talked about a couple different pricing models. Subscription and then sort of like the fixed monthly fee or something. I'm also curious to hear how customer preference for different pricing models was kind of viewed. That would be interesting. And I'm curious to hear what your thoughts are on what would make a good VPP platform? Cause when it comes to cost, a lot of the issues are, there's different sort of resources, different players who have different price and capacity beating behavior. So it makes sense to think about aggregation, but what would make for a good platform for an aggregator? Yeah, those are great questions. So I'll maybe start with the pricing piece of this. There are kind of two camps when it comes to thinking about how we financially incentivize customers to participate in these types of programs. Kind of the more kind of the purist economists will say, well just get the retail prices right, get the rates right that customers pay to consume electricity and all of this stuff will happen naturally, right? It'll happen in the most economically efficient way because customers will just naturally respond to those price signals. The other camp says customers are very, that's like that would be the economically rational approach, customers are very limited in the amount of time that they have to spend thinking about their electricity rates and their electricity bills because they have a million other things happening in their lives. So just give them the simplest possible value proposition, I'll pay you $50 per month to manage your air conditioner and then sort of take it out of their hands and don't force them to think anymore about it. People tend to be somewhat polarizing, people tend to take one view or the other. I personally, my view on this has always been that those two things can coexist. Something like a pretty simple time of use rate for residential customers where the price is, say higher during the evening hours and lower during all of the other hours and maybe very low in the middle of the night. That's something that most customers can wrap their heads around and the benefit of exposing all customers to that type of price signal is that that gives all customers an opportunity to respond and save money, right? You aren't just focusing on customers who can afford an EV.  You're setting those prices in a way that any type of behavioral response that works for the consumer will allow them to save money. So to me, that's the baseline, but then if we really want to get sort of the advanced level of control and management of these technologies that we really need to provide all of the services that I described in this study, then we do need to have more active management of some of these really flexible loads like EV charging or batteries. So that's where the second piece comes in and by giving customers that simple payment option, and then on the back end, doing the really complex work of managing the load in a way that benefits the system. That's where you can get more, additional incremental bang for your buck beyond that baseline pricing signal. Great. Other student questions? Yep, yeah, yep. You here? Thank you for speaking today. You mentioned Jigarshaw and the IRA. You mentioned Jigarshaw and the IRA. In your experience, do VPP programs and specifically VPP pilot projects qualify for EIR or Energy and Infrastructure Reinvestment loans and have they been successful in allocating money because sometimes they don't have $100 million projects? But yeah, so you're referring specifically to whether VPPs could qualify for the types of loans that like the DOE loan program's office is lending money for. So I think the short answer is yes. And one of the reasons, that you're hearing DOE and Jigarshaw talk a lot about VPPs is because they do wanna drum up interest in that part of the energy ecosystem in coming out, going out to the DOE and applying for those loans. So the answer is yes. I think you hit on kind of the key point is for those loans to make sense, particularly for utility, it needs to be a big loan because the utility does have access to other forms of capital. But I know for a fact that DOE is out there pushing VPPs in part because they do view that as being an important ingredient in the decarbonization solution. Great, we have two questions up here. We're gonna, it's all the uptime for it. Great in the middle. Hey, it was a really nice talk, thank you for it. And my question is sort of like a technical one and it's about the 400 megawatt power of the VPP and how is it calculated? Is it like the effective load carrying capacity of the VPP or is it like, so based on like what sort of parameters it's like the 400 calculated, like I'm sure the portfolio would have higher capacity but I just wanna know like what's the parameters for the calculation. Yeah, so the way it was calculated as we said in any hour that contributes to the top 400 megawatts of peak demand for this utility, the resource had to be able to serve all of that load in each of those hours. So we essentially required, with that definition, essentially required the VPP to be fully available to provide capacity and essentially give it the equivalent of a 100% ELCC across all three resource types. One last question in the middle here. I wanna say thank you so much. This was a fantastic talk. Truly really interesting stuff and especially hearing about the implementation and different proposed ideas for how that's gonna look like in the real world. My question was kind of piggybacking off the first question that was asked which was how do you see VPP programs developing in parallel with utility scale battery storage and then in the eyes of utilities are these two investment targets and priorities different or mutually exclusive for utility scale battery storage and then VPP programs? Yeah, that's a great question. I think the short answer for me is not either or. I think both resource types can provide strong benefits to the system and will be needed. I think in particular, we will eventually reach a point where we've maxed out on how much response we can get from VPPs. There are only so many customers who have smart thermostats and EVs and we typically work with utility to develop a planning study around VPPs or demand flexibility. One of the metrics that we'll report back to them is achievable potential. So what can you realistically expect to get subject to all the constraints around customer interest and participating in these types of programs? So there will be a limit on that that definitely does, even if VPPs are the most cost effective option, does open up broader opportunities for other resource types as well. I think the one thing I'll say is we haven't found a utility yet that has maxed out that achievable potential. Typically there's still a lot of low hanging fruit that exists. Great, well Ryan, thank you very much. By the way, we did pick up on your Jigar Shah reference and Chaitanya actually suggested we get him to speak next quarter. We did have somebody from that part of DOE last year which was also very popular. This is kind of boots on the ground, steel on the frame action rated things. So as predicted you did actually bridge the gap between the academics actually right at the end in response to follow this question between the academics and the practitioners and I think we need a lot more of that. So with that, thanks for a great talk and thanks to the audience for great questions. Thank you.


According to the World Health Organization, the number of elderly people defined as over 60 years old will have doubled from 11% in 2000 to 22% by 2050. As Matthew Parts in his 2006 article shows, this led to a baby boom in the 1950s and early 1960s. So as a paper by banister and colleagues from 2010 shows, one of the first effects is a neighbor shortage in China. As reported by an article in the journal Science, many academics think that the government should relax the one-child policy and allow couples to have more than one children. The team led by Li in 2011 argues that this reduced the cost of living and education when raising children, which would encourage parenthood. First, Zhang and Gose have suggested in 2006 that the central government should increase the elderly financial independence.


My name is David Wong. This is decoupled front end in the future. We're going to mostly talk about quote-unquote headless Drupal It's not going to be a very technical talk I mean, we're not going to be sharing code or like hey use this directive here It's going to be mostly high-level about you know the implications of using it going headless The difficulties and or challenges faced when going headless and what headless actually means And so if you're here expecting, you know, coach snippets and how-to's this might not be the session for you But if you wanted to have a discussion about the practice of doing headless What this entails then you're in the right place So this is your your last chance. I guess to escape and offer up your seat to somebody else Again decoupled front end in the future. My name is David Wong. I'm eating on Twitter I don't actually talk very much about headless on Twitter. So, you know, there's one reason not to follow me I actually post a lot of Instagram images I've given this talk a number of times already to a different Audience every time I've talked in front of developers I've talked in front of designers and I've talked in front of JavaScript people who you know could give it You know two craps about what Drupal was and so if I ramble a little bit It's because I've tried to make this talk a little more inclusive than straight Drupal devs talking at each other And I actually only have about 20 minutes of slides prepared because I'm hoping to hear back from you guys I certainly don't feel like the end-all Master or the person who knows everything there is to know about this particular subject And so the microphone there is for questions and discussion afterwards I work for a company called Acquia as you probably have noticed by my shirt and this is version 0.9 of This talk I've given it like I said three times already because most JavaScript MVC frameworks are like 0.1 Anyway, I figured this talk is never going to be perfect, but if we're here to talk about things like that We're okay with less imperfection So we're here to talk about ostensibly quote-unquote headless Drupal Actually, let's do a first show of hands. Who's heard about the concept headless Drupal? It does this word mean something to people. Okay? Usually when I ask people about headless Drupal, I usually get two reactions.  This is her favorite movie and as By proximity also mine now apparently So what is headless right? What is headless? Everybody has an idea of what headless is and I think all what 400 people have joined the headless Drupal group on G.o with a different conception of what headless might mean For some headless is Drupal as a content model and entity API minus the client-facing theme layer For some headless just means Drupal as a restful web services endpoint For some headless means Drupal serving as a content repository for a greater system of web properties or web apps For some headless simply means bring your own front-end. I want to bring my own front-end to Drupal More prosaically your app up front Drupal in the back, you know, whether it be another CMS system It need not necessarily be JavaScript and yes, of course headless Drupal does also entail Client-side JavaScript MVC frameworks rendering Drupal data and this is the popular and the widespread conception of what headless is But my point here is that headless is a lot more than that You talk to headless of some people like the old drush drush is headless. Well, yeah, drush is headless Drupal too This is a minority of use cases in the wild right now of quote-unquote headless Drupal The JavaScript MVC framework use case is actually a small sliver of this wider use case of using Drupal as a services endpoint And we'll talk a little bit more about this. So why would you go with headless Drupal? Why would you not use the totality of Drupal?   It is absolutely yours to 100% control and tweak as you like and For those of you who are themers and traditional themers of Drupal That you know, this is a Drupal site. This is from a demo framework An open-source demo installation of Drupal that we use quite frequently at Acquia So let's take a look Let's just take this image right here 36 hours in Brooklyn, right? It's just an image and a view right It's it's just got a label. How hard can it be? How ugly can the markup be right? Right and there are people who've been railing about this for years I've been doing Drupal for seven of those years and as long as I've been in Drupal There's been a certain individual let's say the king of Denmark who has been railing against this sort of thing forever And it's been you know He's been pushing that stone up that hill for seven years and you know This is Drupal 7 this is after years and years of his it was complaining and cursing and this is still what we have Right and at this point I was going to do a more an impression but since he's not in the room I won't but but catch me at a party and I might do it You you get all the power of Drupal's content modeling tools, right? We're not taking any of that away Drupal's content modeling Drupal's content authoring and workflow all these things that we use on the Drupal Chronicle back end, you know, none of this goes away when you take away its front end, right? Users roles and permissions. This is a huge pain to implement on your own like you get this for free for free, right? And all the restful serialized entity data you can eat right because Drupal just spits that out willy-nilly as easily as you'd like it to and I wish Jeff eating or somebody like that. We're in this room right now. This value cannot be oversold You know like we get there's this Drupal community obsession with with oh, you know, it's Drupal so point-and-clicky and then even outside of the Drupal community It's so easy to point and click, you know, it's Drupal's for point-and-click developers It's not for real developers, but from a content modeling and information architecture and content Management for lack of better word perspective, you know, nobody ever said oh crap I just point and click my way to a really robust content model Nobody ever complains about that, right? Like if you want to go and write it and extend your own classes be my guest But you know point and clicky you can do a lot damn worse than creating robust relational content models pointing clicking wise And doing this, you know using Drupal says as a service layer I mean Takes us one step closer to that mythical holy grail of right once publish everywhere, right? You know like this this sort of idea that we're never going to be able to Write specific bits of content. We can't keep chasing Devices and and and contacts as they pop off like we have to get a step ahead We have to be more agnostic. We can't be just okay now We got to make an iphone, you know view or we got to make an ipad view.  We have to be more agnostic from the get-go and As a bonus nobody says you can't keep your headed sites either, right? Like, you know, you can have some headless Drupal and headed sites working side-by-side or even at the same URL if you wanted None of that goes away What does go away though other things you don't get and this is where it gets tricky Anything that comes from Drupal's front-end and this depends right? I'm saying anything right now So let's assume that we're doing a fully headless site. We have cut off the theme layer entirely You don't get anything from Drupal's front-end Drupal is a data service at this point And so all the things that you relied upon from Drupal's front-end from like anything that comes from Drupal's render pipeline Oh, yeah, that's kind of gone Anything that involves say drag-and-drop visual templating Anything that you know allows site builders to say, oh, yeah, I want this panel here I want this block there. Oh, and I want this block there and rendered as this display or this view mode Yeah, that's kind of your front-end problem now, right? It's no longer Drupal's problem Drupal's not going to give that to you right now at least not the way it's architected and we'll talk about that as well too Panels display suite modules any of those Drupal components that otherwise might inform things like display that might help you display things that might Do it for you without you thinking You know these go by the wayside, you know like you it's one of those things like you want It's like when you divorce your parents at 17, right? You want emancipation? Sure, but you know, you're not getting allowance anymore Front-end facing form API form API, you know welcome to rolling your own form API Basically anything that comes from Drupal's front-end and I'm taking a hard line here saying that you know work work You know this is the The headless Drupal that you've heard about maybe the head not the headless Drupal you've built But the headless Drupal you've heard about you know Josh Koenig's talked about this a lot and we actually co-presented this about a month ago The idea that we're going to completely chop off the front-end Now there's degrees to this and I'll show you some examples of where these degrees can take place Like we don't have to unilaterally chop off Drupal's front-end But if the ultimate goal is to have complete independence of front-end and back-end These are some of the implications that we have to live with at least for now and These are not trivial hurdles. I want to re-emphasize this like this is not something you go and say damn it I'm gonna do it, you know and screw it This is gonna be easy and and these frameworks make all this work easy because it can't be overstated how much of Your customers of your clients of the people who end up using your Drupal sites Who aren't necessarily developing your Drupal sites rely on these functionalities or have come to accept Drupal as that thing that provides that Functionality, you know for years and years and years We've sold and we've built and we evangelize Drupal as this particular thing that will give you all these features and all these functionalities and now comes along in the last year a Practice that says yes, we will make our front-end developers lives easier. We're going to embrace these new technologies We are going to draw the line here for our developers and what I haven't really seen is much of a conversation around Well, what are the implications for the users of these sites? What is it? What are the implications for the perception of Drupal at large, you know? What does this mean about what's Drupal's role in all of this because it is changing and the changes that I just talked about are huge they're not trivial and That's sort of discussion sort of fallen by the wayside it gets a little, you know sweep swept on the rug like oh Yeah, you know like well, that's just something we just have to accept when we go down this route Well, I don't think all parties involved have really considered what going down this route means I think we've talked a great length about the technological benefits But you know how this changes Drupal's positioning to clients to users to site builders It's tremendous and it's something that I would like to talk about today And all this comes down to the fact that Drupal's theme system within Drupal itself is privileged, right? Drupal's theme system has access to things that the services layer right now in Drupal does not or at least does not easily have So why in the world do we even do this thing? You know after we talked about like the pluses and the minuses Why would one want to do this and there are compelling reasons for what would one want to do this? I asked this before and I was gonna how many people in here identify as front-end developers No, it's not about half. Okay, great The truth is front-end moves fast. It moves really fast. It moves way faster than Drupal Drupal contrived and especially Drupal core front-end You know Drupal is always chasing the innovations in front-end and I've said this in two talks already and This is something that I feel very strongly that Drupal is not a front-end trend center It is definitely a follower and sometimes a fast follower, but it's never a trend center And we're always more or less at the agenda of other forces when it comes to integrating things into the Drupal front-end Separating a front-end layer from Drupal allows it to move independently of Drupal itself And so the dependencies upon Drupal and Drupal's the Drupal pace car. Let's say, you know, we can you know Take the fast lane and move around it It'll allow front-end to move at innovation speed and like Drupal and the content model Which hopefully aren't changing as fast as your front-end technologies Move at its own pace your content model your site when you build it. It has its own speed as well The Drupal core moves at its own speed Drupal contribute moves its own speed your sites Data model has its own pace which it might be faster or slower than Drupal and your front-end You know your front-end technologies that the things that you want to leverage from a technology perspective they have their own pace as well and It's sort of I think it's been described as the Goldilocks solution I think by the four kitchens guys that everybody gets to use the tools that they like and move at the speed that they Like front-end developers aren't hand shackled to the limitations of Drupal's markup or its speed or its ability to innovate Your content creators your content modelers and your information architects get to use the same Drupal goodies that they've known Since forever and are familiar with and your your developers who develop in Drupal get to keep the Drupal parts that they like And this all goes back at least for me to the reset the lesson of the responsive web Which is we can't predict the next big change at least on the front-end You know the responsive web came and completely shook web development to its core Ethan Markoats seminal article on responsive web the one with the the black and white images on a list apart if you guys remember seeing that came out a couple months after Drupal 7 went official 1.0 and It was not a thing until then and Drupal 7 was shipped Basically in ignorance of this trend that suddenly came blew up the front-end development space and changed our work as front-enders forever essentially for the last four years and What are we doing in Drupal 8 to anticipate or accommodate the next earth-shattering change that comes in front of us As an aside, I want to point out that Drupal has two heads Drupal is actually a two-headed beast.  That's also a head Right now. I've really only talked about cutting off one of them But we'll also talk about cutting off the other one So let me give you a couple examples of sites that I'm talking about who are at least in some way headless And maybe not headless in the way you're thinking but are truly headless When you when you think about the larger taxonomy of what it means to be headless a Drupal site For example feeding mobile apps right now. This is a headless site. There's there's content that's being pushed to a device that has no It doesn't care what the what the endpoint is that it's pulling data from on your mobile device. This is a headless Drupal site This is common sense media. I used to work for them. They have Common sense media or they have native mobile apps that are pulling data directly from the Drupal website and spitting it out Under the common sense media app. They're feeding data to set top boxes They have API's that they're monetizing. This is in many ways headless Drupal, right? You know the Comcast box that's pulling data out of this Drupal website. It's a headless Drupal instance There's an unnamed client a Drupal content is Drupal is being used for content modeling for narrative data It's plugging into this massive online retail system that's fronted by Angular So this yellow box imagine is its ERP system its blue box is Drupal and this green box is you know Whatever system that Drupal is also referencing and all of this is being combined and matched together and shoved into this one web App at the top which is powered by Angular Which is pulling its data from multiple sources. So in this case, it's not even headless Drupal It's Angular wrapping a constellation of systems underneath it of which Drupal is only a small part Headless Drupal can also be Let's say if you have a Drupal site that is pushing content to other Drupal endpoints that have a public face But this original silo does not so for example, you have an authoring environment. That's pushing content to multiple endpoints This is in a way headless Drupal as well And then sort of the holy grail at least from a front-end developer is that you have a Drupal site That is completely separated where you have swappable front-end teams Techniques and systems and you have this Drupal base. That's consistent. So let's say, you know You have a Drupal base of a large site you want to build the front-end of ember one day You're gonna have you're gonna have another team build it out of Angular. You have another team that's building it out of I don't know React or whatever. I shouldn't be naming all JavaScript, but the same idea that you can Build sites with a consistent Drupal back-end, but let the front-end be whatever you want You know as needed and the last thing And I don't have this is not very well thought out, but but this is I know it's kind of a thing You know there's this talk about the internet of things and it comes back to this notion of being prepared for the next big thing and being Moving beyond this idea that Drupal has to own everything end-to-end and predict everything and that we have to keep bending Drupal The internet of things shmin and of things I'm 34 years old and I'm already seen enough of the internet where I'm like Internet of things whatever, you know let the kids have it, right? I don't even have kids yet But I think the the the the propositions offered there are valid You know like Drupal content on non web devices. Jesus talked about this I think everybody here at least has one non web device that might have a browser that you know You know Drupal reading in my Kindle. Okay. What who really wants to do that? You know, I think being dismissive of new technology before it really emerges is a fool's errand And I think that if we were going to dismiss things like the internet of things out of hand before They really have a chance to explode we're gonna look like idiots in the end if we don't you know bet correctly And I don't feel like like betting against it is a good deal. So and this is where I get kind of out of there What if I I'm gonna preface this by Larry Garfield the guy in the vest in the middle Came up he said yesterday that Drupal's admin UI doesn't really have API so much as it has buttons with DB calls mapped to them And this goes like today idea that Drupal's theme system and Drupal's admin are privileged privileged systems within Drupal itself Like they have access to APIs that no other system in Drupal do and so the idea of making a Completely decoupled but for you know equivalent front-end is difficult is because we have an architecture like this right now But what if all Drupal front-ends were decoupled service-based apps including the ones that ship with core What you know, what if the admin if seven theme were actually seven dot app and it was say a backbone app Or you can swap it out with an ember app or you can swap it out with whatever the hell kind of app you want You know it versus the twig theme system, you know, what if we could do that? What if Drupal was built like that from the get-go such that these systems could be equivalents to what come with core And that that's a bit of my challenge Okay, what the pantheon sign? Oh, it's because I work for Acria. That's why Oh And so that's my challenge, you know And I've had conversations with people like what if this could be possible What if this is the way Drupal was built or at least a very viable option? What if this wasn't something that didn't take a tremendous amount of work like it does now and Wasn't full of compromise, you know What if we everything including Drupal's native front end started on the same foot as everything else?  I don't have like a punishing or a drive-home message, but Drupal has for its existence tried to be all things to everybody It's an all-in-one soup-to-nuts Drupal shaped hammer Everything can be solved in Drupal Drupal wants to solve your complete web problem from the moment You want to enter content to the last bit of CSS that you render you build the app Oh, yeah, sorry that took a second you bend the app to Drupal You build the use case around Drupal and you live and die by the entire stack until now Everything from your hello, there we go presentation Content data model all three layers are done in Drupal and are expected to be handled by Drupal But what if Drupal is just another layer in your stack and didn't have to own all of it And you could swap out any piece freely at any time for any other technology that you wanted and so my argument at least is by decoupling the front end we make Drupal as a system more flexible more useful more relevant to developers in the world than less and There's this analogy that Josh Koenig used and I really love it there's a big Venn diagram of Drupal developers and this other circle is Skilled front-end developers and the intersection of the two is so narrow as to be almost a line or maybe a dot and that there's a Universal development and work that's going on that's kind of outside the purview of Drupal And we're not leveraging it whatsoever And if we could bring those two circles more closely into alignment even by a fraction we would introduce so much more Fresh blood ideas vitality and developers into the into our ecosystem than we have right now and Mr. Spock agrees with me so So so these resources have changed a little bit There's a headless Drupal working group Which is kind of like a bazaar of people throwing out their ideas and there's not really any focus and actually part of the Reason I pitched this conversation is to bring a little more focus through the discussion So that we have something to work something towards I know Amitai is giving a talk later today about his work with Drupal 7 and And and headless and his interpretations of how headless should go. I would highly recommend going to that too He likes to talk as much as I do which is great And I'm David I'm eating on Twitter feel free to berate me on the Internet's and I want to have a conversation here These are all the slides I have but I was told by Stephanie that I must have this slide on here So you can cast that judgments upon me and and and rain and rain them down like blood from the sky But I don't clap but clapping when it's over. I would love to hear people's thoughts on this at the microphone And if I know it's gonna be difficult But if we could try doing go into the mic and if not if that's not gonna happen, I'll just repeat it All right, stripe shirt Okay shot. Let's shop. Yeah What we need is like a really a boom mic, right? You know and like with a big fuzzy You know like a TV show I'll just repeat your question. Sure Right, right How do we sit versus other CMS's that have similar systems? I'm glad you asked Wordpress has some stuff going on that's very interesting Wordpress has oh you can't see is haha. This is on my screen. Okay. Here we go Hey, everybody WordPress has something called client dot j dash j s which is a reference backbone app Wrapping the WordPress JSON API. So this is a reference app that they've built For other developers to to copy and to look at I Know I think it's is a type of three. It's one of the major European CMS is is working towards fundamentally transitioning their architecture such that their admin experience is a services-based Architecture and so is it type of three? Okay, I mean it's not shipped yet, but it's something that they're actively there's an initiative there to bring that to light And so at least where there's simply there's WordPress. There's type of three There's others there granted all of this is very much the cutting edge, right? Like I'm not selling the alarm after the house is burned down like there's an ember But you know that the fire has not consumed us all yet But what I would like to do is At least get in front of this problem and not wait until Drupal 9 to seriously have this conversation You know like during you know Drupal 8 has introduced all this great change in decoupling systems that we previously thought were monolithic And we've broken things apart architecturally at least on the back end And I mean the very very back end not like the seven theme But like the systems underlying it that allow for much more plugability and Decomposition is that the right word? Yeah, a deep decomposition of components underneath Drupal that allow at least in theory swapability where there was none before And I would like to see a similar level of effort expended for the front end such that we can do similar things there I'll come back to you Your thoughts around So the the the question asked was a client wants to refresh their D7 site where the content model is Satisfactory to them, but they want to have a front-end refresh that may be more than just CSS How would headless, you know, how would headless you could use case for this Right, right. No, and that's one that that's a good point. There is no clear and Obvious and or recommended way to do this right now. Everybody implements it from scratch. Go ahead Yeah So the for the people on the TV who watches next week. It's a solstice project on GitHub an angular wrapper for solar as an intermediary of Drupal sites Did you want Larry's actually going to step up to the mic. Wow following the rules That's why I took a seat on the aisle here. So I could do that job. Good job so one of the challenges to what you're describing is an awful lot of Drupal's power and flexibility comes from that tight coupling and the fact that you know you have Render arrays that are modified by a configuration that is embedded within a piece of content that controls the display That's how you get panelizer. That's how you can't even do that kind of thing if you have You know a fully decoupled front-end and back-end You lose a ton of that flexibility because everything is a lot more coarse-grained And if you made it as fine-grained it is now then you haven't actually decoupled anything, right, right, so I'm not going to say we shouldn't do it for that reason I'm actually going to say we desperately need to do it But how do we make the argument that it's okay to lose? Per elements cache capabilities like we have now with render caching in the name of this kind of decoupling How do we make that case that certain things will break and not be possible if we don't privilege one theme system over another? How do we make that? argument I think and this may not solve the problem, but the way I'd envision it always is that there would be I I Don't want to open up the universe for any and all possible front-ends But I think an acceptable compromise that would get us a lot more forward that would move us a lot more forward is to have a Reference angular implementation that maybe is tightly coupled to Drupal a reference backbone implementation That may be tightly coupled to Drupal that Drupal is making assumptions about this front-end to a certain degree That would allow that kind of privileged Coupling and then that you know we can at least build an angular map It may not be any anger app, but it might be you know, we might be able to For lack of a better descriptor, you know something like sub theme this this angular app to build Angular apps off of it won't be a blank slate one But it would make certain assumptions about Drupal and Drupal will make certain assumptions about it and that we would have Instead of just being tightly coupled to twig and the rendering rays and and the Drupal theme system We would have at least multiple options at that point So if I could continue on that, yeah So you're not as much saying don't have a privileged front-end as have multiple privileged front-ends I guess I would say I guess I think it's multiple privileged front-ends is better than just one and or a highly deprivileged one And I get what you're saying. I don't think it's actually feasible Because you know the power of having everything in memory together in PHP is where that coupling and power comes from There's just things that you know, there's a depth that an angular app will never get And there's a depth that a front-end built with Silux or symphony that's talking to Drupal over rest behind the scenes and still serving pages is never going to get that Unless it has render arrays by doing through it now. I'd love to get rid of those all those render arrays I'm actually asking you please help me make this argument To fully break these things apart, but how do we make that argument that there's some level of? Easy flexibility that we lose when we break things apart and simplify them that way. I don't know the answer I so I am throwing that out So while we marinate on these questions out anyone else please jump in please anybody who it's okay glasses Please step to the mic. Sorry. I don't know what it's a say man. Fair enough. Yeah So yeah, I mean I don't have the answer either, but I think that it might Make sense to like talk about specific Drupal versions now that we have the beta out and everything, right? I mean and think of it as separate problems. I mean, yes, yes, we want to solve that particular issue in Drupal 7 No, I also think that it might make sense to to talk about these issues like making You know as you said you don't you don't have access to form API and you don't have Access to the output from the field for matters and so on so maybe think about these problems separately and try to solve Each of these cases separately and as as you know as as much as you as you can and achieve as much as you can But break them into separate problems instead of thinking it thinking of it as you know one big giant sure issue I'm big on open data and governance so wouldn't it be interesting for Drupal to be like the headliner for every single government to Publish their data as an JSON format together with their sites in Corporation and that way just push Drupal to to more and more government sites try to promote it and Actually fill in the giant giant gap We have right now because a lot of governments just don't go for big data because it's a lot of stuff stuff to actually deal with right now They have to actually redo most of their stuff because they can't just do it with the platforms they're using and If we can then in one way or another propose like yes, which the Drupal and It's basically with a click of a button and you just publish JSON data next to your current Like your current front end without changing anything would not be an interesting idea to actually promote and work with Yeah depends on the government Yeah, obviously you have the thing is that's our North Korea. We love that Yeah, but like Belgium is pretty big on it right now. They're trying to promote open data But there's not a lot of government well internal government doing it because they're actually The biggest issue is they have the current sites are using do not support Open data in one way or another and the thing is no Drupal 8 support for services is much better than 7s out of the box Right, and then this is almost like a talking point at this point about Drupal 8 Look, oh, you get the rest module and it's actually kind of nice to have it built in The question isn't that the rest is rest going to be strong enough in D8 It's what are we getting out of rest and how can we make that more robust for the needs of a fully baked app like this? You know like we can get data out of Drupal just fine now The question about governance like that is just it's governance of the government You know it's getting clients on board with hey Let's expose some of this data because Drupal can't do it and fairly trivially to it that At this point we want to make it more robust such that we can build better apps around it than just simply querying No data let's say All right, who wants to step up Okay, I'll repeat your question. That's fine. So oh That's hard to summarize So I think if I if I'm hearing you correctly you to take a page from the the single-page app model where you know You're lots and lots of JavaScript calls as needed pulling in data, you know just in time and then rendering it as needed. Yes Sort of okay We got a fixes mic situation. Yeah, did you ever reply Larry? conversation I guess the implication of that then I think that goes back to what David was talking about before that means No panels no panelizer no display suites no field for matters You have re-implemented all of that in your angler app. It's anyone actually want to do that. I'm not volunteering but how do we You know, how do we have that capability without having that, you know, you're configuring the formatter as part of the So Like if you if you manage to share the data that you clicked In in NFD's modules like this place you'd you can you could use it in in the JavaScript app to Render whatever you need and that way like you wouldn't take everything away You just a half of it or some part of it So and do it again. Yes.  Yes One of the so one of the things that that Jesse Beach and Carl read a minute talked about And I feel like I'm sort of channeling and speaking for them as well because they couldn't be here We talked about this in Austin is has anybody seen Carl read one's talk about Writing a new render pipeline Sorry, you're like that. So normally it's Morton that's trolling me during my talks and so you're taking Morton's place Okay, there we go. So Carl read a man had proposed this new object-oriented render pipeline, which was like, okay Yeah, yeah, yeah, and then in the end He was able to address by fragment and tired rendered sections of pages of nodes By URL and so, you know, give me this URL of this region this block down to this field rendered in JSON and When both Jesse and I saw this not to speak too much for them. It was just kind of Eye-opening like wow, why can't we have that all the time like we're getting kind of the best of both worlds We're getting Drupal rendered Objects in JSON addressable by URL that we can predictably call again and again and again And these can be fragments of an entire rendered page. And so, you know Drupal is Informing it. So the fundamental problem that we're talking about here that Larry's bringing up is that there's no way in the current services Bake architecture that you can build a Drupal site Easily or it without tremendous pain that allows the author to both express content and Intent for that content. And so if the author has an idea of like this needs to be a sidebar and this needs to be, you know Rendered as a blah blah blah on this different side There isn't a reliable way to do this right now via our services API because you're just going to bring back a node, you know unrendered via Via our JSON API and then you're going to have to decide what to do with it once you get to the angular side And angular might not know anything about, you know, how Drupal might render it, you know via plugins or via Via panels or, you know, what have you and so that that's part of the way there and I Feel like this this sort of space here what we're trying to get Drupal to Be all things to all people but in a different way than it has been before Is this weird place where Jeff Eaton gets on board and people like Jesse get on board and people like myself get on board Where the content strategists are trying to build a more context context and device less Sensitive Drupal Drupal that that's more universal that isn't built for just desktops or just built for html or just built for Responsive websites, you know the Jeff Eaton's of the world and then there's like the front-end engineers of the world who want to use tools like Ember and Angular and react and you know, whatever the hell new framework comes out tomorrow Because it's better tooling. It's more fun to do and it's a damn site better than Drupal's theme layer And then there's the third which I guess I sort of fall into where I Don't want Drupal to to stay The current Drupal model is getting a little long in the tooth and it's hard to defend against other Products that might do certain things better Drupal as a whole might do all of it better But that we ignore certain innovations in areas front-end or otherwise is at our own peril because that's where talent and interest and attention are Going and we want to be able to capture at least some of that or at least be relevant in those conversations Because if we don't then it's just me like oh Drupal That's a site to use to make your complex website not much else. Oh Yeah What right no, that's absolutely possible So there are people who are building angular components into their Drupal website So Drupal's rendering a page and then as one of your panel blocks or panel panes is an angular widget of some kind You know like this this is the if you look at Austin of Yeah, the Sally Sally young did a talk about I think it was NBS MEC and they're using that technique Angular embedded within Drupal as a portion if not the majority of a display There's also people, you know like common sense media like I gave before where they have a headed website Regular plain old Drupal like you would make right and then a separate stack that mirrors that from a data level But is just an API endpoint and all their API stuff based off where there be iPhone apps You know Comcast set top boxes, whatever I'll talk to that So there's that as well. I mean that that's what people are doing currently the goal is for these D8 or D8 point X or whatever to Not have to jump through hurdles to not have to write all this service of stuff to not have to sacrifice as much as we're sacrificing as I described so that These alternative front-ends can be if not first-class citizens at least not sitting You know essentially in the bathroom in the tail where they are right now Stripe shirt again Mike doesn't like Talking about JavaScript libraries and frameworks that might sit on top specifically for a minute and forgetting the other options that could be the head In your experience and From feedback you've received so far case studies you've heard Do you think there are any libraries that are better fit than others for whatever reason be it community? Technically whatever for this kind of implementation with Drupal or is it literally just it's a free-for-all. I think it's a free-for-all I think you asked three different front-end developers to get three different answers. I think the technologies are so new and the Changes the differences between them are so opinionated that it really is just almost religious now at this point You know like is Android or iPhone better, right? Let's not answer it from the core doctor of sense, but like from a you know usability sense, you know is your Android iPhone better, you know You ask three different developers, they'll tell you three different things So the question is if So the question is will the complexity of allowing multiple client heads to a triple site in the future lead to overwhelming or Increasing workload and or complexity of projects. I actually think it I Think in the long run it actually reduced complexity in that you can just we can that Drupal site that you're building a head on top of May last six years seven years doesn't change right or changes slightly right and you can swap out that front end as You want you can swap out the vendor that provides that front-end as you want if you have a vendor that specializes in a particular JavaScript skill set but knows nothing about Drupal they can still write a robust app on top of your Drupal site Right and somebody comes in as long as your as long as your your API is well documented I mean people have been writing web apps on top of robust API's for you know decades now Sure, right. Well, that's true, and I'm not saying we should get rid of the HTML front end Anyway, I'm not I'm not saying cut off Drupal's existing head You know, I'm ultimately saying you know give the option of either popping that one off and like a Lego man Put the one with the red face on versus the yellow face or alternatively have multiple heads You know in an array on top of your shoulders Each with different colors There's nothing that will put nothing I proposing is saying let's lose Drupal's current ability that's published straight to HTML I'm never going to propose that. I'm not saying Drupal should only be a back-end architecture Never that's never a goal. Well, I don't think that's necessarily true. I think Having more options when it comes to publishing given the proliferation of the context that our content is expected to be on is Only a good thing like limiting ourselves the HTML. I think is a fond It's fondly looking at our shoulder into a past when web development was more simple I think we should embrace complexity. We should embrace innovation and not Pretend like it's not going to catch up to us So I've heard a lot of talk about these swapping out of front-end and front-end Systems being highly opinionated. How do you? Do you see these front-end systems being contributed back? How do you see this is? impacting Contribution are they going to be so opinionated and so specific to the content model as to be unable to be contributed back to the community? Wow, that's a hard question In this perfect world that I've envisioned right that isn't really fully visioned. It's more like a remembered dream than anything else We would have Reference apps like it let you know for each of Several front-ends and that these apps would be general enough that you know like like the way how base themes are I mean base themes are really opinionated, you know Omega 3 versus Zen versus, you know Versus Aurora versus what's another opinion a one? Adaptive theme your mother ship right, you know all of these have strong opinions and people in Drupal have managed to get along with Those just fine, right, you know, they might have arguments in the hallways or say, you know Your system sucks, whatever but sites get stood up all the same. I don't see that Model changing for something as you know swapping out a front-end whether it be, you know, this JavaScript framework or another Front-enders are by nature. I think very opinionated or at least the opinionated ones end up speaking and that Propagates more opinions, you know, and so Yeah, please Just wanted to make a note about the the content writers so it's really important to to realize that when we go decoupled that the The the administration experience in the content model is far different. So it's not page centric It's it's much more agnostic to the endpoint. So the difficulty in that is The way in which content is written and stored Doesn't really allow for preview and also requires a different Thought process as to how to create that content So that's something that's really important. So I think For this to work first of all it needs a particular type of organization and a certain level of complexity Overall that I don't think this is a hobbyist. Oh, no, no right by no means, right? This is yeah is more of a larger structured organization direction and Also, the content model will likely still have to have some sort of a page centric option for cases where you were Explaining that you know the author wants to have that right sorry bar. They want to have that that sent So it's probably the the solution is some sort of a blended approach to structure content. That's completely decoupled from the endpoint and page centric Content modeling and you know how that gets divided on that point what I'd say is Those editors are going to be incapable of previewing the content to all of the endpoints that it flows period So what has to be important is to identify where their concerns lie Does that person really care about the mobile experience for their users? Or is it just that they really care when they're compositing the days editorial for the splash page on the home page of the site? And and so it's it's with anything it's about identifying where the concerns lie from the stakeholders point of view But I think what's being proposed is why I'm trying to think about how to deal with the fact that we are in a multi-tenanted multi-device world and Support the fact that that's going to keep growing faster than our editor's concerns will Yeah, so maybe this ties in a little bit with that contextual thing But I was just going to say I mean just thinking about the menu system alone and the idea of having a pre-expanded section and The idea of then maybe being able to drill open up other sections and go in and that's been sold You know three four different ways just in Drupal on board and then you know It's going to be approached a million different ways from all the other You know our frameworks and so but all the user ones at the end is just that little pancake button and just to click on something But you know it's sort of so over diversified Do we really exhaust all the no we can't Just because they're clapping doesn't mean we're done Yeah, but go ahead Back in the days when we built our own CRMs, you know, I did a lot of fiddling with trying to headless stuff one of the big challenges is forms, you know, you mentioned forms API and Has there actually been any practical thought about how we would manage the input and output of forms? Through this kind of thing right so what I mean that you know what I keep talking about having a reference implementation Is that there is no reference implementation? There is no best practice, you know in fact There might only be worse practices out there, you know Who knows because there isn't actually that much sharing going on either and I'm encouraged to see as many people as there are in this room today But certainly anybody who's doing this sort of thing right now seems to be doing it mostly in isolation Except for a couple people who are very verbose on the g.o. Group and are sharing everything like code and everything Um, and I actually would wish they share less because they tend to dominate the channel But there is no collaboration around this yet It's really really new. I mean it is really new and there is no structure. There is no initiative. There is no working community even around this and I Mean, I would at least consider it a minor minor minor victory If walking out of this Drupal con there was at least a more cohesive community of discussion around this topic because There are obviously a lot of conversations to be had left, you know beyond this 45 minute one And there are people who need to hear it beyond just, you know Larry Garfield that who's who Need to see the the importance of this use case, you know in a more broad sense And then on Larry's side the kind of how far have we made any kind of progress for Drupal 8 on The removing of the button that is the you know the admin functionality being a button on the form rather than being an API call It's a slow and ongoing battle Progress is being made Like the big one is The entity API actually exists independently of the node form now, which is the first time in Drupal history That's been the case. So that's a huge win But it is an uphill battle because we're used to It's easy if I just do it all as one thing That doesn't make it simple that makes it easy for me to write right now But it means all I can do is that one use case and then that cuts off all of these other potential heads So, you know, I've been fighting that fight at a different architectural level for a long time And it is a hard battle and that's why I'm asking, you know, how do we make that case? You know something else that occurs to me who here's a module developer Who's module developers in the room? So I'm gonna call it to you the same thing I've been saying in a lot of my dev talks Push everything you can to your twig files in Drupal 8 Because this is wonderful little tool called twig.js that compiles twig templates the same twig templates you have in Drupal to JavaScript based templates instead of PHP based templates So you can override Templates on the client side using JavaScript instead of on the server-sizing PHP It's a little more work than I'm just hand-waving, but There are tools like that if we can push things to the right place that let us pick and choose selectively and I think that's My best guess is, you know, we need to be able to break things at a place where this piece we can then do selectively so it's not as much rip out the head as You know start picking out hairs like push all display logic to twig templates because then they can always be overwritten and Reimplemented client-side in JavaScript The the initial goal of the whiskey initiative and of the scotch initiative was to have all blocks as their own Things which means something like Facebook's big pipe where? You know you load at the skeleton and then you parallel request 20 blocks Which come back at strings and you assemble them into the page becomes really easy to do that that's the kind of stuff we've been trying to build and The biggest challenge has been fighting against the architecture That is already there that makes that really really really hard and fighting against the people who are still trying to leverage that architecture So that's that's the challenge we have is You know making a different set of trade-offs to make this kind of stuff possible and Just making the case for making a different set of trade-offs is hard even before you start coding it No, I agree I don't expect this to be like an easy sell to to the larger Drupal community, but Somebody's got to carry the torch. And so, you know, I'm here I'm up before before everybody leaves for lunch and because I'm really hungry too And I'm going to start getting cranky and saying opinionated things if I don't eat soon There is a buff a headless buff at one o'clock in g room g 110 It's right after lunch. So everybody should be you know sleepy and satisfied and we'll have much more moderate opinions. Yes When is it? Yeah, oh, you'll you'll bring it at the buff. Okay, so if you come to the buff, you will show a scaffold application He's building a marionette for writing web apps.  Otherwise, thanks everybody for coming. Enjoy your lunch