{"id":475,"date":"2023-01-06T20:03:27","date_gmt":"2023-01-06T20:03:27","guid":{"rendered":"https:\/\/guide.dafdto.com\/?p=475"},"modified":"2023-01-11T20:58:32","modified_gmt":"2023-01-11T20:58:32","slug":"general-digital-enterprise-guidelines","status":"publish","type":"post","link":"https:\/\/guide.dafdto.com\/2023\/01\/06\/general-digital-enterprise-guidelines\/","title":{"rendered":"General Digital Enterprise Guidelines"},"content":{"rendered":"\t\t<div data-elementor-type=\"wp-post\" data-elementor-id=\"475\" class=\"elementor elementor-475\" data-elementor-post-type=\"post\">\n\t\t\t\t\t\t<section class=\"elementor-section elementor-top-section elementor-element elementor-element-e15efed elementor-section-boxed elementor-section-height-default elementor-section-height-default\" data-id=\"e15efed\" data-element_type=\"section\">\n\t\t\t\t\t\t<div class=\"elementor-container elementor-column-gap-default\">\n\t\t\t\t\t<div class=\"elementor-column elementor-col-100 elementor-top-column elementor-element elementor-element-31a3f33\" data-id=\"31a3f33\" data-element_type=\"column\">\n\t\t\t<div class=\"elementor-widget-wrap elementor-element-populated\">\n\t\t\t\t\t\t<div class=\"elementor-element elementor-element-32d8199 elementor-widget elementor-widget-text-editor\" data-id=\"32d8199\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t<style>\/*! elementor - v3.20.0 - 13-03-2024 *\/\n.elementor-widget-text-editor.elementor-drop-cap-view-stacked .elementor-drop-cap{background-color:#69727d;color:#fff}.elementor-widget-text-editor.elementor-drop-cap-view-framed .elementor-drop-cap{color:#69727d;border:3px solid;background-color:transparent}.elementor-widget-text-editor:not(.elementor-drop-cap-view-default) .elementor-drop-cap{margin-top:8px}.elementor-widget-text-editor:not(.elementor-drop-cap-view-default) .elementor-drop-cap-letter{width:1em;height:1em}.elementor-widget-text-editor .elementor-drop-cap{float:left;text-align:center;line-height:1;font-size:50px}.elementor-widget-text-editor .elementor-drop-cap-letter{display:inline-block}<\/style>\t\t\t\t<p>\u00a0<\/p><h2>Where and When to Insert DE<\/h2><h3>Does It Matter Where My Program Starts?<\/h3><p>ACQ 101 says the earlier the better, but don&#8217;t use that as an excuse to do nothing. Look for rational inject points such as mods which can be done digitally even if the program is in the dark ages of 2-D paper drawings. Focus on applying DE methods to an existing program to analyze failures or issues, for additional AoAs during the lifecycle, when the environment or operations change, including threat changes, and for change impact analysis (ECBs and CCBs).<\/p><p>\u00a0<\/p><h3>Acquisition Category (ACAT) Considerations<\/h3><p>DE methods are appropriate for all ACAT programs, and for non-ACAT efforts including prototyping. Models allow the effort to progress beyond a prototype accurately and efficiently.<\/p><p>\u00a0<\/p><h3>Insertion Into an Acquisition Lifecycle<\/h3><p>Ideally, using DE methods Pre-MDD and throughout the lifecycle to create a digital thread yields the highest value, but DE methods can be applied at any point in the lifecycle. Focus on modeling system aspects that are broken or need to be changed. Also consider building a digital twin of the final as built system, even if DE methods have not been used throughout the entire lifecycle. This will facilitate successful sustainment, including environment, operations, and requirements changes during operations, and follow-on systems.<\/p><p>\u00a0<\/p><h2>How to Implement DE<\/h2><h3>Acquisition Program Goals<\/h3><p>It is important initially to begin defining the output goals and analysis types required for the Acquisition Program early on, continually revisiting them as the Acquisition Program progresses. Using this approach allows the program to reuse available process models or create custom versions based on the specific needs of Program Management.<\/p><p>Implementation requires understanding of government and contactor technical data flows, current digital capabilities and gaps, workforce competency and infrastructure needs. Contractual considerations include IDE, Model Centric Technical Review, IP, System Model (SM) Delivery, SM Industry Standards Compliance, and Model Interfaces and Formats.<\/p><p>\u00a0<\/p><h3>Processes<\/h3><ul><li>Requirements<\/li><li>Oversight &amp; Review<\/li><li>Contracting<\/li><li>Logistics &amp; Sustainment<\/li><li>Technical<\/li><li>Financial<\/li><li>Scheduling<\/li><\/ul><h3>\u00a0<\/h3><h3>Interfaces<\/h3><p>Use standard and\/or open source interfaces when possible. Look to use either\/both before the considering the use of a proprietary interface.<\/p><p>\u00a0<\/p><h3>Interface Considerations<\/h3><ul><li>Input \/ Output<\/li><li>Data Formats \/ Data Transfer<\/li><li>Ontology<\/li><li>Lexicon<\/li><li>Symbology \/ Syllabary (i.e., \u13a3\u13cf\u13f2)<\/li><\/ul><h3>Input &amp; Output Requirements<\/h3><ul><li>Use standardized and\/or open data transfer types when possible, avoiding proprietary types, increasing future program \/ enterprise agility.<\/li><\/ul><h2>General Guidance on Executing Digital Engineering<\/h2><p>The current AF acquisition construct does not enable enterprise management and the speed of relevancy:<\/p><ul><li>No management of cross-cutting capability investment<\/li><li>Duplicative work to manage external stakeholders\/agencies\/partners<\/li><li>Multiple levels of review inhibiting approval<\/li><\/ul><p>Current AF Engineering Practices are:<\/p><ul><li>Disparate, nonstandard stovepiped data bases of mostly 2D &amp; text data<\/li><li>Empirical Analysis &amp; Independent data analysis by function and mission &#8211; FM, PK, EN, AQ, SL, User<\/li><li>Limited disparate MBE models, no digital thread, no enterprise view<\/li><li>Limited disparate enterprise and mission modeling<\/li><li>Mostly Paper\/PDF and limited model-based CDRLs, reviews, TBLs, deliverables<\/li><li>Shifting from single mission focus to an enterprise focus, will realize operational enhancements, acquisition agility, and resource efficiencies and create substantial improvements in speed, cost, and performance.<\/li><\/ul><p>DE will facilitate this and enable:<\/p><ul><li>Single source of authoritative truth<\/li><li>Enterprise Integrated Master Schedule (IMS)<\/li><li>Internal and external enterprise digital thread with internally and externally integrated system model. including all functions and stakeholders (FM, PK, EN, AQ, SL, User, Contractor)<\/li><li>Model-based Collaboration Environment to support Acquisition and Define\/Maintain Technical Baseline and Technical Data Packages<\/li><li>Continuous insight and improvement to enable agile adjustment as required to respond to changing threats, environment, operations and requirements. to provide enterprise capabilities to Warfighters<\/li><\/ul><p>Effective Digital Engineering Implementation Requires:<\/p><ul><li>Assessment of cultural impacts and socialize enterprise focus and model-based acquisition benefits<\/li><li>Assessment of workforce DE competency, and development plans to address gaps<\/li><li>Development\/adoption\/implementation of DE standards and metrics<\/li><li>Development, implementation, and Configuration Managed of integrated models<\/li><\/ul><h2>Cultural Challenges and Mitigations<\/h2><p>\u00a0<\/p><h3>Job security\u00a0<\/h3><p>People worry about their obsolescence and job security whenever a new technology is introduced.<\/p><p><b>Mitigation<\/b>:\u00a0Commit to providing the training needed to all affected.<\/p><h3>\u201cThat\u2019s not how WE do it!\u201d<\/h3><p>People become comfortable with the status quo; even if the current process is broken, it is considered better than a new one forced on them.<\/p><p><b>Mitigation<\/b>:\u00a0Engage stakeholders in adapting the new tools and processes to their work. Show them how the new way of working will make their jobs easier, better, and more interesting.<\/p><h3>The learning curve<\/h3><p>New tools need new processes; these take time to learn and master. The learning curve is not just personal, organizations are affected as well.<\/p><p><b>Mitigation<\/b>: Have a technology insertion plan. Start with a pilot project to develop a core of expertise; have the pilot team help train and mentor. Adapt processes as experience and the team grows.<\/p><h3>\u201cThis is unknown territory, what if we get lost?\u201d<\/h3><p>Any new approach brings potential for mistakes and some mistakes will be made.<\/p><p><b>Mitigation<\/b>:\u00a0Reach out to the larger MBSE community; learn from each other\u2019s mistakes and share experiences.<\/p><h3>Increases workload for critical staff<\/h3><p>Limited program resources.<\/p><p><b>Mitigation<\/b>:\u00a0Cross training and mentoring.<\/p><h3>Requires MBSE-ready skills<\/h3><p>Both the government team and the contractors\/offerors need working knowledge of modeling languages, object-oriented design, MBSE methods, tools, processes, best practices, etc.<\/p><p><b>Mitigation<\/b>:\u00a0Acquiring MBSE skills will need to be hired in or by training existing employees. Typically, training will be required at different levels and may need to be repeated as technology and tools or processes change.<\/p><h2>Process Challenges and Mitigations<\/h2><p>\u00a0<\/p><h3>Integration<\/h3><p>Information needs to move easily between tools, from process to process, and from person to person.<\/p><p><b>Mitigation<\/b>: Using standard data-exchange formations eases transfers between tools, but the interfaces between processes and people need to be defined and managed. Model the process; not just the product.<\/p><h3>Interoperability tools<\/h3><p>Using standard data-exchange format eases transfers between tools; however, some will not directly support any of the chosen interfaces.<\/p><p><b>Mitigation<\/b>:\u00a0Customer interface tools and\/or processes will be needed. Generalized automated translations are preferred, since they can be performed frequently and consistently<\/p><h3>Interoperability roles<\/h3><p>The new processes for MBSE will have roles that do not match prior processes. Some roles may disappear and others will be created. People\u2019s jobs will change.<\/p><p><b>Mitigation<\/b>:\u00a0Define the roles and responsibilities in the new processes. Provide additional training where needed. Adapt these as the organization\u2019s experience in MBSE grows.<\/p><h3>\u201cHow do we know it\u2019s working\u201d<\/h3><p>Established processes have known measures of progress and success with the experience to back them up. New processes need new ways to measure those properties.<\/p><p><b>Mitigation<\/b>:\u00a0Develop measures of process and the criteria for success. Use them, evaluate them, and adapt those that are not effective. Document this to build a knowledge base.<\/p><h3>Transitions<\/h3><p>Current milestones, entry and exit criteria, and reviewed products will change with MBSE.<\/p><p><b>Mitigation<\/b>:\u00a0Start with the current milestones. Adapt criteria to fit new data formats as needed. As experience grows, change the milestones and data reviewed as makes sense for all stakeholders.<\/p><h3>Continuous model management<\/h3><p>Properly maintaining the model(s) as a single source of truth will require processes to ensure synchronization among models, configuration management, and version control.<\/p><p><b>Mitigation<\/b>:\u00a0Early on, establish and enforce processes to ensure the model is properly maintained, configuration controlled, and version controlled. Use the model to generate content for and drive system, hardware, and software documentation.<\/p><h3>Lack of metrics and measurements<\/h3><p>Currently there is not a well-established and commonly accepted set of measures for applying model-based approach on programs and systems.<\/p><p><b>Mitigation<\/b>:\u00a0Work is ongoing to extend current standard software measurement concepts and techniques, such as quality, size, effort, and cost for model-based approaches.<\/p><h3>Change in acquisition deliverables<\/h3><p>Traditionally, deliverables from acquisitions are document-centric. Acquisition employing MBSE will need to request models and tools as contract deliverables.<\/p><p><b>Mitigation<\/b>:\u00a0Ensure RFPs and contract proposals have mechanisms to ensure access and deliverables for models and tools.<\/p><h2>Tool Cost Challenges and Mitigations<\/h2><h3>Initial investment: core tools<\/h3><p>Infrastructure costs are higher to pay for new tools, tool maintenance, training and platforms. Each stakeholder may have their own suite of MBSE tools.<\/p><p><b>Mitigation<\/b>:\u00a0Establish the policy early for which tools each stakeholder will need and how the tools will be provided, installed, and purchased. Include these costs in the budget to better track expenditures and justify expenses.<\/p><h3>Initial investment: support tools<\/h3><p>MBSE datasets must permit exchange with other supporting engineering and analysis tools.<\/p><p><b>Mitigation<\/b>:\u00a0The approach for data exchange should be established early and implemented in the contracts.<\/p><h3>Initial investment: hardware and software<\/h3><p>Additional hardware and software maybe needed that are not part of the core MBSE tool purchases, such as network and workstation upgrades.<\/p><p><b>Mitigation<\/b>:\u00a0The approach for providing the infrastructure should be established early. Have stakeholders assess their infrastructure needs.<\/p><h3>Initial investment: training<\/h3><p>A core competency in the tools must be established. Formal training may need to be supplemented by hiring new talent and\/or executing pilot projects.<\/p><p><b>Mitigation<\/b>:\u00a0Each stakeholder needs to create a transition plan for MBSE and determine expected costs.<\/p><h3>Maintenance<\/h3><p>All the tools and infrastructure have maintenance costs that may be greater than before. This includes training.<\/p><p><b>Mitigation<\/b>:\u00a0With time, the savings in development costs should offset the maintenance costs, and eventually the initial investment.<\/p><h2>Maturity and Interoperability of Tool Challenges and Mitigations<\/h2><h3>Incompatible or proprietary data formats<\/h3><p>Tools often use proprietary data formats or incompatible data formats that must be translated prior to use.<\/p><p><b>Mitigation<\/b>:\u00a0Include data format or data export format in tool selection and evaluation criteria. Test and pilot tool integration prior to use on acquisition.<\/p><h3>Creating relationships among different views, or perspectives<\/h3><p>Tools must support a diverse range of models and analyses for domains within a system or development process, where each domain applies specialized views and tools to support capturing and analyzing data within those views.<\/p><p><b>Mitigation<\/b>:\u00a0Adopt tools that can exchange data in tool environments that can support multifaceted views and models. Customize data exchange when needed<\/p><h3>Large number of tools to select from (mature and unsupported)<\/h3><p>Numerous tools are required for a complete end-to-end tool chain, and there are many tool choices. It can be difficult to predict which tools will continue to mature and which tools will become unsupported.<\/p><p><b>Mitigation<\/b>:\u00a0Evaluate program needs periodically. Watch the market for tools that can meet program needs.<\/p><h3>Versioning and configuration control of tools<\/h3><p>Software tools are periodically updated. Numerous stakeholders within the supply chain continuously access and manipulate data, potentially utilizing different versions of a tool.<\/p><p><b>Mitigation<\/b>:\u00a0Establish a process within the program that clearly identifies the rules of engagement for tool versioning and configuration management.<\/p><h3>Semantic inconsistency<\/h3><p>Semantics of data is lost during the exchange between tools.<\/p><p><b>Mitigation<\/b>:\u00a0Establish an ontology or common data model that support terminology and data relationships within your program.<\/p><h2>Model Integration Challenges and Mitigations<\/h2><h3>Lack of model integration techniques<\/h3><p>Integrating models is difficult because different languages, different levels of abstraction, different naming. conventions, etc.<\/p><p><b>Mitigation<\/b>:\u00a0Modeling standards and guides can help. Research and testing to develop integration techniques is needed.<\/p><h3>Protecting contractor proprietary information and mission-sensitive information in models<\/h3><p>Some information in models may be sensitive and should be handled appropriately in integrated models where multiple people and teams have access to the models.<\/p><p><b>Mitigation<\/b>:\u00a0Establish and enforce role-based access controls to models. Establish processes to ensure that sensitive data is not integrated into model.<\/p><h3>Ensuring accountability of changes<\/h3><p>On a shared model, it can be easy for users to change the model.<\/p><p><b>Mitigation<\/b>:\u00a0Need role-based access control to models. Establish and enforce processes to ensure model changes are controlled.<\/p><h3>Lack of incremental model change techniques<\/h3><p>Managing incremental model change (i.e., when a change made in one model impacts other models and only the impacted areas should be changed) is difficult.<\/p><p><b>Mitigation<\/b>:\u00a0Research is needed into incremental model change techniques. Strong processes and communication among teams can help.<\/p><h2>Standards and Metrics<\/h2><p>Industry 4.0 \u2013 the Industrial Internet of Things (IIoT) is driving value with increased speed and cost reduction \u2013 examples:<\/p><ul><li>Product design and development with 20% to 50% decreased time to market<\/li><li>85% better forecasts of supply chain capabilities<\/li><li>10% to 20% reduction in costs associated with ensuring manufacturing quality<\/li><\/ul><p>Scaling-up pilot programs to capture the full value of innovative technology requires an action plan addressing 3 questions:<\/p><ul><li>Is the digital strategy driven by measurable business needs?<\/li><li>Do you understand your organization\u2019s digital capabilities and have a plan to fill any gaps?<\/li><li>Do you [or your contactors] have the technology to scale-up, such as having the machines, automation, quality assurance, and distribution capabilities to take advantage of Industry 4.0 productivity improvements?<\/li><\/ul><p>Faster production is squandered if finished parts stack up in the shipping department.<br \/>&#8211;Charles Cassidy and Kevin Goering, McKinsey and Co.<\/p><p>Source: <a href=\"http:\/\/magazine.aerospacemanufacturinganddesign.com\/article\/march-2018\/managing-transformation--in-smaller-enterprises.aspx\">http:\/\/magazine.aerospacemanufacturinganddesign.com\/article\/march-2018\/managing-transformation&#8211;in-smaller-enterprises.aspx<\/a><\/p><h2>Before implementing DE<\/h2><p>\u00a0<\/p><h3>1. Determine metrics that will measure DE effectiveness and drive the improvements you want to achieve with DE &#8211; such as, but not limited to:<\/h3><ul><li>Engineering Change Order (ECO) impact assessment time and effectiveness for all functions &#8211; EN, PK, FM, SL.<\/li><li>Engineering Review Board (ECB) and Change control Board (CCB) approval review and approval time; note that ECB and CCB review and approvals may become continuous and real-time rather than event based<\/li><li>Technical Evaluation time for source sections and contract modifications<\/li><li>Source Selection time<\/li><li>Contractor proposal response time<\/li><li>Contract change order time<\/li><li>Technology Insertion impact assessment and implementation time<\/li><li>AoA time, and frequency and number of alternatives investigated &#8211; initial and throughout development\/production<\/li><li>Technical Review preparation, review and approval times &#8211; PDR\/CDR, FCA\/PCA; note that reviews and approvals may become continuous and real-time rather than event based<\/li><li>Number of liens and waivers &#8211; time to resolve liens and number of waivers<\/li><li>Technology Readiness Assessment (TRA) and Manufacturing Readiness assessment (MRA) or Independent Technical Risk Assessment (ITRA) time and effectiveness<\/li><li>Design and Production time (contractor)<\/li><li>Nonconformance volume and time to resolve<\/li><li>Test time and effectiveness<\/li><li>Acquisition documentation time and CM &#8211; SEP, TEMP, TRD, etc. &#8211; can be model-driven and continuously synchronized<\/li><li>Architecture definition and synchronization &#8211; can be model-driven and continuously synchronized<\/li><\/ul><h3>2. Determine data flow throughout acquisition\/development\/production\/operations\/sustainment life cycle; include contractor data flow and government\/contractor data touch points.<\/h3><p>Determine data needed from the contractor and formats; specify open standards instead of tool or proprietary standards whenever feasible. Include DE deliverables in contract. The following figures define Typical Technical &amp; Product Data Definitions &amp; Relationships and Typical Prime Contractor Technical Data &amp; Configuration Flow. Note that all technical data must be under CM, and that Product Data must also be in the Technical Baseline.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"<p>\u00a0 Where and When to Insert DE Does It Matter Where My Program Starts? ACQ 101 says the earlier the better, but don&#8217;t use that as an excuse to do nothing. Look for rational inject points such as mods which can be done digitally even if the program is in the dark ages of 2-D [&hellip;]<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/posts\/475"}],"collection":[{"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/comments?post=475"}],"version-history":[{"count":16,"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/posts\/475\/revisions"}],"predecessor-version":[{"id":545,"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/posts\/475\/revisions\/545"}],"wp:attachment":[{"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/media?parent=475"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/categories?post=475"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/guide.dafdto.com\/wp-json\/wp\/v2\/tags?post=475"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}