Architecture is More Than Just Meeting Requirements

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 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

3. The Architecture Business Cycle (ABC) • 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

4. Software Architecture • 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 • 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 • 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 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.

9. Feedback mechanisms (cont’d) • 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 • Understanding the requirements • Creating or selecting the architecture • Representing and communicating the architecture • Analyzing or evaluating the architecture • Implementing the system based on 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 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.

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 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.

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.

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 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.

15. Structural Recommendations (cont’d) • 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. • 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