contextually driven architecture reviews
play

Contextually Driven Architecture Reviews for PNSQC F. Michael - PowerPoint PPT Presentation

Contextually Driven Architecture Reviews for PNSQC F. Michael Dedolph fmdedolph@netscape.net October 18, 2010 Contextually Driven Architecture Reviews Dedolph 10/18/2010 1 Authors Note Presenters note: Most of this presentation


  1. Contextually Driven Architecture Reviews for PNSQC F. Michael Dedolph fmdedolph@netscape.net October 18, 2010 Contextually Driven Architecture Reviews – Dedolph – 10/18/2010 1

  2. Author’s Note Presenter’s note: Most of this presentation material was used at the SEI’s SATURN 2009 conference, and at the Washington DC Area SPIN meeting in Feb 2009. Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 2

  3. Architecture Reviews Start Additional topics: • How reviews can be institutionalized Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 3

  4. Getting Started - Concepts Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 4

  5. What is “Architecture”? > Before we can review it, we should know what “it” is. Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 5

  6. “A system architecture . . .” • Provides a solution to a problem for a client. – For early reviews, it is a conceptual or potential solution. • Architecture has been characterized as “design with constraints” – Alternatively, you could say architecture includes a design that works within the constraints – Constraints include cost and schedule! > Any given architecture is NOT the ONLY solution, but some solutions are “better” than others . Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 6

  7. Where Architecture Exists • Architecture exists at the intersection of management, technology, and design. – Management – cost, profitability, schedule, preserving legacy investments, marketability, minimum risk . . . – Technology – methods, materials, tools, approaches – Design – will need different views; lowest-level must be “buildable”; designs concepts often work in many domains Management Technology Design Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 7

  8. A Framework for Architecture Problem Statements • Architecture is the solution to a problem for a client. The problem space has multiple aspects. These aspects are borrowed from civil architecture: – Function – what it does, how well it does it. – Form – what it “looks like”; includes major environmental interfaces. Can be physical or logical form; for SW, includes things like protocols, languages, . . . – Economy – cost aspects, including development, maintenance cost, material cost, system retirement, etc. – Time – relationship to past, present, and future. An additional consideration can be: – Operational/ Developmental – Things that pertain to development constraints and system operating environment, rather than the system itself • FFET/O should – Provide the critical, discernible success criteria – Be expressed in sufficient detail to make judgments about the proposed solution, BUT, – Avoid being unnecessarily proscriptive (thou shalt not) or prescriptive (thou shalt) Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 8

  9. Classical Architecture - Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 9

  10. The Taj Majal Problem Statement Might Have Read Like This: The function of Taj Mahal is to provide a tomb for the Emperor and a monument to the Emperor’s departed wife. It must be so beautiful that people will travel to it from around the world to honor her memory, and know how much he cared for her. As a tomb for a Muslim Emperor and Empress, it must include a mosque on the grounds, and should provide a space for people to stay when they came to visit and marvel. The building form and materials will need to maintain symmetry, deal with the unprecedented weight of the structure, manage the shearing force of the nearby river on the foundations, avoid discoloration of the stone and fading of paint, and maintain visual perspective. A verse from the Koran will frame the main arch, and must appear to be written in the same size letters from the ground. Economy is unimportant. It will cost whatever it costs, and take as long as it takes. Up to 10,000 people can work on the Project, for as long as it takes. The structure is to last for all time . So the foundation must stand, and discoloration of the stone or fading of paint seen in previous palaces is unacceptable. Construction will take as long as it takes (work started around 1632 and was completed around 1653.) Operationally , there is insufficient expertise in the kingdom to build this. So the best Hindu and Persian architects will work together on the Project, and will hire anyone they need. Since some of the materials needed to meet the form constraints are heavy, a road will need to be built to transport them. Some valuable materials are needed that are only available in China, so reliable ordering and transportation must be arranged. Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 10

  11. Problem Statements Are the basis for the review. Provide a succinct summary of critical success criteria – Short: 2 pages is good – Includes major constraints – Client-centric – Cover Function, Form, Economy, Time, and (optionally) Operational – Be expressed in sufficient detail to make judgments about the proposed solution , but are not unnecessarily proscriptive of prescriptive Problem Statements Are NOT – A requirements document, but may summarize the most critical high level requirements Problem statements also have unstated "always" criteria, e.g.,: – Possible to construct – Can make money/ will provide value – Solution won't result in harm – Legal Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 11

  12. The Architecture Review Problem Statement • The review method should increase the probability of success for the Project (function) by addressing FFET/O aspects of the system being reviewed (form). Findings generated by the review need to be unbiased, independent, and relevant for both management and technical staff (function). The findings must be complete enough to alert management to high-risk issues (function), but also framed in a way that promotes project level “buy-in” for resolving the issues (operational, functional, form.) • The method should consider design, technology, and management constraints (form, operational), be representationally independent (form), and flexible enough to work in multiple domains (form, function). • The reviews must be cost effective (economy), and whenever possible, they should leverage existing expertise within the company (economy). • The review method should work at any point in the lifecycle, but, in particular, support early reviews (time, form). 90% or more of the reviews will be conducted in 3 days or less by a small, in-house team of 3-10 people (time, economy). Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 12

  13. Fundamental Architecture Review Method In a nutshell: • Define the problem the client wants solved • Compare it to the architecture (proposed solution) • Identify the gaps (or risks) After: •Let the project resolve the gaps . Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 13

  14. Architecture Review Questions > Question to answer before a review: – Who decides? (Know the client) – What problem are we trying to solve? – Are key stakeholder interests represented? > Questions to answer during a review: – How good is the proposed solution? – What are the issues/ risks/ gaps in the solution? > Questions to answer after a review: – Which things will we address? – How will we address them ? Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 14

  15. How to Conduct an Architecture Review Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 15

  16. Review Ground Rules • Ground rules are covered in the pre-review, and again at the start of the review meeting. –No attribution—review products, processes, and ideas, not people. Frame issues and observations in terms of the product architecture and the problem it is intended to solve, not the presenter or architect • Do no harm: “Help ever, hurt never” –Team is there to identify, not solve problems • If you must, write an observation/suggestion card –Client requests (and pays) for the review, but , the project owns the findings and responsibility for correcting them • One exception, the “management alert”, covered later –Ask questions at any time. (The speaker may defer the answer.) –Write any notes, questions or thoughts you have on index cards. –At the end of the presentation, review the index cards to make sure your questions got answered. • If not, make sure to record it as an issue. Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 16

  17. Review Steps (list) • Preparation 1. Respond to initial contact/request 2. Develop problem statement 3. Select team and develop agenda based on the problem statement 4. Arrange logistics – travel, space, phones, connectivity, etc. 5. Hold pre-review call • Review Meeting 1. Review Project presentations , with Q&A 2. Hold Review Team Caucus 3. Conduct Readout 4. Hold Sponsor/Client meeting (optional) • Follow-up 1. Write and distribute the Review Report 2. Present findings to lessons learned/review process governing groups ( Board Report ) 3. Review the Project’s action plans 4. Close the review by meeting with project and/or sponsor Contextually Driven Architecture Reviews – Dedolph – 5/7/2009 17

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend