Architecture Review Processes Architecture interaction in ...Presentation Transcript
Architecture Review Processes Architecture interaction in project oversight and execution.
What’s Architecture? Diagrams System Interactions Stakeholder roles Information management Data definitions Purchased software Interfaces with other systems Logical design New Systems Legacy Systems TASD Purchases Identity Management Network Topology
The 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.
A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
Things That Architects Don’t Do
Process compliance – that’s project office
Estimates – that’s service owners
Hardware specifications – that’s Engineering
Software specifications – that’s Developers
Requirement gathering – that’s Business Analysts
Process description – that’s Business Analysts
Windows – that’s Building Maintenance
Things That Architects Can Do
Plan technology direction and set technology standards
Help you figure out which technologies you should support.
Review plans, designs and purchases
Assess 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 processes
Technical 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.
You 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?
Iterative projects may propose how they will articulate architecture and design
Planning / Design Review (Gate 2)
Approve project architecture, solution design, technology direction
Do this each time architecture changes
Execution / Build / Pilot Review (pre-release) (Gate 3)
Approve architecture /design changes that may occur during E&B
Purchase process reviews
Pre-purchase Review (RFP, IFB)
Ensure sensible technical language in requirements
Purchase Proposal Review (pre-award)
Approve technology selections, architecture and strategy of proposal
Basic review flow
Submit documents (project team)
Review documents (architect)
If issues are found:
If issues are not resolved:
Approve with issue or Reject
Re-plan and resubmit or halt
If approved with issue
Track and resolve issue later on
Architecture Views and Perspectives
What does it need to do?
What goes in, comes out, and what do we keep?
How do the parts work together, at the same time?
How will we produce the system?
How will we deliver it?
How will we retire the old system?
How will we keep it going?
When will we stop it?
Accessibility and Usability
Will people be able to use it?
Availability and Resilience
Will it work when it needs to?
What are we required to do?
Are we protecting it?
What will it take to do it?
How will it grow and change?
Where will we build it?
Performance and Scalability
Will it handle all the work?
Project Reviews are Unique Efforts
We 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)”*