Software Architecture

This first lecture lays the foundation of the course. It answers what software architecture is (and what it is not), walks through the quality attributes an architect commits to, and shows how functional and non-functional requirements, constraints, and early design decisions shape a system. It then introduces architectural patterns, the benefits architecture brings to a project, how architecture drives business process reorganization, the development models a team can follow, and how budgeting and project management roles work. The lecture closes with the assessment structure and grading scheme, followed by a summary of exam guidance and the key industry applications of architecture.

1.1 What Software Architecture Is — and Is Not

1.1.1 Course Expectations and Positioning

The session opens with a simple question to everyone in the room: what do you expect out of a course in software architecture? The answers arrive from all sides: how complex systems work, system design, designing robust and resilient systems, understanding the end-to-end workflow of how software is designed, being able to build software systems that scale well, system design as a blueprint to the stakeholders, learning about design patterns, designing scalable systems, problem–solution thinking using patterns and practices, optimizing design, system structure and design, modern software architecture, learning architecture patterns and best practices, understanding how enterprise solutions are designed, building future-ready software, understanding scalability, the low-level and high-level architecture of software systems, designing complex scalable systems, sustainable and scalable workflows, reuse, stakeholders, risk in deployment, laying a foundation of work, and helping both business owners and development get on the same page.

From this list, a few words get singled out as especially telling. Stakeholders is called a nice word. Scalable and resilient are words worth liking too. High-level design makes sense as a description of the subject. But one warning follows immediately: there is a strong expectation in the room that this is a course on software design, and it is not. This is not a design-patterns course and it is not a low-level design course. It is a high-level design course. So the phrasing from the instructor is worth holding onto: while it is a design course, it is not a design course — the design work studied here happens at a much higher level of structure and decision-making than the design of classes and methods.

Because design patterns are not taught here, prior knowledge of design patterns is expected from you. For anyone who has not had that exposure, recorded lectures on design patterns are referenced and you can go through them to catch up. You do not need to memorize design patterns to follow this course, but you are expected to have met them before.

1.1.2 Architecture as an Outline Blueprint

The word blueprint was used in the opening answers, and it fits. Software architecture is the outline blueprint of a system. The architect's decisions determine things like: what subsystems the system is made of, what the major recognizable components of the system are — and importantly, these are components, not classes as in software design — which aspects of the software system need to be taken up by the architect, and why. This distinction between components (architecture-level) and classes (design-level) is the first sharp line drawn between the two disciplines.

Later in the course the material moves into styles, views, and what is described as the three structures, which are the formal ways an architecture is organized, presented, and studied. The architectural decisions themselves are taken early because once they are fixed, they are expensive or impossible to change.

1.1.3 Architecture as Art and Science

Many people believe that a good thinker is a good dreamer — that the architect simply sits, closes his eyes, and produces a beautiful picture. There is some truth in that. Software architecture is a bit of an art and a bit of a science. But there is a lot of science in it, and the whole point of the course is to study the science of architecture. That scientific grounding is also what lets someone who wants to go into research proceed on a research path afterwards.

The course states a clear outcome: by the end you should be able to identify the architecturally significant requirements (ASRs) of a system. This is a piece of terminology to give a lot of importance to. An ASR is a requirement that genuinely shapes the architecture — a requirement the architect must take into account when making structural decisions. Understanding what makes a requirement architecturally significant is a recurring theme, and the term comes back again when the assignments are explained.

In practice, this positioning matters beyond the classroom. Enterprises routinely call in architects precisely because business owners and development teams "are not on the same page": the architect's blueprint is the shared artifact that lets business goals, non-functional expectations, and engineering reality be discussed on one document. A future-ready, scalable, resilient enterprise solution starts from decisions made at this high level — the layer where a mistake is cheapest to fix and most expensive to ignore.

1.2 Quality Attributes and the Architect's Commitments

1.2.1 The Quality Attributes of a System

Architecture has a major impact on the quality attributes of the software system that is created. That is one reason the opening answers used words like scalable and robust. Quality attributes are not just influenced by the architecture — they are totally determined by it. The architecture does influence other, non-quality attributes too, but the quality attributes are decided at the architectural level.

The quality attributes this course stresses are: performance, modifiability, security, scalability, reusability, availability, testability, and usability. There are a few others as well that are not all listed, but these are the ones the course keeps returning to.

One useful distinction: some of these attributes are system quality attributes — they need both hardware and software to be achieved (performance, availability, security all depend on machines, networks, and code together), while others are purely software attributes (modifiability, testability, reusability depend only on the code's structure). Both kinds are architectural concerns, because even the hardware-dependent ones are enabled or blocked by the software's structure.

1.2.2 Quality Must Be Marinated, Not Sprinkled

The client believes that requirements get fully communicated, yet many of the most important requirements are never stated — they are taken for granted, and they surface only when the bill is due and the customer is not satisfied with what was delivered. That gap sometimes ends in major controversy. The conventional software requirement specification (SRS) documents only the input forms, output forms, computation logic, and business logic. A system that correctly produces every input, every output, and every computed result can still fail the customer, because the customer is actually looking for performance, availability, maintainability, testability, security, and scalability.

1.2.3 Quality Is Measurable and Negotiated

Someone in the room says quality is not measurable. That claim is rejected directly. Quality is measurable, and learning how to measure it is part of the course. You have to deliver the quality you commit to, and you decide what to commit only after negotiating it with the stakeholders. You decide exactly what level of performance, availability, security, and scalability you are going to provide. This is a different way of thinking about the architect's job: the architect does not just build to a specification, the architect negotiates what quality will be delivered and then commits to it.

A second, equally common example is availability, which is typically stated as a percentage: "99.9% available." Because a year has 365 × 24 = 8,760 hours, 99.9% availability permits only 0.1% of that — 8.76 hours — of downtime per year. Moving the goal to 99.99% cuts the allowed downtime to 52.6 minutes per year and typically forces a visibly different (redundant, failover-capable) architecture. The same technique applies to security (what threats, what detection time, what recovery time), scalability (how many users at what response time), and every other attribute on the list.

1.2.4 Usability as the Emerging Most-Important Attribute

Usability has emerged in the last five to ten years as the most important quality attribute of a system. A concrete example of what a usability requirement looks like: think of how WhatsApp interacts with you. A usability requirement might state that a page should carry no more than so many controls, that a particular type of control must be used, that each item should have a question-mark symbol with help support, and that the user should be able to reverse any activity before committing it. These are the kinds of attributes that make a system usable, and they are specified and measured just like any other quality attribute.

The reason usability has risen to the top is commercial: with competing products one tap apart, the product that is frustrating to use loses users regardless of its features. Two systems with identical functions differ in market value almost entirely through usability. That makes usability the quality attribute the modern architect must weigh first — which is exactly why the course flags it so prominently.

In industry, the marinated-not-sprinkled principle is exactly what separates architecture practices from feature factories: cloud providers, banks, and e-commerce platforms publish availability and latency targets as contracts precisely because their customers learned to demand measured qualities. A modern engineering organization treats a 99.99% availability commitment as a first-class requirement with its own architecture — redundancy, failover, chaos testing — rather than a hope applied at release time.

1.3 Functional and Non-Functional Requirements

1.3.1 The SRS Blind Spot

Functional requirements are what the SRS documents: inputs, outputs, computation logic, and business logic. The IT industry is very well geared to take care of functional requirements — documenting them and making commitments around them is not really a concern. But the actual implementation of a system has very little to do with the functional requirements. Coding has to do with functional requirements — though even in coding you can sometimes satisfy non-functional requirements. The deeper point is that what the coder will do has been determined before the coder gets into action: in design, and before design, in architecture. The architecture gives the overall high-level picture; the designers, understanding the motivation behind the architecture, make sure the design systems they build achieve the requirements.

1.3.2 Non-Functional Requirements Must Be Coaxed Out

Non-functional requirements (NFRs) are also customer requirements. But very often the architect has to coax them out of the customer. Sometimes it reaches a point where the architect has to first educate the customer that these things are non-functional requirements, and then ask the customer to sign off: this is what you require. NFRs are expensive — achieving them costs much more than achieving the functional requirements — and the customer would not pay for them if the customer did not require them. So they are very much real requirements, just harder to surface.

The litigation story carries the whole lesson: the dispute was not about whether the software worked — it was about whether the software was as the client expected. Documents had been written by people who did not feel the client's expectations, the expectation gap grew until it could only be resolved by lawyers, and the case was lost because the expectation had never been converted into a signed requirement. The only protection is writing the NFR down, with a number, and getting the signature before the work starts.

1.3.3 The Architect's Sign-Off Responsibility

The architect works toward the functional requirements, the non-functional requirements, and the constraints. Getting the NFRs written down and signed early is what protects everyone. The requirements the architect commits to become the basis for everything that follows, and the architect also explains to the stakeholders why the chosen architecture is necessary and what it will achieve by way of NFRs.

In industry this sign-off practice is institutionalized as service-level agreements (SLAs): the measurable NFR commitments (uptime, latency, throughput) that a provider signs with a customer, with penalties attached. Every litigation-avoidance lesson of this section is built into the SLA discipline — and the same discipline, applied a layer down, is what the architect applies to every project, with the client's signature in place of a legal document.

1.4 Constraints and Early Design Decisions

1.4.1 Constraints: Hardware, Software, and Client Policy

A constraint can be ridiculous. The customer may say: use any RDBMS you like, as long as it's Oracle. What does that mean? It means the customer wants Oracle, only Oracle, because all of the customer's systems work using Oracle. That is a constraint. Constraints can come from the choice of hardware, the choice of software, or the client's internal policies. If a company has a policy decision that it will not use any product from a given vendor, that becomes a constraint. For example, if a retailer were to decide it will not use storage on a particular cloud provider, that decision becomes a constraint on the architecture. The constraint also interacts with your team's talent: a team that is very conversant with a specific storage system may be useless if the company policy forbids that storage, and you will need different skill sets. Better to discover that early. If you build for months and then discover a constraint, the investment is wasted and the regret is permanent.

1.4.2 Early Design Decisions

Certain design decisions should be taken early so that the people designing the various aspects of the system can make sure compatibility is achieved. There are interfaces that have got to be matched. Early design decisions include: which operating system to use, what form of RDBMS to use, whether you will use a NoSQL setup or pure SQL, whether you will use flat files, whether you will use local storage or remote storage, and — for a mobile application — where data lives on the device. There is an RDBMS available in every mobile device called SQLite; it is present in Apple and Android devices. So some data may live in SQLite, some in file storage, and some in other storage mechanisms provided within the programming languages on the mobile platforms. These small decisions are taken early to make sure they facilitate the type of working you want from the system.

1.4.3 Asynchronous Processing as an Early Decision

Asynchronous processing is explained with a working definition: it is a way to process two activities in parallel. Running two activities in parallel is only possible if one activity does not have to wait for a response from the second activity before it can proceed to the next step. So you initiate both activities and let them meet up at a later phase. An example: you make a request to a server for certain information, and while the request is being processed you continue some other activity — maybe you are doing data entry and you keep entering. As soon as the data becomes available, it updates certain fields and you continue working from there. Decisions like this have an impact on usability and on performance, which is exactly why they are early design decisions rather than implementation details.

Every mobile app in production is a working demonstration of this section: the platform (iOS/Android), the embedded SQLite database, the local-versus-remote storage split, and the asynchronous background fetch that updates the screen without freezing it are exactly the early decisions this lecture describes — made once, at the start, and lived with for the life of the product.

1.5 Architectural Patterns vs Design Patterns

1.5.1 Patterns as Reusable Solutions

There is something called architectural patterns, and they are different from design patterns. This course discusses architectural patterns. A pattern is a regular, reusable solution to a problem: a problem of a particular type, arising in a particular context, solved with a particular solution. So the pattern captures the problem, the context, and the solution together, so that when you meet the same situation again you can apply the solution you already know works. Design patterns are the same idea applied at the level of code and class structure; architectural patterns apply at the level of system structure.

1.5.2 Prior Knowledge of Design Patterns

Because the course is about architectural patterns, design patterns themselves are not taught here. From an examination point of view, the paper setters who contribute the exam are instructed not to give any question that is purely on design patterns. Still, you are expected to have prior exposure to design patterns. If you have not, the recorded design-patterns lectures are easy to understand, and you do not need to understand coding to grasp them. Knowing how to code does give you a connection to them — the instructor, who codes, finds that connection — but it is not necessary.

In industry, the pattern ladder maps directly onto job levels: a developer solves local problems with design patterns, an architect solves system-level problems with architectural patterns, and both are expected to recognize the situation before inventing anything. Enterprise solutions are routinely described in interviews and design documents by their architectural patterns ("it's a layered system with an event-driven core") — the pattern name is the fastest, most precise description of a system's structure that exists.

1.6 Benefits of Architecture: Communication, Modularity, and Change

1.6.1 Stakeholder Communication

The architecture document is the first view the stakeholders get of what will probably come to them. It is the first document that lets a stakeholder know what to expect. The architect discusses with the stakeholders — and the course will engage with how those discussions are conducted: what the topic is, what the form of negotiation is, and how you come to consensus. The architect not only presents the architecture but also explains why this architecture is necessary and what it will achieve by way of NFRs. That explanation is the important part. Stakeholder engagement improves when an architecture exists, because people come to know where you are heading and what they are going to expect.

1.6.2 Modularity, Reuse, and Divide and Rule

Architecture helps you create a design in a form such that components can be reused. Reusability comes in because you may use ready-made components, or you may construct components that can be used in different situations. The moment we talk about architecture we bring in modularity. The architect does not think of creating everything ab initio (from scratch); an architect likes to work with proven technologies, so if a particular sub-module is proven, it can be brought into the overall solution.

There is a classical idea here: divide and rule. Divide and rule is convenient for any administrator because when you divide things into smaller groups, entropy reduces — there is less confusion, and you have specialists working together. In a software system the same idea applies: a module that does a particular purpose is put into one unit, a separate team can work on it, and the interfaces between units are precisely defined. Once you have the architecture you can orient all the teams to work towards it. And if you want to give anyone a skeletal idea of what the system is about, you present the architecture and they know what the system is about.

1.6.3 Managing Change and Localizing Impact

Once you fix an architecture, you can manage change much better. The point of predicting system quality is really early determination: with the quality attributes and architectural decisions set, you can determine what type of quality attributes the system will have. A good architecture is one where you estimate the changes and plan them in such a way that almost any change that actually comes up as a requirement will not impact the architecture. Changes that will have ramifications in a single submodule do not even need to come back to the architect — the development team will take care of them. Changes that affect multiple modules are still not a major issue: the modules remain as they are, and you engage the people involved in each of the modules to get the changes done. The best outcome is an architecture designed and divided so that almost any change that is ever required is local — completely handled by the design team with no ripple effect across the architecture.

In industry the three-tier change ladder shows up as the difference between a routine sprint change (Tier 1 — a developer's ticket), a coordinated release across teams (Tier 2), and an architectural review board decision (Tier 3). Teams that feel "every change touches everything" are experiencing exactly what a bad architecture produces — and the fix is not better coding, it is better division.

1.7 Business Process Reorganization and Organizational Impact

1.7.1 The Hospital Analogy

The architect's early decisions are hard to undo, and a building analogy makes the point. If you build a hospital, there is an architect who decides this building is going to be a hospital, and that locks in a number of decisions that you cannot change later. If you decide to make a building for a hospital and then try to convert it into a cinema hall, a mall, or a school, it becomes very difficult. If you want a mall that will have a multiplex, you have to design a particular part of the mall to take the multiplex — the projector room, the viewing room, with no pillars in between. Similarly, if you want high availability you might want a certain type of distributed architecture, and that choice helps determine the future of the system. The architecture decision is the equivalent of deciding where the pillars go.

1.7.2 The Finance–Receiving Reorganization Example

Once you determine an architecture you may also involve business process reorganization, and if you reorganize business processes you may have to reorganize the organization structure itself. A concrete case: the finance department had to be bifurcated; some people from finance were moved to receiving, and the receiving section had to be separated from administration. The trigger was a new business process for processing customer requests. Under the old system, all issues relating to customer requests went to finance, and only when the check cleared was the request forwarded to the next department. Under the new process, requests that come with payment are handled in receiving rather than going to finance: the check gets separated in receiving, and the processing of the document can start even before the check is cleared. Check clearing becomes a separate process running in parallel, which expedites the processing of customer requests. This is a worked example of the type of change an architecture can force on an organization.

1.7.3 The Check-Processing Decision Options

Here is the same scenario as a decision problem. An envelope arrives from a customer. It contains a check and a work request. The check is a financial document. If the check bounces, the work cannot proceed. So you have options:

• Option one: wait for the check to be processed; once it is cleared by the bank, continue the activity.
• Option two: continue the activity regardless of whether the check is cleared, and after one week check back; if within a week the check is not cleared, whatever processing you have run on the activity, you stop it at that level.
• Option three: split the work so the check is processed in parallel with the activity.

To run the check processing in parallel, you might have to change the organization so the people doing these tasks can work side by side. You might have to change the roles played by departments: who is going to process the check? Processing a check requires certain talents — you have to recognize a check, find out whether it is an order, and so on. It may feel trivial, but the finance department may not think it is trivial, so it may involve training some people. Once trained, the finance department agrees these people have the requisite knowledge to process a check and decide whether the work can at least be initiated. You hold the check; if it is perfectly in order, you allow the normal work on the activity to proceed while the check is sent to the bank for clearing. That saves a little bit of time. The point of the example is that architectural decisions about how work is processed can ripple into who works where, who is trained, and how departments are structured.

Real-world: this is the business-process angle of architecture — a system design choice is not just a technical choice; it can reorganize an entire department and the flow of documents through a company. It is the reason architecture decisions are presented to business leadership, not just to engineering: in industry, a reorganization like the finance–receiving split is exactly what "business process reengineering" projects deliver, with the software architecture as the enabling lever.

1.8 Development Models: Waterfall, Agile, Prototyping, and DevOps

1.8.1 Waterfall and Agile

Once a system is ready, there are different approaches to building it. The conventional approach used to be the waterfall model: you analyzed, you designed, you coded, you constructed, you deployed — and then nobody wanted it, and there was a lot of ill will. Still, the waterfall model is valuable because it presents the major activities involved in developing a software system, in order. Today, and this is discussed in great detail during the course, the industry has moved to agile systems. In an agile approach, right from the very beginning you start giving the customer a feel of what they will be getting at the end of the system, thereby cutting down the variation between the customer's expectations and what is actually delivered.

1.8.2 Prototyping and Evolutionary Prototyping

Prototyping makes a sample of how things will work, to demonstrate that it works. Evolutionary prototyping is fashionable these days, particularly in machine learning and artificial intelligence work. A common pattern: you code in Python — a very strong language with very good libraries, but it is not compiler based. Being interpreter-oriented, it is very easy to troubleshoot and to try out various options, so it is great for rapid prototyping. But when you want to manufacture a product to put on the retail counter, you might switch to something like Java. So the prototype and the final implementation may be in different languages.

A prototype can also be a skeletal system. For example, in an ERP system you might develop all the screens without any functionality: clicking a button takes you to the next screen, and you create dummy reports — when you click report, the report prints. The customer gets a look and feel of the entire system. Then you gradually populate the system. Maybe you leave out certain types of validation that are less required and put them into subsequent sprints. You create backlogs for each iteration and move that way, and gradually the product comes into being.

1.8.3 DevOps and the Never-Finished Product

Today's environment is a DevOps environment. In DevOps you have continuous construction, continuous integration, and continuous deployment, which means the product is actually never complete. Even when the product is complete, you keep thinking of evolutionary ideas to improve it, and every product becomes an evolutionary prototype for the next product. You see it with products like Facebook, WhatsApp, and X — any of the major products in the industry today — they are continuously undergoing change and improvement and evolving into something better. If you look back at WhatsApp the way it was some fifteen years back in its nascent state, you would probably feel that that was a prototype for what is delivered today. When they made it, of course, they did not call it a prototype; it was a finished product, and that is what made it popular. But in hindsight, that is what the pattern looks like.

Real-world: the ML/AI industry runs on the evolutionary-prototyping pattern the lecture names — models are prototyped in Python notebooks and promoted into production platforms; and every major consumer product (Facebook, WhatsApp, X) demonstrates the DevOps never-finished cycle, with continuous integration and deployment pipelines that keep a product permanently evolving while always keeping it releasable.

1.9 Budgeting, Costing, and Project Management Roles

1.9.1 Project Manager vs Architect

There are two important roles in any software system project. The project manager does have technical responsibilities, but the job is more to do with ensuring the scope is adhered to, on time and at the right cost. Cost, time, and scope are the three pillars of the project manager's responsibility. The negotiation of the scope is mostly done by the architect. The architect co-owns the scope with the customer. So the division of labour is: the architect negotiates what will be built and why the architecture is what it is; the project manager makes sure it gets delivered within the agreed scope, time, and cost.

1.9.2 Bottom-Up vs Top-Down Budgeting

Budgets can be built bottom-up or top-down, and normally it is a combination of both that helps you evolve a budget. Top-down means you come out with a figure, break it up gradually into details, allocate the cost to each unit, and ask people to accept it — will you accept it, can you do it at this cost, or this is the cost you have to do it at in any case. Bottom-up means you ask each unit what resources they will put into the work, estimate the cost, add the costs upward, and come out with the total product cost. Putting the two exercises together cross-checks one against the other.

1.9.3 Crystal-Gazing vs Informed Pricing

By being able to take a clear decision, you can decide on the cost. You know what you will be doing, you know what it is going to cost you, and you can get a cost commitment and a schedule commitment. If you had started off without formulating an architecture, the project was bound to go out of hand, because you will end up doing work without knowing where you are heading. As you move, you start realizing problems, and at a certain stage the problems may be so many that the project goes way out of the budget.

The alternative is a crystal-gazing exercise: "This project — quote five million. Our competitor is giving it at four million. Okay, we'll also take it at four million." You just do not know why five million, and why four million. Whereas if you can engage the customer and explain in greater detail than your competition why you are charging what you are charging and what you will deliver, the competitor will probably go back to your competitor and ask: are you delivering this stuff? The competitor says no, that is not part of our commitment. Then you have something meaningful to work on, and people understand who is in control. An informed, architecture-based cost commitment beats a guess every time.

Real-world: every credible software vendor prices from an informed base — scope, architecture, and committed service levels produce the proposal; the same discipline appears in fixed-price contracts, where the architecture-based cost commitment the lecture describes becomes a signed, legal price. The crystal-gazing vendor, by contrast, is the one who wins the bidding war and then discovers, mid-project, "the problems may be so many that the project goes way out of the budget."

1.10 Assessment Structure and Grading

1.10.1 Credit Units and CGPA Weighting

This is a five-credit-point course. Credit units determine the weightage a course has on your grade point average, and they also tell you how much time to spend on a course — you spend five units of time on this course because it is worth five units. Courses come in three, four, or five units. Whatever grade you get in this course gets multiplied by five.

$$\text{CGPA contribution}=g\times u$$

where $g$ is the grade points awarded on the 0–10 scale and $u$ is the course's credit units. For a five-unit course the weightage of the grade is five; for a four-unit course it is four. So the same grade moves the CGPA more in a heavier course. The four-unit versus five-unit difference genuinely does affect the CGPA.

1.10.2 Relative Grading and the Sigma Rule

Marks get converted into grades for the official report card. For example, fifty out of one hundred gives an A grade, and an A grade translates to nine points out of ten. The pass mark in this program is an overall 5.5 CGPA; a mixture of C minuses and C's, fifty-fifty, helps you clear.

Grading itself is relative. If the faculty finds that everybody scored about seventy percent plus or minus five marks, they would give everyone a comfortable grade (e.g., B) and be over and done with. Otherwise a histogram of all the marks is drawn. This follows the concept of the standard normal distribution: people who are higher than the average by at least one sigma end up with a B grade; people who are away from the average by two sigma end up with an A grade; and exceptionally high outliers, where nobody's marks are anywhere near them, end up with an A plus.

$$\text{A band}\approx \bar{x}+2\sigma ,\text{B band}\approx \bar{x}+\sigma$$

where $\bar{x}$ is the class average mark and $\sigma$ is the standard deviation of the marks. The source describes these bands only in plain words — "at least one sigma above the average" for B and "two sigma above" for A — and the enrichment docs confirm this standard framing, so the exact boundaries of the grade bands should be treated as approximate.

The same pushing logic applies at the borders: people between A and B who are getting a B could have been pushed to A, but instead they get an A minus; C graders who are coming to the border and could have done with a B get a B minus; and the same happens for C minus. D graders are not penalized with a D grade, because a D grade gives only four points on the CGPA scale and pulls down the overall CGPA quite significantly — so students who do not quite deserve a C (the people who got a C did much better) get pushed up into a C minus. A C minus is below average, but it keeps the CGPA healthier than a D would.

1.10.3 Examinations, Makeup, and Study Strategy

The internal component (EC1) includes quizzes and assignments: the quizzes are multiple choice, and the assignment is descriptive and participative. The exams (EC2 and EC3) are descriptive — definitely not MCQ. Historically EC2 has always been closed book and EC3 open book; during the pandemic period EC2 was also made open book, and whether the institution is still in that mode is not certain. The instruction about an open-book exam is simple: do not hope to start reading the book during the exam. It is like practical work with an open Google — if you do not know what to Google, you will end up nowhere. You had better have read the book if you intend to refer to it. Teachers have read the books too, and they are not impressed by copied passages. The question paper expects you to connect what you write with the question, not to dump something relevant-looking. Printed PDFs can carry intellectual-property issues on campus, and e-books and soft copies are generally not allowed; handwritten notes in a bound volume, spiral or flat bound, are allowed, and you should check the examination department's announcement for the exact rules.

The makeup exam exists for people with a business exigency, medical issue, or extraordinary circumstance who cannot take the regular exam. You can appear for only one of the two — once you have taken the regular exam the chapter is closed, and they will not allow the makeup. The regular and makeup papers are completely different; they have no similarity to each other. There is no makeup for the makeup.

The exam questions will be tough but they will be easy to answer. Do not bother about getting full marks. There is a fairness guarantee in this course: a given question is corrected by the same examiner for all students, so if the best mark that examiner gives is three out of ten, you can be sure nobody got better than three out of ten. No amount of memorizing is going to help, because the questions will be a little vague. Past papers will not help either — the course is so wide that you cannot study everything in it, so you get an overall idea, understand the concepts, sleep well the night before, read the question paper very carefully, and answer what has been asked.

Assignments and quizzes are optional under the institution's peculiar rule — you do not have to appear for them — but they are the easiest place to make the mark, and the internal 30 percent matters for relative grading. Getting twenty out of thirty is not a problem, and if you land up getting fifty-five marks overall you clear the course. EC2 and EC3 are mandatory: if you do not appear for them, you do not clear the course and you repeat it. A quiz is a half-hour quiz with a ten-day window in which to appear. Revaluation requests are normally fairly futile, especially the "begging requests" that ask for one more mark; but if there is a totaling mistake, or you believe a particular question was left unevaluated, teachers have no problem re-evaluating and giving you the marks.

1.10.4 Course Map: Modules, Contact Sessions, and Assignments

The course runs across sixteen contact sessions, each with a stated outline. Contact session one was the introduction. The next session moves into the architectural context: what an architect is, software architecture, and an introduction to styles, views, and the three structures. The midterm exam covers modules one to five; the comprehensive exam covers modules one to ten. Module references, recorded lectures, and textbook chapters are given for each module, and the direct references are all to the primary textbook (T1), with a secondary textbook (T2) that is not really a necessity. Reference material (R1 through R5) is provided as PDFs.

Assignment one is an individual assignment done before the midterm exam. You choose an existing system from your workplace, understand its goal and key requirements, document the purpose of the system — why it exists — the functional and non-functional requirements, build a utility tree, identify the architecturally significant requirements, choose the tactics that satisfy them, and draw at least one diagram under each of these options: context, module, component-connector, and deployment view. Then you give a brief description of how the system works functionally and one slide on what you learned. You are expected to give only one page for each point, except that each diagram gets its own page. The assignment is submitted as slides, but a PDF is the safer form to give because PowerPoint sometimes gives problems in reading.

Assignment two comes after the midterm exam. It is a group assignment, but you will be evaluated individually — each person works on an independent assignment while participating in a group discussion (groups are created on the e-learning site), and you are graded on your individual submission and your participation, not on the group as a whole.

Exam Guidance Summary

Key Industry Applications