What is software architecture?
The Harvard Chan AI Glossary
In our classes, we often pause to explain the ideas behind AI and the language used to describe it. These posts grew out of those conversations. They’re for anyone who would like to understand AI better, with no technical background assumed.
Software architecture describes the main parts of a system, what each is responsible for and how they interact. It explains the arrangement behind the product, rather than only what appears on the screen. In an AI application, those parts might include the user interface, stored records, a model and connections to other services.
Imagine a tool that helps people organize their reading. The interface is where someone adds a book or asks a question. A database is the organized store holding reading records. The AI model is the learned component that generates summaries or suggestions. A separate service might supply book information. Architecture explains how information moves between these parts.
The design needs to answer practical questions. Where are records saved? Which component checks who can read them? What happens when the model service is unavailable? Can a user recover a deleted note? A diagram that shows only a box labeled “AI” leaves most of these responsibilities unexplained.
Architecture differs from a product requirements document, or PRD. The PRD states whom the product serves, what it should do and what conditions it must satisfy. Architecture describes a proposed way of organizing the software to deliver that behavior. Decide what is needed before choosing how to build it. Architecture should follow the requirements, not substitute for them.
It also differs from the detailed implementation: the particular code used to make each part operate. A high-level design can remain similar while individual functions change. Equally, a seemingly small requirement—such as allowing several people to edit the same record—may require reconsidering how the parts coordinate.
For AI-enabled products, it is especially useful to show which decisions are made by ordinary software rules, which rely on a model and which require a person. This makes uncertain steps and authority boundaries visible. The model should not quietly inherit responsibility for everything that has not been specified elsewhere.
For the public dental-care dashboard discussed in class, an architecture would need more than a screen and a box labeled “AI.” It would identify where attendance and treatment-stage records originate, how patients are matched across visits, where follow-up tasks are stored and who may change them. It should also show what the dashboard displays when an update fails. A fictional-data prototype can explore the interface; the architecture makes the additional requirements for a functioning service visible.
If you would like to find out more about AI and improve your leadership skills, consider the AI in Health Care Certificate of Specialization from the Advanced Learning Academy at Harvard T.H. Chan School of Public Health. You can take an individual course or work toward the full certificate.
AI is a fast-moving field. This explanation reflects our class discussions and related material at the time of writing. Terminology, capabilities and tools may change.
For suggested additions or corrections, please email me at tpanch@hsph.harvard.edu.
Dr. Trishan Panch
Program Director, AI in Health Care
Harvard T.H. Chan School of Public Health — Advanced Learning Academy