GENERAL SERVICES ADMINISTRATION
Washington, DC 20405
CIO 2110.4
May 24, 2017
GSA ORDER
SUBJECT: GSA Enterprise Architecture Policy
1. Purpose. This Order establishes agency-wide policy, principles, roles and responsibilities for the establishment and implementation of the General Services Administration (GSA) Enterprise Architecture (EA).
2. Cancellations. This Order cancels CIO 2110.3 GSA Enterprise Architecture Policy, dated September 29, 2015.
3. Background. The Clinger-Cohen Act of 1996 requires agency Chief Information Officers (CIO) to oversee the development and maintenance of a sound and integrated agency-wide information architecture. The Office of Management and Budget (OMB), through Circular A-130, has interpreted the information architecture identified in the Clinger-Cohen Act to mean the agency Enterprise Architecture (EA). The E-Government Act of 2002 defines EA as: a strategic information asset base, which defines the mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to changing mission needs, and includes a baseline architecture, a target architecture, and a sequencing plan.
4. Applicability.
a. This Order applies to all GSA organizations and persons in positions with responsibility for using information technology to support business and administrative operations in GSA.
b. This Order applies to the Office of Inspector General (OIG) to the extent that the OIG determines this Order is consistent with the OIG’s independent authority under the IG Act, and it does not conflict with other OIG policies or the OIG mission.
c. This Order applies to the Civilian Board of Contract Appeals (CBCA) to the extent that the CBCA determines that the Order is consistent with the CBCA’s independent authority under the Contract Disputes Act and applicable regulations and court decisions.
5. Roles and responsibilities. The organizational roles and responsibilities listed below are specific to the requirements of the EA practice within GSA.
a. GSA Administrator. The Administrator is responsible for the agency’s Strategic Plan which guides the development and maintenance of the agency’s EA and Capital Planning and Investment Control (CPIC) process.
b. Heads of Service and Staff Offices (HSSOs). The HSSOs and RAs ensure that their organizations actively participate with the Chief Enterprise Architect (CEA) to define their change drivers, business and information management requirements, and performance measures in order to assure that the overall EA supports their Business and Strategy Segment Architecture segments’ goals and objectives. Service and Staff Offices (SSOs) will be responsible for resourcing the development of the OMB approved GSA architecture segments in their business lines;
c. Chief Information Officer (CIO). The CIO is responsible for the IRM Strategic Plan and IT Capital Plan in support of the agency’s Strategic Plan. The IT Capital Plan, being operational in nature, supports the goals and missions identified in the IRM Strategic Plan developed as part of GSA’s EA program.
d. Chief Financial Officer (CFO). The CFO is the responsible authority for all architectural considerations required under the Chief Financial Officers Act of 1990 (the CFO Act) and ensuring the EA and the CPIC processes are integrated with strategic and budget planning.
e. Chief Information Security Officer (CISO). The CISO is responsible for carrying out the Federal Information Security Management Act (FISMA) and acting as the agency-wide information security liaison. Additionally, the CISO and Chief Enterprise Architect (CEA) will ensure appropriate guidance is developed for incorporating security into enterprise and segment architectures.
f. Chief Enterprise Architect (CEA). The CEA is responsible for providing direction for the EA development and maintenance, and ensuring its collaboration with the Federal Enterprise Architecture and with GSA’s partners. GSA’s EA is maintained in the GSA EA Analytics and Reporting (GEAR) tool, accessible at ea.gsa.gov. GEAR is the authoritative source for the application list, the IT Standards profile, the FISMA Systems list, and business capabilities.
6. Policy. The GSA EA is an agency-wide asset that involves the active participation of all program organizations. The EA utilizes GSA’s strategic goals, mission and support services, data, and enabling technologies to communicate the business vision and target architecture in conjunction with the GSA Performance Management, CPIC, and Solutions Life Cycle (SLC) processes. Per OMB Circular No. A-130, the Agency's CPIC process must build from GSA's current EA and its transition to target EA.
a. The GSA EA will support the business needs and priorities expressed through the GSA Strategic Plan and IT Strategic Plan;
b. The GSA EA will be used to support alignment of the GSA IT portfolio;
c. The EA, Policy and Planning Division will provide management oversight of GSA’s EA;
d. The EA, Policy and Planning Division will establish value and performance measures to assess compliance, completion, and results derived directly and indirectly from the use of the GSA EA;
e. GSA IT and the SSOs will develop and maintain segment architectures with support and guidance from the EA, Policy & Planning Division; and
f. GSA IT and the SSOs will support GSA ‘s EA program in accordance with OMB defined methods and practices.
7. Top 10 Agile Architecture Guiding Principles. There are ten key overarching principles to keep in mind when developing an EA. These philosophies should be considered at every step of every stage in the process.
a. EA should be useful for everyone. EA should not be IT-focused. If it is, then it becomes a technology architecture. EA needs to be focused on providing valuable information to users at all levels and from all parts of the organization.
b. Business stakeholders are trusted partners who ultimately own the data. EA should provide the framework and platform to collect EA data so that the information can be understood and communicated consistently across the enterprise. However, it is the business stakeholders who are the owners of the data. EA should never forget that without the business, there is no purpose for the IT.
c. Focus on the data, not the diagrams. At the enterprise level, the focus needs to be on the data and ensuring it is useful for everyone. Models most often provide value at the solution architecture level. There is a fundamental shift in EA occurring with the transition from a model focused EA to one that is centered around the data. The data can then be provided to users to answer the questions they want asked.
d. Visualizing the EA data is key. Data that is collected as part of the EA must be visible to the agency community. This needs to be done with no additional software downloads, i.e. through a standard browser. It should not be kept in databases only visible to the EA team, or worse, spreadsheets that become out of date as soon as the newest spreadsheet is created. Simple, consumable data is better than overly complex data that will limit the number of interested users.
e. Good architecture is about design intent. Changes will happen. Communicate often on the front end to understand the requirements for the architecture. Gather requirements from stakeholders, both within the organization and external (i.e., Office of Management and Budget). Then design the architecture with the expectation that unanticipated changes will come. With good design intent, adjustments can be made to the architecture without damaging its original purpose.
f. Reduce redundant data calls by reusing EA data. Reuse data to the maximum extent possible. Find common data attributes that can be reused across the organization to reduce the need for redundant data calls. Direct users across your enterprise to the EA solution to allow them to answer their questions themselves. This allows the EA team to stop being the “middleman.” Additionally, use the data to answer external data calls with a simple export.
g. Single EA application. To be effective EA data should be stored in one central repository, removing any questions or doubt regarding where to find the authoritative information. Multiple applications and multiple data formats will lead to inconsistencies, gaps, and confusion. A single application will simplify the process for developing the user front end.
h. EA does not enforce, it informs. EA cannot be an enforcement mechanism. The focus of the EA team is to provide authoritative and accurate data to users at all levels of the organizations. This focus allows the agency to make informed, data driven decisions. Additionally, if EA becomes the authoritative source for senior leadership to make planning decisions, project owners will seek to be included in the EA.
i. EA is never complete. There should be no expectation of a grand final state of the EA. Even when there is a complete inventory of the important parts of the enterprise, there will continue to be work maintaining the information, as well as using it to help guide future state decisions.
j. Deliver business value quickly. When building out a new EA based on the agile approach, it is extremely important to deliver business value within the first few months.
8. References.
a. The Clinger-Cohen Act, (Pub. L. 104-106, Division E), National Defense Authorization Act for Fiscal Year 1996
b. OMB Circular A-11, Preparation, Submission and Execution of the Budget
c. OMB Circular A-130, Management of Federal Information Resources
d. E-Government Act, (Pub. L. 107-347), E-Government Act of 2002
e. Federal Enterprise Architecture, Office of Management and Budget webpage
9. Contacts. The EA team is available to answer questions and provide support via email to ea_planning@gsa.gov.
10. Signature.
/S/_________________________________________
DAVID SHIVE
Chief Information Officer
Office of GSA IT
U.S. General Services Administration