We're going to zoom in on the jobs of designing, or architecting, or research and planning, whatever you want to call them. First, we have this idea of designing parameters and processes. Sounds super-bureaucratic but there are two key focal points I would really look at here. So, on parameters, the headline parameter, which we discussed is uptime or availability. So, how often is the application available? As we discussed, is a function of MTBF and MTTR, cuz yourself if you remember those. What is important here is, how the team as a whole, so not just the Ops people but the Dev people, the product people, or whoever is taking responsibility for the asset in question, how they decide what they want this to be. In the Ben Treynor interview, he talks about exactly how they do this and it's really interesting. The product teams, because they're in charge of the customer experience, set the uptime budget that they want to have. So, it might be 99.99 percent of the time it's up, 100 percent is crazy and unnecessary. I mean, people just probably won't notice. So, they said this and then if the team, if there's an outage or they push new code and it breaks for a little while, then they've expended their budget and they just have to let the system run until they get back to their uptime budget. That's a pretty good way, there probably other ways. One thing you don't want to do is just oscillate between being completely terrified to do upgrades and being completely, I guess, cal person, a crazy, you're reckless about doing them. I have seen that happen and that's, of course, bad. It's important to be explicit about what performance you want is probably is important that the people that are in charge of customer experience, user experience, somehow decide that. Then, that the Dev and the Ops team have the right processes to make that happen. The most important thing is not to build a giant book of exactly how the processes should work, that gets ossified but to do this iteratively over cycles. So, many DevOps teams will work in iterations of say one to three weeks just like an agile product development team might work. So, the biggest thing about these processes is you're iterating on them and you have your outcomes you're trying to get and you're iterating on the processes and there is a sincere and constructive dialogue between Dev and Ops and whoever else is working on this overall experience to continue to make those processes make more sense and perform better. This team will generally be responsible for designing the system topology so that they may run some servers in their own data center or offices. They may use some third-party data centers. They might use these serverless services like AWS and Heroku and Google Cloud Engine and the Microsoft equivalent. So, there's that. This is tightly related to how they go and actually implement their topology for development and live environment. So, sometimes the Dev team will be in charge of these Dev environments. Sometimes an Ops team or a DevOps team will provide that for them so that they don't have to do it as much. But you want to make sure it is not happening here in this intersection is that there's overly prescriptive and Dev doesn't feel that they have the freedom to explore and do what they think makes sense for their particular area, product service, whatever they're working on. Then, finally, there's selecting tools. This is the job of Ops in the area of Ops. So, these are tools like, for instance, configuration management, is a set of tools that deal with taking an input file like a manifest or a declaration and automatically turning up a new server in the right configuration. These are tools like Puppet, Chef, Ansible, that automate and standardize this process. There is a cluster management. So, clusters are sets of computers or be they physical or logical. How do we make sure that we always have at least three geographically diverse instances of Application X so that it can fail over and have enough capacity, stuff like that? So, there's this cluster management job. Then, monitoring, of course, we have the job of monitoring and there are tools for that, things like Noggin, there's really quite a lot of tools for that. Another big category, for example, purposes is logging. So, all the systems are going to produce a lot of logs like I ran, I failed, I did this, I did that and those are important to have both for troubleshooting as well as for after the fact analysis on forensic analysis, looking at capacity planning and things like that are popular tools. This area are, Splunk is a big one, Logway is another one, there are many others, some teams do their own tools. So, those are the jobs of designing. These are things that are generally in the area of Ops that are the job of Ops.