1 Acquisition Automation – Challenges and Pitfalls Breakout Session # E11 Name: Jim Hargrove and Allen Edgar Date: Tuesday, July 31, 2012 Time: 2:30 pm-3:45 pm

2 Current Environment Different System Architectures Acquisition System Implementation Summary Acquisition Automation – Challenges and Pitfalls Session Objectives

Current Environment 3 Processes Technology User Adoption

4 Acquisition Systems similar to other business systems Adoption of new technology, including acquisition systems, has had mixed results and benefits Commercial systems don’t address complexity/ uniqueness of Government operations Key business processes are not adequately addressed Actionable business intelligence is just emerging and limited Current Environment – Processes

5 IT architectures are driven by commercial systems Current systems are still stove piped with gaps in cross domain functionality Challenging/expensive integrations to financial systems in many cases Current Environment - Technology

6 User adoption is inconsistent Work arounds and Manual double entry of data are common Systems are not used to full capability Current Environment – User Adoption

7 Challenge: Developing the right combination of end-to-end technology, process and people to meet the agency needs IT Architecture Technology Agency Perspective Business Processes User Adoption Pitfalls: Failure to understand how system fits into agency’s big picture Decisions in each area impact system selection for contract writing automation Acquisition System Implementation Considerations

System Architecture 8 Service Oriented Architecture Integration Centric Application Centric ERP

9 May Impact: Usability Adaptability Flexibility Implementation process and schedule Lifecycle cost Change process and schedule System Architectures – Why it Matters

10 SOA is a set of principles and methodologies for designing and developing software in the form of interoperable services – it is a design philosophy not a product These services are well-defined business functionalities built as software components (discrete pieces of code) Most applications claim to use or be SOA compliant Collection of loosely coupled units of components (services) that can be discovered and invoked dynamically SOA is not database dependent and can leverage a consolidated or multiple different databases System Architectures –Service Oriented Architecture (SOA) – Key Characteristics

11 Advantages Promotes dynamic, agile and effective Changes SOA-based integration simplifies management of distributed resources across multiple platforms Requires less hardware, is standards-based and less costly Disadvantages Single application may generate millions of service message exchanges; managing how these services interact can be complex Security models may no longer suffice when application exposes it capabilities as services used by other applications System Architectures – Service Oriented Architecture (SOA)

12 Collection of both tightly and loosely coupled, standards-based applications, tools and web components (services) Links applications together via an integration layer to facilitate adapter and service based technologies for interaction between components Supports a common business enterprise architecture data structure Each application utilizes its own data structure and security Application data structures mapped to the common data structure System Architectures – Integration Centric Key Characteristics

13 Links Applications Together via an Integration Layer to Facilitate Adapter and Service Based Technologies System Architectures – Integration Centric

14 Advantages Integration layer facilitates system Interaction, data transfer, and reporting Promotes flexibility in changing functionality Integration layer can be expanded to include common services across all applications Disadvantages Requires mapping of multiple APIs to integration layer database Multiple applications and databases to manage and support May limit functionality and strategic and ad hoc reporting Promotes stove pipe application solutions that are independently purchased, managed, and supported System Architectures – Integration Centric

15 System Architectures – Integration Centric Agency Implementation Considerations Best suited when agency wants to keep all or most current business applications Suited for organizations of any size Want system that is designed to meet most standard Government processes and practices Less complex and costly implementations limited to individual applications Only Individual system data migration required Want to enhance multi-system reporting (not full strategic or ad hoc)

16 System Architectures – Application Centric Key Characteristics Primary application may serve as the integration layer for all other required tools, services and applications Multiple applications using their own data structure and security Minimizes duplication of capabilities within the application but not across all applications May include added capability through the addition of bolt- on tools or applications Enhance management and strategic reporting

17 Primary Application May Serve as the Integration Layer for all Other Required Tools, Services and Applications System Architectures – Application Centric

18 Advantages May reduce applications, databases, SW licenses Application Centric Integration layer facilitates system interaction and data transfer Maintains flexible capability to change, add or delete interfaced systems Reduces number of mapping APIs Disadvantages Promotes stove pipe application solutions that are independently purchased, managed, and supported Does not support full strategic and ad hoc reporting Some capabilities are tightly integrated limiting interfaced applications functionality System Architectures – Application Centric

19 Best suited when agency wants to keep all or most current business applications Suited for organizations of any size Want system that is designed to meet most standard Government processes and practices Supports less complex and costly implementations that are limited to individual applications Only single application data migration required Enhances multi-system reporting (not full strategic or ad hoc) System Architectures – Application Centric Agency Implementation Considerations

20 Tightly integrated system using an integration bus Operates in real time (or near real time), without relying on periodic updates Common database supporting all applications Consistent look and feel throughout each module Structured commercial processes and application modules System Architectures – Enterprise Resource Planning (ERP) - Key Characteristics

21 An Integrated System That Operates in Real (or Near Real) Time Without Relying On Periodic Updates System Architectures – ERP

22 Advantages Eliminates separate stove-piped applications and databases Reduces separate applications and licenses Supports real (or near real) time system interaction, data transfer, ad hoc and strategic management reporting Disadvantages Based on structured commercial processes that may not be practical for Federal and DoD organizations Implementation and change process could be complex, difficult, costly and may require problematic customizations Generally supported by third party vendor ERP high costs and consolidation of agency applications increases vendor's sole source negotiating power that could result in higher support, maintenance, and upgrade cost System Architectures – ERP

23 Best suited when there is a need to replace all or most current business applications with ERP Better suited for large organizations with significant number of users Have willingness to change many standard Government processes and practices to commercial processes Have tolerance and resources for complex and costly implementation Significant data migration required System Architectures – ERP Agency Implementation Considerations

Implementation Challenges & Pitfalls 24 Technology Agency Perspective Business Processes User Adoption

25 Challenge : Take advantage of capabilities for efficiency System meets the changing information needs of management Capturing data adds value while reducing workload System flexibility Pitfalls: Don’t underestimate impact of any functionality gaps and how they will be mitigated System customizations can cause life cycle maintenance issues Acquisition System Implementation – Technology

26 Challenge: Using an Acquisition Strategy that optimizes system life cycle Software selection and systems Integrator alignment Government control, expertise and management Service provider considerations Incremental implementation Pitfalls: Ignoring the commercial IT capabilities and development cycle Long acquisition cycles that don’t adjust to changing technology and requirements Acquisition System Implementation – Technology

27 Challenge: Understanding how system fits into agency’s big picture System acquisition goals – Outcome based metrics Alignment to improve agency mission Address internal controls Use of new technology and functionality Acquisition System Implementation – Agency Enterprise Perspective

28 Pitfalls: Failure to include all stakeholders Not assessing impact on all areas Not anticipating change and need for flexibility Not sharing risk and reward between government and industry Acquisition System Implementation – Agency Enterprise Perspective

29 Challenge: Balancing outcome based broad objectives vs detailed requirements Understanding the weaknesses of the current approach Documenting high level requirements Changing processes to take advantage of technology Pitfall: Not recognizing the significant impact commercial systems business processes has on the functional requirements Acquisition System Implementation – Business Processes

30 Pitfalls: Replicating old systems’ processes Allowing functional stovepipes to limit E2E process efficiencies Focusing only on acquisition domain without considering financial requirements Ignoring the big data and management information needs Acquisition System Implementation – Business Processes

31 Challenge: Managing changing requirements – policy and technology don’t stand still Pitfalls: Forgetting that contract management is more an art than a science! Resistance to change in processes Not allowing flexibility for unique situations or changing policies Acquisition System Implementation – Business Processes

32 Challenge: Using Change Management to promote User Adoption Communicate a clear and consistent message Experienced cross-domain resources. Training and system support Pitfalls: Ignoring WIFM – What’s in it For Me? Too little communication Ignoring usability issues Acquisition System Implementation – User Adoption

33 Current State: Implementations have had mixed results in agencies achieving improvements to meet their mission Architecture: Impacts all aspects of system life cycle SOA is a design philosophy not a product Different architectures are better suited to different implementations All architectures have advantages and disadvantages Acquisition Automation - Summary

34 Acquisition Automation - Summary System Implementation: Take advantage of capabilities for efficiency - functionality Understand how system fits into agency’s big picture - mission Balance broad objectives vs detailed requirements - flexibility Use Change Management to promote User Adoption - WIFM

Questions ? 35