‫Welcome to the first lecture.
‫In this lecture, we're going to get an introduction
‫to software architecture
‫and also learn why software architecture is so important.
‫After that we will define more formally
‫and explain what software architecture means for us
‫in the context of this course.
‫And finally, we'll discuss where software architecture fits
‫in the overall picture of the software development cycle.
‫So let's start with some analogies
‫from outside the software world
‫which will give us a good intuition
‫of what software architecture means to us.
‫Everything we build has a structure,
‫whether we know about it or not,
‫and whether we thought about it ahead of time
‫or arrived at it spontaneously.
‫The more we invest in building a product,
‫the harder it becomes to change its structure
‫after the fact.
‫But what is the importance of a structure,
‫and why would we want to change it at all in the future?
‫Well, the thing is the structure of our system
‫describes both the intent of our product and its qualities.
‫For example, if we look at the architecture of a theater
‫we see that its intent is to have shows and performances,
‫but if we make people live or work in a theater
‫instead of in a suitable house or an office
‫they would find themselves very uncomfortable,
‫and would have a terrible experience.
‫On the other hand, if we look at the architecture
‫of a residential home, we see that it would be perfect
‫for people to live there,
‫but hosting big shows or performances
‫would not work very well.
‫Now when it comes to software, the same principles apply.
‫There's almost an infinite number of ways
‫for us to organize our code
‫to achieve the functionality of the system,
‫but different organizations
‫will give us different properties.
‫In other words, the software architecture
‫impacts how our product will perform
‫and scale how easy it will be for us to add new features
‫and grow our engineering team,
‫and also how well it's going to respond to failures
‫or security attacks.
‫And similarly to physical structures,
‫if we organize our software in a suboptimal way
‫the cost of a redesign will be significant,
‫both in terms of time and money,
‫especially so when we're working on a large scale system.
‫So now that we have some basic intuition
‫and motivation for software architecture
‫let's define it a bit more formally
‫so we know exactly what we're talking about
‫when we use this term.
‫Now, there are many ways define software architecture,
‫and for many years people have been arguing
‫about the best way to define it.
‫So in our course, the definition we're going to use
‫is as follows,
‫the software architecture of a system
‫is a high level description of the system structure,
‫it's different components,
‫and how those components communicate with each other
‫to fulfill the system's requirements and constraints.
‫It's a heavily loaded definition,
‫so let's unpack it piece by piece.
‫The first part of the definition
‫states that the software architecture
‫is a high level description of the system.
‫It means that it's an abstraction
‫that shows us the important components
‫that help us reason about the system
‫while hiding the implementation details out of the view.
‫This implies that things like technologies
‫or programming languages we use to implement the system
‫are not part of the software architecture,
‫and are part of the implementation instead.
‫This is an important point because many engineers
‫falsely assume that software architecture
‫is just about picking the right technologies or frameworks.
‫This could not be further from the truth,
‫and in fact, we want to delay making these choices
‫until the very end of our design.
‫The second part of the definition
‫talks about the different components
‫and how they communicate with each other.
‫The components that we're talking about
‫when we talk about software architecture
‫are black box elements
‫that are defined by their behavior and APIs.
‫As a matter of fact,
‫those components may themselves be complex systems
‫that are described
‫through their own software architectural diagrams.
‫So in a sense, this definition may be recursive when needed.
‫Finally, the last part of the definition
‫talks about fulfilling the system's requirements
‫and constraints,
‫which means that the software architecture
‫should describe how all those components are coming together
‫to do what the system must do,
‫which is basically our requirements,
‫and how the system does not do what it shouldn't do,
‫which is described in the system constraints.
‫We're going to talk about all those components
‫in great detail throughout the course,
‫but I think having this definition upfront
‫is going to set the stage
‫for what we're going to learn in the following lectures.
‫Now when it comes software development,
‫we can talk about software architecture
‫on many different levels of abstraction,
‫starting from the lowest level abstractions
‫like different classes or structs,
‫depending on the programming language, and the organization,
‫and communication between objects inside a program.
‫We can also go one level up
‫and talk about modules, packages, or libraries,
‫and how they interact with each other.
‫But since in this course
‫we're going to be focusing on large scale systems,
‫we're going to talk about a higher level abstraction
‫where the individual components are separate services
‫that run as individual processes or groups of processes
‫potentially on different computers.
‫It turns out that taking this more distributed
‫multi-service approach allows us to architect systems
‫that can handle large amounts of requests, process,
‫and store very large amounts of data,
‫and serve thousands, hundreds of thousands,
‫or even millions of users every day.
‫A few examples of such systems
‫include online software services such as ride-sharing,
‫video-on-demand, social media, online video games,
‫investing services and banks, and many, many others.
‫When we set our goal to build a product
‫that operates on such a scale,
‫getting the architecture just right
‫can mean going from a small start-up
‫to a multi-billion dollar company
‫and making a positive impact on millions of people
‫all around the world.
‫On the flip side,
‫if we don't do a good job at the design phase
‫we can potentially waste months of engineering time
‫building a system that doesn't meet our requirements
‫and that nobody wants to use.
‫And restructuring a system
‫that was not architected correctly
‫is very hard and expensive.
‫So as we can see, the stakes here are high,
‫which makes what we're going to learn in this course
‫super important.
‫Now before we conclude this lecture,
‫I want to talk about one last thing
‫which is the place where software architecture
‫fits in the overall picture.
‫Software development can roughly be described
‫in four phases,
‫design, implementation, testing, and deployment.
‫Since generally software products
‫keep evolving over a long period of time,
‫those four phases can be repeated many times,
‫where arguably the first iteration is the most critical,
‫and subsequent iterations make incremental changes
‫to the existing system.
‫Now something that I already alluded to
‫but didn't state formally is that software architecture
‫is the output of the design phase phase,
‫and the input to the implementation phase.
‫In this course, we're going to focus
‫on arguably the most important step,
‫which is the design phase.
‫The design phase is essentially a process
‫of defining the software architecture of the system
‫that an entire team or even multiple teams of engineers
‫later proceed to implement,
‫sometimes over a course of multiple weeks or months.
‫Now there are many challenges
‫of defining a good software architecture for our system
‫but the biggest challenge that software engineers
‫struggle with the most
‫is the fact that unlike an algorithm or a formula
‫that can be proven to be both correct and optimal,
‫we can't do the same for software architecture.
‫So to guarantee our success,
‫what we can do is follow a methodical design process
‫as well as apply industry proven architectural patterns
‫and best practices,
‫which is what we're going to learn throughout the course.
‫But before we proceed to the first topic,
‫let's quickly summarize what we learned in this lecture.
‫In this lecture, we got the intuition and motivation
‫for software architecture.
‫We learned that every software system has an architecture
‫which is basically its structure,
‫and its structure is absolutely critical for its success.
‫We later define software architecture more formally
‫as a high level description of the system structure,
‫it's different components,
‫and how those components communicate with each other
‫to fulfill the system's requirements and constraints.
‫And we concluded with placing software architecture
‫in the overall software development cycle
‫as the output of the design phase
‫and the input to our systems implementation.
‫So now that we got a solid introduction
‫to what we're going to learn,
‫let's go ahead and start learning
‫the first topic of the course.