Architecture Review Processes

Architecture Review Processes

اسلاید 1: Architecture Review ProcessesArchitecture interaction in project oversight and execution.

اسلاید 2: What’s Architecture?DiagramsSystem InteractionsStakeholder rolesInformation managementData definitionsPurchased softwareInterfaces with other systemsLogical designNew SystemsLegacy SystemsTASDPurchasesIdentity ManagementNetwork Topology

اسلاید 3: ArchitectureThe fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.ISO/IEC 42010:2007A formal description of a system, or a detailed plan of the system at component level to guide its implementation.TOGAFThe structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. TOGAF

اسلاید 4: Things That Architects Don’t DoProcess compliance – that’s project officeEstimates – that’s service ownersHardware specifications – that’s EngineeringSoftware specifications – that’s DevelopersRequirement gathering – that’s Business AnalystsProcess description – that’s Business AnalystsWindows – that’s Building Maintenance

اسلاید 5: Things That Architects Can DoPlan technology direction and set technology standardsHelp you figure out which technologies you should support.Review plans, designs and purchasesAssess how well a plan aligns with current direction and desired future positions.Identify opportunities to reuse components and services.Leverage enterprise contracts and license agreements.Integrate shared services where they might be cost-effective.Review business organization and business processesTechnical Architecture: align your technology plan with enterprise goals, business plans and business processes. Enterprise Architecture: align your business plans, business process and technology plan with your enterprise goals.

اسلاید 6: Architecture ReviewsYou are about to sign off on the software architecture of a multimillion-dollar software-intensive system. What assurance do you have that the architectural decisions underpinning the design are the right ones to deliver a system that meets the required business goals? Source: Software Architecture Review: The State of Practice Muhammad Ali Babar, Lero—the Irish Software Engineering Research Centre Ian Gorton, Pacific Northwest National Laboratory computer COMPUTING PRACTICES Published by the IEEE Computer Society 0018-9162/09/$25.00 © 2009 IEEE

اسلاید 7: Architecture ReviewsHow sure are you that the project will not be delayed through downstream rework—or even fail—due to inappropriate architectural choices?Do you know whether all system stakeholders have confidence in the proposed solution? Are “best endeavors” a good enough basis for accepting an architectural design?Source: Software Architecture Review: The State of Practice Muhammad Ali Babar, Lero—the Irish Software Engineering Research Centre Ian Gorton, Pacific Northwest National Laboratory computer COMPUTING PRACTICES Published by the IEEE Computer Society 0018-9162/09/$25.00 © 2009 IEEE

اسلاید 8: Architecture ReviewsArchitecture reviews are an effective way of ensuring design quality and addressing architectural concerns. The principal objectives of a software architecture review are to assess an architecture’s ability to deliver a system capable of fulfilling the quality requirements and to identify potential risks.11. P. Clements, R. Kazman, and M. Klein, Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, 2002.Source: Software Architecture Review: The State of Practice Muhammad Ali Babar, Lero—the Irish Software Engineering Research Centre Ian Gorton, Pacific Northwest National Laboratory computer COMPUTING PRACTICES Published by the IEEE Computer Society 0018-9162/09/$25.00 © 2009 IEEE

اسلاید 9: Benefits of Architecture ReviewIdentifying potential risks in the proposed architecture (88%)Assessing quality attributes (for example, scalability, performance) (77%)Identifying opportunities for reuse of artifacts and components (72%)Promoting good architecture design and evaluation practices (64%)Reducing project cost caused by undetected design problems (63%)Capturing the rationale for important design decisions (59%)Uncovering problems and conflicts in requirements (59%)Conforming to organization’s quality assurance process (55%)Assisting stakeholders in negotiating conflicting requirements (43%)Partitioning architectural design responsibilities (40%)Identifying skills required to implement the proposed architecture (40%)Improving architecture documentation quality (40%)Facilitating clear articulation of nonfunctional requirements (31%)Opening new communication channels among stakeholders (31%)Survey of benefits perceived from systems architecture among 86 responding organizations, from Software Architecture Review: The State of Practice by Muhammad Ali Babar, Lero—the Irish Software Engineering Research Centre and Ian Gorton, Pacific Northwest National Laboratory, IEEE Computer July 2009 © IEEE 2009

اسلاید 10: Types of reviewProject process reviewsProject Initiation Review (Gate 1)Approve project goals, strategy, conceptIterative projects may propose how they will articulate architecture and designPlanning / Design Review (Gate 2)Approve project architecture, solution design, technology directionDo this each time architecture changesExecution / Build / Pilot Review (pre-release) (Gate 3)Approve architecture /design changes that may occur during E&BPurchase process reviewsPre-purchase Review (RFP, IFB)Ensure sensible technical language in requirementsPurchase Proposal Review (pre-award)Approve technology selections, architecture and strategy of proposal

اسلاید 11: Basic review flowSubmit documents (project team)Review documents (architect)If issues are found:Resolve issuesRe-submitIf issues are not resolved:Approve with issue or RejectIf rejected:Re-plan and resubmit or haltIf approved with issueTrack and resolve issue later on

اسلاید 12: Architecture Views and PerspectivesViewpointsFunctionalWhat does it need to do?InformationWhat goes in, comes out, and what do we keep?ConcurrencyHow do the parts work together, at the same time?DevelopmentHow will we produce the system?DeploymentHow will we deliver it?How will we retire the old system?OperationHow will we keep it going?When will we stop it?PerspectivesAccessibility and UsabilityWill people be able to use it?Availability and Resilience Will it work when it needs to?Regulation What are we required to do?SecurityAre we protecting it?Development Resource What will it take to do it?Evolution How will it grow and change?Location Where will we build it?Performance and Scalability Will it handle all the work?

اسلاید 13: Project Reviews are Unique EffortsWe do not specify a set of criteria that can be applied to any project, because the concerns and goals of each IT project are unique. We do follow a pattern and a set of guidelines that inform our review, and use experience-based reasoning to evaluate projects. This is reflective of the state of current architecture practice in the industry.“When asked about the nature of the architecture review process, 56 percent of respondents described their organization’s review process as informal, 41 percent reported a formal process in place, and 3 percent were not sure, as architecture review processes varied from project to project.”*“The two most common techniques applied to review an architecture are experience-based reasoning (83 percent) and prototyping (70 percent)”**From Software Architecture Review: The State of Practice by Muhammad Ali Babar, Lero—the Irish Software Engineering Research Centre and Ian Gorton, Pacific Northwest National Laboratory, IEEE Computer July 2009 © IEEE 2009

اسلاید 14: Better review flow for complex projectsEngage architects before the gate reviewInitiation discussions: determine strategy optionsEarly planning option: conceptual discussionsMid-planning option: design decision discussionsObtain guidance prior to reviewGet pre-reviews as effort is sunk in the TASD.Guide the design effort with the results of pre-reviews.Balance review frequency based on risk and remaining effort.Don’t arrive at the gate with a big gapClosing a gap between what you have and what’s required will take up time and effort.Discovering the gap at the gate extends the project.Small corrections during the development process makes a more manageable schedule and allows approval reviews to go faster, too.

اسلاید 15: Pipeline Vs BottleneckWork architecture activities into the project plan.Schedule time to pre-review and refine architecture.Balance work-at-risk with review effort and resources.Plan architecture updates into project change process.Arrive at gates ready-to-pass.Treat architecture activities as “externalities” to the plan.Assign architecture document production to non-technical contributors.Plan short reviews of documents that take a long time to write. Connect with the architecture group only at gate reviews.Blame the process for gate delays.Pipeline StrategiesBottleneckStrategiesPipeline strategies keep project progress flowing smoothly by planning for review. Bottleneck strategies ensure schedule overruns and risk re-work on design artifacts.

اسلاید 16: Minimum Review RequirementsGate 1PPM Project Info TabAgency Approval(Registration projects may have to deliver more information because this is the only review)Gate 2Complete TASD (all parts)Complete DesignComplete Execution PlanProcurement Plan (if applicable)Agency ApprovalGate 3Updated TASD and documents (all project changes reflected in documentation).Release planOperation planAgency ApprovalPre-purchaseCoherent requirementsArchitecture disclosure and conformance requiredPre-AwardCoherent and compliant proposal

اسلاید 17: Design ProcessBusiness RequirementConceptual ArchitectureLogical DesignImplementationArchitectureEngineeringPreliminary ArchitectureEngineeringDesignGate1Gate 2Gate 3

اسلاید 18: Architecture documentationPPM Project InformationEstablish project strategy, goals and scopeState assumptions and constraintsEstablish key deliverables and milestonesCollect project documents and design artifactsTechnical Architecture System Design TemplateFunctional Diagram & NarrativeConceptual Diagram, Narrative & ChecklistPreliminary Diagram, Narrative & ChecklistDetail Diagram, Narrative & ChecklistPurchasing PlanEstablish strategy and provide overview context for planned purchases

اسلاید 19: PPM and ArchitectureProject Info TabStakeholders, Contacts and DatesBusiness Case, Scope and GoalsStrategy for project executionAssumptions & ConstraintsIssues and Risks TabTrack issues that the team has surfacedTrack issues that Architects surfaceDocument ManagementCollect TASD, Procurement Plan, and other artifacts.

اسلاید 20:

اسلاید 21: TASD TemplateIt’s a templateIt’s the official document for communicating architecture, and the format has been formally approvedTake a uniform approach to presentation to reduce review durations, put any extra information at the end of a sectionFollow the structure and leave the section headers intact, don’t delete things or you’ll confuse the reviewerObtain information to answer the questions where it is applicable but unknownIt’s a template, not a final documentAdd diagrams or checklist sections that are useful to telling the architecture storyIf desired, add agency-specific or project-specific sections at the end of the document.Sample diagrams indicate the desired level of detail but are not intended to prescribe a formatFor very large or complex projects, alternative documents are possible, but they should be approved at initiation

اسلاید 22: TASD ContentThe checklists collect the most basic informationThey cover most of the important perspectives and points of view.They ensure the project team has considered some important design features.Architects can get a pretty good idea of a system by reading the checklist.Diagrams provide a roadmapRelationships and connectivity that are difficult to narrate can be drawn clearly.Diagrams should be specific to the project and reflect important design features.More than one diagram may be needed, particularly to represent different viewpoints, or dynamic aspects of the system.Narratives complete the pictureNot limited to the checklist topics, Narratives can fill in gaps in the TASD format.Narratives can tell a story about data flow, about business interactions, nonfunctional requirements, or about system relationships in more detail than a diagram can represent.Narratives can relate the decision process leading to design choices.

اسلاید 23: Architecture ResourcesOSCIO Architecture TeamProvide Statewide Architecture review and interpretation.Agency Architect or Technical OfficerSpecialize in agency technology and business applications.Formulate agency standards and practices.Project Analysts and Technical TeamBring expert knowledge about what the project intends to accomplish.Apply architecture standards to technical planning and implementation.Design software and other technical components to fit the architecture.

اسلاید 24: Avoiding Architecture RiskConsider the architecture documentation risky product, and plan benchmark reviews that balance the effort sunk versus effort remaining, and the risk of re-doing progress since the last benchmark. Don’t wait until the gate to start the TASD, nor to find out whether it’s deficient.Get a review of detailed architecture design before engineering the detail components.As PM or PMA, make sure that business analysts, architects and engineers all update their part of the architecture documentation when altering their detail designs.

اسلاید 25: Architecture Review ProcessesArchitecture interaction in project oversight and execution.

اسلاید 26: Architecture ReviewWe perform architecture reviews to ensure: The architecture of a system is documented.It provides a coherent description of the system.It is conformant to State and Agency principles, standards and plans.It is compatible with the legacy technical landscape.That the chosen technology and design is likely to achieve the project’s goals and objectives.

اسلاید 27: Office of the State CIO Strategic Planning OfficeArchitecture TeamDoug Banich 919-754-6210douglas.banich@its.nc.gov