oversight

Audit of Enterprise Architecture.

Published by the Department of Education, Office of Inspector General on 2002-09-27.

Below is a raw (and likely hideous) rendition of the original report. (PDF)

Audit of Enterprise Architecture

FINAL AUDIT REPORT
ED-OIG/A07-C0001
September 2002

Our mission is to promote the effic iency,
effectiveness, and integrity of the
Departments programs and operations.

U.S. Department of Education
Office of Inspector General
Kansas City, Missouri Office

NOTICE
Statements that managerial practices need improvements, as well as other
conclusions and recommendations in this report
represent the opinions of the Office of Inspector General. Determinations of
corrective action to be taken will be made by the appropriate Department of Education officials.
In accordance with Freedom of Information Act (5 U.S. C.  552) reports
Issued by the Office of Inspector General are available, if requested, to
members of the press and general public to the extent information contained therein is not subject to
exemptions in the Act.

Audit of Enterprise Architecture

Table of Contents

Executive Summary ......1
Audit Results ........3
Finding 1  The Department and FSA are Making Progress in Developing
An Enterprise Architecture But Challenges Remain ....3
Finding 2  The Departments and FSAs IT Architectures Are Not
Integrated ........8
Finding 3  Data Standardization Could Facilitate Program Performance
Evaluation...11
Background ...16
Objective, Scope, & Methodology .19
Statement on Management Controls 20
Appendix I -

General Accounting Offices Enterprise Architecture Maturity
Framework ....21

Appendix II -

Analysis of Departments Progress in Completing an Enterprise
Architecture Based on Steps in the CIO Councils
A Practical Guide to Federal Enterprise Architecture..25

Appendix III-

Analysis of FSAs Progress in Completing an Enterprise
Architecture Based on Steps in the CIO Councils
A Practical Guide to Federal Enterprise Architecture 28

Appendix IV - Auditee Comments on the Draft Report ..32

ED-OIG/AO7-C0001

Audit of Enterprise Architecture

Executive Summary

We reviewed the Department of Educations (Department) and Federal Student Aids (FSA) enterprise
architectures for information technology to determine the status of the development of their
architectures. Specifically, we determined whether (1) the Departments and FSAs enterprise
architecture activities were consistent with the Federal Enterprise Architecture Framework, and (2)
FSAs and the Departments architectures were compatible and interfaced with each other. Although
both the Department and FSA have made progress in laying the groundwork for their enterprise
architectures, critical elements need to be completed; specifically, the architectures need to be
integrated, and data standardization characteristics and techniques need to be fully implemented.
An enterprise architecture is a blueprint for guiding and constraining business and technological change
for an enterprise, which is necessary to ensure that information technology investments are selected,
controlled, and evaluated in context with an overall information technology strategy. The General
Accounting Office (GAO) reported1 that based on a survey of Federal agencies, most agencies were in
the early stages of developing enterprise architectures. Using a scale that included five stages,2 GAO
reported that the Department was at stage two  defined as building the enterprise architecture
management foundation.
We found that the Department has completed the core elements listed in stage two and is currently
performing core elements related to stages three and four. We also determined that FSA is performing
core elements related to stage four, but it had not used an automated tool in developing its enterprise
architecture, which is a core element of stage two. FSA had recently designated a Chief Architect to
provide direction and support for a structured development approach, which is also a core element of
stage two. The Department is lacking the basic building blocks of an architecture, including a final
baseline architecture and target architecture. FSA has completed these building blocks but needs to
complete core elements associated with stage two.

1

Information Technology: Enterprise Architecture Use across the Federal Government Can Be Improved (GAO02-6), February 2002.
2
GAO defined the five stages of maturity in the process of developing an enterprise architecture: Stage 1  creating
enterprise architecture awareness; Stage 2  building the enterprise architecture management foundation; Stage 3 
developing architecture products; Stage 4  completing enterprise architecture products; and Stage 5  leveraging
the enterprise architecture for managing change (see pages 3-4, and Appendix I for a more complete description of
what each stage entails).

ED-OIG/AO7-C0001

Page 1

We also found that the Department had not made any provisions for incorporating FSAs architecture
into a department-wide architecture. As a result of concerns raised by the Office of Management and
Budget (OMB) in its Analytical Perspective on the fiscal year (FY) 2003 budget, the Department and
FSA have committed to working together. However, efforts to integrate the two architectures have
been delayed pending agreement on a Memorandum of Understanding. Without an integrated
department-wide enterprise architecture, the Department and FSA risk acquiring and developing
systems that may not be able to communicate with each other.
Neither the Department nor FSA had fully implemented the use of common identifiers for students and
institutions and had not reached agreement on data characteristics and standards for use in departmentwide system applications. Further, the Department had not established a common data dictionary3 for
departmental and FSA programs. Instead, each Department program uses its own data dictionary for
its own system. The lack of data standards contributes to problems with data quality and reliability,
making it difficult to track students across programs.
We recommend that the Department and FSA (1) complete remaining critical steps in developing an
enterprise architecture; (2) complete the integration of the FSA and Department architecture efforts into
one department-wide architecture through the Enterprise Architecture Working Group and other related
efforts; and (3) agree on common data characteristics and standards from which they can develop a
department-wide data dictionary.
The Department and FSA generally agreed with our findings but disagreed with some
recommendations. We have incorporated their comments, where appropriate, and have summarized
the Departments/FSAs comments and OIGs response at the end of each respective finding. The full
text of the Departments comments are included as Appendix IV.

3

A data dictionary is a repository of information describing the characteristics of data used to design, monitor,
document, protect, and control data in information systems and databases.

ED-OIG/AO7-C0001

Page 2

Audit of Enterprise Architecture
Audit Results

Developing an enterprise-wide information technology (IT) architecture is a challenging and necessary
process to ensure that information technology investments are selected, controlled, and evaluated in a
cost-effective and efficient manner, within the context of an overall information technology strategy. The
Office of Management and Budget (OMB) guidelines state that in creating an architecture, agencies
must identify and document business processes; information flows and relationships; applications, data
descriptions and relationships; and the technology infrastructure. The architecture is then used to
provide a roadmap from an organizations current (baseline) operational and technological environment
toward the desired (target) state. Many Federal agencies are still in the early stages of developing an
information technology architecture. We reviewed the Departments and FSAs enterprise architectures
for information technology to determine whether (1) the architectures were consistent with the Federal
Enterprise Architecture Framework, and (2) FSAs and the Departments architectures were
compatible and interfaced with each other.
Both the Department and FSA have made progress in taking specific actions to lay the groundwork for
their enterprise architectures, however, critical elements need to be completed in order for the
Department and FSA to have a functioning enterprise architecture in place for acquiring and using
systems across the Department in a cost-effective and efficient manner. In addition, the Department and
FSA have not (1) made provisions for integrating their separate enterprise architectures into a
department-wide enterprise architecture, and (2) fully implemented data standardization characteristics
and techniques such as the use of common identifiers for students and institutions for use in departmentwide system applications.

Finding No. 1  The Department and FSA are Making Progress in Developing An
Enterprise Architecture But Challenges Remain

The OMB guidelines4 require Federal agencies to develop and implement enterprise architectures to
provide a framework for evolving or maintaining existing and planned information technology, and for
evaluating investments in terms of the entitys progress toward the desired operational and technological
4

Management of Federal Information Resources, OMB Circular A-130 (November 30, 2000).

ED-OIG/AO7-C0001

Page 3

environment. Federal agencies have been challenged in implementing OMBs guidance for designing
enterprise architectures that guide capital planning and investment decisions. In a 2002 survey5 of
Federal agencies efforts in developing architectures, the General Accounting Office (GAO) determined
that most Federal agencies had achieved stage one or two of an architecture maturity framework, with
the Department at stage two. Guidance issued last year by the Federal Chief Information Officer (CIO)
Council6 provides detailed steps for developing IT architectures to provide a framework for evolving
information systems, developing new systems, and inserting new technologies that optimize an
organizations mission value. The Department and FSA have each completed key steps recommended
by the CIO Council guidance but have a number of critical steps remaining.
GAO evaluated the agencies progress using an enterprise architecture maturity framework, developed
from the CIO Council guidance, that defines five stages of architecture maturity and necessary core
elements (see Appendix I for a more complete description and what steps the Department and FSA
have completed in relation to each stage of maturity):


Stage 1: Creating EA [Enterprise Architecture] Awareness is characterized by
either no plans to develop and use an EA, or plans and actions that do not yet
demonstrate an awareness of the value of having and using one.



Stage 2: Building the EA Management Foundation focuses on assignment of roles
and responsibilities and establishment of plans for developing EA products.



Stage 3: Developing Architecture Products focuses on actual development of EA
products.



Stage 4: Completing EA Products is characterized by complete and approved EA
products that the agency can use to help select and control its portfolio of IT
investments.



Stage 5: Leveraging the EA for Managing Change entails evolving the products according
to a written and approved policy for EA maintenance.

5

Information Technology: Enterprise Architecture Use across the Federal Government Can Be Improved (GAO-026), February 2002.
6
A Practical Guide to Federal Enterprise Architecture, Version 1.0 (February 2001).

ED-OIG/AO7-C0001

Page 4

Based on a survey of Federal agencies, using a scale of stage one to five, GAO reported most agencies
were performing core elements related to stages two and three, with the Departments progress
reported as stage two.7
In our audit, we found that the Department has completed the core elements listed in stage two of
GAOs maturity model and is in the process of performing core elements related to stages three and
four. FSA is performing core elements related to stage four, but it has not completed all of the core
elements defined in stage two because it had not selected or acquired an automated tool in developing
its enterprise architecture. FSA had only recently designated a Chief Architect to provide direction and
support for a structured development approach, which is also a core element of stage two.
Both the Department and FSA have made progress in taking specific actions to lay the groundwork for
their enterprise architectures. However, the Department is lacking some basic building blocks, and
FSA has the building blocks but needs to complete core elements associated with stage two. Both the
Department and FSA need to complete critical elements in order to have a functioning enterprise
architecture in place for acquiring and using systems across the Department in a cost-effective and
efficient manner.
The Departments Status and Critical Elements Remaining
Although the Department is systematically approaching the development of an enterprise architecture,
given its current status of development, the Departments enterprise architecture lacks the basic building
blocks of an architecture. As of the date of our review, the Department had completed its baseline or
documentation of its current architecture, but the document has not been finalized or approved by the
Departments Investment Review Board. The Department is beginning to develop the target or to-be
architecture8 for the future, but it does not plan to begin work on its sequencing plan until the next fiscal
year.
Among the key activities that lie ahead for the Department is the development of its target enterprise
architecture, which includes the collection of crucial information on its proposed business processes,
strategic plans, and requirements. The Department will also need to develop and maintain a sequencing
7

According to the Department official who completed the GAO survey, because the Department and FSA were
working independently in developing separate enterprise architectures, the information provided to GAO was a
departmental perspective and did not consider FSAs progress.
8
As we reported in our final audit report (Control No. A11-C0009), dated September 30, 2002, on the Departments
efforts to implement the Government Paperwork Elimination Act (GPEA), the Department has not developed a GPEA
plan to determine what information processes should be prioritized for automation, which could affect development
of an IT architecture.

ED-OIG/AO7-C0001

Page 5

plan to ensure the successful transition and implementation of its baseline to the target architecture. This
plan would need to consider a variety of factors, such as business goals and operational priorities,
sustaining operations during the transition, and anticipated management and organizational changes.
Active management and trained project personnel, along with effective integration of the enterprise
architecture with other enterprise life cycle processes, will be required to achieve success in using the
enterprise architecture that is developed.
FSAs Status and Critical Elements Remaining
As of the date of our review, FSA had developed an initial enterprise architecture limited to FSA. FSA
has completed its baseline architecture, target architecture, and the sequencing plan for transitioning
from the baseline to the target architectures. In addition, FSA has developed a strategy to support its
baseline and to act as the roadmap for transition to its target environment. Among the key steps that
FSA needs to complete is the establishment of a program management office headed by a permanent
Chief Architect to manage the development and maintenance of the enterprise architecture. FSA has
recently designated a Chief Architect. These management positions are essential for ensuring that
FSAs information technology investments are aligned with the enterprise architecture and optimizing the
interdependencies and interrelationships among business operations and the underlying information
technology that supports them.
According to CIO architect officials, FSAs architecture provides a good operational view of the
enterprise, but it lacks information on the detailed framework layers, which describe all aspects of its
business processes. Without the detailed framework layers, FSAs architecture risks modernization
driven by technology rather than business. FSAs successful development of an enterprise architecture
ultimately depends on effective integration of the enterprise architecture process with the enterprise
business processes.
Another key step FSA needs to complete is the acquisition of an automated support tool to act as a
repository for architecture products. FSA has been testing an automated tool but had not yet acquired
one. Such a tool provides the ability to effectively create and maintain the enterprise architecture
products. CIO Council guidance states that tool standardization is a cost-effective and recommended
best practice, for determining architecture quality and alignment with the
enterprise architecture policy from an acquisition cost perspective and for consistent interoperability of
models. An automated support tool also facilitates analysis between projects within the architecture,
including prioritizing efforts and tracking progress and impact on other projects, as well as, identifying
possible redundancies. (See Appendix II and III for our analysis of the Department and FSAs
progress, respectively, in relation to the CIO Council guidance for developing enterprise architectures.)
ED-OIG/AO7-C0001

Page 6

Sufficiently addressing remaining critical process steps as outlined in the CIO Council guidance and
completing them within reasonable timeframes are crucial as the Department and FSA continue with
development of their enterprise architectures.

Recommendations
1.1

We recommend that both the Department CIO and FSA CIO address the remaining critical
steps outlined in the CIO Council guidance and establish timeframes for completing those steps.

1.2

We also recommend that, similar to the Department, the FSA CIO
-- Select and acquire an automated support tool to act as a repository for architecture products.
-- Thoroughly develop the detailed framework layers to ensure an enterprise architecture driven
by business views.

Department Comments and OIG Response
The Department and FSA concurred with the basic findings in the audit report. The Department and
FSA provided comments regarding the current status of the enterprise architecture efforts. The
combined comments state that they have taken action to address the remaining critical steps outlined in
the CIO Council guidance and have established timeframes for completing those steps. According to
the comments, a Program Management Plan (Plan) was completed in September 2001, and a project
plan was recently prepared and distributed to the Information Management Working Group (IMWG)
for review. The Plan includes milestones and a work breakdown structure that calls for the Department
to have its enterprise architecture in place by September 2003. At the time of our fieldwork, the
Department and FSA had not developed a project plan for addressing critical steps outlined in the CIO
Council guidance and established timeframes for completing those steps. However, once the Plan is
approved and finalized to address the steps outlined in the CIO Council guidance (included as
Appendices II and III of this report) it could address our recommendation.
The comments state that, in June 2002, FSA selected and acquired the Popkin architecture tool to act
as a repository for architecture artifacts, which is a different tool than the one the Department is using.
However, at our July 2002 exit conference, FSA officials stated that they had selected the Popkin
architecture tool, but had not yet acquired it. Since we have not confirmed the acquisition of the
ED-OIG/AO7-C0001

Page 7

architecture tool, we did not amend our recommendation. In addition, Department officials at the exit
conference raised concerns, which we share, regarding the interoperability of the tool with the
Departments tool and the additional costs of obtaining that interoperability.
The comments also state that FSAs Architecture Working Group (AWG) satisfies this element of the
Maturity Model; however, FSA provided no additional information indicating the designation of the
AWG as the program office responsible for overseeing architecture development efforts.
In addition, the comments indicate that the EAWG is currently working on developing detailed
framework layers to ensure an enterprise architecture driven by business views. We commend this
effort to address this recommendation.

Finding No. 2  The Departments and FSAs IT Architectures Are Not
Integrated

We found that the Department and FSA had been working independently in developing separate
enterprise architectures. An enterprise architecture guides and constrains business and technological
changes for an enterprise, which can be an organization, or a functional or mission area spanning more
than one organization (e.g., financial management). In some cases, both organization and functional or
mission area architectures are appropriate, where organizations interrelate closely, sharing functional and
mission area responsibilities. The separate, non-integrated approach followed by the Department and
FSA in developing an architecture is contrary to the basic principles of an information technology
architecture and could prevent the Department from achieving the benefits of an enterprise architecture.
In addition, OMB has expressed concern that the Department and FSA had two separate enterprise
architectures underway, and that those architectures were not integrated.
According to CIO Council guidance, it is critical that enterprise architecture be derived through a topdown incremental approach, consistent with the hierarchical architectural views that are the building
blocks of published architecture frameworks. It is equally important, according to this guidance, that the
higher-level views span the entire enterprise. Only through such an approach can an organization
develop enterprise-wide understanding of the interrelationships and interdependencies among business
operations and supporting technology.

ED-OIG/AO7-C0001

Page 8

In July 1997, the GAO reported9 that the Department did not have an enterprise (systems) architecture.
According to the report, one of the purposes of the enterprise architecture is to ensure that systems are
interoperable. Having an enterprise architecture would reduce the need for the Department to
implement expensive workarounds, such as, computer programs to bridge the gap between the
Department and other data providers systems. According to GAOs report, one of the benefits of a
department-wide enterprise architecture is to standardize system architecture  hardware, operating
systems, application language, and data base management systems. Without systems that have the same
architectural characteristics, accommodations must be made through the use of computer programs to
bridge the gap between the Department and other data providers systems by converting data into
mutually recognizable formats. An enterprise architecture reduces the likelihood of inconsistent system
design and development decisions, and the corresponding increased costs and performance shortfalls.
Without a complete and enforced enterprise architecture, the Department runs the risk of buying and
building systems that are duplicative, incompatible, or unnecessarily costly to maintain and interface.
Although the 1997 GAO report specifically referred to Title IV (FSA) systems, it recommended that
the Secretary of Education direct the Departments Chief Information Officer to develop a departmentwide systems architecture.
In its Analytical Perspectives on the FY 2003 budget, OMBs analyses of the Departments information
technology investments noted the two separate efforts underway in the Department, and stated that the
nonintegrated approach allows for possible duplication of process, systems, and technology.
In preparing the Analytical Perspectives, OMB met with Department and FSA officials to discuss the
Departments enterprise architecture efforts. OMB strongly encouraged the Department to work with
FSA to develop a department-wide enterprise architecture. As a result of OMBs concerns, the
Department and FSA committed to start to work together to integrate their respective IT architectures.
Based on this commitment, under the Departments process improvement milestones included in the
Analytical Perspectives, OMB noted that The agency is working to develop a single, integrated
and comprehensive EA. the Department is undertaking a major reform of the IT security and
testing process and is working to fully integrate all IT into a common process for IT
management.
In its January 2002 draft of the Enterprise Architecture Program Management Plan (PMP), the
Department refers to integrating the two enterprise architectures, specifically, that FSA will be included
in the department-wide enterprise architecture. As of July 2002, the Department and FSA have been in
contact and met three times (December 2001, January 2002, and February 2002) to discuss a high9

Student Financial Aid Information: Systems Architecture Needed To Improve Programs Efficiency (GAO/AIMD97-122), July 1997.

ED-OIG/AO7-C0001

Page 9

level project plan to work toward one integrated enterprise-wide IT architecture. According to
Department officials, the integration effort has been delayed due to difficulty in coming to agreement on
a Memorandum of Understanding between the Department and FSA. The Department recently
organized Information Management Working Group (IMWG) subcommittees with representation
department-wide, one of which is tasked with overall enterprise architecture issues. Although the
commitment to integrate the two architectures is a positive step towards developing a department-wide
enterprise architecture, more aggressive efforts are needed. Without an integrated, department-wide
enterprise architecture, the Department and FSA risk acquiring and developing systems that may not be
able to communicate with other departmental systems.

Recommendations
2.1

We recommend that the Department CIO and FSA CIO complete the integration of the FSA
and Department architecture efforts into one department-wide architecture through the
Enterprise Architecture Working Group and other related efforts.

Department Comments and OIG Response
The Department and FSA concurred with the basic findings of the draft audit report. Their comments
stated that the Department is taking aggressive steps to incorporate FSAs previously separate
enterprise architecture into the Departments enterprise architecture and that now the term enterprise
architecture . . . mean[s] the Department, including FSA, as the enterprise.
Both the Department and FSA disagreed with the recommendation to finalize a Memorandum of
Understanding (MOU). The comments state that an MOU was no longer required because the recently
established EAWG, a chartered subcommittee of the Information Management Working Group
(IMWG), and its steering committee were accomplishing what the MOU was intended to accomplish.
Based on the Departments and FSAs assertion that the EAWG is accomplishing the same objectives,
we agree that a MOU is no longer warranted and have deleted the recommendation. We commend the
Department and FSA for taking action and encourage both the Department and FSA to actively
communicate and continue working together in developing and maintaining a department-wide
enterprise architecture.
According to the Department and FSAs comments, the EAWG is focusing on specific aspects of the
architecture and integration efforts. The comments state that, to date, the EAWG has developed a
Concept Operations paper, a high-level enterprise architecture design, and an integration paper. The
ED-OIG/AO7-C0001

Page 10

comments also state that the timelines for completion of joint working group activities have been
developed through the Enterprise Architecture project plan and work breakdown structure, which was
recently distributed to the IMWG for its review. The comments state that these recommendations
should be deleted from the final report. At the time of our fieldwork, the Department and FSA had
agreed to work jointly in integrating their respective enterprise architecture activities, but had yet to take
action to develop a joint working group or timelines for the completion of activities. While we
commend the Department and FSA for its action to date, addressing this recommendation, they have
not completely integrated the separate architectures, which was the point of our recommendations under
this section. We have modified the recommendations to recommend that the Department and FSA
complete the integration of the architectures.

Finding No. 3  Data Standardization Could Facilitate Program Performance
Evaluation

Data standards are used to govern the conventions for identifying, naming, and formatting data, and are
an important component of an IT architecture. Having such standards in place helps ensure that the
data being collected and maintained within an organization are structured and stored so as to be
accessible, understandable, and comparable across different systems, to everyone in the organization.
The use of common identifiers or data naming conventions across systems is well established as an aid
to data sharing and understandability.
Although GAOs 1997 report recommended that the Department establish standard reporting formats
and data definitions, the Department has only partially done so. For example, neither the Department
nor FSA have fully implemented the use of common identifiers for students and institutions, nor have
they reached agreement on data characteristics and standards for use in department-wide system
applications. Further, the Department has not established a common data dictionary10 for departmental
and FSA programs. Instead, each program uses its own data dictionary for its own system. As a
result, the lack of common identifiers complicates data matching and makes it difficult to track students
across programs. The lack of an integrated department-wide enterprise architecture makes it difficult
for the Department and FSA to fully standardize data elements.

10

A data dictionary is a repository of information describing the characteristics of data used to design, monitor,
document, protect, and control data in information systems and databases.

ED-OIG/AO7-C0001

Page 11

A fully functioning enterprise architecture could resolve data standardization issues. The CIO Councils
Federal Enterprise Architecture Framework highlights the importance of data standardization and states
that
The lack of data integration due to incompatible database structures; poor quality
and integrity of data; and the mixture of organizations, processes, and business
rules with data, hinder data collection, manipulation, and transmission.Data
standardization, including a common vocabulary and data definition, will be
difficult to achieve but is critical. A common organization eliminates redundancy
and ensures data consistency.
As depicted in Figure 3.1, an architecture guides and constrains the development and evolution of
related systems in both logical and technical terms, which includes hardware and software
standardization. First, the architecture logically defines the organizations functions, provides high-level
descriptions of its information systems and their interrelationships, and specifies how and where
information flows. Second, the architecture technically explains operational standards and
characteristics for hardware, software, communications, data, security, and performance.

ED-OIG/AO7-C0001

Page 12

Figure 3.1: Key Logical and Technical Components of a Systems Architecture System11

 Logical Architecture 
Agency Mission
Concept of Operations
Business Functions

----------------------------- Information Flows --------------------------------
System
A

System
B

System
C

System
D

System


E

System
Z

 Technical Architecture 
Hardware Characteristics and Standards
(e.g., expandability, reliability, maintainability, fault tolerance)

Software Characteristics and Standards
(e.g., reliability, testability, flexibility, maintainability, portability, reusability,
adherence to open systems standards, standards for the languages to be used;
institutionalized process standards or methodologies for designing, coding, testing,
and documenting software projects)

Communications Characteristics and Standards
(e.g., reliability, availability, standards for communications protocols)

Data Characteristics and Standards
(e.g., standards for data formats and naming conventions; data dictionary)

Security Characteristics and Standards
(e.g., hardware and software solutions to address security requirements that are
based on a security policy and security concept of operations)

Performance Characteristics and Standards
(e.g., ability to meet operational requirements, response-time requirements,
availability, reliability)

The CIO Councils guidance on enterprise architecture emphasizes the connection between data
standardization and enterprise architecture. The Councils guide  A Practical Guide to Federal
Enterprise Architecture  states that one of the essential reasons for developing an enterprise
architecture includes ensuring that

Student Financial Aid Information: Systems Architecture Needed To Improve Programs Efficiency (GAO/AIMD97-122), July 1997. OIG modified table from original format included in GAO report.

ED-OIG/AO7-C0001

Page 13

the business rules are consistent across the organization, that the data and its
use are immutable, interfaces and information flow are standardized, and the
connectivity and interoperability are managed across the enterprise ...
The CIO Councils guide also states that a target architecture should specify the level of interoperability
needed between data sources and data users and that
Data, as a corporate asset, is key to an organizations vision, mission, goals, and
daily work routine. The more efficiently an Agency gathers data, stores and
retrieves that data, and uses the data, the more productive the Agency.
Information is power. Business processes are best improved by streamlining the
flow and use of data and information.
Currently, the Department has stove-pipe systems that contain information relative to each system
application, but that do not match similar information in other systems. For example, according to a
Department official, the Grant Accounting and Payment System (GAPS) contains financial information
but not program data, so tracking specific costs crossing a number of programs to specific program
goals would be difficult. In addition, different data fields with varying definitions between systems make
it difficult to track the Departments performance across programs. Data standardization can facilitate
the evaluation of program performance. FSA is using middleware12 to interpret the data from different
systems and convert that information into mutually recognizable formats. Although effective, the use of
middleware is not an efficient alternative to data standardization and, as such, should not be considered
a solution to standardization.
As stated earlier, in July 1997, GAO reported that the Department did not have an overall enterprise
architecture; one aspect of developing such an architecture is data standardization. GAO recommended
that the Departments CIO develop a department-wide systems architecture and ensure that it
addressed systems integration, common identifiers, and data standards deficiencies. We found that little
progress has been made department-wide in response to GAOs recommendations for data
standardization. However, the Department has completed a business case detailing plans for
standardizing departmental data in order to achieve quality and more results-based data, a document
required by OMB. According to an official in the Departments Office of the Chief Information Officer
(OCIO), the Department recently initiated a group to work on data standardization and that group is in
the first stages of developing and implementing common identifiers.
12

Middleware is a type of software that permits two or more incompatible applications to exchange information from
different databases.

ED-OIG/AO7-C0001

Page 14

The Department has included data standardization in its action items for the Management Improvement
Team (MIT) and has recently organized IMWG subcommittees with representation department-wide,
one of which is tasked with data standardization issues. Specifically, the Departments Blueprint for
Management Excellence states that it will certify at least 50 percent of major agency and program
databases for data quality, and produce standards and guidelines for agreed-upon national education
data requirements, by September 30, 2002. According to the OCIO official responsible for data
standardization issues, both of these action items are in the early stages, and the database certification
will likely go beyond the target date due to the large number of databases used within the Department.
The official added that the groups goal is still to have a data dictionary in place by September 2002.
The lack of data standards could contribute to problems with data quality and reliability, and complicate
data matching, making it difficult to track students across programs.

Recommendation
We recommend that the Department CIO and FSA CIO
3.1

Develop common data characteristics and standards that can be included within an enterprise
architecture and from which they can develop a department-wide data dictionary.

The Department and FSA Comments and OIG Response
The Department and FSA concurred with the finding and agreed with our recommendation. Their
comments stated that the Department is well on its way to completing a data dictionary and that EAWG
has a Data Dictionary Subcommittee charged with developing a single enterprise data dictionary.
We believe the Department and FSA have made significant progress toward the development and
completion of the dictionary and recommend that they continue to move forward to achieve the desired
result. We commend both the Department and FSA for their current, on-going efforts to complete a
mini-dictionary by the end of FY 2002.

ED-OIG/AO7-C0001

Page 15

Audit of Enterprise Architecture
Background

Reflecting the general consensus in industry that large, complex systems development and acquisition
efforts should be guided by explicit architectures, Congress passed the Clinger-Cohen Act in 199613
requiring Federal Agency CIOs to develop, maintain, and facilitate integrated enterprise architectures.
Additionally, OMB issued guidance for agencies to follow in implementing the Act, including guidance
requiring agencies to document and submit their initial enterprise architecture for OMBs review.
In March 1998, we reported14 that the Department had not fully implemented the Clinger-Cohen Act,
including not developing, maintaining, and facilitating the implementation of a sound and integrated
technology architecture for the Department. Although the Department reported progress on all of the
audit recommendations in the March 1998 report and expected to complete corrective actions by
February 2002, not all corrective actions had been implemented at the time of our review.
Enterprise architectures are essential tools for effectively and efficiently engineering business processes
and for implementing and evolving IT systems. Enterprise architectures can clarify and help optimize the
interdependencies and interrelationships among an organizations business operations and the underlying
information technology infrastructure and applications that support these operations. Employed in
concert with other important information technology management controls, such as portfolio-based
capital planning and investment control practices, enterprise architectures can greatly increase the
chances that organizations operational and information technology environments will be configured in
such a way as to optimize mission performance.
Developing, implementing, and maintaining an enterprise architecture is a dynamic, iterative process of
changing the enterprise over time by incorporating new business processes, new technology, and new
capabilities. The development and implementation of an enterprise architecture requires sustained
attention to process management and agency action over an extended period of time. Moreover, once
implemented, the enterprise architecture requires regular upkeep and maintenance to ensure that it is
13

Previously referred to as the Information Technology Management Reform Act of 1996, Division E of Public Law
104-106, 110 Stat. 679 (1996).
14
The Status of Educations Implementation of the Clinger-Cohen Act, Audit Control Number 11-70007, March 1998.

ED-OIG/AO7-C0001

Page 16

kept current and accurate. Periodic reassessments are necessary to ensure that the enterprise
architecture remains aligned with the Departments strategic mission and priorities, changing business
practices, funding profiles, and technology innovation.
Guidance on Enterprise Architecture Frameworks
In order to assist agencies in complying with the Clinger-Cohen Act requirements, the CIO Council,
the Department of the Treasury, the Department of Defense, the National Institute of Standards
Technology, and GAO have developed architecture frameworks or models that define the content of
enterprise architectures. The CIO Councils guidance15 provides




A Federal framework for the content and structure of an enterprise architecture,
A process for assessing investment compliance with an enterprise architecture, and
A set of management controls for developing, implementing, and maintaining an enterprise
architecture

The CIO Councils guidance includes an appendix detailing the Zachman Framework, which has
become the de facto standard for enterprise architecture development. The Zachman Framework
provides much of the foundation for the Federal Enterprise Architecture Framework (FEAF) and other
frameworks for Federal Departments and Agencies. The CIO Council has issued guidance identifying
three commonly accepted architectural frameworks16 as candidate frameworks. These frameworks
contain essential and supporting products and promote development of architectures that are complete,
understandable, and integratable. Frameworks include concepts that drive the types of architecture
products being created. The products, both graphical and textual, capture the information prescribed
by the framework.
The Departments and FSAs Architecture Frameworks
The Department and FSA are basically using the Zachman-based Framework. The Zachman
Framework outlines six increasingly detailed views or levels of abstraction for six architecture
descriptions. The levels of abstractions are

15

A Practical Guide to Federal Enterprise Architecture, Version 1.0 (February 2001).
The frameworks are: Federal Enterprise Architecture Framework (FEAF); Department of Defense (DoD) Command,
Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance (C4ISR) Architecture Framework;
and Treasury Enterprise Architecture Framework (TEAF)
16

ED-OIG/AO7-C0001

Page 17

1. The Planner or Ballpark View
2. The Owners or Enterprise Model View
3. The Designers or Systems Model View
4. The Builders or Technology Model View
5. The Subcontractors or Detailed Representation View
6. The Functioning Enterprise or Actual System View
And the six architecture descriptionsand the interrogatives that they answerare
1. The Data DescriptionWhat
2. The Function DescriptionHow
3. The Network DescriptionWhere
4. The People DescriptionWho
5. The Time DescriptionWhen
6. The Motivation DescriptionWhy
The Department started out using the FEAF, but according to Department officials, shifted to a
Zachman-based Framework because it provided a more comprehensive framework to capture all of the
information about the enterprise. The FEAF, published by the CIO Council, partitions a given
architecture into business, data, applications, and technology architectures. FSAs approach and
concepts behind their enterprise architecture framework were also adapted from the Zachman
Framework. FSAs framework lists the architecture components, such as Business Architecture,
Information Technology Direction, etc., for each level of abstraction.
FSA as a Performance-Based Organization
The Higher Education Amendments (HEA) of 1998 established a Performance-Based Organization
(PBO)  a discrete management unit responsible for managing the operational functions supporting the
programs authorized under Title IV of the HEA. The responsibilities of the PBO included integrating the
information systems supporting the Federal student financial assistance programs; implementing an open,
common, integrated system for the delivery of student financial assistance under Title IV; and developing
and maintaining a student financial assistance system that contains complete, accurate, and timely data to
ensure program integrity. In order to improve the efficiency and effectiveness of the student aid delivery
system, the Amendments stated that the Secretary and the PBO Chief Operating Officer should
encourage and participate in the establishment of voluntary consensus standards and requirements for
the electronic transmission of information necessary for the administration of programs under Title IV.
ED-OIG/AO7-C0001

Page 18

Audit of Enterprise Architecture

Objective, Scope, and Methodology

The objective of our review was to determine the status of the Departments and FSAs development of
an enterprise architecture. Specifically, we determined whether (1) the Departments and FSAs
enterprise architecture activities were consistent with the Federal Enterprise Architecture Framework,
and (2) FSAs and the Departments architectures were compatible and interfaced with each other.
To accomplish our objective, we reviewed applicable Department and FSA policies and procedures, as
well as laws, regulations, and agency guidelines addressing enterprise architectures. We obtained and
reviewed the documentation of the Department and FSAs enterprise architecture. We interviewed
personnel from the CIOs office within FSA, as well as, personnel in the Departments CIO office.
We also reviewed prior OIG audit reports, along with GAO reports, applicable to systems and
enterprise architecture issues. We evaluated the Department and FSA enterprise architectures
developed to date using the CIO Councils A Practical Guide to Federal Enterprise Architecture and
Federal Enterprise Architecture Framework; and GAOs report Enterprise Architecture Use across
the Federal Government Can Be Improved. In addition, we reviewed the CIO Councils
Architecture Alignment and Assessment Guide; and GAOs Information Technology Investment
Management Framework for additional criteria to use in evaluating the Departments and FSAs
progress in developing enterprise architectures.
We conducted work at the Departments and FSAs CIO offices in Washington, D.C. and our OIG
office in Kansas City, MO, during the period October 2001 to May 2002. We held an exit conference
with Department and FSA officials on July 15, 2002. Our audit was performed in accordance with
government auditing standards appropriate to the scope of the review.

ED-OIG/AO7-C0001

Page 19

Audit of Enterprise Architecture

Statement on Management Controls

As part of our review, we gained an understanding of the Departments management control structure
applicable to the scope of this review. For purposes of this review, we assessed and classified the
significant management controls related to the Departments information technology efforts into the
planning and assessment activities over the Departments and FSAs development of an enterprise
architecture. The assessment also included a determination of whether the processes used by FSA and
the Department provided a reasonable level of assurance of compliance with the Clinger-Cohen Act of
1996.
Because of inherent limitations, and the limited nature of our review, a study and evaluation made for the
limited purpose described above would not necessarily disclose all material weaknesses in the
management control structure. However, our assessment identified management control weaknesses as
set out in the Audit Results section of this report.

ED-OIG/AO7-C0001

Page 20

Appendix I - General Accounting Offices Enterprise Architecture
Maturity Framework

GAOs enterprise architecture maturity framework defines each of the five stages of maturity by
describing the enterprise architecture management core elements associated with each stage as follows:
Stage 1: Creating EA [Enterprise Architecture] Awareness is characterized by
either no plans to develop and use an EA, or plans and actions that do not yet
demonstrate an awareness of the value of having and using one. While Stage 1
agencies may have initiated some EA core elements, these agencies efforts are ad
hoc and unstructured, and do not provide the management foundation necessary
for successful EA development.
Stage 2: Building the EA Management Foundation focuses on assignment of
roles and responsibilities and establishment of plans for developing EA products.
Specifically, a Stage 2 agency has designated a chief architect and established and
staffed a program office responsible for EA development. Further, a steering
committee or group that has responsibility for directing and overseeing the
development has been established and the membership of the steering committee
is comprised of business and IT representatives. At Stage 2, the agency either has
plans for developing or has begun development of at least some of the necessary
EA products. This stage also requires the agency to have selected both a
framework that will be the basis for the nature and content of the specific
products it plans to develop, and an automated tool to help in the development.
Stage 3: Developing Architecture Products focuses on actual development of EA
products. At Stage 3, the agency has defined the scope of its EA as encompassing
the entire enterprise, whether organization-based or function-based, and it has a
written and approved policy demonstrating institutional commitment. Although
the products may not yet be complete, they are intended to describe the agency in
business, data, applications, and technology terms. Further, the products are to
describe the current (i.e., as is) and future (i.e., to be) states and the plan for
transitioning from current to future state (i.e., sequencing plan). Also, as the

ED-OIG/AO7-C0001

Page 21

architecture products are being developed, they are to be subject to configuration
control.
Stage 4: Completing EA Products is characterized by complete and approved EA
products that the agency can use to help select and control its portfolio of IT
investments. The complete products describe the agency in business, data,
applications, and technology terms. Also, the products are complete in that they
describe the agencys current and future states and the transition plan for
sequencing from the current state to the future state. Further, the agencys Chief
Information Officer (CIO) has approved the EA and the agency has a written
policy requiring that IT investments comply with the EA.
Stage 5: Leveraging the EA for Managing Change entails evolving the products
according to a written and approved policy for EA maintenance. Also at this
stage either the steering committee, investment review board, or agency head
approves the EA. Finally, the agency has incorporated the EA into its corporate
decision making and has established and is using metrics to measure the
effectiveness of its EA.
The following tables summarize the Departments and FSAs progress in developing an enterprise
architecture related to each stage of development included in GAOs maturity model framework.

ED-OIG/AO7-C0001

Page 22

The Department had completed, but not finalized its baseline or current architecture and is now
beginning to develop the target or to-be architecture for the future. Table 1.1 compares the
Departments architecture development to GAOs five-stage enterprise architecture maturity
framework.
TABLE 1.1 Status of Departments Enterprise Architecture Efforts Using GAOs Maturity
Model
STAGE

ELEMENTS IN STAGE

Stage 1: Creating Enterprise Agency is aware of Enterprise Architecture.
Architecture Awareness
Committee or group representing the enterprise is responsible for
Stage 2: Building the
directing, overseeing, and/or approving Enterprise Architecture.
Enterprise Architecture
Management Foundation

ELEMENT
SATISFIED
Yes
Yes

Program office responsible for Enterprise Architecture development
exists.
Chief Architect exists.
Enterprise Architecture being developed using framework and
automated tool.
Enterprise Architecture plans call for describing enterprise in terms
of business, data, applications, or technology.
Enterprise Architecture plans call for describing "as is" environment,
"to be" environment, or sequencing plan.
Written/approved policy exists for Enterprise Architecture
development.

Yes

Enterprise Architecture products are under configuration
management.
Enterprise Architecture products describe or will describe
enterprise's business-and the data, applications, and technology that
support it.
Enterprise Architecture products describe or will describe, "as is"
environment, "to be" environment, and sequencing plan.
Enterprise Architecture scope is enterprise-focused.

Stage 3: Developing
Architecture Products

Yes

No

Yes

Yes
Yes
Yes

Yes

Yes
Yes

Stage 5: Leveraging the
Environment Architecture
for Managing Change

ED-OIG/AO7-C0001

Written/approved policy exists for information technology
investment compliance with Enterprise Architecture.

Yes

Enterprise Architecture products describe enterprise's business-and
the data, applications, and technology that support it.
Enterprise Architecture products describe "as is" environment, "to
be" environment, and sequencing plan.
Agency chief information officer has approved Enterprise
Architecture.
Written/approved policy exists for Enterprise Architecture
maintenance.

Yes

Either Enterprise Architecture steering committee, investment review
board, or agency head has approved Enterprise Architecture.
Metrics exist for measuring Enterprise Architecture benefits.

Stage 4: Completing
Architecture Products

No

No
Yes
No

No

Page 23

FSA has developed an initial enterprise architecture limited to FSA. Table 1.2 compares FSAs
architecture development to GAOs five-stage enterprise architecture maturity framework.
TABLE 1.2 Status of FSAs Enterprise Architecture Efforts Using GAOs Maturity Model
STAGE

ELEMENTS IN STAGE

Agency is aware of Enterprise Architecture.
Stage 1: Creating
Enterprise Architecture
Awareness
Committee or group representing the enterprise is responsible for directing, overseeing,
Stage 2: Building the
Enterprise Architecture and/or approving Enterprise Architecture.
Management Foundation

ELEMENT
SATISFIED
Yes

Yes

Program office responsible for Enterpris e Architecture development exists.

No 17

Chief Architect exists.

Yes
Yes 18

Enterprise Architecture being developed using framework and automated tool.

Yes

Enterprise Architecture products describe or will describe enterprise's business-and the
data, applications, and technology that support it.
Enterprise Architecture products describe or will describe, "as is" environment, "to be"
environment, and sequencing plan.
Enterprise Architecture scope is enterprise-focused.

Yes

Written/approved policy exists for information technology investment compliance with
Enterprise Architecture.

No

Enterprise Architecture products describe enterprise's business-and the data,
applications, and technology that support it.
Enterprise Architecture products describe "as is" environment, "to be" environment,
and sequencing plan.
Agency chief information officer has approved Enterprise Architecture.

Stage 4: Completing
Architecture Products

Yes

Enterprise Architecture products are under configuration management.

Stage 3: Developing
Architecture Products

Enterprise Architecture plans call for describing enterprise in terms of business, data,
applications, or technology.
Enterprise Architecture plans call for describing "as is" environment, "to be"
environment, or sequencing plan.
Written/approved policy exists for Enterprise Architecture development.

Yes

Stage 5: Leveraging the Written/approved policy exists for Enterprise Architecture maintenance.

Yes
Yes

Yes
Yes

Yes
Yes
No

Environment Architecture
for Managing Change
Either Enterprise Architecture steering committee, investment review board, or agency
head has approved Enterprise Architecture.
Metrics exist for measuring Enterprise Architecture benefits.

17

No 19
No

FSA contracted with its Modernization Partner, Accenture, to form the Modernization Partner Program Management
Office (PMO), which is charged with providing comprehensive program management activities focusing on the business
goals of the Modernization Program, guidance, and management needed to support the delivery of all Modernization
projects and initiatives. FSAs comments on the draft report contends that its Architecture Working Group (AWG)
satisfies this element of the Maturity Model; however, FSA provided no additional information indicating the designation
of the AWG as program office responsible for overseeing architecture development efforts.
18
FSA used a framework to develop its enterprise architecture but still is in the process of selecting an automated support
tool to act as a repository for architecture products. According to FSAs comments on the draft report, subsequent to
completion of our fieldwork, it selected and acquired the Popkin architecture tool.
19
According to an FSA official, the Deputy Secretary has not signed the last two revisions to the Modernization Blueprint.

ED-OIG/AO7-C0001

Page 24

Appendix II - Analysis of Departments Progress in Completing an
Enterprise Architecture Based on Steps in the CIO Councils
A Practical Guide to Federal Enterprise Architecture

Steps in Enterprise
Architecture Development
Process

Departments
Progress in Steps ( =
completed NC = Not
Completed at this
time)

Obtain executive buy-in and support
Ensure agency head buy-in and
support
Issue executive enterprise architecture
policy
Obtain support from senior executive
and business units




Establish management structure and
control
Establish Technical Review
Committee
Establish Capital Investment Council
Establish EA Executive Steering
Committee
Appoint Chief Architect
Establish EA Program Management
Office
Appoint key personnel for risk
management, configuration
management, and quality assurance
(QA)
Establish Enterprise Architecture core
team
Develop EA marketing strategy and
communications plan
Develop EA program management
plan
Initiate development of enterprise
architecture



Define architecture process and
approach
Define intended use of architecture
Define scope of architecture
Determine depth of architecture
Select appropriate EA products
-- Select products that represent
business of enterprise
-- Select products that represent
agency technical assets
Evaluate and select framework



ED-OIG/AO7-C0001

Examples of Actions
Planned/Taken by
Department

Examples of
Actions Still
To Be
Taken
























Page 25

Steps in Enterprise
Architecture Development
Process

Departments
Progress in Steps ( =
completed NC = Not
Completed at this
time)

Examples of Actions
Planned/Taken by
Department

Select EA toolset



Develop baseline enterprise
architecture
Collect information that describes
existing enterprise
Generate products and populate EA
repository
Review, validate, and refine models



Develop target enterprise
architecture

NC

Phase II - ED Enterprise
Architecture Target
Activities - will develop the
target environment.

NC

Phase III - Transition Plan
Development - will be used
to create the transition plan
or roadmap for moving from
the current to the target
environment.

NC

Phase II - ED Enterprise
Architecture Target
Activities - Target EA for
all business functions and
views will integrate FSA
and external stakeholder
interactions based on the
integration strategies
developed in Phase I. EA
program management and

Examples of
Actions Still
To Be
Taken




Department
CIO personnel
stated that
they were
beginning work
on the target
architecture in
March 2002.

Collect information that defines future
business operations and supporting
technology:
Strategic business objectives
Information needed to support
business
Applications to provide information
Technology to support applications
Generate products and populate EA
repository
Review, validate, and refine models
Develop sequencing plan

Identify gaps
Define and differentiate legacy,
migration, and new systems
Plan migration
Approve, publish, and disseminate
EA products
Use enterprise architecture

ED-OIG/AO7-C0001

The
Departments
projected
completion
date for using
its enterprise
architecture is
September
2002.

Page 26

Steps in Enterprise
Architecture Development
Process

Departments
Progress in Steps ( =
completed NC = Not
Completed at this
time)

Examples of Actions
Planned/Taken by
Department

Examples of
Actions Still
To Be
Taken

governance activities will
continue. EA governance
structures and processes
will be used to review,
validate and approve the
target products.
Integrate EA with capital planning
and investment control and systems
life cycle processes
-- Train personnel
-- Establish enforcement processes
and procedures
-- Define compliance criteria and
consequences
-- Set up integrated reviews
Execute integrated process
Maintain enterprise architecture

NC

Phases I through III will be
completed by November
2002. At that point Phase
IV - EA Maintenance - will
begin and a more detailed
plan, based on the
approved EA Transition
Plan, will be developed.

NC

Phases I through III will be
completed by November
2002. At that point Phase
IV - EA Maintenance - will
begin and a more detailed
plan, based on the
approved EA Transition
Plan, will be developed.

Maintain EA as enterprise evolves
-- Reassess EA periodically
Manage projects to reflect reality
-- Ensure business direction and
processes reflect operations
-- Ensure current architecture reflects
system evolution
-- Initiate new and follow-up projects
-- Prepare proposal
-- Align project to EA
-- Evaluate legacy system
maintenance requirements against
sequencing plan
-- Maintain sequencing plan as
integrated program plan
Continue to consider proposals for
EA modifications

Source: Department of Educations Office of Inspector Generals analysis of Departments enterprise architecture
efforts compared to CIO Councils guidance: A Practical Guide to Federal Enterprise Architecture.

ED-OIG/AO7-C0001

Page 27

Appendix III - Analysis of FSAs Progress in Completing an Enterprise
Architecture Based on Steps in the CIO Councils A
Practical Guide to Federal Enterprise Architecture

Steps in Enterprise
Architecture Development
Process

FSAs Progress in
Steps ( = completed
NC = Not Completed
at this time)

Obtain executive buy-in and
support
Ensure agency head buy-in and
support
Issue executive enterprise
architecture policy
Obtain support from senior
executive and business units



Establish management structure
and control

NC

Establish Technical Review
Committee
Establish Capital Investment
Council
Establish EA Executive Steering
Committee
Appoint Chief Architect
Establish EA Program Management
Office

Examples of Actions
Planned/Taken by
FSA

Examples of
Actions Still To
Be Taken






FSA has not
designated an
Enterprise
Architecture Program
Management Office.




NC

Appoint key personnel for risk
management, configuration
management, and quality assurance
(QA)
Establish Enterprise Architecture
core team
Develop EA marketing strategy and
communications plan

GAO and CIO Council
guidance state
formation of an
enterprise
architecture program
management office is
a best practice in
developing an
enterprise
architecture.



Develop EA program management
plan

FSA has not created a
Program Office for
Architecture within its
organization.



ED-OIG/AO7-C0001




Page 28

Steps in Enterprise
Architecture Development
Process

FSAs Progress in
Steps ( = completed
NC = Not Completed
at this time)

Initiate development of enterprise
architecture



Define architecture process and
approach
Define intended use of architecture
Define scope of architecture
Determine depth of architecture
Select appropriate EA products
-- Select products that represent
business of enterprise
-- Select products that represent
agency technical assets
Evaluate and select framework
Select EA toolset

Examples of Actions
Planned/Taken by
FSA

Examples of
Actions Still To
Be Taken



FSA has tested the Ptech
Framework tool, which the
Department chose as its
tool.

FSA still needs to
adopt an enterprise
architecture support
tool.

FSA has tested, with the
Department, the Ptech
Framework tool for
capturing enterprise
architecture information.

FSA still needs to
adopt an enterprise
architecture support
tool.








NC

Develop baseline enterprise
architecture
Collect information that describes
existing enterprise
Generate products and populate
EA repository
Review, validate, and refine models



Develop target enterprise
architecture
Collect information that defines
future business operations and
supporting technology:
Strategic business objectives
Information needed to support
business
Applications to provide
information
Technology to support
applications
Generate products and populate
EA repository



Review, validate, and refine models



Develop sequencing plan
Identify gaps
Define and differentiate legacy,
migration, and new systems
Plan migration
Approve, publish, and disseminate
EA products





ED-OIG/AO7-C0001
















Page 29

Steps in Enterprise
Architecture Development
Process

FSAs Progress in
Steps ( = completed
NC = Not Completed
at this time)

Use enterprise architecture
Integrate EA with capital planning
and investment control and
systems life cycle processes

NC
NC

-- Train personnel

NC

-- Establish enforcement processes
and procedures
-- Define compliance criteria and
consequences
-- Set up integrated reviews
Execute integrated process




NC

Maintain enterprise architecture

NC

Maintain EA as enterprise evolves

NC

ED-OIG/AO7-C0001

Examples of Actions
Planned/Taken by
FSA

Examples of
Actions Still To
Be Taken

FSA needs to finalize
draft policy and
guidance on the
integration of its
enterprise
architecture with the
capital planning and
investment control
and systems life cycle
processes.
FSA has drafted processes
to provide for education of
staff on architecture issues,
publicity, and
demonstrations of the
architecture using the
Architecture Support
Group. This document was
still in draft form as of
December 2001.



FSA formulated a process
and plan for integrating the
architecture with the
investment projects and
has undertaken projects
that fit within the
sequencing plan for
moving to the target
architecture.
FSA needs to finalize
guidance and policy
on management of
projects and
coordination with
enterprise
architecture.

Page 30

-- Reassess EA periodically

NC

The BTA Process Guide
states that the Architecture
Working Group (AWG) will
review FSA's future
direction and its current IT
architecture, and then make
architectural renewal
determinations.

Manage projects to reflect reality

NC

-- Ensure business direction and
processes reflect operations

NC

-- Ensure current architecture
reflects system evolution

NC

Several documents are still
in draft form.
FSA's BTA Process Guide
outlines processes that are
to be taken to ensure
alignment with business
processes. The BTA Phase
II Business Case also
outlines how FSA will
ensure that IT investments
support key business
objectives and maintain
business relevancy for
technology related
decisions.
Documentation states that
the AWG will review FSAs
future direction and its
current IT architecture, and
then make architectural
renewal determinations.

-- Evaluate legacy system
maintenance requirements against
sequencing plan
-- Maintain sequencing plan as
integrated program plan



Continue to consider proposals for
EA modifications

NC


FSA stated that its AWG
will review future direction
and current architecture,
and then make architectural
renewal determinations.

FSA needs to finalize
draft policy and
guidance on the
Architecture Working
Group and its role in
the enterprise
architecture process.

Source: Department of Educations Office of Inspector Generals analysis of Federal Student Aids enterprise
architecture efforts compared to CIO Councils guidance: A Practical Guide to Federal Enterprise Architecture.

ED-OIG/AO7-C0001

Page 31

Appendix IV  Auditee Comments on the Draft Report

ED-OIG/AO7-C0001

Page 32

REPORT DISTRIBUTION SCHEDULE
Audit Control Number A07-C0001

Action Officials

No. of Copies

Craig B. Luigart
Chief Information Officer
ROB 3, Room 4082
7th and D streets SW
Washington, DC 20202

1

Theresa S. Shaw
Chief Operating Officer
Federal Student Aid
U.S. Department of Education
830 1st Street, N.E.
Washington, DC 20202

1

Other ED Offlicials/Staff (electronic copy)
William D. Hansen, Deputy Secretary
John Danielson, Chief of Staff
Eugene Hickok, Under Secretary
Jack Martin, Chief Financial Officer
Stephen Hawald, Chief Information Officer, FSA
Pamela Jefferson, FSA, Audit Liaison Officer
Barbara Scott, Office of Chief Information Officer
Arthur Graham, Deputy Chief Information Officer for Information Management
Kent Talbert, Deputy General Counsel, Office of General Counsel
Thomas P. Skelly, Director, Budget Service
John Gibbons, Director, Communications
Clay Boothby, Acting DAS, Legislation and Congressional Affairs
Laurie M. Rich, AS, Intergovernmental and Interagency Affairs
Philip Maestri, Director, Finl Improve. & Post Audit Opns, OCFO
Michelle Douglas and Carolyn Adams, OGC (Correspondence Control)
LWanda Rosemond, General Operations Team
Charles Miller, Post Audit Group, OCFO
Headquarters and Regional Audit Managers

1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1 each