Presentation slides
Upcoming SlideShare
Loading in...5
×
 

Presentation slides

on

  • 1,058 views

 

Statistics

Views

Total Views
1,058
Views on SlideShare
1,057
Embed Views
1

Actions

Likes
0
Downloads
8
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • This brief was developed for the purpose of gaining concurrence from Army and DOD leadership with respect to two proposals: Army specific Modified DODAF Templates to be used by all Army Business and Enterprise Information Environment Domain Leaders and Business Information System Material Developers for the purpose of documenting Domain and Program Level Architectures An internal Army process for validating all Army Business and Enterprise Information Environment Domain and System Level Architectures and obtaining “Army Pre-Certification Authority” certification prior to submission of those architectures to OSD for BEA Compliance Certification.
  • The overarching number one priority for the Army CIO/G-6 Army Architecture and Integration Cell (AAIC) Business Enterprise Architecture (BEA) Team is to facilitate the migration of the Army’s business management systems to better support Soldiers in the transformed, Modular Force Structure being implemented in accordance with the Army Campaign Plan. It is the goal of the Army BEA Team to make sure that new systems which are vital to Soldiers are fielded in accordance with their respective IOC schedules and fielding of these systems is not delayed as the result of a failure by the Army to meet legislative or executive requirements relative to system architecture, interoperability or DOD BEA Compliance Certification. CIO/G6 is a supporting organization . With respect to architecture, it is imperative that leadership understand the role of CIO/G6 as a supporting organization whose role is to facilitate the efforts of subject matter experts within the functional areas by providing common architecture tools and templates, as well as technical strategies for interoperability, for Army-wide usage and implementation. Reducing IT spending and compliance with legislation that changes annually must be of secondary concern. Real dollar savings will come from more efficient business operations, NOT decreased IT spending. A 50% cut in the Army IT budget would not yield as much savings (~3B) as a 2% increase in operational efficiency (~$3.6B) that could result from better business information management and enhanced system interoperability. Ask this question: If Clinger-Cohen was repealed tomorrow , and the FY-06 NDAA did not require BEA Certification, would we still need to do this to support transformation of the Army to modular forces capable of dominant operations across the full spectrum of warfare (i.e. develop force sustainment systems that support smaller, geographically dispersed units with smaller footprints in more expeditionary/austere environments)? If the answer is “yes”, then we should stop starting every conversation with “You have to do this because the law…” If the answer is “no”, then we need to get the law changed.
  • This is our Army version of a DOD Model. The DOD version shows Business Mission Threads ending at the Warfighter Mission Area. Our version is modified to show that in the Army Warfighting is our business and our “business systems” are a critical portion of the warfighting mission. For example: Moving an injured soldier from a fighting position or a Stryker vehicle on patrol, to a Battalion Aid Station, then to the USNS Comfort and then back to Germany involves both tactical and strategic ground and air assets, as well as, Soldier tasks, “business” HR and Medical systems, C4ISR and logistics tasks. Attempting to carve out a “Business Architecture” which ignores the third, fourth and fifth order effects to warfighting mission threads created by each of the tasks involved in protecting, treating and moving injured soldiers within and out of the AOR would be foolish. IRB USD P&R USD AT&L USD C W A R F I G H T E R S Real Property & Installation Lifecycle Management Financial Management Materiel Supply & Service Management Weapon System Lifecycle Management Human Resources Management Legal IT HR Plng Budget Design & Dev Procure-ment Storage Transport Main-tenance Dispos-ition IRB IRB IRB
  • It is absolutely critical that Mission Area and Domain leaders understand the scope and magnitude of their responsibilities. An inordinate focus on Portfolio Management is counter-productive to effective management. Domain leaders must establish and document Strategic Plans (including mission statements, goals and objectives) for their functional areas, business process management plans (including BPR when appropriate), CONOPS/Operational Doctrine and Outcomes-Based Performance Metrics. Attempting to document an enterprise architecture, when no strategic plan or business process management plan exists, is like drawing in the dark…. Moreover, attempting to implement “portfolio management” without a well documented enterprise architecture is unlikely to optimize organizational resources and investments .
  • The Army business enterprise can not be compared to any Fortune 100 Company. While some “best business practices” can be adapted and applied to the Army, no organization on earth (with the possible exception of the Navy/Marine Corps) has a business infrastructure anywhere close to the same size or magnitude of complexity as the United States Army. Attempting to develop or implement a single, over-arching architecture for the entire Army Business Enterprise is simply not feasible. Yet, at the same time, having multiple, stove-piped architectures has proven costly and inefficient. A “Federated Architecture,” with collaborative development processes and structured methodologies for aggregation and integration, provides a workable, hybrid model that provides the flexibility and adaptability necessary to be a usable management tool, while breaking the overall task into “manageable chunks” that can be developed and implemented within defined scopes of effort. In a federated architecture, subject matter experts within the Mission Areas and Domains (i.e. functional leaders) manage and document their business processes, defining their own internal business rules and functionality requirements. Architectures are developed collaboratively between domains, services and agencies. Higher echelon architectures limit their focus to “touch points and exceptions.”
  • Most stakeholders already do, and all stakeholders eventually must, recognize that this will be an iterative process which improves with annual version releases. While many, if not most Domain leaders, currently do not have a good grasp of the functional or system requirements their various programs are designed to fulfill, with time and the use of these tools, the ability of Domain leaders to understand and manage their domain information infrastructures will increase (making subsequent versions of the Domain Architectures more complete, accurate and useful as management tools).
  • As depicted above, there is a portion of every domain architecture which includes systems not within the scope of control of that domain. Examples include CSS VSAT which is in the Log and HR Domain Architectures, but clearly is an enterprise infrastructure asset that needs to be managed as part of the EIE portfolio. Not all cross-domain assets are EIE. LDSS is a Warfighter System in the Focused Logistics Domain, but it must be reflected in the Logistics Domain within the BEA because core logistics functions will rely on it. We can’t be afraid to deal with cross domain assets. We just need to have a policy and system fro doing it in such a way as to support the needs of all stakeholders.
  • AAIC is currently coordinating an effort between BCSA (Logistics C2 System being fielded by PEO C3T), OSD(NII)/DISA and FCS to perform a feasibility test of a potential solution strategy for using Information services across a service oriented implementation. Also, PLM+ has been awarded and GCSS-A is implementing portions of the same SAP Netweaver technology that will be the basis of PLM+ to support development of a mobile engine that will provide disconnected operations for GCSS-A (and potentially other CSS applications) via the CSS SATCOM network. The PM for eHRS and Army DIMHRS is also working on a potential technical solution using IBM technology Other efforts may be underway in the Army, possibly within the IDM-T or Fusion.NET efforts or similar programs, with which we (AAIC Business Team) are not yet involved.
  • This process flow diagram comes from the most recent version of the USD(AT&L) CONOPS for DOD BEA Certification. It has been modified to show “Domain Leader Submits” and “Army Validation” where the DOD document showed the generic process depicted below.
  • An architecture is simply a documented presentation depicting in words and pictures what something will look like when it is finished. Architectural drawings of a construction project show owners, developers and other stakeholders what a building, bridge or other structure will look like after it is built or renovated. Similarly, the Army Enterprise Architectures (at the Army, Mission Area, Domain or MACOM levels) must show Army stakeholders the form the organization will take after it is stood up or reorganized. Just as a construction team can not build a complex structure from architectural drawings alone without structural, mechanical, electrical and other detailed design documents prepared by engineers within each discipline, an Army organization can not transform itself or implement a new infrastructure with architectures alone. Transformation and implementation requires detailed designs that are prepared by different groups of subject matter experts within various disciplines using architectural drawings and other documents as guidance. In short, Architecture is a very important tool, but it is only one of many tools needed to manage or transform an organization (or build the infrastructure required to support that organization post-transformation). Enterprise Architectures are Tools…Not End-Products. The majority of architecture development efforts are NOT IT related , but rather go to the documentation and depiction of business processes and requirements. This is especially true at the Domain, Mission Area and Enterprise levels. Architectures must be developed by operational staffs with subject matter expertise directly relating to the operational processes which need to be assessed, redesigned where appropriate and documented/depicted. IT Management is one of many management functions which can be greatly improved through the use of architectures. However, the highest goal of architectures is to improve business operations…not IT . Contrary to popular belief, Architecture Development and IT Portfolio Management are NOT exclusively integrated activities . Architectures make it much easier to effectively manage assets and optimize the effectiveness of portfolio investments, but portfolio investment decisions must be based on a great deal of factors above and beyond architectures.
  • Definitions adapted from an article written by Dawn Meyerriecks (former Director of NCES) Enterprise Management Services – Provides end-to-end GIG performance monitoring, configuration management and problem detection/resolution, as well as enterprise IT resource accounting and addressing, for example, for users, systems and devices. Messaging Services – Provides the ability to exchange information among users or applications on the enterprise infrastructure, such as e-mail, DoD-unique message formats, message-oriented middleware, instant messaging and alerts.  Discovery Services – Provides processes for discovery of information content or services that exploit metadata descriptions of IT resources stored in directories, registries and catalogs (to include search engines). Mediation Services – Helps broker, translate, aggregate, fuse or integrate data. Collaboration Services – Allow users to work together and jointly use selected capabilities on the network—for example, chat, online meetings and work group software. Platform Services – Provides infrastructure to host and organize distributed on-line processing capabilities. Storage Services – Provide physical and virtual places to host data on the network with varying degrees of persistence, such as archiving, continuity of operations and content staging. Security Services – Provides capabilities that address vulnerabilities in networks, infrastructure services or systems. Further, these provide characterizations of the “risk strength” of components as well as “risk posture” of the hosting run-time environment in support of future dynamically composed operational threads. User Assistance Services – Automated “helper” capabilities that reduce the effort required to perform manpower intensive tasks. Accessibility Services – Provides Section 509-compliant interface options to support broad user-base requirements in the DoD community.
  • EIE PfM Challenge: Optimize Army EIE Technology Investments Such as VSAT, ESB and architecture tools Even though they are paid for by many different organizations/domains Issues: How to manage a portfolio of systems owned by different proponents? How to dictate a strategy without dictating a solution? How to make enterprise software license purchases for SOA enablers? How to make enterprise software license purchases for IT tools?
  • As depicted above, there is a portion of every domain architecture which includes systems not within the scope of control of that domain. Examples include CSS VSAT which is in the Log and HR Domain Architectures, but clearly is an enterprise infrastructure asset that needs to be managed as part of the EIE portfolio. Not all cross-domain assets are EIE. LDSS is a Warfighter System in the Focused Logistics Domain, but it must be reflected in the Logistics Domain within the BEA because core logistics functions will rely on it. We can’t be afraid to deal with cross domain assets. We just need to have a policy and system fro doing it in such a way as to support the needs of all stakeholders.
  • In alignment with OSD, Navy and Air Force efforts, CIO/G6 will act as the Pre-Certification Authority (PCA) for Army BEA and EIE Architectures requiring OSD Compliance certification in accordance with NDAA. However, CIO/G6, in its role as PCA, does NOT approve, disapprove or validate operational processes and priorities established by Domain Leaders . The goal and purpose of Army Enterprise Architecture Validation is to identify and facilitate the adjudication of gaps, overlaps and conflicts between Domain architectures. In other words, in the process described above, CIO/G6, G3/TRADOC and ASA(ALT)/G8 are not approving or disapproving business processes or priorities established by ASA-level Domain Leaders . What they are doing in this role, is validating that business processes which directly impact warfighting capabilities of the Army are aligned with the Army’s Warfighting Mission requirements and ensuring that Architectures submitted to OSD for Business Enterprise or EIE Architecture Certification are consistent with other submissions to OSD (such as OMB A-11 Exhibit 300s, Acquisition Plans and FYDP submittals). Note: THE VALIDATION PROCESS IS NOT AN APPROVAL PROCESS . It is a process designed to ensure that different parts of the Army organization do not develop, report or pursue stove-piped plans and programs.

Presentation slides Presentation slides Presentation Transcript

  • A Warriors Guide to Business Architecture This Presentation is NOT endorsed or supported by any Government organization. The views, ideas and concepts are solely and exclusively those of the presenter and do NOT represent any official or unofficial policy. Saving Money and Supporting the Warfighter
  • Purpose of Brief
    • To provide an update about Army efforts to develop and use enterprise architectures and service oriented architectures (SOA).
    • This presentation is Unclassified and will focus on the “Business” side of the Army.
  • DoD and Army Governance Structure Enterprise Information Environment Mission Area (EIEMA) DoD Lead: DoD CIO/ASD(NII) | Army Lead: CIO/G-6 Governance Business Mission Area (BMA) DoD Lead: USD(C) | Army Lead: USA Acquisition Owner: USD(AT&L) | Army Lead: ASA(ALT) Financial Management Owner: USD(C) | Army Lead: ASA(FM&C) Human Resource Management Owner: USD(P&R) | Army Lead: ASA(MR&A) Logistics Owner: USD(L&MR) | Army Lead: ASA(ALT ) Installations & Environment Owner: USD(AT&L) | Army Lead: ASA(I&E) Civil Works Army Owner: ASA(CW) Governance Warfighting Mission Area (WMA) DoD Lead: CJCS | Army Lead: G-3/5/7 Battlespace Awareness Owner: V. Dir Intel, J-2, JS | Army Lead: G-2 Battlespace Communications Owner: V. Dir. C4, J-6, JS | Army Lead: G-6 Focused Logistics Owner: V. Dir. Log., J-4, JS | Army Lead: G-4 Protection Owner: Dep. Dir FP, J-4, JS | Army Lead: G-8 Force Application Owner: Dep. Dir JWCS, JS | Army Lead: G-8 Information Assurance Domain Owner: Director, Information Assurance | Army Lead: CIO/G-6 Communications Owner: D, Wireless | Army Lead: CIO/G-6 Computing Infrastructure Owner: D, Architecture & Interoperability | Army Lead: CIO/G-6 Core Enterprise Services Owner: D, Information Management | Army Lead: CIO/G-6 Governance National Intelligence Mission Area DoD Lead: USD(I) | Army Lead: G-2 Governance In Work In Work Governance National Intelligence Technical Infrastructure Mission Area (NITMA) Owner: ICSIS | Army Lead: In Work Draft Army Alignment with GIG ES Governance 4 Mission Areas: - 15 Domains - 9 Domain Owners
  • Purpose of Army BEA Effort
    • Ensure the Army “To-Be” Business Enterprise fully supports a Modular, Expeditionary Army
      • Joint Interoperability
      • Decrease the In-Theater Sustainment Footprint
      • Make Army Sustainment More Cost-Effective
      • Ensure Required Army Programs meet IOC Goals
    • Compliance
      • Defense Authorization & Appropriation Acts
      • Clinger-Cohen Act and other Congressional Guidance
      • USD(AT&L), USD(C) and other DoD Requirements
      • Executive Orders and other (i.e. OMB) guidance
  • BEA & EIE MUST Align to WMA WMA requirements must be fed into the mission area architectures for the BMA and EIE MA to ensure business systems are fully aligned to the operational needs of the Army. Procurement Disposition Garrison Storage & Transportation Depot Maintenance Human Resources Design & Development Planning, Budgeting IT Infrastructure Legal Field Maintenance Operational Usage Strategic Storage & Transportation WMA Training Medical Services Oriented Implementation Financial Management Real Property & Installation Lifecycle Management Materiel Supply & Service Management Weapon System Lifecycle Management Personnel Management
  • EA is NOT “A CIO Thing” It’s About Better Business Process Management, NOT Computer Systems!
  • Roles of CIO
    • Technical Strategy
    • Support/Assistance
    • Honest Broker/ Facilitator
    • Integrator/Librarian
  • DoD and Army Governance Structure Enterprise Information Environment Mission Area (EIEMA) DoD Lead: DoD CIO/ASD(NII) | Army Lead: CIO/G-6 Governance Business Mission Area (BMA) DoD Lead: USD(C) | Army Lead: USA Acquisition Owner: USD(AT&L) | Army Lead: ASA(ALT) Financial Management Owner: USD(C) | Army Lead: ASA(FM&C) Human Resource Management Owner: USD(P&R) | Army Lead: ASA(MR&A) Logistics Owner: USD(L&MR) | Army Lead: ASA(ALT ) Installations & Environment Owner: USD(AT&L) | Army Lead: ASA(I&E) Civil Works Army Owner: ASA(CW) Governance Warfighting Mission Area (WMA) DoD Lead: CJCS | Army Lead: G-3/5/7 Battlespace Awareness Owner: V. Dir Intel, J-2, JS | Army Lead: G-2 Battlespace Communications Owner: V. Dir. C4, J-6, JS | Army Lead: G-6 Focused Logistics Owner: V. Dir. Log., J-4, JS | Army Lead: G-4 Protection Owner: Dep. Dir FP, J-4, JS | Army Lead: G-8 Force Application Owner: Dep. Dir JWCS, JS | Army Lead: G-8 Information Assurance Domain Owner: Director, Information Assurance | Army Lead: CIO/G-6 Communications Owner: D, Wireless | Army Lead: CIO/G-6 Computing Infrastructure Owner: D, Architecture & Interoperability | Army Lead: CIO/G-6 Core Enterprise Services Owner: D, Information Management | Army Lead: CIO/G-6 Governance National Intelligence Mission Area DoD Lead: USD(I) | Army Lead: G-2 Governance In Work In Work Governance National Intelligence Technical Infrastructure Mission Area (NITMA) Owner: ICSIS | Army Lead: In Work Draft Army Alignment with GIG ES Governance 4 Mission Areas: - 15 Domains - 9 Domain Owners
  • Domain Leader Activities Iterative Feedback Domain Strategic Plan including APG TAP Assignments Business Process Mgmt Plan CONOPS Lifecycle Management Strategic IRM Plan CM Plan COOP Plan SSAA CIR/PIR Assessment Requirements Docs Unit Level Doctrine Detailed Design Docs T&E and Audit/Monitor Plans Build Systems Outcomes Based Performance Metrics System Architecture Portfolio Mgmt Vulnerability Assessment (& PNE) Threat Analyses Domain Architecture Domain Leader Activities PM/PEO Activities Critical Prerequisite
  • Notional Domain Organization Domain Leader Strategic Planning Working Group Requirements Working Group Technical Working Group Strategic Planning Portfolio Management SRS Metrics Army Operational Requirements Army Doctrine Changes & Requirements Joint Requirements System Planning Technical Requirements & Standards Technical COA Analyses & Assessments Domain Level Enterprise Architecture Working Group Domain Action Officer
  • Federated Architecture Approach Army EA Joint Federated Architecture Joint BEA DoD LOG Joint LOG Navy LOG Army LOG AF LOG Army BEA Army WF Army EIE Army Intel OSD LOG GCSS-A PLM+ LMP LDSS The Army is too big to manage as a single monolithic entity; A federated architecture breaks the elephant into interoperable, bite-size segments. Army FM Army I&E Army HR Army CE Navy EA AF EA Legend Collaborative Design Federated Governance Combined Collaborative Design & Governance
  • EA Must Impact Development
    • Analyze & Integrate Domain Architectures
    • Cross Domain Integration
    • Optimization Analyses
      • Bandwidth Reduction Opportunities
      • Footprint Reduction Opportunities
    • Assess Information Assurance Vulnerabilities
    • Develop Technical Strategies &
    • Provide Technical Guidance
    • Interoperability
    • Reduced Footprint
    • COTS Utilization/Optimization
    • Help Domains Develop Architectures
    • Develop & Provide Common Templates
    • Standardize Processes
    • Develop & Teach EA Courses
    PMs Develop & Field Systems CIO EA Team Roles Technical Guidance for Materiel Developers Constrained, Federated Architectures Unconstrained, Stove-Piped Domain Architectures Materiel Developer Input to Domain Architectures
  • EA Is An Iterative Process Recognize Constraints; Change & Improve Continuously. Group Organization By Functions Enterprise Strategic Plan Establish Stakeholder Groups Phase I: Establish Domains Develop Business Process Management Plans High Level Operational Architectures Develop Detailed Architectures Federate Operational Architectures Complete Functional Group Architectures Phase 3: Initial EA Development Phase 4: Iterative Improvement
  • Hybrid Service Oriented Architecture
    • Hybrid Model
    • Enterprise Services provide Interoperability for Common Requirements
    • System-System Interfaces used where required/more effective
    • Enterprise Services
      • Core (CES)
      • Business (BES)
    Intra-Domain Service Bus or Integration Broker System-System Interfaces
  • Three Types of Processes
    • Different Types of Processes Need to be Handled Differently:
    • Transactional Processes – Not good SOA Candidates
    • Verification Processes – Good SOA Candidates
    • Management Processes – Good SOA Candidates
    Concept taken from Corning, Inc.
  • Only Share Some Services
    • Not all processes should be “shared”
    • Some processes are different/unique for a reason
    • 10 roofers are sometimes less efficient than 5 on a small roof
    • 50M Gallons of soda is no cheaper per gallon than 25M (but costs more to store and handle)
    Concept taken from Corning, Inc. Order Capture Product Creation Inventory Receipt Pick Ship Order Capture Product Creation Inventory Receipt Pick Ship Order Capture Product Creation Inventory Receipt Pick Ship Order Capture Product Creation Inventory Receipt Pick Ship Billing AR Posting Delivery Returns Returns Returns Returns Domain Processes Business Enterprise Services Domain Processes
  • Army/DOD Hybrid Architecture GIG-ES USAF-ES Individual Programs and Proponents HR Web- Sphere CW TBD ACQ TBD I&E TBD LOG Net- Weaver FM TBD Domain Integration Brokers/ESBs ARMY LandWarNet Core Enterprise Services (CES)
    • Enterprise Services
      • Core (CES)
      • Business (BES)
  • Current Implementation Concept GIG-ES USAF-ES Individual Programs and Proponents HR Web- Sphere CW TBD ACQ TBD I&E TBD LOG Net- Weaver FM TBD Domain Integration Brokers/ESBs ARMY LandWarNet Core Enterprise Services (CES) Vendor Neutral Services; Published, Discoverable and Re-usable.
  • Sample Implementations LandWarNet - ES DOD GIG-ES
    • Federated ESB/SOI
    • Enterprise Service Bus
    • Services Oriented Implementation
    NMCI - ES GCSS-A LOG SOA Layer PLM+/SAP Netweaver LMP DIMHRS HR SOA Layer e.g. IBM WebSphere SOA Capable Application eHRS BCS3 GCCS-A XML Data Synch FCS
  • EA Template Details
  • Common Templates Are Critical Common Templates
  • Systems Inventory
  • Enterprise Level Domain-Capability Matrix
  • Domain Level Program-Capability Matrix
    • The Army Domain Level SV-5 acts to specifically assign Domain Level ROCs to one or more Programs within the domain.
    • This Matrix specifically enables the tying of MDEP funding lines (occurring at the program level) back to ROCs from The Army Plan (TAP Codes).
  • Domain Level System-Capability Matrix
  • System Service Exchange Matrix
    • Identifies the operational processes being enabled by information systems providing specific services.
    • Enables managing systems development to better support continuously improving (i.e. changing) operational business processes. It also supports Information Assurance and Standards development efforts.
  • Communications Matrix
  • Enterprise Service – Info Assurance Matrix Uses existing standards and tools for data element IA Criticality Assessment, and provides an easy way to assess the level of IA effort each system within the Domain will need.
  • Services Standards Profile
  • Back Up Slides
  • Challenges
    • Data, Data and Data
    • Security, Security and Security
    • Vertically Integrated Tool Sets
    • Governance – Mindset Change
  • Portfolio Management Details
  • DOD BEA Certification Process CIO/G6 Certifies Domain Leader Submits Army Validation
  • Architecture Precedes Portfolio Reviews
    • Domain Architectures are tools used for many things, including Portfolio Management
      • Army Portfolio Management process requires Domains to have validated Domain architectures completed before performing portfolio reviews
    Domain Leaders Complete Domain Architectures G6 Federates Mission Area Architectures Domains Conduct Portfolio Reviews Army Programs Prepare PfM Packages Move Forward Architecture Validation Portfolio Management
  • What Is Enterprise Architecture ? A Tool for Managing Business Processes & Assets NOT Portfolio Management NOT IT/MIS Management Strategic Planning Performance Metrics Enterprise Architecture Business Process Redesign Strategic Planning Performance Metrics Enterprise Architecture
  • The Value of Architecture (1 of 2)
    • Deliver More Effective Systems In Less Time with Less Money
      • Architectures provide a tool to better manage and document requirements. Better requirement definition leads to fewer program cost and schedule overruns.
    • Eliminate “Stove-Pipes”
      • Architectures help identify functional gaps and overlaps
    • Ensure Information Infrastructure Planning Meets Operational Needs
      • Architectures provide a means to forward plan & program bandwidth
    Less Cost & Schedule Overruns Clearly Defined Requirements = LandWarNet Requirements LOG ACQ HR CW I&E
  • The Value of Architecture (2 of 2)
    • Enable Interoperability Between Force Sustainment and Projection Systems
      • Architectures provide common frameworks for technology development, thereby ensuring alignment of technology strategies
    • Make the Army More Adaptable
      • Architectures allow Business Process Management to drive technology (and not technology to drive processes)
    • Enhance Army Joint Warfighting Capabilities
      • Architectures provide common frameworks for the development of solutions which cross services and agencies (e.g. Medical, Logistics, Joint Fires, etc.)
  • Notional CIO Team Organization Army Enterprise Architecture WMA Architecture BattleSpace Comms Domain Architecture BattleSpace Awareness Domain Architecture ForceProtection Domain Architecture EIEMA Architecture BMA Architecture NIMA Architecture … CES Domain Architecture Communications Domain Architecture Computing Infrastructure Domain Architecture Information Assurance Domain Architecture Logistics Financial Management Domain Architecture Human Resources Domain Architecture
  • Core Enterprise Services (CES) Conferencing Shared Information Space Application Sharing Web Conference People Discovery Text Messaging Whiteboard Workspaces Content Delivery Content Discovery Content Store Identity and Metadata Management Enterprise Services Support Infrastructure Net-Centric Applications Service Discovery Service Security Mediation Service Management Service Messaging
  • ESB/Integration Layer Parts
    • Vendor Products
    • BEA – WebLogic
    • IBM – WebSphere Suite
    • Microsoft – BizTalk, etc.
    • Oracle –
    • SAP – NetWeaver
    • Sonic – Sonic ESB
    • Sun –
    • OpenSource Efforts
    • WDI Business Integration Engine
    • MULE Framework
    eXtensibel Style Sheet Language Transformation (XSLT) Maps one XML Schema to another Transformation Not Truly “Standards” … BPNM, BPEL4WS, etc. Intelligent Routing (aka Process Mapping) Not Truly “Standards” … Authentication, Discovery, etc. (WSDL) Universal Description, Discovery & Integration (UDDI) Simple Object Access Protocol (SOAP) Java Messaging (JMS) Standard Provide Common Services Describes XML Services Searchable registry of XML Services RPC Capability for XML Enterprise Messaging between Systems Function Core Enterprise Services Connectivity Communications (aka Message Oriented Middleware) Capability
  • Hybrid Architecture GIG-ES USAF-ES Individual Programs and Proponents HR Web- Sphere CW TBD ACQ TBD I&E TBD LOG Net- Weaver FM TBD Domain Integration Brokers/ESBs ARMY LandWarNet Core Enterprise Services (CES)
    • Enterprise Services
      • Core (CES)
      • Business (BES)
  • Army Pre-Certification Process
    • Ensure Army Business Information Systems beyond FY-2011:
    • Align to WMA (Operational) Architecture; Don’t Create Gaps or Overlaps
      • Business architectures aligned to Army warfighting architecture & operational requirements (G3, in coordination with TRADOC and appropriate Domain leaders, validates OV-5 to APGM/COCOM 127 and Army Doctrine)
    • Align to EIE MA Architecture
      • Will work with future LandWarNet (G6 Validates AV-2, SV-2 and TV-1)
    • Interoperate with Other Business Systems
      • Follow Army technical strategy for interoperability (G6 Validates AV-2, SV-2 and TV-1)
      • Use Army-wide Taxonomies and Ontologies (NetCentric Data Strategy, SW Blocking, JTA, etc.)
    • Do Not Conflict with Other Business AIS; Align with POM
      • Transition Plan matches Army Acquisition Plans and POM (ASA(ALT), in coordination with G8, validates SV-8)
    CIO/G6 Staffs for Domain Leader Army CIO Pre-Certifies To OSD CIO/G6 Submits to OSD Domain Develops Architecture CIO/G6 AAIC Teams with & Supports Domains Domain Leader Approves Architecture Only; NOT PfM G6 Validates X - MA Interop . (SV & TV) CIO/G6 Technical & Interoperability Alignment G3 Warfighting Alignment TRADOC G-8 ASA(ALT) Acquisition Plan & POM Alignment
  • Component Planning Guidance Drives BEA
    • OV-5a and 5b
    • OV-5c
    • SV-5
    • SV-4
    • TV-1
    Army Planning Guidance Memorandum (APGM) TAP Capability Codes (PC code) TRADOC & FM 3-0 Defined Tasks (AUTL/JUTL) Specific Capabilities Task Oriented, IT Enabled Operational Processes Army Doctrine Enabling Information Services *WS Web Services
  • Army “Perspective” Drives Army Process OV-5a & 5b: Required Operational Capabilities (ROC) listed by TAP Code (PCnnnn) from Army Planning Guidance (APG) in Section II of The Army Plan (TAP) SV-4 & 5: Use Cases / IT-Enabled Processes Defined in DoD and Army Regulations and Operating Procedures OV-5c: Specific Tasks/Capabilities Defined in Army Doctrine and Unit Level Doctrine Army BEA Design Process Flow Example Using Logistics Process PC1029: An inland bulk fuel storage and distribution system supporting U.S., joint, and Allied Forces in theaters of operation TRADOC documentation of process(es) by which battalions will order and receive fuel at forward deployed locations including which sub-tasks are IT-enabled Ability for Stryker Battalion S-4 staff to order fuel delivery at forward position and have fuel arrive just before Stryker Battalion Information Services provided by FCS/LDSS and GCSS-A as required to support automated portions of TRADOC developed process for forward fueling SV-4a, 5a & TV-1: Information Services As Implemented in Supporting Information Systems
  • Data Challenge
  • Vertical Toolset Challenge
  • Security Challenge