Architecture Compliance and Requirements Traceability ACART

Architecture Compliance and Requirements Traceability (ACART) Introductory Training ACART Release 2.0 BEA/ACART Product Interdependencies BEA AV-1/2 Scope, Capabilities, and Definition BEA TV-1 Technical Standards BEA SV-5 System Functions BEA SV-1 System Interfaces ACART Scoping Product ACART Assertion Products BEA SV-6 System Data Exchanges Mechanism ICOMs BEA OV-5 Operational Activities BEA OV-2 Operational Nodes I/O ICOMs Control ICOMs BEA Laws, Regulations, & Policies (LRP) BEA OV-3 Information Exchanges BEA OV-6c Operational Processes BEA OV-6c Transaction Data Objects BEA OV-7 Data Model Entities SFIS Elements BEA OV-6a Business Rules 2 Background • The Business Enterprise Architecture (BEA) contains mandatory requirements that a program must adhere to in order to become compliant. The BEA is too extensive and detailed for a program to effectively use without an automated method to filter out the non-applicable parts • ACART (Architecture Compliance and Requirements Traceability Tool) provides a link between the Business Enterprise Architecture (BEA) and Systems/Programs working architecture compliance • The ACART tool does the following: Documents the program’s scope and state of compliancy The automated features within the ACART tool, filter out parts of the architecture that are not relevant to the program assessment. Documents the programs Compliance Plan Provides for Pre-Certification Authority (PCA) Approval of the above Saves an historical record of the program’s assessment Aligns with the BEA Compliance Requirements for assessments 3 Compliance Guidance Summary • Scoping: The program shall choose an entry point into the architecture (for example: Operational Activities) and determine the scope of the project relative to the architecture. Program scoping shall be completed for: Activities, Processes, Data Objects, Data Elements, and Information Exchanges • Assertions: Based on program scope, program managers shall make assertions in the following areas: Laws, Regulations and Policies: The system will enforce LRP. Business Rules: System configuration will be compliant with Rules. Data Entities: The system will use data entities similar in definition. SFIS and Other Initiatives: The system will comply with the initiative • Documentation: The system manager should: Scope, Assert, and Save the system assessment in the system Create a Compliance Plan for items marked less than Compliant to include planned corrective action and Estimated Completion Date in ACART Make assessment available for PCA Review 4 ACART Concept of Operations BEA CERTIFIED ARCHITECTURAL VIEWS Architecture Views Operational Activities Business Processes Data Objects/Entities Business Rules Laws and Regulations GUIDANCE SFIS CHECKLIST INITIATIVES BTA AIDS TO COMPLIANCY Laws, Policies, Regulations Database Program Does Initial Scoping and Assertions for all BEA Facets -- Saves and Downloads 2 ACART Tool BTA Program Develops Activities and Process List Applicable to the Program and enters into ACART Final Approved 4A Architecture Facets In Scope and Asserted To by the Program Spreadsheet of BEA Output ACART Outputs Linked to Program Requirement Database System Requirements Database 3 P R O G R A M 1 4B Correction/Feedback to Architecture 5 Login Process 6 LOGIN Functions • Most Users initially will be pre-registered with view or edit access (using program manager input). • After initial user setup – follow-on registrations will still be approved by the program manager or designated representative, but handled as follows: • Prospective User Registers on line • ACART forwards request to program manager • ACART uses response to complete registration • Individual notified by email of access/userid/pw 7 User Homepage • Links to Programs that individual user has access • Link for Changing Password • Link for Reporting 8 Program Homepage • Links to Scoping and Assertion Pages • Link to Compliance Dashboard • Link to BEA Feedback • Link to ACART Reports Page 9 Step Through the Sieve Process for Scoping and Assertions 10 An Overview: “Scoping and Assertion” 1. 2. 3. 4. 5. 6. 7. 8. Actions as per BEA Compliance Guidance Scoping the Program by Architectural facet Assertion IAW BEA Compliance Guidance Developing A Compliance Plan with ECD’s Save Assessments in ACART Export Assessment To Excel Viewing Program with filter off relative to BEA Interactive Map of Compliance Process 8 7 6 5 3 2 4 1 11 Picture with “Hyperlinks” • All Boxes are Hyperlinks • In the upper left corner of each assessment page is a diagram of the sieve process flow • Left to Right Flows show the multiple Sieve paths: • Blue boxes are areas that must be “Scoped” • Green boxes are areas that must be “Scoped” and “Asserted to” • Yellow Boxes are for Checklists used for High Visibility Compliance areas like SFIS • The colored boxes with borders are all hyperlinks to the appropriate assessment page 12 User Action: Scope the Activities • First Step in Compliance Assertion is to “Scope” Activities 13 User Action: Scope Business Processes • The Second Step in Compliance Assertion is to “Scope” Processes which have now been filtered by the selected Activities 14 User Action: Select and Assert LRP • The user now Scopes LRP which is filtered by the selected Processes and then the user must assert that “Controls are enforced” or “non-compliant” and for “non-compliant” entries…document a plan to get compliant 15 User Action: Scope and Assert to Business Rules from Processes • The user now Scopes Process Related Business Rules which are filtered by the selected Processes. The user must also assert that system is “compliant” or “non-compliant.” For “non-compliant” entries…document a plan to get compliant 16 User Action: Scope Data Objects • Data Objects are linked to Processes and applicable objects must be “scoped” 17 User Action: Scope Data Elements • Data Elements are linked to Data Objects and applicable objects must be “scoped” 18 User Action: Scope and Assert to Business Rules from Data Elements • The user now Scopes Data Related Business Rules which are filtered by the selected Data Elements. The user must also assert that system is “compliant” or “non-compliant”. For “non-compliant” entries…document a plan to get compliant 19 User Action: Scope Information Exchanges • Information Exchanges are linked/filtered from selected Activities 20 User Action: Select and Assert to Data Entity Definitions • The user now Scopes Data Entity Definitions which are filtered by the selected Information Exchanges. The user must also assert that “definitions in agreement” or “non-compliant”. For “non-compliant” entries…document a plan to get compliant 21 User Action: Select System Functions to Determine Applicable SFIS Checklist Items • The User may choose to select “SFIS Checklist – All” and scope/assert to all 211 items…..or…… • The user may select individual system functions to allow scoping and assertions of a more focused list of SFIS checklist items previously determine as applicable to a particular feeder system. • The user is provided a list of system functions which will filter the required SFIS elements – this is important for feeder systems with singular functions which have only a few SFIS elements/checklist items in scope making it easier for the user to comply with guidance 22 User Action: Scope and Assert to Applicable SFIS Checklist Items • The user Scopes and then Asserts to Compliance with the Applicable Checklist Items 23 Reporting And Compliance 24 Reports Homepage Layout • “Desktop” to Pull Systems for which reports are desired • Filters to determine whether to view program only or entire BEA • Dashboard Style Graphical Reports • Compliance Summary Reports • Compliance Plans • System Directory Listing Program Views for which the User has access to edit or view 25 System View Report • Architectural Facets and their descriptions are pulled into the report along with the user’s assessment and remarks 26 Compliance Summary Graphics • Stacked Bar Charts are used to summarize the program assessment as an individual program and relative to the overall BEA 27 Compliance Plan • Once an assessment is fully complete, the “Compliance Plan” will be embedded in the output – No additional work required by the user • Output includes: • Description of Compliancy State • What is being done • Estimated Completion Date 28 State of Completion of Compliance Plan • If an item has been marked “non-compliant” it will show up as “red” on the pie chart unless an Estimated Completion Date for corrective action has been entered. • In the example shown…ten items are non-compliant and 8 do not yet have a plan for correction. 29 Summary • System Functions demonstrated in this briefing: How ACART aids the certification process How ACART filters out “not applicable” pieces of the architecture How reports can be used for program analysis or portfolio analysis How the ACART system retains/documents BEA Compliance Assertions How the ACART system aids a program in preparing Compliance Plan 30 References To access ACART 2.0 or request an account: https://businesstransformationagency.info/ACARTv2/view/ACART/ login.asp For more information, please contact: Valerie Bahena, 703-607-2566 valerie.bahena@bta.mil Ted Hobson, 703-607-1166 ted.hobson.ctr@bta.mil Michael Rader, 703-607-3225 michael.rader.ctr@bta.mil 31