Hi. There's a reason that software engineering is modeled after other engineering pursuits. The idea that software engineering will take tried-and-true methods of providing engineering rigor is something that was absolutely thought about when it comes to software engineering. One of the tasks within the software engineering process, of course, is software architecture and that too has its name from something that's already tried-and-true. There's a couple of definitions here go ahead and read those. Effectively, we're looking at the software from a much higher-level than you might at building a class diagram and actually doing the coding. In addition to the actual software itself, we're going to be considering many other elements like the environment, like the hardware, like the personnel. Do we have enough people and tools and skills to actually make this project successful? Where does this project fit within the enterprise architecture? These are all elements that become more important when we think about architecture than about something else. Well, we care because good things are well architected. When you think about the internet, when you think about ATMs they're architected well, and they work well. It isn't necessarily true that good architecture forces success, but success is almost certainly dependent on having good architecture. What we want to avoid of course is the big mistakes. When doing analysis upfront in the architecture stage about where it fits within the overall environment you can avoid rather large mistakes that aren't really seeable. When you get into the trees you want to be able to see the forest and make those decisions. Projects still fail a lot and while it does differ based on the kind of process that you use, what we're looking at is still large levels of project failure. So while this is success you can see that the elements that are missing to get up 100% that's all failure. So there are a number of things that we focus on in architecture and yes there is some overlap with design. And many people will talk about architectural design and throw both software architecture and software design in one group. We don't do that. We treat them as separate endeavors entirely. Architectural concerns are again at that higher level. Things like performance. Elements of performance are often hampered by hardware, right. That is not a software design issue. It's not about how we build the classes it's something that sits outside in the enterprise idea. It's how we go about architecting the solution to make sure that it's going to be successful not just itself but in the environment that it's going to sit. Things like maintenance because we care about upkeep. We care about professional support teams, product support teams that we have to get. We care about security, testability, usability, all these high-level things that aren't really applicable to an individual class or the UML diagram you used to design the system. They're higher-level concerns. The reason I mentioned before that we follow the engineering process it's the same thing here with architects, with architectural style. Just like there are different styles in architecture in buildings we have co-opted that model exactly. There are architectural styles within software architecture just as much as there are different types of houses. Again, it's bigger than just the software. We're going to look at a number of elements that go into the software development process and ensuring success that are not related to the software itself in most cases. While we could apply an architectural style to the system that will be built that is not direct implementation. It doesn't constrain how the code is built within that style. It merely makes it fit into a larger set. So that in fact, it talks about how one piece of software interacts with another piece of software. So, the very high-level interactions between components of a larger system.