What is Architecture ?

1. What is Architecture ?

2. Technology Issues • Ability to deal with organizational or product complexity in a timely manner • Ability to adopt a disruptive technology that is not feasible today • Desire for systems or family of applications to have qualities or characteristics such as a high level of integration, evolvability, and understandability • Desire to reduce development, maintenance, and operating costs of system or applications.

3. Architecture “Architecture is an instrument whose central function is to intervene in man’s favor” James Fitch, 1972

4. What is Architecture ?

5. What is Architecture ? • A collection of software and system components, connections, and constraints. • A collection of system stakeholders' need statements. • A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements.

6. Architecture as a tool to communicate with stakeholders • For designers and implementors, the architecture provides their "marching orders." The architecture establishes constraints (plus exploitable freedom) on downstream development activities. • For testers and integrators, the architecture dictates the correct black-box behavior of the pieces that must fit together. • For technical managers, architecture provides the basis for forming development teams corresponding to the work assignments identified. • For project managers, architecture serves as the basis for a work breakdown structure, planning, allocation of project resources, and tracking of progress by the various teams. • For designers of other systems with which this one must interoperate, the architecture defines the set of operations provided and required, and the protocols for their operation, that allows the interoperation to take place.

7. Architecture as a tool to understand a system • For technical mangers, architecture is basis for conformance checking, for assurance that implementations have in fact been faithful to the architectural prescriptions. • For maintainers, architecture is a starting point for maintenance activities, revealing the areas a prospective change will affect. • For new project members, the architecture is usually the first artifact for familiarization with a system's design. • For those inheriting the job of architect after the previous architect's untimely departure, the architecture is the artifact that (if properly documented) preserves that architect's knowledge and rationale. • For re-engineers, architecture is the often first artifact recovered to understand existing system

8. What does a good Architecture provide ? • It is at a high-enough level of abstraction that the system can be viewed as a whole. • The structure must support the functionality required of the system. Thus, the dynamic behavior of the system must be taken into account when designing the architecture. • The structure must conform to the system qualities (also known as non-functional requirements): • Performance, security, reliability requirements associated with current functionality • Flexibility, extensibility requirements associated with accommodating future functionality at a reasonable cost of change. • These requirements may conflict, and tradeoffs among alternatives are an essential part of designing an architecture. • At the architectural level, all implementation details are hidden.

9. From Requirements to Architecture • From requirements specification to architecture • Decompose software into modules with interfaces • Specify high-level behavior, interactions, and non-functional properties • Consider key tradeoffs • Schedule vs. Budget, • Cost vs. Robustness, • Fault Tolerance vs. • Size, Security vs. Speed • Maintain a record of design decisions and traceability • Specifies how the software product is to do its tasks

10. Architecture vs Design • Differences between Architecture and Design • Architecture is concerned about higher level issues • components vs procedures • interactions among components vs interfaces • constraints on components and interactions vs algorithms, procedures and type

11. Architecture vs Design • Architecture is concerned with a different set • of structural issues • Large-grained composition vs procedural composition • Component interactions (protocols) vs procedural/task interactions (pc, rpc, msgs, etc) • Information content vs data types and representations

12. How to document Architecture • Views approach • UML • Free form diagrams + text • Paper napkins

13. Architectural Roles • Role Descriptions • The Architect says: I decide how the building will look and function. • The Engineer says: I will make sure the building will be structurally sound • The Scientist says: I do research and invent, to further knowledge. • The Builder says: I will build the building.

14. Technology Architecture • Combined Architecture and Engineering Function • Determine what technologies will be used • Determine how the technologies will be used • Verify that the technologies are used correctly

15. Architect Role and Responsibilities • An architect is someone who designs or develops architectures • Architectural or Technological Vision • Conceptualizing and Experimenting with Alternatives • Creating Models and Component and Interface Documents • Validates Technologies to Meet Requirements

16. Architect Role and Responsibilities • Architectures are seldom embraced without challenges • Sell architectures to various stakeholders • Navigates Network of Influence to Ensure the Success of a Architecture • Consults and Provides Guidance to the Development Team • Consultant to Business and Management Teams • Communicates to all Interested Parties

17. Architect Role and Responsibilities • Knowledge of organization's product domain and relevant technologies and development processes. • High tolerance of ambiguity and ability to work at an abstract level. • Combination of Strategist and Technologist

18. Architect Role and Responsibilities • Organizational Politics • Architectures will have a diverse stakeholders and are to be used by many developers – to gain and maintain sponsorship the architect must be an influencer. • Understand both business and personal objectives. Listening, networking, articulation and selling a vision over the life of an architecture are important.

19. Architect Role and Responsibilities • The architect is a consultant who is committed to the success of others. • Must create conceptual solutions for business customers. This includes the ability to clearly articulate the solution in a common vernacular. • Development teams are the users of an architecture, its not their job to make a architecture successful, but rather satisfy their specific functionality, schedule and quality requirements.

20. Architect Role and Responsibilities • A few things that an Architect is not...... • Project Manager... but can provide clarity to complex dependencies or scheduling issues • Quality Assurance Technician... but can assist is integration evaluations • Guarantor that an application is programmed perfectly... but can provide development platform or architectural insights • Firefighters... but we can assist with prevention and recovery

21. Technology Architecture Team “Conceptual integrity must proceed from one mind, or from a very small number of agreeing resonant minds” Fredrick Brooks – Mythical Man-Month (1995)

22. Technology Architecture Team • Combined Architecture and Engineering Function • Concept and Functional Vision • Construction Philosophy and Direction • Ensure that the development teams have the guidance needed for success • Architectural Clarity • Landscape Guidance • Consistent Practices

23. Technology Architecture Team • Quality Reviews and Consultant Services • End-to-End Technical Quality (Verification v. Validation) • Architectural Conformance • Maintenance Reviews • Compatibility Assessments • Team Guidance • Continuous Process Improvement • Modifications to Architecture as Applications or Systems Evolve

24. Organization Pitfalls for Technology Architecture Teams • Leadership Issues • Architecture flounder without leadership or executive sponsorship • Individual Agenda • Strong opinions about directional issues with teams • Divided Attention • Development vs. Strategic Direction • Ivory Towers • Avoid setting direction in a isolation

25. Critical Success Factors for Architecture Teams • Small dedicated full-time team to create and deploy the architecture • Complementary skills • Communications • Goodwill between Architecture, Management, and Development Teams, Production Support

26. Execution for Technology Environment • Inventory Applications and assign architect to each initiative • Identify technologies patterns • Develop standards from existing patterns or technology requirements • Communicate architecture to the development teams

27. Project Participation • Design • More than concept less than detailed design • Developer Education • Guidance with Tools and Technology • Communicate Vision for Product and Requirements

28. Project Participation • Supervision • Confirm Plans (Partnership with Management) • Confirm Implementation (Partnership with Technical Lead) • Confirm Quality (Partnership with Quality Assurance) • Post Development Review • Confirm Architecture • Modify Existing

29. Architecture Reviews • Meets Requirements for Application • Confirm technology or products meets the needs of the system of application • Meets Infrastructure Requirements • Confirm Architecture • Modify Existing • Meets Quality Requirements • Consistent with Enterprise Requirements

30. Tactical Benefits • Cost • Reuse of existing tools • Redeployment of development resources • Reduction of training costs • Quality • Engineering Personal Participate in Verification and Validation process. • End-To-End Quality is a team function.

31. Summary • A planned architecture will provide a framework to deal with organizational or product complexity • An effective architecture will enable the adoption of things not feasible today • A consistent architecture will ensure that applications possess qualities or characteristics such as a interoperability, evolvability, and understandability • A practiced architectural approach will reduce development, maintenance, and operating costs of system or applications.

32. Reference Architecture Teams: Malan, Bredemeyer The Role of the Architect : Malan, Bredemeyer [June 2000] The Software Architect’s Profession: Sewell and Sewell [2002] How to Lead, Follow, and Get Out of the Way: Malan, Bredemeyer, Branson [Enterprise Architecture Conference Boston, March 2001] US Department of Energy – Technology Architecture Perspective [January 2001] Software Architecture Documentation in Practice: Documenting Architectural Layers : Bachmann et al.