صفحه 1:
Architecture
Review Processes
Architecture interaction in
project oversight and
execution.
صفحه 2:
What’s Architecture? -
6 2 6 x
qehold inte
itd سین 8 0
۳ menial
۱۱۵۳۱۵96 رت
صفحه 3:
Architecture
= 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.
0
= A formal description of a system, or a detailed
plan of the system at component level to
guide its implementation.
0
= The structure of components, their inter-
relationships, and the ی and
guidelines governing their design and
evolution over time.
مد ۰
صفحه 4:
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
صفحه 5:
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
Ee ee ATER SETI ا
Batata eer ta Cont
Identify opportunities to reuse components and services.
"= Leverage enterprise contracts and license agreements.
Ei inetepe ل ا oe me mete) Nee ewes teat CcCelnn Tom
Review business organization and business processes
EMME To م اي ا ET IU ETD
.10665565م 655 لأقناط قصة كتقام دوفصتفتاط ,كله0ن عكتم ادع
SIS ose ete vel Meroe er (eres one ev Sh
process and technology plan with your enterprise goals.
صفحه 6:
Architecture Reviews
= You are about to sign off on the software
architecture of a multimillion-dollar software-
1111611517 Kot 00
= 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?
صفحه 7:
Architecture Reviews
= How 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?
ee ee Ce eee
Freee ek eerie et ea reteset eee steer ag
tte er mo i Scena
صفحه 8:
Architecture Reviews
= Architecture 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.:
0 ee eer reer
صفحه 9:
Benefits of Architecture
= Identifying potential risks in the proposed architecture (88%)
* Assessing quality attributes (for example, scalability, performance)
3
= Identifying opportunities for reuse of artifacts and components (72%)
= Promoting good architecture design and evaluation practices (64%)
Dis cerlisttpodcdcaiaeUecre attract temas sneak Cer)
= 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%)
Te eae re ec ccc
3
= Improving architecture documentation quality (40%)
® Facilitating clear articulation of nonfunctional requirements (31%)
= Opening new communication channels among stakeholders (31%)
لق اط لس ل ا 1
Leo rene aN ea)
صفحه 10:
Types of review
= Project process reviews
= Project Initiation Review (Gate 1)
™ Approve project goals, strategy, concept
ماهلنهمتایه له ترما معط معوحرمتم ره فامهزمتم منناهت16 «
3
= Planning / Design Review (Gate 2)
™ Approve project architecture, solution design, technology
celta Toate
ل ل ا ا 00 ها Moe tele(1 9
= 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)
«۰ عاصمصمتنن و۲۵ صذ موقنت مضه تهمنصطءه۱ ماطتعصمی معتاعوظ
= Purchase Proposal Review (pre-award)
DON acne Moment onan annem”
۱
صفحه 11:
Basic review flow
Submit documents (project
team) @ =|
= Review documents (architect)
= If issues are found: 4
= Resolve issues
= Re-submit [۳ Es
If issues are not resolvee, |
3
If rejected: ی
= Re-plan and resubmit or 21
If approved with issue
= Track and resolve issue later
صفحه 12:
Architecture Views and
Perspectives
es aaah
Accessibility and Usability
SMVine rca rene neste.
= Availability and Resilience
ات و ۱۱۱۴
Regulation =
7 م لمعتنيوع عند ععة غقط ل"
Security =
0
= Development Resource
= What will it take to do it?
= Evolution
= How will it grow and change?
= Location
6 ين اللي قت اننا eR Leg
0 ا ا Vilalta
۱ yea ed
مأصهم سرعلا
ةا
What does it need to do? =
Information
خض يكنات قعصدمه ۳
ا
Concurrency
0 صانوج عمط ول موم «
00
Development
۳: mare reas ema
system?
Deployment
» 7اذ هافق فتن اله مك
SIR rm areas مه عطا
EN ices
دمت هع م0
Semi 7ودزهو ذ وعمعا
۳
صفحه 13:
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.
ae aera Roan eon rae Nec cle
MN aa aOR Cosel kag oe ncaa
Cg seen nee SB ewig a Ie Cee eg
See MRR cea ee eee een came eagle
eee ne Ni cond Jee an geal
0
architecture are experience-based reasoning (83 percent) and
prototyping (70 percent)’*
SR Lira ey ee eee
Engineering Research Centre and lan Gorton, Pacific Northwest National Laboratory, IEEE Computer July 2009
نا get
صفحه 14:
Better review flow for
complex projects
= Engage architects before the gate review
ا isomerate (tere Lae a
۳
« لمنامععهمه مصمتاحره وصتصصفام راب۳ ret ost)
= Mid-planning option: design decision discussions
= Obtain guidance prior to review
= Get pre-reviews as effort is sunk in the TASD.
" Guide the design effort with the results of pre-
roa enn
= Balance review frequency based on risk and
2100000003
= Don’t arrive at the gate with a big gap 1
» قصة عتتقط نامز كقطتي مععتوتافط مهو وصتدملكت gees
required will take up time and effort.
۱ ean 1
peel eee
و
۱
0۰ رتماعق) 0و ما ل ل
صفحه 15:
Pipeline Vs Bottleneck
Treat architecture activities
as “externalities” to the plan.
Assign architecture document
production to non-technical
۱9۱9 015.
Plan short reviews of
documents that take a long
ما مصتا ۰
Connect with the architecture
group only at gate reviews.
Blame the process for gate
ENE
line strategies keep project progress flowing smoothly by planning for review.
leneck strategies ensure schedule overruns and risk re-work on design artifact
Work 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.
صفحه 16:
Minimum Review
Requirements
ate 3
Updated TASD and
documents (all project
changes reflected in
documentation).
Release plan
Operation plan
Agency Approval
ei
= Pre-purchase
Coherent requirements
Architecture disclosure
and conformance
required
= Pre-Award
Coherent and compliant
proposal
™ Gate 1
= PPM Project Info Tab
= Agency Approval
* )مموزعاسمتتوم asset)
كتط تدقع فط بتوتاقرت ملم معد 061106
Siac)
J Gene 2
= Complete TASD (all
parts)
Complete Design
Complete Execution
مقاط
= Procurement Plan (if
applicable)
Agency Approval
صفحه 17:
Design Process
واه موس
صفحه 18:
Architecture
documentation
= PPM Project Information
= Establish project strategy, goals and scope
= State assumptions and constraints
= Establish key deliverables and milestones
= Collect project documents and design artifacts
= Technical Architecture System Design
۱
= Functional Diagram & Narrative
= Conceptual Diagram, Narrative & Checklist
= Preliminary Diagram, Narrative & Checklist
= Detail Diagram, Narrative & Checklist
= Purchasing Plan
= Establish strategy and provide overview context for
planned purchases
صفحه 19:
PPM and Architecture
= Project Info Tab
حصي ست سيو إورنى إوزواءء ازوف او |(ن انان 01 ا
= Business Case, Scope and Cli
= Strategy for project executi}
= Assumptions & Constraints
= Issues and Risks Tab
= Track issues that the team has surfaced
= Track issues that Architects surface
= Document Management
= Collect TASD, Procurement Plan, and other
artifacts.
صفحه 20:
ae
صفحه 21:
TASD Template
= It’s a template
= It’s the official document for communicating architecture, and
the format has been formally approved
= Take a uniform approach to presentation to reduce review
۱
۱ and leave the section headers intact, don’t
0 icre
" Obtain information to answer the questions where it is
applicable but unknown
= It’s a template, not a final document
™ Add eae or checklist sections that are useful to telling the
architecture story
* If 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 format
* For very large or complex projects, alternative documents are
لم1 غه 20160ممة 6ط 10نامطة توعطاغ غتاط ,6 [طتوقمم
صفحه 22:
TASD Content
= The checklists collect the most basic information
Pere momr Cesar eet reese entero Lem
Seats soso ete ل tated
features.
۱ ECR oa Root acer t tite gt
roto
® Diagrams provide a roadmap
ee Cen ا
0
۱ ل comtn Toate a
features.
غمعدعممعم ما تراعة انع توم ,لعقوعه عط تقس تسمدموهتل عده صمطا عرولة »
csc ا ا 0
عنم ما ماعلمرهمی عونامها۱ 0
« ممتتههاا رعمنرما اعتلععظ» مط ما 0متتصنا ام( tere Me vot mast)
TASD format.
" Narratives can tell a story about data flow, about business interactions,
۳ Moe raat ate tetris atorK Cite
than a diagram can represent.
SI tert eters tet ost ا Me Ce
صفحه 23:
Architecture Resources
= OSCIO Architecture Team
= Provide Statewide Architecture review and
interpretation.
= Agency Architect or Technical Officer
™ Specialize in agency technology and business
applications.
=" Formulate agency standards and practices.
= Project Analysts and Technical Team
= Bring 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:
oye ۳
Avoiding Architecture
Risk
™ Consider the architecture documentation
risky product, and plan benchmark reviews
that balance the effort sunk versus effort
el wey 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 Processes
Architecture interaction in
project oversight and
execution.
صفحه 26:
Architecture Review
We 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 Office
= Architecture Team
= Doug Banich 919-754-6210
= douglas.banich@its.nc.gov
Architecture
Review Processes
Architecture interaction in
project oversight and
execution.
What’s Architecture?
Architecture
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.
ISO/IEC 42010:2007
TOGAF
The structure of components, their interrelationships, and the principles and
guidelines governing their design and
evolution over time.
TOGAF
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
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.
Help you figure out which technologies you should support.
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.
Architecture Reviews
You are about to sign off on the software
architecture of a multimillion-dollar softwareintensive 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 00189162/09/$25.00 © 2009 IEEE
Architecture Reviews
How 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
Architecture Reviews
1.
Architecture 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.1
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 00189162/09/$25.00 © 2009 IEEE
Benefits of Architecture
Review
Identifying 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
Types of review
Project process reviews
Project Initiation Review (Gate 1)
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 project goals, strategy, concept
Iterative projects may propose how they will articulate
architecture and design
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
A&E In t eract i o n fo r t yp i cal a rch i t ect u re revi ew.
8/19/2009
ITS Archi t ect ure
Submit documents (project
team)
Review documents (architect)
If issues are found:
st a rt
PPM Business
Ca se
Rese arch raised
i ssues, t o discover
cont ext and
d et e rmine g ood
pra ct i ce
expect a t i ons
Inqu ire about it – why does it
a ppear inconsist ent , what ca n
mit iga t e t h e issu e, or what do I
misunderst a nd?
Y
Que st ions, issue s,
comme nt s and/or
concerns
document
Approve with issue or Reject
N, or a ll
a ddressed previousl y
If rejected:
Formulat e reply and/or fix
document a t ion
Document Issu es o r Risks i n PPM
for re sol ut ion
Y
Re-plan and resubmit or halt
If approved with issue
Is t here a n
op en i ssue or
risk?
N
Ca n we wait for
mit ig at io n?
N
Ca n we
a pprove wit h
Issues/Risks?
Track and resolve issue later on
Recommend
a ppro val , si g n off
PPM
Y
End
Ag ency Document
prepa re d pri or t o
review (t ypi cal ly in
PPM)
A&E proce ss st ep
for resol ut io n of
concerns.
Ag ency process
st ep for resolut ion
of concerns
Comme nt Repl ies
a nd re vised desi g n
docume nt s
Is t here a
concern no t
ad dressed by
t he ag ency?
Resolve issues
Re-submit
A&E St andard
process
Ot her document s
sup pli ed
TASD
If issues are not resolved:
Purch asi ng Pla n
Read a ll supp lied
document a t i on
Don Je rman
Legend
N
Recommend
rej ect ion, reject i n
PPM
Y
Mit igat e Issue/Risk
Architecture Views and
Perspectives
Viewpoints
Functional
Information
How will we produce the
system?
Deployment
How do the parts work
together, at the same time?
How will we deliver it?
How will we retire the old
system?
Operation
How will we keep it going?
When will we stop it?
How will it grow and change?
Location
What will it take to do it?
Evolution
Are we protecting it?
Development Resource
What are we required to do?
Security
Will it work when it needs to?
Regulation
Will people be able to use it?
Availability and Resilience
Development
What goes in, comes out, and
what do we keep?
Concurrency
What does it need to do?
Perspectives
Accessibility and Usability
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)”*
*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
Better review flow for
complex projects
Engage architects before the gate review
Obtain guidance prior to review
Initiation discussions: determine strategy
options
Early planning option: conceptual discussions
Mid-planning option: design decision discussions
Get pre-reviews as effort is sunk in the TASD.
Guide the design effort with the results of prereviews.
Balance review frequency based on risk and
remaining effort.
Don’t arrive at the gate with a big gap
Closing 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.
?
Pipeline Vs Bottleneck
Pipeline Strategies
Strategies
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.
eline strategies keep project progress flowing smoothly by planning for review.
leneck strategies ensure schedule overruns and risk re-work on design artifact
Work 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.
Bottleneck
Minimum Review
Requirements
Gate 1
PPM Project Info Tab
Agency Approval
(Registration projects may have to
deliver more information because this
is the only review)
Gate 2
Complete TASD (all
parts)
Complete Design
Complete Execution
Plan
Procurement Plan (if
applicable)
Agency Approval
Gate 3
Pre-purchase
Updated TASD and
documents (all project
changes reflected in
documentation).
Release plan
Operation plan
Agency Approval
Coherent requirements
Architecture disclosure
and conformance
required
Pre-Award
Coherent and compliant
proposal
Design Process
Business
Requirement
Gate1
Conceptual Architecture
Architecture
Preliminary Architecture
Logical Design
Engineering
Gate 2
Engineering
Design
Implementation
Gate 3
Architecture
documentation
PPM Project Information
Technical Architecture System Design
Template
Establish project strategy, goals and scope
State assumptions and constraints
Establish key deliverables and milestones
Collect project documents and design artifacts
Functional Diagram & Narrative
Conceptual Diagram, Narrative & Checklist
Preliminary Diagram, Narrative & Checklist
Detail Diagram, Narrative & Checklist
Purchasing Plan
Establish strategy and provide overview context for
planned purchases
PPM and Architecture
Project Info Tab
Issues and Risks Tab
Stakeholders, Contacts and Dates
Business Case, Scope and Goals
Strategy for project execution
Assumptions & Constraints
Track issues that the team has surfaced
Track issues that Architects surface
Document Management
Collect TASD, Procurement Plan, and other
artifacts.
TASD Template
It’s a template
It’s the official document for communicating architecture, and
the format has been formally approved
Take a uniform approach to presentation to reduce review
durations, put any extra information at the end of a section
Follow the structure and leave the section headers intact, don’t
delete things or you’ll confuse the reviewer
Obtain information to answer the questions where it is
applicable but unknown
It’s a template, not a final document
Add diagrams or checklist sections that are useful to telling the
architecture story
If 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 format
For very large or complex projects, alternative documents are
possible, but they should be approved at initiation
TASD Content
The checklists collect the most basic information
Diagrams provide a roadmap
They 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.
Relationships 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 picture
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,
nonfunctional requirements, or about system relationships in more detail
than a diagram can represent.
Narratives can relate the decision process leading to design choices.
Architecture Resources
OSCIO Architecture Team
Agency Architect or Technical Officer
Provide Statewide Architecture review and
interpretation.
Specialize in agency technology and business
applications.
Formulate agency standards and practices.
Project Analysts and Technical Team
Bring 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.
Avoiding Architecture
Risk
Consider 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.
Architecture
Review Processes
Architecture interaction in
project oversight and
execution.
Architecture Review
We 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.
Office of the State CIO
Strategic Planning Office
Architecture Team
Doug Banich 919-754-6210
douglas.banich@its.nc.gov
