It aac

IT Acquisition Advisory Council (IT-AAC)
A non-partisan think tank, 501.C3

Roadmap for Sustainable IT Acquisition Reform

Leveraging non-traditional expertise and benchmarked standards of practices
That exceed CCA & Section 804 Mandates

Honorable John Grimes, Former OSD CIO
John Weiler, Managing Director, john@IT-AAC.org
Dr. Marv Langston, IT AAC Vi Ch i marv@langston.org
D M L t IT-AAC Vice Chair @l t
Kevin Carroll, IT-AAC Vice Chair
904 Clifton Drive www.IT-AAC.org Virginia 22308
* Alexandria *
www.IT-AAC.org *0400 768-0400
703 768 (703)

Senior Exec Briefing Summary
™
Assuring Business Value from every IT $ Spent

 Purpose

 Today's Situation

 Our Proposal to Assist

 Way Forward Recommendation

 Predictable Outcomes

“Together, these steps will help to catalyze a fundamental reform of Federal IT, which is essential to improving
the effectiveness and efficiency of the Federal Government” White House, OMB Director
501.C Non-Profit Research Institute IT-AAC Proprietary © 2008- 2010 All Rights Reserved 1
703-768-0400 www.IT-AAC.org

™
Think Tank Purpose
To provide the Decision Makers with an alternative set of resources
and expertise needed to guide the establishment of a “best in class”
set of IT Acquisition Processes and Governance Structure.
Structure
Acquisition Practitioners and workforce will need commercial methods, access to deep
industry expertise and emerging standards of practice to overcome common failure patterns
and cultural impediments that have prevented previous attempts to achieve following
objectives:

Speed -- achieve 6-12 month cycle times vice 7-8 years (early pilots prove this is possible)

Incremental development, testing, and fielding -- vice one "big bang"

Actionable Requirements -- Sacrifice or defer customization for speed and COTS/OS utilization - Leverage
established standards of practice and open modular platforms

Meet DoD's wide-range IT needs -- from modernizing C2 to updating word processing software

Focused on Outcomes and Operational Effectiveness - Health IT, InfoSharing, Cyber Security, Consolidated IT
Infrastructure,
Infrastructure Business Systems
“You can’t solve today’s problems with the same thinking that got you there” Albert Einstein


IT-AAC understands IT Acquisition Dilemma
™
Wave 3 Solutions can’t be acquired using MilSpec processes…

 We are in early stages of Wave 3 information technology
 Mainframe and Client-Server waves remain in place 3. Internet - Cloud
tion Driven Capability
y

 Waves represent many co-dependent technologies, • Virtualized compute; global
network enabled, plug & play
matured over time
• IT Infrastructure decoupled from
 Adding functional capability has Applications
• COTS & OSS Integration,
Integration
n

become easier with each new wave
b i ith h
Software as a Service
 But enterprise infrastructure 2. Client/Server - Decentralized
gaps & vulnerabilities have • PC enabled and network
become more critical • Software distributed in both server and client
Informat

computers
t
• Heavy focus on software development and point to
point integration
1. Centralized - Mainframe
• Central computer center, slow turn around
center
• One size fits all
• Limited reuse of application modules
1950 1960 1970 1980 1990 2000 2010 2020
Information Technology Evolution
I f ti T h l E l ti
DoD is using 1970s acquisition processes; to acquire Wave 3 IT capability

Understanding the Many Dimensions of
the IT Acquisition Lifecycle
™

IT Acquisition Building Blocks:
 Governance and Oversight: how an enterprise supports, oversees and manages IT programs and on-going portfolio. SOA as defined in the commercial
market is governance tool not technology. DoD5000 and BCL represent the current approaches.

 Decision Analytics: enables effective Program Management and Value Stream Analysis execution. As most of these sub-processes are designed to improve
decision making, a relative new discipline has evolved (since 86), that addresses the human and cultural challenges in decision making. Decision Analytics is the
discipline of framing the essence and success criteria of each gate in the acquisition lifecycle. It brings focus to the high risk areas of a program, and reduces
analysis/paralysis.

 Requirements Development: Actionable requirements must be constrained by the realm of the possible. With pressures to do more with less, we must
possible less
embrace mechanisms that force a relative valuation/impact of the gap/capability, with clearly defined outcomes

 Architecture: This is one of the most critical elements of the acquisition lifecycle, as it should represent all stake holder agreements. The market embrace of
SOA is not about technology, but a refocusing of the EA on service level management and data. A good architecture is a lexicon that links requirements,
technologies and acquisition strategy.

 T h l
Technology Assessment: Understanding the limitation of technology early in the process is key. Without a clear view of the “realm of the possible” validated
A t
by real world results, we often find ourselves in high risk areas and over specification. Market research must be done early to help users constrain requirements
and embrace the inherent business practices that codify. Recognizing that 70% make up of every IT application is vested in IT infrastructure (netcentric, cloud,
SOA), it is critical to establish a common infrastructure/infrastructure standard by which all applications can share. The most prolific is ITIL to date.

 Business Case Analysis: Demonstrating the business value of technology investments, based on evidenced based research and lifecycle cost. This is a
core requirement of Clinger Cohen Act.

 Performance Based Acquisition and Metrics: Software as a Service and SOA portent a new dynamic for acquisition of IT (health IT, cyber, business
systems), that brings focus to Service Level Agreements (SLAs), Software as a Service (SaaS) and SL Management. If the previous activities do not directly feed
the acquisition strategy or provide mechanisms for contractor accountability, all is lost.

“IT Reform is about Operational Efficiency and Innovation”


Today’s Situation -- as highlighted by the HASC
™ Panel on Defense Acquisition Reform
q

Studies of both commercial and government IT projects have found some
disturbing statistics;

 Only 16% of IT projects are completed on time and on budget.

 31% are cancelled before completion
completion.

 The remaining 53% are late and over budget, with the typical cost growth exceeding the original
budget more than 89%.

 Of the IT projects that are completed, the final product contains only 61% of the originally
specified features.

As was pointed out in testimony before the Panel, the traditional defense acquisition process is “ill-suited for
information technology systems. Phase A is intended to mature technology; yet information technologies are now largely
matured in the commercial sector”. Weapon system acquisition processes are often applied to IT systems acquisition,
without addressing unique aspects of IT “the weapon systems acquisition process is optimized to manage production
IT.
risk and does not really fit information technology acquisition that does not lead to significant production quantities.”
Defense Acquisition Panel, HASC

Understanding IT Acquisition Reform Laws
™ MilSpec must give way to Industry Best Practices: SOA, Agile, COTS
HR5136: ‘‘Implementing Management for Performance and Related Reforms to Obtain Value in Every Acquisition’’. Requires:
(1) Determine clear performance metrics for specific programs from the start;
(2) Foster an ongoing dialogue during the technology development process between the system developers and the
warfighters;
(3) Promote an open architecture approach that allows for more modularization of hardware and software;
(4) Develop a plan for how to strengthen the IT acquisition workforce;
(5) Implement alternative milestone decision points that are more consistent with commercial product development for IT;
(6) Develop a process for competitive prototyping in the IT environment;
(7) Develop a new test and evaluation approach that merges developmental and operational testing in a parallel fashion;
(8) Place greater emphasis on the up-front market analysis; and
(9) Conduct a rigorous analysis of contracting mechanisms and contract incentive

Clinger Cohen Act Requires:
(1) Streamline the IT Acquisition Process
(2) Change business processes (BPR), not COTS
(3) Favor COTS/OSS over custom development.
(4) Build business case and acquire based objective assessment criteria
(5) Use architecture for driving investment decisions
(6) Favor standards and best practices over MilSpec approaches


Congressional Action to Reform
™ IT Acquisition: 2009 NDAA Sec804
q

“The Secretary of Defense shall develop and implement a new acquisition process for information technology
systems. The acquisition process developed and implemented pursuant to this subsection shall, to the extent
determined appropriate by the Secretary--

 be based on the recommendations in chapter 6 of the March 2009 report of the Defense Science Board Task
Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology; and

 be designed to include--
– early and continual involvement of the user;
– multiple, rapidly executed increments or releases of capability;
– early, successive p
y prototyping to support an evolutionary approach; and
yp g pp y pp
– a modular, open-systems approach”

Congress and DSB made these recommendations based on early adoptions by AF, Navy, USMC, and BTA of
alternative methods like the Architecture Assurance Method (AAM), a risk management framework designed
to improve decision making and assure stake holder value AAM incorporates by reference industry best
value.
practices like SOA, ITIL, and Evidenced Based Research.


OMB Guidance on IT Reform
™ from OMB’s 25 Point Plan

Align the Acquisition Process with the Technology Cycle
 Point 13. Design and develop a cadre of specialized IT acquisition professionals .

 Point 14. Identify IT acquisition best practices and adopt government-wide.

 Point 15. Issue contracting guidance and templates to support modular development

 Point 16. Reduce barriers to entry for small innovative technology companies"


OMB’s View of Federal IT
Fundamentally Broken!
™


Sources of Evidence
™
Failure to fix IT is costing the tax payer $40Billion a Year

“We are buying yesterday’s technology tomorrow in the rare instances we are successful ”
 DSB IATF: “DoD reliance on FFRDCs is isolating it from sources of new technologies and will hinder the departments ability to get the
DoD technologies,
best technical advise in the future”

 AF Science Advisory Board 2000: PMs need greater access to real world lesson learned and innovations of the market to mitigate risk
and cost overruns. PMs frequently enter high risk areas due to limited access to lessons learned from those who have already forged
ahead.

 CMU SEI Study 2004: The DoDAF alone is not effective for IT architectures, lacks business view, performance metrics or means of
avoiding over specification. DoDAF (C4ISR) was developed by Mitre and IDA in 1986 to provide DoD with a systems engineering
documentation tool for existing system implementations. 2009 NDAA Sec 803 : Government needs a high integrity knowledge
exchange by which innovations of the market can be objectively assessed.

 DSB 2009: Weapons Systems Style Solution Architecture and Acquisition Processes take too long, cost too much, recommend
establishing a separate IT Acquisition market that is tuned for the fast paced market.
t bli hi t A i iti k t th t i t d f th f t d k t

 IT-AAC 2009: Major IT Programs lack senior leadership support, and have few vested in the success. All participants, including
oversight, must be incentivized in meeting program goals and outcomes.

 BENS RPT on ACQUISITION 2009: DoD needs independent architecture development that is not compromised by those with a
vested interest in the outcome FAR OCI rules must be better enforced
outcome. enforced.

 NDAA Sec 804 2010: DoD will establish a modular IT Acquisition process that is responsive to the fast paced IT market.

"Weapons systems depend on stable requirements, but with IT, technology changes faster than the requirements process can
keep up," he said "It changes faster than the budget process and it changes faster than the acquisition milestone process
up said. It process.
For all these reasons, the normal acquisition process does not work for information technology.” DepSec Bill Lynn
statement at the 2009 Defense IT Acquisition Summit hosted by IT-AAC

Federal IT Acquisition Root Causes
™ compromising mission effectiveness and costing tax payer $40B/year

1. IT Acquisition Ecosystem Ineffective:
– Missing incentives & metrics, redundant oversight, vague accountability, ineffective
g , g , g y,
governance (MOE, SLA) puts focus on compliance vs outcomes.
– Programs spending up to 25% on compliance without any reduction in risk.

2. Good laws (CCA, OMB 119, FAR, Sec804) lack enforcement:
( , , , )
– Frequently compounded by Ad-hoc Implementations and MilSpec methods.
– DODAF, JCIDS, NESI, LISI were designed for Weapons Systems, compete with
standards and orthogonal to Industry Best Practices.

3. Conflict of Interest unenforced, optimal resources and expertise overlooked:
– FAR prohibits Contractors with vested interests in implementation should not use
“Chinese firewalls” to bypass rules or gain unfair advantage.
– Optimal resources in IT Program planning, market research, and solution engineering
overlooked, inhibiting access to real world best practices and innovations of the
market. Standards bodies & non-profit research institutes under utilized.

“Insanity is continuing the same process over and over again and expecting different results” Albert Einstein


Root Cause (cont.)
™

4. FFRDCs/SIs are Stifling Innovation and Decision Making due to Analysis/Paralysis:
– Traditional Sis/FFRDCs are insulated from IT innovations and commercial best practices.
– PMs lacks effective outreach/research capabilities needed to inform the requirements and
acquisition lifecycle. Lacks timely access to innovations of the market, commercial
expertise, or benchmarked best practices and lessons learned.
– Small Businesses, Innovators and Public Service entities (.edu, .org, SDOs) are under
utilized,
utilized threatening Open Systems and Open Architecture efforts
efforts.

5. MilSpec Acquisition Processes in conflict with Open Systems, best practices and drive “design
to spec” approach ( in spite of CCA and NDAA Section 804 directive to the contrary):
– MilSpec Requirements (JCIDS), Architecture (DoDAF), Tech Assessment (TRL/C&A)
(JCIDS) (DoDAF) (TRL/C&A),
Business Case Analysis (AoA), Procurement (DoD5000) and Enterprise Management
(CMM) processes are inconsistent with fast paced IT market (in spite of Paperwork
Reduction Act, CCA, Section 804 and OMB A119 directives)
– Section 804 call Open Process cannot be implemented using the same resources and
expertise that created the current MilSpec processes

6. Budgeting (POM) approaches drive stove pipe solutions:
– Frequently undermining ability to establish common & interoperable infrastructure services
which accounts for 70% of every IT program buy. Concepts like SOA, Cloud Computing
and Service Level Management cannot be embraced without a change in the above.

Critical Success Factors for
™ Sustainable IT Acquisition Reform
q

Root causes analysis derived from 15 years of studies, suggests the following critical
success factors for sustainable IT Acquisition Reform. Any new process will need to
meet the following litmus test:

 Must replace each of the existing IT Acquisition lifecycle building blocks (per DSB report) and
address the unique challenges of the fast p
q g paced IT market ( (JCIDS, DODAF, DOD5000, NESI) )

 Must be derived from commercial best practices (CCA)

 Must avoid MilSpect by leverage existing investments and capabilities (CCA, NTTAA)

 Should favor processes already proven in the market

 Should be based on a consensus based standard (OMB A119)

 Must be modular, services oriented (NDAA Section 804)

 Should be measurable, repeatable and sustainable, with supporting training, education and
mentoring (HR 5013)


™

IT Reform Way Forward
Adapting Agile Acquisition Standards and
Benchmarked Commercial Best Practices


Resources for Sustainable IT Reform
™
for when failure is not an option
Interoperability Clearinghouse (ICH)
• Repository of reusable Best Practices Frameworks (process and solution architectures)
• Conflict Free Research Coop dedicated to operationalizing Clinger Cohen Act directives
• Means of accessing wide range of SMEs and community of practices outside the Defense
Industrial Complex

Acquisition Assessment Method (AAM)
• D i i Analytics Tool for IT centric AoA, EoA, BCA, Ri k and T h i l A
Decision A l i T l f i A A E A BCA Risk d Technical Assessments
• Measurable, repeatable and sustainable method to enable cost avoidance and savings
• Incorporates by reference: SOA best practices, IT Infrastructure Libraries (ITIL) and
Evidenced Based Research (EBR)

Solution Architecture Innovation Lab (SAIL)
• Virtual Lab by which innovators can validate their solutions
™ • Solution Architecture patterns for e-Gov, IT Infrastructure, Cyber-Security & Health IT
• M
Means of tapping existing testing and implementation resources for rapid deployment
ft i i ti t ti di l t ti f id d l t

IT-Acquisition Advisory Council (IT-AAC)
• A non-partisan Government and industry think tank created to drive sustainable IT Acquisition
Reform
• Leverages expertise from academia, standards bodies, innovators and COIs
• Provide an interchange for senior level leadership interchange

Partner with DAU to create a Mentoring
™ and Training Curriculum
g


Assessment of Alternative
IT Acquisition Processes
™

MilSpec Assessment Alternative Assessment Where
Acquisition against Sec 804 Acquisition against Sec 804 successfully
Processes Criteria Process Criteria applied
Decision
D i i Ad h
hoc, nott Largest gap in IT
L t i Acquisition
A i iti Open,
O AF, N
AF Navy, USMC,
USMC
Analytics formalized Lifecycle Assurance Successfully BTA, GSA, DISA,
Method (AAM) piloted, modular
Requirements JCIDS, IT Box Not tuned for Value Stream Exceeds criteria US TRANSCOM,
Development COTS, SOA,
COTS SOA OSS Analysis w/ Agile DISA,
DISA CIA
Market Development
Architecture DoDAF Missing Metrics, OMB FEA RMs Strong evidence, PTO, DOC,
Systems Infrastructure View, SEI SMART Services Based GPO, GSA, DOI,
Engineering Stake holder DOT,
DOT DHS
Method perspectives
Technology TRL IT Matures at a AF Solution COTS/OSS AF, USMC, BTA,
Assessment: Assessment very fast rate Assessment Focused, support Navy CANES,
Process (ASAP) BPR PTO, GPO, GSA
Risk & Cost Analysis of Time consuming, ASAP/AAM BCA Effective w/ AF, Navy, USMC,
Management Alternatives, not aligned with COTS based sys BTA
industry B.P. BTA ERAM Limited risk mgt
Governance DoD 5000 Milestone based,
based ICH Clinger Integrated SOA BTA,
BTA OSD HA,
HA
and Oversight Bus Capability not effective for IT Cohen Act Guide best practices Navy,
Lifecycle (BCL)

Resource Optimization Considerations
you cannot outsource risk or critical thinking
™

1. FFRDCs: Best suited for govt unique R&D and Weapon Systems Source Selection.

2. Standards Development Orgs (SDO), Trade Associations: Source of standardizations among
suppliers, ISVs. Effective source for market communications and outreach.

3. Research Institutes, Labs & Academia: Excellent source of low cost research, piloting of emerging
technologies not yet proven in the market. Effective in IT & acquisition training.

4. Consultancies, A&AS Firms: Excellent for IV&V and source selection if free of vendor relationships or
implementation interests. Can mitigate OCI issues in acquisition.

5. Innovators, ISVs, Open Source: The engine of innovation. Most effective and efficient way of filling
common industry IT gaps. Great source of customer case studies and best practices.

6. System Integrators: Optimized for large scale implementation and outsourcing. Have significant
outsourcing
economies of scale and technology usability insights.


Resource Guide for Effective IT Acquisition
Based on Clinger Cohen Act and FAR Guidance
™

Partner Type FFRDC User Groups, Standards Research Consultants, Innovators, System
Communities development Institutes, IV&V, A&AS Tech Mfg, Integrators
SDLC Phase of Practice orgs, trade Labs & Firms Open Source
associations Academia
Requirement, Only when OMB Lines of SDOs = Provide Limited access Great source FAR OCI
Gap Analysis no other Business Primary driver Conflict free to industry for customer Rules limit
company can offers Critical for open structure and lessons use cases, participation
support (4). Role (6,7) systems. economies of learned. lessons
Conflict free scale (2,6)
( ) learned.
structures (2,3)
Architecture Only when Agency CxOs Provide Principle Primary source FAR OCI rules FAR OCI rules
and Planning, no other provides standards of source of of expertise limit prohibit direct
Mkt Research company can critical practice, not expertise participation support
support ( )
pp (4) g
guidance ( , 3)
(2, ) support
pp
PMO & IV&V Only when Not inherently Play Optimized for Key role FAR OCI rules FAR OCI rules
Support no other governmental supporting role this area prohibit prohibit
company can participation participation
support (4)
Material Forbidden (4) Not inherently Support role Support role Provide Primary
Solution Governmental developmental partnership
Engineering area
System Impl., Forbidden (4) Not inherently Forbidden Lack Internal IV&V Provider of key Primary
Maint, & Governmental Resources & for Prime technologies partnership
Support Expertise contract area
reduces risk.


Critical Success Factors
for Sustainable IT Acquisition Reform
™

Clinger Cohen Act, FAR, and NDAA Sec804 directives cannot be accomplished with the same
thinking that got us their. FFRDCs are prohibited from competing with industry and therefore the
least effective resource for IT programs. The CSF include;

 Agile Methods derived from benchmarked commercial best practices (CCA, Sec804)

 Leverage existing investments and innovations of the market while avoiding competing with
industry or duplicating what already exists (Economy Act)

 Utilize pub c se ce institutes a d sta da ds bod es o e FFRDCs (
Ut e public service st tutes and standards bodies over Cs (FAR)
)

 Should be based on Open, consensus based methods (OMB A119)

 Must be modular, services oriented (NDAA Section 804)
, ( )

 Should be measurable, repeatable and sustainable, with supporting training, education and
mentoring (HR 5013)
15 years of studies suggest the following critical success factors for sustainable IT Acquisition Reform. An
“Open” IT Acquisition process will still need to conform to the rule of law (non-MilSpec):


™
Repeatable Patterns of Success
when agencies t IT expertise outside the Defense Industrial Complex!
h i tap ti t id th D f I d ti lC l !

Navy: Assessment of AFLOAT Program – USAF: Streamlined COTS Acquisition USAF: Procurement of E-FOIA
CANES SOA & Security Strategy Process. Applied to Server Virtualization. System using AAM

Eliminated hi-risk Requirements by Established optimal arch with ROI of Completed AoA, BCA, AQ Selection
23%, $100Ms in potential savings 450% & $458 million savings in just 4 months.

USMC: AoA and BusCase for Cross GSA: Financial Mgt System consolidation BTA: Assessment of External DoD
Domain, Thin Client Solutions using AAM. Hosting Options using AAM

Greatly Exceeded Forecasted Saving Moved FMS from OMB “red” to $300 million in potential savings with
in both analysis and acquisition “green”. Eliminated duplicative minimal investment
investments that saved $200M

BTA: Apply AAM to complete AoA and GPO: Developed Acquisition Strategy for JFCOM: MNIS Evaluation of Alternatives
BCA for DoD SOA Project Future Digital System for Cross Domain Solutions

Reduced pre-acquisition cycle time Led to successful acquisition and Evaluated 100’s of Options in 90 days,
and cost of Analysis by 80% implementation on time, on budget enabling stake holder buy in and
(4 months vs 18) and 80% cheaper than NARA RMS source selection.

“. the concept of the Interoperability Clearinghouse is sound and vital. Its developing role as an honest broker of all interoperability technologies, no matter what the source,
is especially needed. Such efforts should be supported by any organization that wants to stop putting all of its money into maintaining archaic software and obtuse data
formats, and instead start focusing on bottom-line issues of productivity and cost-effective use of information technology.” OSD Commissioned Assessment of Interop.
Clearinghouse (Mitre 2000)

™

AF Solution Assessment Process (ASAP) Case Study;
Thin Client/Server Based Computing
Using ASAP/AAM enabled a 60day turn around to complete the following
mandatory tasks;

1. Converted Requirements to Services/Capabilities Gaps
q p p

2. Established Measures of Effectiveness and Source Selection Eval Criteria

3. Conducted Baseline Assessment (cost/value of current portfolio)

4. Market Research (Realm of the Possible) that reaches real innovators and
associated lessons learned.

5. Conduct Evaluation of Alternatives (apples to apples) using Evidence Based
Research

6. Lite Weight Business Case Analysis for Investment Justification


Scope of ASAP Phase 2 Effort
™ Adapting ICH s Architecture Assurance Method
ICH’s

ASAP Phase 1 (June 08 - Jan 07)
 TA Root Cause Analysis

 Integration of AF TA best practices and ICH Architecture Assurance Method

 ASAP Process development documentation

 Facilitated TA Value Stream Analysis

ASAP Phase 2 (Aug 07 – Sept 07)
 SBC Capability Determination

 SBC Capability Prioritization

 SBC Solution Architecture & Feasibility Assessment

 SBC Business Case Analysis (lite)

 ASAP Process maturity assessment

TA-ASAP Phase 3, Operationalize an Enterprise Process (4 FTEs) pending funding approval)
 SBC Procurement Documentation Development

 SBC Source Selection

 TA-ASAP Management Oversight and Governance Build Out

 TA-ASAP Process Integration (XC EA, XC PfM, XC CBA, AQ OTD)

 Estimated TA resource allocation is 4-5 FTEs to support an AF enterprise wide implementation

™ ASAP Project Milestone
j
Capability Determination

ASAP Artifacts Capability Prioritization
Feas./Arch. Assessment
BCA

June 14 July 1 Aug 2 Sept 1 Oct 1

BCA ASAP
Project Announced to Kick Off MAJCOM Data Call
Completed Assessment
Plan AF Meeting Data Call Results
Data Collection Period
on Capabilities AFCA On-board ASAP ASAP
Completed Report

HERE
ASAP Process Execution
 Capabilities Determination - data 3 weeks
collection capabilities list
 Capabilities Prioritization less than a week
 Assessment of technology Products 1 day
 BCA (operated in parallel with ASAP 5 weeks from start or
1 week after ASAP Assessment
 Remaining time is being applied to final
task on evaluation of the ASAP process
itself


A
ASAP Phase 2 Project Plan
Process; TA-ASAP Process Model
S
A
P
Artifact; TA Sequencing Diagram
Innovation Thread
™

Type 1 Technical Solutions - COTS (Portal)
PE

Y

AL
N

Sp ON
N

ific

EN L
RM LITY
TY

Type 2 Major Program Solution (DoDAF/5000)

Pr IOT ILIT
TIO

TIO

SS URA

N
UR
SS ITY
ec
I
ION

T

T
ram ZAT
Type 3 Technical Solutions - Custom (Guard)

IO
dic
INA

EN
PR PAB
BI

IS
ISI

CT

AT
T
IL
Type 4 Product Evaluation - Innovation
T

PA

YS
rio
QU

AS ITEC
M

M
ISI

I

AS SIB

ITE

IC
Type 5 Product Evaluation - Commodity
CA

CA

AL
QU

Pe
AC

TE

RIF
A

CH
SE

CH
SE

AN
og
AC

DE

FE
or

VE
AR
AR
Selection Outcomes
Lab
T1
S
O Capability Feasibility Architecture Selection Network Outcomes
Capability Independent Individual
L Prioritization Assessment Assessment Audit Assessment Certification
Determination Audit
U KPP/CSF
Lab
T GO GO
I T2 COTS COTS

O Capability Feasibility Architecture Selection Network Outcomes
Individual
N Determination Capability Assessment Assessment Independent P Assessment Audit Certification
Prioritization KPP/CSF Audit
R
T3 CUSTOM NOGO NOGO
O
I STEP-1 STEP-2 STEP-3 STEP-4 C
N BCA
N Cat-1: Value,
Value U Selection
S l ti Network
N k
Architecture Mature, Funded Individual Outcomes
O Feasibility Assessment R Assessment Audit Certification
V Assessment
A
Invest E
T4 Cat-2: Value, Mature,
T
Capability
Combined To Be Funded M
I
O Determination E
N Cat-3: Value, N
Capability
Immature
Prioritization Wait
T
C
O
Cat-4: No Value
C t 4 N V l
Lab
We
W R
M
M T5
Here
O
Architecture Selection Network Outcomes
D Assessment Independent Assessment Certification
I Audit
T
Y Pre-Tech Assessment Technology Assessment Phase Implementation Phase

Use Cases System BCA Templates Probable Actual vs
Volumes/Timings Behaviors and Models Cost Mode Planned

™ SBC Capabilities before ASAP
p

1Reduce time to deploy infrastructure1aReduce the time to deploy new applications across entire command within hours.1bReduce the time to reassign client locations 1cReduce the time to stand
up new organization/office/unit2Reduce infrastructure cost2aReduce equipment accountability cost asset mgt2bReduce software license cost 2cReduce number of report of survey asset
mgt2dReduce power consumption (HVAC)2eReduce touch maintenance throughout installation2gReduce number of CSAs/SAs2iReduce technology refresh cost3Improve Reliability,
Availability Survivability (RAS)3aReduce mission downtime caused by CMI/Intrusions3bReduce mission downtime caused by loss PC-resident data3cProvide for data backup/recovery
services for clients 3dAllow workstation recovery within 15 minutes from a remote location to include applications user data and operating system3eProvide improved reliability and availability
clients.3dAllow applications, data,
of computing resources, services4Work within current Security Management Posture4aReduce Vulnerabilities4bImprove patch compliance5Provide support for AF Use Cases5aProvide
support for client type – Baseline5bProvide support for client type – Functional5cProvide support for client type – Non-Standard5dProvide support for client type – Standalone5eProvide support
for client type – Remote5fProvide support for client type – Unmanaged6Support SBC storage strategy6aProvide server-side storage of System data and/or system images6bProvide server-
side storage of enterprise data6cProvide server-side storage of user data and/or system images6dProvide server-side storage of user application6eProvide server-side storage of enterprise
data application7Support Infrastructure Requirements7aMaintain current bandwidth/network loads (min 10 GB to max 100GB user profiles, 100 MB to the desktop)7bProvide consistent
capability, whether rich or thin, with differing capabilities based on Active Directory rights/groups7dProvide support for the Common Access Card (CAC)/DOD Public Key Infrastructure (PKI)
logon8Improved Manageability8aProvide for remote manageability of desktop8bProvide support for all business and mission applications, including bandwidth sensitive applications8cProvide
for a client computing environment solution that scales over the AF enterprise 8dAllow use of a diverse mix of hardware end devices in a heterogeneous environment 8eIncrease IT service
availability to the mobile/pervasive user 9Provide the same user experience (irrespective of client; rich or thin client).

Jumbled – Needed a Standardized Methodology
To Establish A Repeatable and Executable TA process


A
S
Process; Capability Determination
SBC Capabilities Tie Back to Mission
Capability GAPS
A Artifact; Hi-Level Capability Matrix
P
™

Mission Capability Gaps
SBC Capability
Mission Capability No High level Capability
FROM CJCSI 3170.01F , NCOE JIC

2 1 Reduce time to deploy infrastructure
1. Improved Operational Efficiencies
asset management, system administration capacity management, manpower 1 2 Reduce infrastructure cost
efficiencies, patch compliance

2. Improved ability to deploy/modify new infrastructure 1 3 Improve Reliability, Availability Survivability (RAS)
within hours

3. Improved Mobility 4 4 Work within current Security Management Posture
as supported by a pervasive SBC infrastructure

4. Improved security 3 5 Provide support for AF Use Cases
loss or theft of physical storage at the edge
l h f f h i l h d
1 6 Support SBC storage strategy

2 7 Support Infrastructure Requirements

1 8 Improved Manageability

1 9 Provide the same user experience (irrespective of client; rich or
CJCSI 3170.01F - Joint Chiefs of Staff Instruction under the
thin client).
Joint Requirements Oversight Council (JROC)
NCOE JIC - Net-Centric Operational
Environment under Joint Integrating Concept

Derived From: ConstellationNet Architecture, USAFE Pil0t, NetCent RFI, AF Data
Call, Industry Studies and Data


A Process; Capability Prioritization
S Established Weighted Criteria
A
P
Artifact; Weighted Capability Matrix
For an Objective Decisions - 1
™

WT No. Capability Importance
150 1 Reduce time to deploy infrastructure
1a Reduce the time to deploy new applications across entire command within hours. 1
1b Reduce the time to reassign client locations 1
1c Reduce the time to stand up new organization/office/unit 1
150 2 Reduce infrastructure cost
2a Reduce equipment accountability cost asset mgt 4
2b Reduce software license cost 1
2c Reduce number of report of survey asset mgt 4
2d Reduce power consumption (HVAC) 1
2e Reduce touch maintenance throughout installation 1
2g Reduce number of CSAs/SAs 1
2i Reduce technology refresh cost 1
50 3 Improve Reliability, Availability Survivability (RAS)
3a Reduce mission downtime caused by CMI/Intrusions 1
3b Reduce mission downtime caused by loss PC-resident data 3
3c Provide for data backup/recovery services for clients. 1
3d Allow workstation recovery within 15 minutes from a remote location to include 2
applications, user data, and operating system
3e Provide improved reliability and availability of computing resources, services 3
50 4 Work within current Security Management Posture
4a Reduce Vulnerabilities 1
4b Improve patch compliance 1
50 5 Provide support for AF Use Cases
5a Provide support for client type – Baseline 1
5b Provide support f client t
P id t for li t type – F
Functional
ti l 1
5c Provide support for client type – Non-Standard 3
5d Provide support for client type – Standalone 2


A Process; Capability Prioritization
S Established Weighted Criteria
A
P
Artifact; Weighted Capability Matrix
For an Objective Decisions - 2
™

5e Provide support for client type – Remote 3

5f Provide support for client type – Unmanaged 5
125 6 Support SBC storage strategy
6a Provide server-side storage of System data and/or system images 1
6b Provide server-side storage of enterprise data 1
6c Provide server-side storage of user data and/or system images 1
6d Provide server-side storage of user application 1
6e Provide server-side storage of enterprise data application 1
125 7 Support Infrastructure Requirements
7a Maintain current bandwidth/network loads (min 10 GB to max 100GB user profiles, 1
100 MB to the desktop)
7b Provide consistent capability, whether rich or thin, with differing capabilities based 1
on Active Directory rights/groups
7d Provide support for the Common Access Card (CAC)/DOD Public Key 1
Infrastructure (PKI) logon
150 8 Improved Manageability
8a Provide for remote manageability of desktop 1
8b Provide support for all business and mission applications, including bandwidth 4
sensitive applications
8c Provide for a client computing environment solution that scales over the AF 1
enterprise
8d Allow use of a diverse mix of hardware end devices in a heterogeneous 1
environment
8e Increase IT service availability to the mobile/pervasive user 2
150 9 Provide
Pro ide the same user e perience (irrespecti e of client; rich or thin
ser experience (irrespective client 1
client).


A Process; Feasibility & Architecture
S
Assessment Results
Assessments
A Artifact; Solution Risk Assessment
™
P Report
Q
Quantify Risks
y

The results showed how the combined Use Cases could be several by a single product suite.
ASAP scored the highest due to clarity toprovide the same useras a difficult though
SoftGrid quickly provided it’s ability to what seamed experience even decision which was
being clouded by no one commercial evaluated where in theoptimal Clearly there are tradeoffs
the range of score was not statistically different and all solution being low risk range. all capabilities
to tradeoffs.
Overall, SoftGrid had the best solution to cover the entirety of the use case including speed to and Wyse solution had
and thatreact, andsolutions could be rapidly the least potential to reduce Citrix potential to reduce
deploy and ‘80%’ manageability. However, SoftGrid has analyzed and then the most procured and
implemented.
infrastructure costs. infrastructure costs.
Citrix and Wyse were the least capable in
manageability.
manageability Ardence was the least capable in
speed to deploy and react. CCI/HP, Citrix,
ClearCube and

n e rity
Wyse had the
W rk w in cu e t S cu

pective of
u va ility

Im ro d M n g a ility

client; rich or thin client).
ro e p o f r F
Blue = Essential 1 - 1.99 most impact on

S p o In stru re
R d ce in stru re

a a e e t o re

P vid su p rt fo A

o e
eploy

rovide the sam user
A ila ility S rviv b

p ve a a e b
S p o S Csto g

ctu
fra ctu

M n g m n P stu
p ve e b ty,

ra
Green = Desirable 2 - 2.99 reliability
e ab ty

c
c

s
rre
educe tim to de

experience (irresp
Im ro R lia ilit

u p rt fra u

e
Yellow = Less Desirable 3 - 3.99
availability, and

R q ire e ts
infrastructure

e u mn
Red = Undesirable 4 - 5.00
e

u p rt B
survivability

se a s
ith

U C se

te y
stra g
va b

c re
A )
(R S
eu

So
st

o
co
R

P
Value Factors 15%
% 15%
% 5%
% 5%
% 5%
% 13%
% 13%
% 15%
% 15%
%
Softgrid 1.67 3.00 3.40 1.50 0.73 1.40 1.00 1.56 1.00 1.67
Ardent 2.33 3.15 3.40 3.00 1.53 1.40 1.33 2.11 2.00 2.23 Very Reliable V
ClearC ube 1.67 2.23 1.30 2.50 2.07 1.40 2.00 2.78 4.00 2.48
Wys e 1.00 1.92 1.30 1.50 2.80 1.00 2.33 4.22 5.00 2.67
Reliable R
C I/H
C P 1.67 2.23 1.30 2.50 2.07 1.40 2.00 2.78 4.00 2.83 Questionable Q
Citrix 1.00 1.92 1.30 1.50 2.80 1.00 2.33 4.22 5.00 3.03 Unreliable U
Revisiting the Assigned Weights may change the scoring outcome
Data Faith - R
- Click on Table -

It aac

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (13)

Destacado

Destacado (9)

Similar a It aac

Similar a It aac (20)

It aac