SEng 5861: Software Architecture

1. SEng 5861: Software Architecture Lecture 2 Dr. Michael Whalen Fall 2010 SEng 5861 - Mike Whalen

2. Topics for Today • Questions / Comments from Last Week • Project Presentations • Architecture Definition & Scope • The Airport Parking Example • Stakeholders • Scenarios SEng 5861 - Mike Whalen

3. ProjectPresentations SEng 5861 - Mike Whalen

4. People skills are important You must earn and maintain the confidence of all of your stakeholders from senior management and users to developers, third parties, and operational staff • Often, your interactions with stakeholders are through presentations • Management: proposals, progress reports • Technical team meetings • You will be judged on the quality of the presentation • Knowing your audience is important • Being able to concisely summarize why they should care in a short presentation is critically important. SEng 5861 - Mike Whalen

5. Architecture Presentations • Two team presentations during the semester • One 10 minute project proposal • One 20 minute technical talk • Presentations should be formatted differently for different audiences • Every group member should be involved (speak) in at least one of the talks SEng 5861 - Mike Whalen

6. Project Proposal Presentation • Audience: management • I’ll pretend to be management • Topic: funding / staffing to create or extend the system that you are studying for your project • Two choices: • Pitch for the “baseline” system • assume it hasn’t been built yet • Pitch the extension / modification that you are proposing • This may not be possible if you don’t yet know what you want to do. • Purpose: persuasion • Why is this system unique / useful? • When will it be delivered? • How much will it cost? • Why are you a credible architect? SEng 5861 - Mike Whalen

7. Project Proposal Presentation • Time: 10 minutes • Expect interruptions! • Plan on 5-6 minutes of material • But be able to talk for 10 minutes • Have (at most) 3-4 slides that you expect to use • Good idea to have backup slides to handle pointed questions SEng 5861 - Mike Whalen

8. Technical Presentation • Describe your proposed extension • Present one or both of the viewpoints in your architecture document • Audience: technical stakeholders • Depends on viewpoint(s) chosen • Entire class will act as your stakeholders • Purpose: convey information • Provide technical overview of original model and your change to it • Persuade users that it is the right solution SEng 5861 - Mike Whalen

9. Technical Presentation • Time: 20 minutes • Should be enough time to give flavor of architecture • Show some deep technical knowledge • Expect technical questions • Answer questions related to comparison of alternatives SEng 5861 - Mike Whalen

10. Architecture definition SEng 5861 - Mike Whalen

11. What is the architecture definition process? SEng 5861 - Mike Whalen

12. Architecture Definition Process • Recall the definition of software architecture: • Architecture definition is the process of discovery of these components, relationships, and principles. Software architecture is the fundamental organization of a system, embodied in its components, their relationships to one another and the environment, and the principles governing its design and evolution. SEng 5861 - Mike Whalen

13. Hospital Food Example (from previous lecture) Physical World Network View Delivery truck Hospital Clinic SEng 5861 - Mike Whalen

14. Hospital Food Example • What did we do? • Asked stakeholders about expected behavior • Looked at system infrastructure • Looked at scope of system • Rapid cycling between the activities SEng 5861 - Mike Whalen

15. Hospital Food Example • Many ideas in solution space • Delivery drivers • VPNs, Card readers, firewalls • These ideas constrain the requirements space • If delivery guy picks up food orders, patients have to choose meals earlier • If we use delivery truck vs. car, we have to batch up meals • Claim: it is a mistake to consider requirements without also working in the solution space SEng 5861 - Mike Whalen

16. Hospital Food Example • However, careful examination of infrastructure is key • This can be physical things (delivery trucks) • Existing software base • Available language, library or OS support • 3rd party solutions • In this example, we were able to implement the system meeting the requirements with no new software • Claim: At this level, we are trying to define the interfaces and constrain the range of solutions, not write code • We are defining the architecture SEng 5861 - Mike Whalen

17. When do you define the architecture? SEng 5861 - Mike Whalen

18. Three Peaks Model SEng 5861 - Mike Whalen

19. Architecture Definition Process SEng 5861 - Mike Whalen

20. Architecture Definition Process Do we really define scope before engaging the stakeholders? How do we know the scope before we know the stakeholder concerns? SEng 5861 - Mike Whalen

21. Architecture Definition Did we do all of these things when we worked on the Hospital Food Example last week? These activities should be a checklist rather than a prescription SEng 5861 - Mike Whalen

22. System Context SEng 5861 - Mike Whalen

23. System Context in Architecture Definition You are HERE SEng 5861 - Mike Whalen

24. Architectural Scope • What does your system do and what is its environment? • Broad functional areas • External interfaces • Systems to be decommissioned or modified • Data to be migrated onto the new system • It should be brief and formally adopted by stakeholders • Often represented by a context diagram SEng 5861 - Mike Whalen

25. Example: Clothing Retailer HBQ SEng 5861 - Mike Whalen

26. HBQ Web Site • A clothing retailer decides to start selling its products over the Internet. The new Web site will include a detailed online catalog (drawn from an existing product database) with facilities for order acceptance, tracking, and fulfillment (i.e. shipping out the ordered products). The system should display approximate stock levels and automatically back-order out-of-stock goods. The retailer’s large database of customers who order products over the telephone must integrate smoothly with the Web site. • The system needs to interact with a number of entities and systems, including: • Customers accessing the Web site over the Internet • The retailer’s existing product database • The retailer’s existing customer database • External systems for validating credit card details and submitting payments • The retailer’s accounts system • The retailer’s warehouse management system • An external product distribution system SEng 5861 - Mike Whalen

27. HBQ Web Context Diagram SEng 5861 - Mike Whalen

28. System Context in Architecture Definition You are HERE SEng 5861 - Mike Whalen

29. Architectural Concerns Concerns: any desire of a stakeholder With respect to the system Requirements: Specific, Unambiguous, Measurable SEng 5861 - Mike Whalen

30. Architectural Concerns Concerns: any desire of a stakeholder With respect to the system Architectural Goals: the “non-requirements” that are left. Requirements: Specific, Unambiguous, Measurable SEng 5861 - Mike Whalen

31. HBQ Architectural Concerns • The values, ethos, and reputation of the retailer must be reflected in the appearance and operation of the online store and its supporting processes • At all times, the Web site should try to present a “human” face to the customer (even those portions of it that are fully automated) • The online store must be easy to use by customers who have limited experience with computers and e-commerce • The online store must be responsive (quick to load and respond to customer actions) whether or not the customer has a fast Internet connection • The online store must cover all aspects of the shopping experience, including an up-to-date, browseable catalog; a secure online purchasing system; order tracking; and returns handling. SEng 5861 - Mike Whalen

32. Requirements • Split into • Functional requirements • Non-functional (architectural) requirements • We have studied this before in 5801 • Review your notes from this class for more information • I will assume you know how to do this SEng 5861 - Mike Whalen

33. Goals • Goal Characteristics: • Imprecise: often the stakeholders may not really be clear on what they mean • Unlikely to be quantifiable or measurable in any useful way, so there is no objective criteria for judging whether or not the goal has been met. It all comes down to gut feelings and subjective assessments of the stakeholders • Usually has a strong business focus, and it is often unclear how this translates into an architectural solution. • Can we ignore them? No. • Often what is important about the system to be built is not easily quantified. SEng 5861 - Mike Whalen

34. Importance of Goals Vs. http://forums.macrumors.com/showthread.php?t=500 SEng 5861 - Mike Whalen

35. What do we do with goals? • Try to turn them into requirements • System should be responsive  quantifiable requirements related to response time, throughput, capacity, etc. • System should be easy to use  Requirements such as: XX% of users who are ‘unfamiliar with e-commerce’ should be able to complete a transaction within YYY time. • Develop architectural principles that translate goals into physical features and qualities of your architecture. • System should be easy to use  common look and feel requirements and error handling, shared processes for automated and manual systems. • Manage expectations! SEng 5861 - Mike Whalen

36. Architectural Principles • A principle is a “meta-concern” for a set of related architectures • Principles often occur when viewing architectures at different levels of business hierarchy An architectural principle is the fundamental statement of belief, approach, or intent that guides the definition of an architecture. SEng 5861 - Mike Whalen

37. Architectural Principles • Switch to wicsa2009-design-principles.pdf SEng 5861 - Mike Whalen

38. Scope Checklist • Are you clear about the fundamental business goals and drivers that have caused the key stakeholders to initiate the project? • Is the scope of the system under consideration clearly and adequately defined? • Has this scope been reviewed, agreed on, and signed off by relevant stakeholders, including at a minimum the aquirers/sponsors and users? • Is the scope specified at an appropriate level of detail, balancing brevity with clarity and completeness? • Is the scope definition internally consistent? • Does the scope include a definition of the system’s functional areas, its external interfaces, details of data to be migrated, and details of other systems to be decommissioned? • Does the scope identify any important technology constraints, such as mandated platforms? • Have you omitted from the scope definition any “obvious” statements that should have been explicitly stated? • Have you consulted all stakeholders who may be able to mandate or suggest important business and technology standards, policies, and guidelines? • Have you documented all concerns using simple, clear language that stakeholders can understand? • Are all principles supported by rationales and implications? Do these ultimately tie back (via rationales) to business goals and forward (via implications) to architectural decisions? • Have you taken into account the relevant organizational standards, policies, and procedures? • Have the stakeholders reviewed and ratified your concerns and principles? SEng 5861 - Mike Whalen

39. Airport parking example SEng 5861 - Mike Whalen

40. Airport Parking Controller • You are asked to build the automated parking system at MSP airport • Support ePark: • Also support ticketed parking: user receives a ticket and pays either by credit card or cash Simply insert your credit or debit card into the card reader at the ramp entrance. This will record the time you entered airport parking. Use the same credit or debit card to pay at an ePark® exit lane. The system is fully automated; there is no waiting in line for a cashier. SEng 5861 - Mike Whalen

41. Airport Parking Controller • Basic functionality: users should be able to: • Enter the parking lot if space is available • Either via ticket or credit card • Exit the parking lot at any time • Pay either via cash or credit card • But there is much more to it! • What if user uses different credit card to enter/exit? • What if there are insufficient funds? • What if I am unable to reach VISA server? • Etc. etc. etc. SEng 5861 - Mike Whalen

42. How would you architect this? • Who are the stakeholders? • What questions should you ask them? • What information is missing? • What is the context? • physical devices? • stakeholders? • MSP airport software systems? • External software systems? • What are architectural concerns? • Use Chapters 8, 9 checklists to check your work SEng 5861 - Mike Whalen

43. What did we come up with? SEng 5861 - Mike Whalen

44. Stakeholders SEng 5861 - Mike Whalen

45. Stakeholders in Architecture Definition You are HERE SEng 5861 - Mike Whalen

46. Stakeholders Ops manager: How do I back up system data for disaster recovery? Security and compliance: How data is logically and physically secured? User: How is this going to make my life better? Developer: What are the system interfaces I need to respect? Management: What is the business case for the system? How much will it cost? SEng 5861 - Mike Whalen

47. Stakeholders A Stakeholder in an organization is a person, group, or entity with an interest in or concerns about the realization of an architecture • Correctly identifying stakeholders and gaining their commitment is key to your success • Cast the net widely early in the project • Draw up and maintain a list of known and potential stakeholders • May need proxy stakeholders who act in the interest of future stakeholders SEng 5861 - Mike Whalen

48. Classes of Stakeholders • Aquirersoversee the procurement of the system or product • Assessors oversee the system’s conformance to standards and legal regulation • Communicators explain the system to other stakeholders via documentation and training materials • Developers construct and deploy the system from specifications • Maintainers manage the evolution of the system once it is operational • Suppliers build and/or supply the hardware, software, or infrastructure on which the system will run • Support staff provide support to users for the product or system when it is running • System Administrators run the system once it has been deployed • Testers test the system to ensure that it is suitable for use • Users use the software. SEng 5861 - Mike Whalen

49. Effective Stakeholders Are: • Informed so that they can make good decisions • Committed to making themselves available and to make hard choices • Authorized to make decisions for the group that they represent • Representative of their group to present the group’s concerns accurately SEng 5861 - Mike Whalen

50. Mapping Views to Stakeholders • Views are supposedly for stakeholders… • Which ones? You tell me. • Aquirers • Assessors • Communicators • Developers • Maintainers • Suppliers • Support staff • System Administrators • Testers • Users SEng 5861 - Mike Whalen