1. Architecture is More Than Just Meeting Requirements Ron Olaski SE510 Fall 2003

2. Architecture The result of technical, business, and social influences and it is a crucial part of the system design process The result of technical, business, and social influences and it is a crucial part of the system design process The realization of early design decisions made with respect to the various parts of a system The realization of early design decisions made with respect to the various parts of a system Serves as an important communication, reasoning, analysis, and growth tool for systems Serves as an important communication, reasoning, analysis, and growth tool for systems

3. The Architecture Business Cycle (ABC) The relationship among the technical, business and social environments that subsequently influence future architecture The relationship among the technical, business and social environments that subsequently influence future architecture Influencing factors include organizational goals, business and technical requirements and processes that bring about new organizational capabilities Influencing factors include organizational goals, business and technical requirements and processes that bring about new organizational capabilities

4. Software Architecture Concerns the structure of large software systems Concerns the structure of large software systems Architectural view is an abstraction that distills away details of implementation, algorithm and data representation and concentrates on the behavior and interaction of “black-box” components Architectural view is an abstraction that distills away details of implementation, algorithm and data representation and concentrates on the behavior and interaction of “black-box” components Developed as the initial step toward designing a system that has a collection of desired properties Developed as the initial step toward designing a system that has a collection of desired properties

5. Software Architecture (cont’d) Consists of software components, the externally visible properties of those components and the relationships between them Consists of software components, the externally visible properties of those components and the relationships between them The earliest artifact that enables the priorities among competing concerns to be analyzed The earliest artifact that enables the priorities among competing concerns to be analyzed

8. Feedback mechanisms The architecture can affect the business goals of the developing organization. The architecture can affect the business goals of the developing organization. The architecture can affect the customer requirements for the ensuing system by presenting the customer with an opportunity to receive an upgraded system in a more reliable, timely and economical manner. The architecture can affect the customer requirements for the ensuing system by presenting the customer with an opportunity to receive an upgraded system in a more reliable, timely and economical manner. The system building process will affect the architect’s experience by adding to the corporate experience base. The system building process will affect the architect’s experience by adding to the corporate experience base.

9. Feedback mechanisms (cont’d) A few systems will influence and actually change the software engineering culture and technical environment. A few systems will influence and actually change the software engineering culture and technical environment.

10. Activities involved in creating a software architecture Creating the business case for the system Creating the business case for the system Understanding the requirements Understanding the requirements Creating or selecting the architecture Creating or selecting the architecture Representing and communicating the architecture Representing and communicating the architecture Analyzing or evaluating the architecture Analyzing or evaluating the architecture Implementing the system based on the architecture Implementing the system based on the architecture Ensuring that the implementation conforms to the architecture Ensuring that the implementation conforms to the architecture

11. Process Recommendations The architecture should be the product of a single architect or a small group with an identified leader. The architecture should be the product of a single architect or a small group with an identified leader. The architect (or team) should have the technical requirements for the system and an articulated, prioritized list of qualitative properties that the architecture is expected to satisfy. The architect (or team) should have the technical requirements for the system and an articulated, prioritized list of qualitative properties that the architecture is expected to satisfy. The architecture should be well documented using an agreed on notation that all stakeholders can understand. The architecture should be well documented using an agreed on notation that all stakeholders can understand.

12. Process Recommendations (cont’d) The architecture should be circulated to the system’s stakeholders, who should be actively involved in its review. The architecture should be circulated to the system’s stakeholders, who should be actively involved in its review. The architecture should be analyzed for applicable quantitative measures and formally reviewed for qualitative properties before it is too late to make changes to it. The architecture should be analyzed for applicable quantitative measures and formally reviewed for qualitative properties before it is too late to make changes to it. The architecture should lend itself to implementation via the creation of a “skeletal” system in which the communication paths are exercised but which at first has minimal functionality. The architecture should lend itself to implementation via the creation of a “skeletal” system in which the communication paths are exercised but which at first has minimal functionality.

13. Process Recommendations (cont’d) The architecture should result in a specific and small set of resource contention areas, the resolution of which are clearly specified, circulated, and maintained. The architecture should result in a specific and small set of resource contention areas, the resolution of which are clearly specified, circulated, and maintained.

14. Structural Recommendations The architecture should feature well-defined modules whose functional responsibilities are allocated on the principles of information hiding and separation of concerns. The architecture should feature well-defined modules whose functional responsibilities are allocated on the principles of information hiding and separation of concerns. The modules should allow development teams to work largely independently of each other. The modules should allow development teams to work largely independently of each other. The information-hiding modules should include those that encapsulate idiosyncrasies of the computing infrastructure, thus insulating the software from platform changes. The information-hiding modules should include those that encapsulate idiosyncrasies of the computing infrastructure, thus insulating the software from platform changes.

15. Structural Recommendations (cont’d) The architecture should never depend upon a particular version of a commercial product or tool. The architecture should never depend upon a particular version of a commercial product or tool. Modules that produce data should be separate from modules that consume data to increase modifiability. Modules that produce data should be separate from modules that consume data to increase modifiability. Every task or process should be written so that its assignment to a specific processor can be easily changed even at run time. Every task or process should be written so that its assignment to a specific processor can be easily changed even at run time.

16. Conclusion