architecture review processes

8/6/2019 Architecture Review Processes

1/27

Architecture ReviewArchitecture Review

ProcessesProcessesArchitecture interaction in projectArchitecture interaction in project

oversight and execution.oversight and execution.


2/27

Whats Architecture?Whats Architecture?


3/27

ArchitectureArchitecture

The fundamental organization of a system, embodied inThe fundamental organization of a system, embodied inits components, their relationships to each other andits components, their relationships to each other andthe environment, and the principles governing itsthe environment, and the principles governing itsdesign and evolution.design and evolution. ISO/IEC 42010:2007ISO/IEC 42010:2007

A formal description of a system, or a detailed plan ofA formal description of a system, or a detailed plan ofthe system at component level to guide itsthe system at component level to guide itsimplementation.implementation. TOGAFTOGAF

The structure of components, their interThe structure of components, their inter--relationships,relationships,and the principles and guidelines governing their designand the principles and guidelines governing their designand evolution over time.and evolution over time. TOGAFTOGAF


4/27

ThingsThat Architects Dont DoThingsThat Architects Dont Do

Process complianceProcess compliance thats project officethats project office

EstimatesEstimates thats service ownersthats service owners

Hardware specificationsHardware specifications thats Engineeringthats Engineering Software specificationsSoftware specifications thats Developersthats Developers

Requirement gatheringRequirement gathering thats Businessthats Business

AnalystsAnalysts Process descriptionProcess description thats Business Analyststhats Business Analysts

WindowsWindows thats Building Maintenancethats Building Maintenance


5/27

ThingsThat Architects Can DoThingsThat Architects Can Do

Plan technology direction and set technology standardsPlan technology direction and set technology standards Help you figure out which technologies you should support.Help you figure out which technologies you should support.

Review plans, designs and purchasesReview plans, designs and purchases Assess how well a plan aligns with current direction and desired futureAssess how well a plan aligns with current direction and desired future

positions.positions.

Identify opportunities to reuse components and services.Identify opportunities to reuse components and services. Leverage enterprise contracts and license agreements.Leverage enterprise contracts and license agreements.

Integrate shared services where they might be costIntegrate shared services where they might be cost--effective.effective.

Review business organization and business processesReview business organization and business processes Technical Architecture: align your technology plan with enterprise goals,Technical Architecture: align your technology plan with enterprise goals,

business plans and business processes.business plans and business processes.

Enterprise Architecture: align your business plans, business process andEnterprise Architecture: align your business plans, business process andtechnology plan with your enterprise goals.technology plan with your enterprise goals.


6/27

Architecture ReviewsArchitecture Reviews

You are about to sign off on the software architectureYou are about to sign off on the software architectureof a multimillionof a multimillion--dollar softwaredollar software--intensive system.intensive system.

What assurance do you have that the architecturalWhat assurance do you have that the architecturaldecisions underpinning the design are the right ones todecisions underpinning the design are the right ones todeliver a system that meets the required business goals?deliver a system that meets the required business goals?

Source: Software Architecture Review: The State ofPractice Muhammad Ali Babar, LeroSource: Software Architecture Review: The State ofPractice Muhammad Ali Babar, Lerothe Irish Software Engineering Research Centhe Irish Software Engineering Research Centre Ian Gorton, Pacifictre Ian Gorton, PacificNorthwest National Laboratory computer COMPUTING PRACTICES Published by the IEEE Computer Society 0018Northwest National Laboratory computer COMPUTING PRACTICES Published by the IEEE Computer Society 0018--9162/09/$25.00 2009 IEE9162/09/$25.00 2009 IEEEE


7/27


How sure are you that the project will not beHow sure are you that the project will not be

delayed through downstream reworkdelayed through downstream reworkor evenor even

failfaildue to inappropriate architectural choices?due to inappropriate architectural choices? Do you know whether all system stakeholdersDo you know whether all system stakeholders

have confidence in the proposed solution?have confidence in the proposed solution?

Are best endeavors a good enough basis forAre best endeavors a good enough basis foraccepting an architectural design?accepting an architectural design?

Source: Software Architecture Review: The State ofPractice Muhammad Ali Babar, LeroSource: Software Architecture Review: The State ofPractice Muhammad Ali Babar, Lerothe Irish Software Engineering Researchthe Irish Software Engineering ResearchCentre Ian Gorton, Pacific Northwest National Laboratory computer COMPUTING PRACTICESPublished by the IEEECentre Ian Gorton, Pacific Northwest National Laboratory computer COMPUTING PRACTICESPublished by the IEEEComputer Society 0018Computer Society 0018--9162/09/$25.00 2009 IEEE9162/09/$25.00 2009 IEEE


8/27


Architecture reviews are an effective way of ensuringArchitecture reviews are an effective way of ensuringdesign quality and addressing architectural concerns.design quality and addressing architectural concerns.

The principal objectives of a software architectureThe principal objectives of a software architecture

review are to assess an architectures ability to deliver areview are to assess an architectures ability to deliver asystem capable of fulfilling the quality requirements andsystem capable of fulfilling the quality requirements andto identify potential risks.to identify potential risks.11

1.1. P. Clements, R. Kazman, and M. Klein, Evaluating Software Architectures: Methods and Case Studies, Addison

P. Clements, R. Kazman, and M. Klein, Evaluating Software Architectures: Methods and Case Studies, Addison--Wesley, 2002.Wesley, 2002.

Source: Software Architecture Review: The State ofPractice Muhammad Ali Babar, LeroSource: Software Architecture Review: The State ofPractice Muhammad Ali Babar, Lerothe Irish Software Engineering Research Centhe Irish Software Engineering Research Centre Ian Gorton, Pacifictre Ian Gorton, PacificNorthwest National Laboratory computer COMPUTING PRACTICES Published by the IEEE Computer Society 0018Northwest National Laboratory computer COMPUTING PRACTICES Published by the IEEE Computer Society 0018--9162/09/$25.00 2009 IEE9162/09/$25.00 2009 IEEEE


9/27

Benefits of Architecture ReviewBenefits of Architecture Review Identifying potential risks in the proposed architecture (88%)Identifying potential risks in the proposed architecture (88%) Assessing quality attributes (for example, scalability, performance) (77%)Assessing quality attributes (for example, scalability, performance) (77%) Identifying opportunities for reuse of artifacts and components (72%)Identifying opportunities for reuse of artifacts and components (72%) Promoting good architecture design and evaluation practices (64%)Promoting good architecture design and evaluation practices (64%) Reducing project cost caused by undetected design problems (63%)Reducing project cost caused by undetected design problems (63%)

Capturing the rationale for important design decisions (59%)Capturing the rationale for important design decisions (59%) Uncovering problems and conflicts in requirements (59%)Uncovering problems and conflicts in requirements (59%) Conforming to organizations quality assurance process (55%)Conforming to organizations quality assurance process (55%) Assisting stakeholders in negotiating conflicting requirements (43%)Assisting stakeholders in negotiating conflicting requirements (43%) Partitioning architectural design responsibilities (40%)Partitioning architectural design responsibilities (40%) Identifying skills required to implement the proposed architecture (40%)Identifying skills required to implement the proposed architecture (40%) Improving architecture documentation quality (40%)Improving architecture documentation quality (40%) Facilitating clear articulation of nonfunctional requirements (31%)Facilitating clear articulation of nonfunctional requirements (31%) Opening new communication channels among stakeholders (31%)Opening new communication channels among stakeholders (31%)

Survey of benefits perceived from systems architecture among 86 responding organizations, fromSurvey of benefits perceived from systems architecture among 86 responding organizations, from Software Architecture Review: The State of Practice bySoftware Architecture Review: The State of Practice byMuhammad AliMuhammad AliBabar,Babar, LeroLerothe Irish Software Engineering Research Centre andthe Irish Software Engineering Research Centre andIan Gorton,Ian Gorton, Pacific Northwest National Laboratory, IEEE Computer July 2009 IEEE 2009Pacific Northwest National Laboratory, IEEE Computer July 2009 IEEE 2009


10/27

Types of reviewTypes of review

Project process reviewsProject process reviews Project Initiation Review (Gate 1)Project Initiation Review (Gate 1)

Approve project goals, strategy, conceptApprove project goals, strategy, concept

Iterative projects may propose how they will articulate architecture and designIterative projects may propose how they will articulate architecture and design

Planning / Design Review (Gate 2)Planning / Design Review (Gate 2) Approve project architecture, solution design, technology directionApprove project architecture, solution design, technology direction

Do this each time architecture changesDo this each time architecture changes

Execution / Build / Pilot Review (preExecution / Build / Pilot Review (pre--release) (Gate 3)release) (Gate 3) Approve architecture /design changes that may occur during E&BApprove architecture /design changes that may occur during E&B

Purchase process reviewsPurchase process reviews

PrePre--purchase Review (RFP, IFB)purchase Review (RFP, IFB) Ensure sensible technical language in requirementsEnsure sensible technical language in requirements

Purchase Proposal Review (prePurchase Proposal Review (pre--award)award) Approve technology selections, architecture and strategy of proposalApprove technology selections, architecture and strategy of proposal


11/27

Basic review flowBasic review flow

Submit documents (project team)Submit documents (project team)

Review documents (architect)Review documents (architect)

If issues are found:If issues are found:

Resolve issuesResolve issues ReRe--submitsubmit

If issues are not resolved:If issues are not resolved: Approve with issue or RejectApprove with issue or Reject

If rejected:If rejected:

ReRe--plan and resubmit or haltplan and resubmit or halt If approved with issueIf approved with issue

Track and resolve issue later onTrack and resolve issue later on


12/27

Architecture Views and PerspectivesArchitecture Views and Perspectives

ViewpointsViewpoints FunctionalFunctional

What does it need to do?What does it need to do?

InformationInformation What goes in, comes out, and what doWhat goes in, comes out, and what do

we keep?we keep?

ConcurrencyConcurrency How do the parts work together, at theHow do the parts work together, at the

same time?same time?

DevelopmentDevelopment How will we produce the system?How will we produce the system?

DeploymentDeployment

How will we deliver it?How will we deliver it? How will we retire the old system?How will we retire the old system?

OperationOperation How will we keep it going?How will we keep it going?

When will we stop it?When will we stop it?

PerspectivesPerspectives Accessibility and UsabilityAccessibility and Usability

Will people be able to use it?Will people be able to use it?

Availability and ResilienceAvailability and Resilience Will it work when it needs to?Will it work when it needs to?

RegulationRegulation What are we required to do?What are we required to do?

SecuritySecurity Are we protecting it?Are we protecting it?

Development ResourceDevelopment Resource What will it take to do it?What will it take to do it?

EvolutionEvolution How will it grow and change?How will it grow and change?

LocationLocation Where will we build it?Where will we build it?

Performance and ScalabilityPerformance and Scalability Will it handle all the work?Will it handle all the work?


13/27

Project Reviews are Unique EffortsProject Reviews are Unique Efforts

We do not specify a set of criteria that can be applied to anyproject, because the concerns and goals of each IT project areunique.

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 organizations review process as informal, 41 percentreported 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*From Software Architecture Review: The State of Practice bySoftware Architecture Review: The State of Practice byMuhammad Ali Babar,Muhammad Ali Babar, LeroLerothe Irish Software Engineering Research Centre andthe Irish Software Engineering Research Centre andIan Gorton,Ian Gorton, Pacific Northwest National Laboratory, IEEE Computer July 2009 IEEE 2009Pacific Northwest National Laboratory, IEEE Computer July 2009 IEEE 2009


14/27

Better review flow for complexBetter review flow for complex

projectsprojects Engage architects before the gate reviewEngage architects before the gate review

Initiation discussions:Initiation discussions: determine strategy optionsdetermine strategy options Early planning option: conceptual discussionsEarly planning option: conceptual discussions

MidMid--planning option: design decision discussionsplanning option: design decision discussions

Obtain guidance prior to reviewObtain guidance prior to review Get preGet pre--reviews as effort is sunk in the TASD.reviews as effort is sunk in the TASD. Guide the design effort with the results of preGuide the design effort with the results of pre--reviews.reviews. Balance review frequency based on risk and remainingBalance review frequency based on risk and remaining

effort.effort.

Dont arrive at the gate with a big gapDont arrive at the gate with a big gap Closing a gap between what you have and whats requiredClosing a gap between what you have and whats required

will take up time and effort.will take up time and effort. Discovering the gapDiscovering the gap at the gateat the gateextends the project.extends the project.

Small corrections during the development process makesSmall corrections during the development process makesa more manageable schedule and allows approval reviewsa more manageable schedule and allows approval reviewsto go faster, too.to go faster, too.


15/27

Pipeline Vs BottleneckPipeline Vs Bottleneck

Work architecture activities intoWork architecture activities into

the project plan.the project plan. Schedule time to preSchedule time to pre--review andreview and

refine architecture.refine architecture.

Balance workBalance work--atat--risk with reviewrisk with revieweffort and resources.effort and resources.

Plan architecture updates intoPlan architecture updates into

project change process.project change process. Arrive at gates readyArrive at gates ready--toto--pass.pass.

Treat architecture activities asTreat architecture activities as

externalities to the plan.externalities to the plan. Assign architecture documentAssign architecture document

production to nonproduction to non--technicaltechnicalcontributors.contributors.

Plan short reviews of documentsPlan short reviews of documentsthat take a long time to write.that take a long time to write.

Connect with the architectureConnect with the architecturegroup only at gate reviews.group only at gate reviews.

Blame the process for gate delays.Blame the process for gate delays.

Pipeline Strategies Bottleneck Strategies

Pipeline strategies keep project progress flowing smoothly by planning for review.

Bottleneck strategies ensure schedule overruns and risk re-work on design artifacts.


16/27

Minimum Review RequirementsMinimum Review Requirements

Gate 1Gate 1 PPM Project Info TabPPM Project Info Tab Agency ApprovalAgency Approval (Registration projects may have to deliver more(Registration projects may have to deliver more

information because this is the only review)information because this is the only review)

Gate 2Gate 2 Complete TASD (all parts)Complete TASD (all parts) Complete DesignComplete Design Complete Execution PlanComplete Execution Plan Procurement Plan (ifProcurement Plan (if

applicable)applicable) Agency ApprovalAgency Approval

Gate 3Gate 3 Updated TASD andUpdated TASD and

documents (all project changesdocuments (all project changesreflected in documentation).reflected in documentation).

Release planRelease plan Operation planOperation plan Agency ApprovalAgency Approval

PrePre--purchasepurchase Coherent requirementsCoherent requirements Architecture disclosure andArchitecture disclosure and

conformance requiredconformance required PrePre--AwardAward

Coherent and compliantCoherent and compliantproposalproposal


17/27

Design ProcessDesign Process

Business

RequirementConceptual Architecture

Logical Design

Implementation

Architecture

Engineering

Preliminary Architecture

Engineering

Design

Gate1

Gate 2

Gate 3


18/27

Architecture documentationArchitecture documentation

PPM Project InformationPPM Project Information Establish project strategy, goals and scopeEstablish project strategy, goals and scope

State assumptions and constraintsState assumptions and constraints

Establish key deliverables and milestonesEstablish key deliverables and milestones

Collect project documents and design artifactsCollect project documents and design artifacts

Technical Architecture System Design TemplateTechnical Architecture System Design Template Functional Diagram & NarrativeFunctional Diagram & Narrative

Conceptual Diagram, Narrative & ChecklistConceptual Diagram, Narrative & Checklist

Preliminary Diagram, Narrative & ChecklistPreliminary Diagram, Narrative & Checklist

Detail Diagram, Narrative & ChecklistDetail Diagram, Narrative & Checklist

PurchasingPlanPurchasingPlan Establish strategy and provide overview context for plannedEstablish strategy and provide overview context for planned

purchasespurchases


19/27

PPM and ArchitecturePPM and Architecture

Project Info TabProject Info Tab Stakeholders, Contacts and DatesStakeholders, Contacts and Dates

Business Case, Scope and GoalsBusiness Case, Scope and Goals

Strategy for project executionStrategy for project execution Assumptions & ConstraintsAssumptions & Constraints

Issues and Risks TabIssues and Risks Tab Track issues that the team has surfacedTrack issues that the team has surfaced

Track issues that Architects surfaceTrack issues that Architects surface Document ManagementDocument Management

Collect TASD, Procurement Plan, and other artifacts.Collect TASD, Procurement Plan, and other artifacts.


20/27


21/27

TASDTemplateTASDTemplate

Its a templateIts a template Its the official document for communicating architecture, and the format hasIts the official document for communicating architecture, and the format has

been formally approvedbeen formally approved

Take a uniform approach to presentation to reduce review durations, put anyTake a uniform approach to presentation to reduce review durations, put anyextra information at the end of a sectionextra information at the end of a section

Follow the structure and leave the section headers intact, dont delete things orFollow the structure and leave the section headers intact, dont delete things oryoull confuse the revieweryoull confuse the reviewer

Obtain information to answer the questions where it is applicable but unknownObtain information to answer the questions where it is applicable but unknown

Its a template, not a final documentIts a template, not a final document Add diagrams or checklist sections that are useful to telling the architecture storyAdd diagrams or checklist sections that are useful to telling the architecture story

If desired, add agencyIf desired, add agency--specific or projectspecific or project--specific sections at the end of thespecific sections at the end of thedocument.document.

Sample diagrams indicate the desired level of detail but are not intended toSample diagrams indicate the desired level of detail but are not intended toprescribe a formatprescribe a format

For very large or complex projects, alternative documents are possible, but theyFor very large or complex projects, alternative documents are possible, but theyshould be approved at initiationshould be approved at initiation


22/27

TASD ContentTASD Content

The checklists collect the most basic informationThe checklists collect the most basic information They cover most of the important perspectives and points of view.They cover most of the important perspectives and points of view. They ensure the project team has considered some important design features.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.Architects can get a pretty good idea of a system by reading the checklist.

Diagrams provide a roadmapDiagrams provide a roadmap Relationships and connectivity that are difficult to narrate can be drawn clearly.Relationships and connectivity that are difficult to narrate can be drawn clearly. Diagrams should be specific to the project and reflect important design features.Diagrams should be specific to the project and reflect important design features. More than one diagram may be needed, particularly to represent differentMore than one diagram may be needed, particularly to represent different

viewpoints, or dynamic aspects of the system.viewpoints, or dynamic aspects of the system.

Narratives complete the pictureNarratives complete the picture Not limited to the checklist topics, Narratives can fill in gaps in the TASD format.Not 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,Narratives can tell a story about data flow, about business interactions,nonfunctional requirements, or about system relationships in more detail than anonfunctional requirements, or about system relationships in more detail than adiagram can represent.diagram can represent.

Narratives can relate the decision process leading to design choices.Narratives can relate the decision process leading to design choices.


23/27

Architecture ResourcesArchitecture Resources

OSCIO Architecture TeamOSCIO Architecture Team Provide Statewide Architecture review and interpretation.Provide Statewide Architecture review and interpretation.

Agency Architect or Technical OfficerAgency Architect or Technical Officer

Specialize in agency technology and business applications.Specialize in agency technology and business applications. Formulate agency standards and practices.Formulate agency standards and practices.

Project Analysts and Technical TeamProject Analysts and Technical Team Bring expert knowledge about what the project intends toBring expert knowledge about what the project intends to

accomplish.accomplish.

Apply architecture standards to technical planning andApply architecture standards to technical planning andimplementation.implementation.

Design software and other technical components to fit theDesign software and other technical components to fit thearchitecture.architecture.


24/27

Avoiding Architecture RiskAvoiding Architecture Risk

Consider the architecture documentation risky product,Consider the architecture documentation risky product,and plan benchmark reviews that balance the effortand plan benchmark reviews that balance the effortsunk versus effort remaining, and the risk of resunk versus effort remaining, and the risk of re--doingdoingprogress since the last benchmark.progress since the last benchmark.

Dont wait until the gate to start the TASD, nor to findDont wait until the gate to start the TASD, nor to findout whether its deficient.out whether its deficient.

Get a review of detailed architecture design beforeGet a review of detailed architecture design beforeengineering the detail components.engineering the detail components.

As PM or PMA, make sure that business analysts,As PM or PMA, make sure that business analysts,architects and engineers all update their part of thearchitects and engineers all update their part of thearchitecture documentation when altering their detailarchitecture documentation when altering their detaildesigns.designs.


25/27


ProcessesProcessesArchitecture interaction in projectArchitecture interaction in project

oversight and execution.oversight and execution.


26/27


We perform architecture reviews to ensure:We perform architecture reviews to ensure:

The architecture of a system is documented.The architecture of a system is documented.

It provides a coherent description of the system.It provides a coherent description of the system. It is conformant to State and Agency principles,It is conformant to State and Agency principles,

standards and plans.standards and plans.

It is compatible with the legacy technicalIt is compatible with the legacy technical

landscape.landscape. That the chosen technology and design is likelyThat the chosen technology and design is likely

to achieve the projects goals and objectives.to achieve the projects goals and objectives.


27/27

Office of the State CIOOffice of the State CIO

Strategic PlanningOfficeStrategic PlanningOffice

Architecture TeamArchitecture Team

Doug Banich 919Doug Banich 919--754754--62106210

[email protected]@its.nc.gov

architecture review processes

Documents