Army Business Enterprise Domain Level Architecture ...

  • 2,508 views
Uploaded on

 

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,508
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
54
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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.
  • 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.
  • 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.”
  • 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.
  • 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.
  • 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.
  • 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?
  • 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.
  • 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).
  • This is a SAMPLE Domain Governance Structure that an Army Domain Leader may elect to establish. CIO/G-6 will help Army Domain Leaders to establish these structures by providing sample working group charters, process diagrams and other guidance which Domain Leaders can adapt to their organizations as they see fit.

Transcript

  • 1. Army Business Enterprise Domain Level Architecture Development Process HQDA, CIO/G6, Architecture, Operations, Network and Space (AONS) Army Architecture Integration Cell (AAIC) http://aaic.army.mil June 16, 2005 Joe Paiva, 703-602-6235, Arthur.Paiva@us.army.mil
  • 2. 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.
  • 3. 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
  • 4. The Role of EA in the Army 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
  • 5. 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
  • 6. Federated 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
  • 7. 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
  • 8. 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
  • 9. Cross Mission Area Interoperability 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
  • 10. 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
  • 11. 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
  • 12. 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 from Corning, Inc.
  • 13. 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)
    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
  • 14. 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)
  • 15. 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
  • 16. 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.
  • 17. 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 MQ Series SOA Capable Application eHRS BCS3 GCCS-A XML Data Synch FCS
  • 18. Questions ?
  • 19. Back-Up Slides ..
  • 20. Iterative EA Development 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
  • 21. Army SV-6: System Service Exchange
    • 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.
  • 22. Army SV-6a: BES-IA 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.
  • 23. Army SV-2: Communications
  • 24. Army Enterprise Level SV-5
    • The Army SV-5 ties the Mission Area architecture back to The Army Plan by mapping Title 10 Required Operational Capabilities (ROCs) as found in Section II of The Army Plan to responsible domains.
    • The Army SV-5 provides Mission Area Level detail by identifying specifically which Domains within a Mission Area are responsible for providing specific Operational Capabilities identified in The Army Plan.
  • 25. Army Domain Level SV-5
    • 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).
  • 26. Army Expanded SV-5
  • 27. Army TV-1: BES Standards Profile
  • 28. Modified SV-1 (used as SV-8)
  • 29. Back-Up Slides ..
  • 30. EA Should 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/G6 BEA Team Roles Technical Guidance for Materiel Developers Constrained, Federated Architectures Unconstrained, Stove-Piped Domain Architectures Materiel Developer Input to Domain Architectures
  • 31. Army Interoperability Vision
    • Enterprise Services
      • Core (CES)
      • Business (BES)
  • 32. Sample Domain Organization Stakeholders, Including MACOMs, Participate at All Levels CIO/G6 Support: - Common Tools - Common Templates - Technology Strategy Doctrine Working Group Domain Leader Domain Executive Committee Interoperability Working Group Requirements Working Group Business Process Management Group Single Authoritative Service Providers Service Request & Reply Standards Required Services Taxonomies and Ontology Investment ( Portfolio Management ) Working Group SRS Performance Metrics Working Group