Welcome

One of the greatest difficulties for young graduates that work in software is getting the big picture. Architecting software is normally reserved for senior people, but this course shows you the ropes of the trade so that you too can work towards becoming a software architect. This course teaches how to design, understand, and evaluate software systems at an architectural level of abstraction. By the end of the course, students will be able to:
 * Why are things organized the way they are?
 * Why do they behave the way they do?
 * What can you do to change it?


 * Identify and characterize the major architectural styles in existing software systems.
 * Recover the architecture of a software system by analyzing its code.
 * Describe a system’s architecture accurately using views of the code and run-time structures.
 * Use existing tools and architectural frameworks to expedite software design.
 * Analyze and use commercial architectural frameworks.
 * Discuss the pros and cons of architectural alternatives.

**Different views of architecture**

 * 1) **Concrete architecture** : An architecture that captures the domain knowledge, system requirements (functional & non-functional) and detailed implementation design for a specific instance / version of the software.
 * 2) **Conceptual architecture** : An architecture that captures the domain knowledge, high level system requirements (functional & non-functional). Not used for a particular implementation of the system.
 * 3) **Reference architecture** : An architecture that mainly captures the domain knowledge across many different product designs

Typical architecture domainsTypical architecture domains are summarised below:
 * 1) **Business architecture**: The structure and behaviour of a business system (not necessarily related to computers). Covers business goals, business functions or capabilities, business processes and roles etc. Business functions and business processes are often mapped to the applications and data they need.
 * 2) **Data architecture**: The data structures used by a business and/or its applications. Descriptions of data in storage and data in motion. Descriptions of data stores, data groups and data items. Mappings of those data artifacts to data qualities, applications, locations etc.
 * 3) **Applications architecture**: The structure and behaviour of applications used in a business, focused on how they interact with each other and with users. Focused on the data consumed and produced by applications rather than their internal structure. In application portfolio management, the applications are usually mapped to business functions and to application platform technologies.**Application (or Component) architecture**: The internal structure, the modularisation of software, within an application. This is software architecture at the lowest level of granularity, as in reference 3. It is usually below the level of modularisation that solution architects define. However, there is no rigid dividing line.
 * 4) **Technical architecture or infrastructure architecture**: The structure and behaviour of the technology infrastructure. Covers the client and server nodes of the hardware configuration, the infrastructure applications that run on them, the infrastructure services they offer to applications, the protocols and networks that connect applications and nodes.

The immediate benefits of software architecture
Architectural styles best support a change in algorithm (how the computation is performed) Architectural styles best support a change in functionality (what computation is performed) Architectural styles are most commonly used to describe enterprise web based applications
 * pipes & filters
 * implicit invocation
 * layered systems
 * pipes & filters
 * implicit invocation
 * layered systems
 * pipes & filters
 * client server style
 * layered style