- [Narrator] Okay, you can't leave an architecture course without getting a methodology, and here's ours. So let's step through it. So, you'll be able to find a stepwise path to a good architecture, and really think of them as checklists. I know we live in a world of Agile and DevOps and we want to iterate our way through it, this does not mean we're getting away from Agile and DevOps, it just means that we're going through a set of steps to understand kind of core components of our architecture to ensure that we do not get things wrong, at least wrong the first time. Your process, or steps, may be a bit different in what you see here.
In other words, feel free to take what we show you here and make any changes that are, adjust for your organization. For example, if you're an IOT based system builder, performance, and data acquisition layer and things like that need to be part of the process. If you're a specialized legal institution, where you're dealing with compliance stuff all the time, then that needs to be part of the process. You may have to think about certain things that are important to your business, perfectly fine. So, we define a four step process here, and we're going to take you through each one of these.
Number one, define your requirements. We'll talk about that in detail here. We're also talking about step two, defining your desired end state. Step three, mapping as is to to be. And step four, creating the final architecture. Let's talk about step one. So step one, define your requirements, it's basically understanding your business processes, your data, your security, your governance, performance, and cost. So core to understanding what your architecture needs to be and do, you need to understand the as is and to be business process state, where you're looking to go, where you came from, what are the current business processes, what's working well, and what's not working well.
You need to understand how that relates to your data, information that's bound to those business processes. Whether it's transactional information such as customer sales updates or whether it's analytic information such as gathering maintenance information from a factory floor, all of that needs to be understood in step one. Security, what are the requirements? Well those are changing, obviously people would like to have the very best security that they can afford, in many cases that's not practical, however we need to kind of find a trade-off between desired state of security, the amount of resources we're able to apply to it, and the real value of security for the particular problem they may be working with.
If people are dealing with information such as customer data, it's certainly not state secrets, and why they need to encrypt it and do identity access management, they don't need to spend a million dollars a month per database like the government does in some instances. Governance, the ability to manage, place policies around the use of various systems. Performance, how the system's going to perform over time, what are the expectations. And then probably the most importantly, cost. What is this going to cost us? How much money is this going to save us? What is the ROI going to be back from this particular exercise that we're doing with the architecture?
- Cloud architecture basics
- What problems need to be solved?
- The "as is" and "to be" states
- Cloud storage, CPUs, and databases
- Building your first architecture