‫Welcome back.
‫In this lecture,
‫we're going to talk about the third architectural driver
‫and type of requirement: the system constraints.
‫We're going to talk about a few types of constraints
‫classified by their source
‫and also the effects that the system constraints have
‫on our software architecture.
‫Finally, we will talk about a few considerations
‫that we need to take into account
‫when we deal with system constraints.
‫So what do we mean by system constraints?
‫Typically, once we define the functional requirements
‫and what our system must do,
‫we have a high degree of freedom
‫on how to structure our system.
‫In other words, while defining the final architecture,
‫we have to make a lot of decisions
‫because we typically have many ways
‫to achieve the desired quality attributes
‫and the desired functionality.
‫Specifically when it comes to quality attributes,
‫we are allowed and are typically expected
‫to make tradeoffs.
‫So a system constraint is essentially a decision
‫that was already either fully or partially made for us,
‫restricting our degrees of freedom.
‫But this is not always a bad thing.
‫Essentially, what I'm alluding to
‫is instead of looking at a constraint
‫from a negative connotation
‫as a choice that was taken away from us,
‫we can also look at it as a decision that was made for us
‫which sometimes makes our job easier.
‫That's why sometimes people refer to system constraints
‫as the pillars for our software architecture.
‫The reason for that is that system constraints
‫provide us with a solid starting point.
‫And since usually constraints are non-negotiable,
‫we sort of need to design the rest of the system
‫around those constraints.
‫So what type of constraints can we have in our system?
‫Generally, there are three types of constraints:
‫technical constraints, business constraints,
‫and legal constraints.
‫As software engineers,
‫technical constraints are something that we deal with
‫every day, so it's not something that is new to us.
‫Examples of technical constraints
‫include things like being locked to a particular hardware
‫or cloud vendor because of an existing contract
‫or security reasons,
‫having to use a particular programming language
‫because of existing frameworks we built in-house
‫or maybe difficulty hiring engineers,
‫having to use a particular database or technology
‫or having to support certain platforms, browsers,
‫or operating systems because of licenses, support cost,
‫or maybe because our clients specifically ask for that.
‫On the surface,
‫technical constraints may all seem like they belong
‫to the realm of implementation
‫and not the software architecture.
‫But unfortunately in practice, in many cases,
‫they do affect the decisions we make in the design phase
‫and put restrictions on our architecture.
‫For example, if our company made the decision
‫to run all our services on-premise or our own data centers,
‫maybe for security reasons or financial reasons,
‫then all the cloud architectures and paradigms
‫like out of scaling or function as a service
‫may be either unavailable to us or are very hard to achieve
‫because we would have to implement
‫a lot of non-trivial infrastructure.
‫Another example is if we have to support some older browsers
‫or low-end mobile devices that don't support
‫certain communication protocols
‫or can't handle as much data,
‫we would have to adopt our architecture significantly
‫to support those platforms and their APIs
‫while providing a different, more high-end experience
‫for newer browsers or higher-end devices.
‫Now let's talk about the second type of constraint
‫that come from our business.
‫Typically as engineers, we want to make the right decisions
‫and architectural choices from a technical perspective,
‫but we're not always able to assess
‫how those decisions align with the goals of our business.
‫For that reason, we frequently get constraints
‫that come from our business team
‫which force us to make certain sacrifices
‫both in terms of architecture and implementation.
‫For example, if we get a business constraint
‫in a form of a limited budget or a strict deadline,
‫we will make very different choices
‫than if we had an unlimited budget or unlimited time.
‫In fact, there are certain software architectural patterns
‫that are more suitable for small startups
‫that have to get to the market fast with a small team
‫and there are other architectural patterns
‫that fit much better with bigger organizations
‫that have many engineering teams and a much larger budget.
‫We'll talk about those architectural patterns
‫in much more detail farther in the course.
‫Besides time and budget limitations,
‫we can also get a business constraint
‫that tells us to use third-party services
‫as part of our architecture.
‫For example, if we're building an online store,
‫we may want to specialize in the experience of the clients
‫who shop on our platform,
‫but use third-party providers
‫to take care of the shipping and the billing.
‫Another example is if we're building an investment platform,
‫we would typically need to integrate
‫with different banks, broker services,
‫as well as security and fraud detection services.
‫Those are all examples of business decisions
‫to specialize in only one area and not get distracted
‫with things that we can get from other partners.
‫But all those third-party providers
‫have their own APIs and architectural paradigms
‫that we would have to work with
‫as part of designing our own system.
‫Now, finally, the third type of constraint
‫comes from certain rules and regulations.
‫Those constraints may be global
‫or specific to a particular geographical region.
‫For example, in the United States,
‫if you are developing a system
‫that handles medical information or patient's records,
‫you need to adhere to the HIPAA regulations
‫that place certain constraints
‫on who can access the patient's data,
‫as well as the security we need to put in place
‫to store the sensitive information.
‫In the European Union,
‫GDPR sets certain limitations on online services
‫regarding what kind of data they can collect, store,
‫and share with third parties about their users.
‫This regulation also has certain limitations
‫on how long some data can be retained.
‫So depending on the country
‫where we're planning to offer our services
‫and the industry that our services belong to,
‫we may have different regulations
‫that affect the architecture of our system.
‫Now, once we identify all the constraints,
‫there are two considerations that we need to keep in mind.
‫The first consideration is that we shouldn't take
‫any constraint that's given to us lightly.
‫What I mean by that is we want to make the distinction
‫between real constraints
‫that there is nothing we can do about
‫and self-imposed constraints that we can negotiate
‫and maybe even remove.
‫For example, if we're working
‫with external rules and regulations,
‫maybe there is not much room for us to negotiate.
‫But if we're getting budget and time constraints
‫from our business, maybe there is room to postpone
‫some of the deadlines or stretch the budget.
‫If we are currently locked to a particular hardware,
‫cloud vendor or a particular set of technologies,
‫maybe this project we're working on
‫is the perfect opportunity to explore other options
‫which may benefit our business in the long run.
‫Once we agree to take on a set of constraints,
‫it's very hard to back away.
‫And if we find out down the line
‫that those constraints were not real constraints,
‫our overall architecture
‫may just not make any sense anymore.
‫This brings us to the second consideration
‫which is that when we do take on certain constraints,
‫we need to leave enough room in our architecture
‫to move away from those constraints in the future.
‫For example, if we are limited
‫to a particular database that we need to use
‫or some third-party service that we have to integrate with,
‫we need to make sure our system is not tightly coupled
‫to that particular technology or those specific APIs.
‫And if in the future,
‫we are able to use different technologies
‫or different services,
‫we will need to make minimal changes
‫instead of re-architecting the entire system from scratch.
‫When we get to the topic of architectural building blocks,
‫we will see many examples of specific tools
‫and general techniques on how we can decouple
‫different parts of the system
‫in a way that they can be easily replaced
‫or updated independently
‫without the need to refactor the entire system.
‫In this lecture,
‫we learned about the third type of architectural driver,
‫the system constraints.
‫We first defined system constraints as a decision
‫that was already either fully or partially made for us
‫restricting our degrees of freedom.
‫After that, we talked about the three types
‫of system constraints, which are technical constraints,
‫business constraints, and legal constraints.
‫And finally, we discussed the two considerations
‫we need to pay attention to
‫when we deal with system constraints
‫which are not taking them lightly
‫and making sure we don't have any tight coupling
‫to those constraints.
‫I will see you soon in the next lecture.