1. Subset of Executive Briefing

2. Defense Business Systems (DBS) Enterprise Resource Planning (ERP) Lessons Learned
-Failure to realize that ERPs are not COTS; ERPs are Configured COTS (for a price) (Not Re-Engineering) -Use an Enterprise Architecture (EA) tool and understand your current architecture (“as is”) and target architecture (“to be”) NOTE: US Army Business Systems using EA Tool ARIS; found 300+ of 760 Logistics systems doing the same thing; Now transitioning without ERP -Do Business Process Review (BPR) internally before choosing software or integrator -If you do use an ERP, ensure the contract has strong disincentives (penalties) for RICE-FW growth. -If you do use an ERP, build in as much functionality into the first increment as possible! Otherwise, be prepared for re-working your RICE-FW elements again. -If you insist on doing an ERP, consider buying from Australians—there are some very good ERP companies in Australia (e.g., MINCOM)
RICEFW means Reports (R), Interface (I), Conversion (C), Enhancements (E), Forms (F) and Workflow (W)

3. Air Force ECSS Lessons Learned
-Failure to understand “as is” and “to be” enterprise architectures -Failure to manage expectations and transition from old culture and new culture gradually -Outsourced major functions to Systems Integrator contractor; Contractor then owns the requirements, not the government! -Acquisition Strategy relied on SI contractor and the Strategy required: -Stable Requirements -Known Costs -Requirements development, translation and allocation is a government function that should NEVER be outsourced -CAPE ICE: “Perverse incentives for contractor performance, particularly for Systems Integrator in creating the custom solution.” -Failure to apply COTS-based Acquisition Strategy -Failure to establish a Metrics Management Program. Did not use EVM; did not promote FFP contracts -Risk Management process not followed -Failure of high level leadership Champion/Mentorship
- Failure to understand "As-Is" & "To-Be" architectures
-Outsourced major functions to Systems Integrator contractor (This relates to having your contractor do BPR, as I mentioned. Doing this, your contractor becomes the de facto builder of the requirements.)
+ Acquisition strategy relied on System Integrator contractor
# Strategy is predicated on stable requirements and known costs
# Requirements development, translation and allocation is a government function that shouldn’t be “outsourced”
# CAPE ICE: “Perverse incentives for contractor performance, particularly for system integrator in creating the custom solution.” (This goes to my point that you must have disincentive for RICE FW development.)
- Failing to apply COTS-based SW acquisition strategy (ERP is not COTS)
- Failing to adequately collect and assess metrics
+ Poor attempt to use EVM; EVM eventually removed from contract
+ Poor use of FFP contract

4. DoD Software Domains and their Impacts on SW Acquisition
Network Cybersecurity Software Architecture
Infrastructure Systems
Modeling & Simulation (M&S) Systems
Not Real Time Data Half-Life
Mix of COTS/GOTS HW/SW architecture
Example: High-Level Architecture (HLA)
Key SW Design is Portable Object Models
Cybersecurity Capabilities
All Systems can use M&S prototypes to train our troops, discover requirements, design and save money.
Real Time Data Half-Life
Mix of COTS/GOTS HW/SW
Key SW Design is Network Performance
Cybersecurity Capabilities
Cloud or Dedicated Servers and Processors
Transport Layer
Infrastructure Systems (e.g., Routing software, Enterprise Cloud Services (e.g., JIE))
Defense Business Systems
(DBS)
Not Real Time Data Half-Life
COTS and Configurable COTS (ERP) HW/SW Architecture
Key SW Design are Privacy and Auditability
Cybersecurity Capabilities
Real time transactions
Cybersecurity Systems
Real Time Data Half-Life
Mix of COTS/GOTS HW/SW architecture
Key SW Design is Defense in Depth
Design based on Required Controls as determined by NIST SP
M&S
Mission Systems
C4ISR Systems
Real Time Data Half-Life
GOTS HW/SW Architecture
Key SW Design is Safety Focus
Cybersecurity Capabilities
Special O/S
Near Real Time Data Half-Life
Key SW Design is Cybersecurity
Cybersecurity Capabilities
Mix of COTS/GOTS HW/SW Architecture
Note: Mission Systems include weapons and mission support equipment (e.g., aircraft); All software systems have embedded software/firmware today.

5. Today, We Learned: The Joint Information Environment (JIE)
The JIE will be the trusted reference model and framework that will enable us to share information when needed, with any mission partner, regardless of location, device, or service provider.
The Benefits of the JIE
Shared, secure interoperable framework that delivers responsive, versatile and decisive actions on any device, anytime, from anywhere on the globe
JIE is the US DoD’s target operational software environment.

6. Today, We Learned:
All PM’s should define what software quality means for their programs from the start; Risk Management and Metrics Management should focus on the PM’s quality definition.
Cybersecurity is now a critical software quality feature in all US DoD Programs.
Cybersecurity must be part of the PM’s quality target definition for their program
Describe the benefits of using EA tools to produce automated software code (Model Driven Software Development (MDSD)).
Auto code is directly linked to your business
Results in higher quality code (less defects), less requirements errors and easier to maintain solution architecture with documentation.
Domain experts can focus on the business processes, not code/technology
Software code is less sensitive to software programmer staff changes.
Best Practice: Never change automated software code.
Guarantees that code generated will follow the architecture principles
Frees up your advanced programmers to focus on the complex parts of your solution architecture that can’t be modeled easily.
Best Practice: Do performance bench-making.
6.8 Describe the “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF).
6.9 Describe the benefits of using EA tools.
6.10 Describe the benefits of using EA tools to produce automated software code (Model Driven Software Development (MDSD)).
6.11 Describe the Open Systems Approach (OSA).
6.12 EXERCISE: Build an Operational, System and Standards View based on a simple military scenario.

7. Today we learned to: Describe the Open Systems Approach (OSA).
Business and Technical interface mandate to ensure best, overall life-cycle costs
USE Architecture to manage your programs
Software Assurance requires Static and Dynamic analysis tools
Software Assurance includes the IT Supply Chain Risks to include HW Firmware (embedded software) Risks (HW Assurance)
Use the 13 Play Playbook to implement an Agile Culture
Use the TechFAR Handbook to contract for Agile
Think about using Cloud solutions in your architecture
Use the CC SRG to ensure Cloud security requirements
Be careful of ERP solutions
Do a thorough analysis of the “as is” software architecture for entire Enterprise before moving to ERP
Use an automated tool to do the Enterprise analysis
Do a Cost-Benefit analysis between moving to an ERP solution and doing database migration
If you do chose an ERP, ensure your contract minimizes the impacts of RICE-FW changes to your life-cycle costs.

8. Questions & Answers
Introduction