Course Meeting Times
Lectures: 7 sessions over 5 weeks, 2.5 hours / session
About System Architecture
Definitions, the Architect and Architecting, and Deliverables of the Architect (PDF)
Students will be able to apply the principles, processes, and tools of system architecting such that they will be able to:
- Structure and lead all the early, conceptual phases of the system development process, and
- Support the process through development, deployment, operation and evolution.
To prepare students for their first, second, and third jobs after the end of the program.
Systems and Products
Students should be able to:
- Explain what a system is and how behavior emerges
- Demonstrate "system thinking" (holism, balance, focus)
- Explain what a product is, how it creates value and competitive advantage
- Identify the common features of a generic Product Development Process (PDP), and create one specialized for a given product
- Identify where the architecting process sits in the PDP, and its role in establishing value and competitive advantage
Students will be able to:
- Define system architecture
- Identify the architecture of systems, critique them, and learn from them
- Create architectures for new or improved systems
- Execute the role of a system architect (see below)
- Produce deliverables of the architect needed to define the architecture of a system
Creative / Critical Process Thinking
Students will be able to:
- Compare existing architecting approaches
- Create new approaches
- Analyze old and new approaches, and synergize a "best" approach
- Think creatively and "out-of-the-box" when necessary
- Develop a personal set of guiding principles for successful architecting
Strategy and Structure
This class is taught in two parts. The first part is during the five-week IAP session, and covers the core material and central ideas of system architecture. The second part, in the subsequent fall term, further develops these concepts through case studies, special topics and a review of a synthetic approach.
In the first "half" (IAP session) we will focus on learning:
- The definitions used in the subject
- The Product Development Process
- The concepts in product architecture
- Analysis of architectures
And, in the second "half" (subsequent Fall term) we will focus on learning:
- Processes upstream and downstream of architecting
- Frameworks for thinking holistically
- Underlying and enduring principles of system architecture
- Creation and critique of architecture
- Methods of critical evaluation of JAMs ("just another method") and contemporary tools
- Alternative and "out of the box" alternatives thinking for yourself
- Approaches to creativity, ambiguity, and complexity
- Advanced topics: Supply chains, platforms and families, and reuse of legacy elements
Additional references are given on the readings page.
The contribution from the IAP session accounts for 25% of the total grade for the subject.
It will include:
|Challenge I presentation||5%|
|Group projects (4 assignments) || |
|Technology search (in groups of 2-4 students)||20%|
|Class participation (discussions and holistic thinking)||10%|
The grading from the fall semester is about 75% of the total for the subject.
Note that the grading system for this course is somewhat different from other classes at MIT. Since many questions do not have an absolute right or wrong answer, a grade such as 37.5/40 would not make sense. Nevertheless you will get a quantitative assessment of your answers. The following grading scale is used and is reflective of the self-consistency and depth of your answers and the thoughtful incorporation of materials from class, the readings and your past educational and professional experience. Note that a grade of 3 is given for an answer that corresponds to an average, expected answer. The grades 4-5 are used for above average answers, the grades 1-2 as modifiers for below average answers.
1. Did not really capture intent of exercise, missed main points. Resubmission strongly encouraged.
2. Captured some, but not all of the important points, but could have been better. Resubmission allowed.
3. Workmanlike discussion, following and applying the ideas presented in class and readings.
4. Very good discussion, which captures the main points and presents a thorough analysis of the issues.
5. Excellent discussion, which captures all of the important points, and adds creative new perspectives of view above and beyond those contemplated by the instructor.
System architecture is an evolving field, and good and creative new thoughts and ideas developed by members of the class can and will be folded into the next iteration of teaching and research. This is how scholarship develops. Except as provided below, please do not submit anything as an assignment for the class that can not be shared with future students of mine at MIT or elsewhere. I intent, in any future reuse of the material, to credit my former students in a general way. There are two exceptions to this policy. In the (rather unlikely) event that you develop something in class which is of the quality and extent of a publishable piece of work (e.g. a conference or journal article), please inform me of your intent to publish it by the end of the class, and then of the citation when published. I will cite the contribution accordingly in the future. In the (more likely) event that you want to use something of a somewhat sensitive or proprietary nature as part of a submission, please indicate at the bottom of each chart or on the cover of the document the restriction (e.g. for Crawley only, of this semester class only, etc.)
Policy on Academic Integrity
SDM students come from the corporate environment, where it is important to get a good answer to the question at hand, but not necessarily important to be original or cite sources of ideas use. This is not the case at MIT, where it is important to create original work, or cite the source of ideas very carefully and completely. Quoting MIT Policies and Procedures, "MIT assumes that all students come to the Institute for a serious purpose and expects them to be responsible individuals who demand of themselves high standards of honesty and personal conduct." The penalties for violation of this policy are severe, and will be applied in this subject. These policies underscore the importance in academia of creativity and proper acknowledgment of sources. We strongly recommend that you work as individuals or teams as indicated on each assignment, and produce original work, or work which cites the contribution of others and sources appropriately.
The calendar below provides information on the course's lecture (L) and workshop (workshop) sessions.
|SES #||Themes||Product Development ProcessES (PDP)||Architectures||Examples||Key Dates|
|L1||Definitions||Technology search||Architecture, form||House, bridge, camera, instruction, SW, amp, whistle||Homework 1, 2, 3, 4 out|
|L2||Definition closure||Reference PDP||Function||Whistle, SW Op amp|| |
Homework 1 (def) due
Homework 2a (form) due
|L3||Complexity||Synthesis PDP||Architecture, concept||Whistle, SW, skateboard, services, network, refrigerator|| |
Homework 3 (PDP) due
Homework 2b (function) due
Homework 5 out
|L4||Ambiguity||Closure PDP, downstream||Timing, operator, cost||Skateboard, services, network, refrigerator||Homework 4a (structure) due|
|L5||Ambiguity (cont.)||Upstream||Needs, goals||Skateboard, services, network, refrigerator||Homework 4b (process) due|
|L6||Summary||Role of the architect||Value, style, platforms||SDM|| |
Homework 4c (final) due
Homework 5 (tech) due