What is software architecture? Well, software architecture is all about how a software system is constructed at the highest level. We need to think big from multiple perspectives with quality in mind, designed right. Development teams will decide how a software system will be broken down into components that work together. The first module of this course will teach you how developers use UML to document their architectural designs. You'll see how architecture can be understood from multiple perspectives through different UML diagrams. In the second module, you'll learn about different software architectures, when and how they're used, their advantages and disadvantages, and how they're represented visually. Finally, the third module we'll get to how architectures are analyzed and evaluated. Software architecture is tied to many practical concerns. These include the structure of development team, the needs of the business, development cycle, and the intent of the software itself. In your capstone project, you'll be dealing with a system as a layered structure. You'll use your newfound knowledge to document and explain this architecture. First though, we'll teach you how to represent, understand sotware architectures using UML. Let's begin. Software architecture is the fundamental design of the entire software system. It defines what elements are included in the system, what function each element has, and how each element relates to one another. In short, it is the big picture or overall structure of the whole system, how everything works together. Let's compare this to designing a skyscraper. The architect of the building will design the overall structure. The architect will take many factors into consideration. For example, what will the building be used for? Who will be using the building? What qualities matter most to the occupants? What constraints do the site pose? Taking in factors like these, the architect will create a plan for the building to suit the needs of the occupants. This is similar to designing a software system. To form its architecture, the software architect will take many factors into consideration. What will the system be used for? Who will be using the system? What qualities matter most to them? Where will the system run? The architect will plan the structure of the system to meet needs like these. So, why do we need software architecture? Let's look back to our skyscraper example. What would happen if there was no clear design for the building? Each work team would construct their own section and they would each have different views on what is needed. What if one team decides that accessibility is the most important factor to consider, while another team decides that security is the most important factor? The two ideas do not work together and overall, it may not suit the needs of the users. You get conflicts, you get duplication, havoc ensues. That's why having proper software architecture is important especially for a large software system. Having a clear design of the overall system as a starting point helps to provide a solid basis for developers to follow. Each developer will then know what needs to be implemented and how things relate to meet the desired needs efficiently. Software architecture provides many advantages. One advantage is higher productivity for your software team. Software development becomes more effective because there is a defined structure in place for coordinating work, implementing individual features, or grounding discussions on potential issues. With a clear architecture, it is easier to know where key responsibilities of the system reside and where to make changes to address new requirements or fix failures. Additionally, a clear architecture will help to achieve quality in your software. With a well-designed structure using principles like separation of concerns, the system becomes easier to maintain, reuse and adapt. Stakeholders are the people who have an interest in the software system at hand. They are people who will either be using the system that you're creating or benefiting from it in some way. Who are the stakeholders when it comes to software architecture? In other words, who would care about the software architecture? The software architecture is very important to people such as the software developers, the project managers, clients and end users. Each will have their own perspective. Let's start with the software developers. Like I previously mentioned, software architecture provides many advantages that help the developers to create and evolve software. It makes development easier by providing a strong direction and organization on what needs to be done. Additionally, project managers value software architecture as it gives useful information to identify possible risks and manage the project successfully. A well-defined architecture will help project managers to understand tasks dependencies, impacts of change and coordinate work assignments. The clients make the big decisions about the system like it's funding. A clear software architecture will help to communicate coherently and confidently that you know what you're doing. Now, what about the end users of the software? Is software architecture really important to them? Users may not directly care about how the software actually works, but they will care that it works well for them. This is similar to a family who just bought a house. The family may not find the specific architecture of their house to be important, but they do care that the house won't collapse on itself and that it fits their needs as a place to live. Software architecture is effectively expressed and communicated through models and diagrams. One important way that software architecture is presented is through UML diagrams. You will see several UML diagrams to represent the different perspectives to be considered in software architecture. Architecture is the process of creating system level and broad guardrails and guidelines for engineers to work within in order to produce a stable, maintainable, long-lasting system. The architecture of a system is going to vary depending on what particular architectural model or style you have in mind. There's many different architectural styles so each one of those styles is a particular way to describe the architecture that fits in that style. I would say that most of the systems that we build are what I would call a service perspective architecture, where a system is viewed as a collection of interacting services that, by their collaboration, achieve the goal that you want in terms of what the application does. But there's other architectures. Those architectures that are based on data flow, where you take something and you process it through a series of stages and you don't describe those so much as services. You say that the data gets transformed and then it's processed through another transformer. So the architectural style dictates how you describe your architecture. Fundamentally though, all architecture involves doing something, because the whole point of an application is to actually do something. So you can ultimately step back and say, what does my application do? And identify the boxes which are things being done, and the lines which are the interactions between the way things are done. The collaborations or the way that information flows or the dependencies. At the very high level, architectures described by boxes and lines. But really, it's made precise by saying, well, we're going to adopt a particular architecture style. And then there's conventions within that style for how you describe your architecture. I think the architect has to keep a lot of perspectives in their head. And I think one of the key skills of an architect is being able to operate at any number of levels of abstraction. And so, if I think about, you have to be able to communicate the code quality requirements at a very deep level in terms of nonfunctional things, like code coverage and unit tests and things like this, all the way up to worrying about the very, very coarse-grained inter-system interactions in potentially a large company. So we, for example would have, architects get together to talk about how entire groups of systems are interacting together, and those have different kinds of design artifacts and different kinds of meetings and conversations that lead into that. I know architects who, strange as that may sound, they rarely deal with actual code or detailed technical implementation. They're more about the people, right? It's about bringing together the right other architects for the right product people, or the right engineers, or the right managers, or whatever in order to drive decisions and actually make change. Because if you boil it all down, that's what the architect is there for. They're there to help being an agent of change. As a software architect, you pretty much have to keep everybody's perspective in mind. You have to think about the perspective of your customer and what they want about your business and what it needs, about the engineering teams and how they expect to be able to work and what they need in order to be able to do a good job. Additionally, you have to then keep the perspective of this. You have to play the long game. You've got to think about the quality and the non-functional attributes of the system, so that those don't get forgotten and so be optimized in the short term. The main thing that you have to keep in mind as an architect is always the question, am I doing something that's adding value to my client? Because if you're not adding value to your client, then you're not living up to one of your responsibilities which is to deliver them a product within their resources. Now, what does adding value mean? In many cases, it's actual tangible things like functionality. It can also be what we call the so-called nonfunctional requirements such as ensuring that the product is going to be built well enough that, over the next decade as they continue to use it and add new requirements, that it'll be easy to add those requirements. That's what an architect has to do. They have to say, okay, from the client standpoint, do I have a understanding of my problem? And does the application that's being built actually match what my understanding of the problem is so that I can solve my problem? From a developer standpoint, you have to ask, can the developers actually build this thing? There's no way that you can be a good architect without understanding the limitations of construction. That's true in the real world of buildings, too. You can't design something that's impossible to build. Monetary cost and delivery time are always issues from an architect standpoint because they will make decisions that can impact one of those two or both at the same time. And then, there's an aesthetic perspective, which I call aesthetic because it's hard to identify the rules. But the architects got this other view of the long duration of their artifact. We know that when you build software, it's going to change. And it's important to build in change from the very beginning. Just like it's important to build in testability from the very beginning. Now you don't want to over invest in change. That's a trade-off that you have to worry about. How much do I invest in being able to support change that may or may not occur? But you do have to keep it in mind. And good architects have a sense for when their design is simple enough to survive many changes over time or flexible enough to survive many changes over time. Those are hard terms to define. It's one of those things you know it when you encounter it in a good system, and you know it when it's not there in the system. But it's very hard to write down rules, although there's been lots of work on identifying. There's lots of good rules that are out there. One of the challenges you face as a software architect is keeping some sort of rain on technology enthusiasm. There's always some new way of doing something. There's always some new language. There's always some new product being pushed by a vendor that will supposedly make it easier to do acts. You have to keep that in check because as an architect, you're thinking, well, my system going to be around for a long time. Fancy new language A, that's just come out, may not exist 10 years from now. Do I want to invest that much effort into that part of my project in taking my development team and training them in a new language with the high risk that that language might not exist anymore? The ability to manage that technological risk is the biggest challenge as a software architect. If you are going to adopt certain technologies, then as an architect you need to keep in mind potential requirements to replace those. If I'm using service A, that I'm talked to using some sort of standardized protocol now, what happens five years from now when that protocol is no longer supported? Have I built my system so that it's basically insulated from those kind of changes? And a classic example is databases. If you assume that your database is going to be a relational database, then you'll be able to survive your database vendor going bankrupt because you can actually get your database from someone else, provided you don't use any weird esoteric leading edge features that were in the first vendor but not in any other database. I've heard many people ask about the intersection of agile and architecture. And I think there's a tendency to see architecture as this ivory tower, I will hand something down to you from on high, and you will implement it. And the reality is, agile doesn't mean you don't have a plan. Agile doesn't mean that you're just running around with your head cut-off. It means that you're still thinking things through in architecture. You just do it in smaller cycles. You do your architecture just as needed instead of this large design upfront. That's the intent. Architecture has a key place in agile development. The thing that most people forget about the Agile Manifesto authors is that all of them were extraordinarily experienced system builders. They already had in their mind many, many different architectural approaches to solving problems. So when someone like Beck goes into a new problem situation, he's not going in with complete ignorance of the world. He's going in and within a few sentences of talking to the client. He probably has a good idea of what kind of overall architectural model is going to work for this problem. Is it going to be a standard database centric web app? Is it going to be something that has more data-flow-like? Is it going to be something that's highly concurrent? Or is it going to be something that's serializable? These are all things that are easily visible to an experienced architect. Then, they know that, okay, if we adopt roughly the database centric view of this application, then the agile process will be great because we know that the database will be able to accommodate all the rapid changes that we're making, because we're smart about using the database. We know what schema updates, blah, blah, blah, blah, blah. We have all this technology that already is in our mind to support agile development. So I don't think you can do agile without also being an experienced architect.
