This Information Memorandum (IM) provides information to states concerning the identification, acquisition, and deployment of an Enterprise Architecture within and across automated human services information systems.

This Information Memorandum is intended to clarify current considerations for jurisdictions in their analyses of alternatives and feasibility studies, to include the definition and possible acquisition of broad-based, Enterprise Architectures as a technically viable, cost-reasonable automation solution. The information herein is not new, as the current regulatory requirements for Feasibility Studies, requirements analysis, and APD's still apply. Rather, this information is tailored to address some of the unique questions that may arise when states consider acquiring, with Federal funding, an Enterprise Architecture solution encompassing multiple human services systems.

The Administration for Children and Families (ACF), and Centers for Medicare and Medicaid Services (CMS) are charged with oversight responsibility for information technology (IT) projects that result in automated information systems supporting the programs administered by these Federal agencies. The use of Enterprise Architectures can guide system modernization and should be recognized as a crucial means to a challenging goal: operational agency structures that are optimally defined in both business and technological environments.

Managed properly, an Enterprise Architecture can clarify and help to optimize the interdependencies and relationships among an organization's business operations and the underlying information technology (IT) infrastructure and applications that support those operations.

For these reasons, state human services programs are encouraged to appropriately consider the use of Enterprise Architectures across human services programs as part of any modernization initiative.

For states considering an EA solution to optimize business practices, this document is intended to provide information on meeting certain Federal requirements necessary to secure Federal Financial Participation (FFP) across multiple benefiting agencies. The discussion below is presented in question and answer format, with the intent of providing the reader with useful information.

A. What is the definition of Enterprise Architecture (EA)?

While there is no one definition of EA, it is primarily business-driven, with the goal of transforming a government organization to one that is citizen-centered, results-oriented, and market-based. Its foundation is the Business Reference Model, which describes the government's Lines of Business and its services. This business-based foundation provides a common framework for improvement in a variety of key areas such as:

• Client Outcomes
• Program Efficiencies
• Budget Allocation
• Information Sharing
• Performance Measurement
• Budget/Performance integration
• Cross-Agency Collaboration
• E-Government
• Component-Based Architectures

It is up to the individual state to define the specific framework and foundation that meets the state's needs. As state governments look to identify opportunities to simplify processes and unify work across agencies and within the lines of business of the government, IT systems that support that framework may be necessary.

The Federal government encourages initiatives that improve the delivery of services to benefit recipients. We support the goal of a more citizen-centered, customer-focused government that maximizes technology investments to better achieve mission outcomes. At the same time, our role in this effort is not to identify what the optimal EA would look like in any particular state, but to provide states with the tools and information needed to secure Federal funding in the construction of such an enterprise-based IT system. We believe that the term "Enterprise Architecture" covers a wide and diverse range of implementation activities, from consolidating social welfare programs, to streamlining business practices and service delivery, to establishing statewide standards for software and IT systems that include all agencies of the state government.

B. Do I need to develop a Feasibility Study if my state's Department of Human Services wants to pursue an EA approach to modernizing our portfolio of social service systems?

Yes. This requirement is consistent with all state requests for Federal funding in support of system development or enhancement. All feasibility studies, whether for replacement of a single program system, or for the acquisition of a broader, EA solution, must document and evaluate at least two unique alternatives in addition to the status quo, and must include a meaningful, systematic comparison to address shortcomings in the existing system. The Administration for Children and Families (ACF) has created and provided considerable guidance to states on how to conduct Feasibility Studies, and Alternatives and Cost-Benefit Analyses, all of which is available online on the internet. One such online research and technical assistance site is the Office of Child Support Enforcement's internet website at: http://www.acf.hhs.gov/programs/cse/stsys/dsts_plan_cba.html.

C. Do I need to consider the transfer of other states' systems as one of the alternatives in my feasibility study for an EA?

States are no longer required to transfer-in another state's automated system. System transfer need only be given appropriate consideration as to its viability, applicability, and cost reasonableness in meeting the organizational, functional, and technical requirements of an EA project.

Federal policy mandating systems transfer was rescinded on July 22, 1994 through revised policy issued under ACF Action Transmittal 94-05. Federal regulations at 45 CFR 95.605 of Subpart F, also stipulate that systems transfer be one of the alternatives considered, and that, if transfer is not chosen, that the decision be explained as part of the Feasibility Study submitted with an Implementation Advance Planning Document (IAPD) for Federal funding.

D. Do I need to include all possible programs in the planning and design of an EA, even if they will not actually be acquiring a system as part of the EA in the near future?

Yes. Stakeholder commitment and buy-in at the outset are crucial to a successful EA project. Therefore, a state should do all it can to identify and include all programs that it anticipates will participate in an EA project, whether or not a particular program will be building-out any of its own, program-specific functionality now or in the future. At the same time, we understand that plans can change and there may be instances where a new program is added after the process has begun. All changes should be incorporated into the plan as soon as they are known so that adjustments can be made to the project's cost allocation methodology.

When considering the total cost of an EA project, planning and initial design costs are slight by comparison to the costs that will eventually be incurred in the detailed system design, coding, and testing of applications, and of the installation of operating software and hardware in the EA. The Federal government places great importance on the commitment and buy-in of all initial stakeholders to ensure the success of an EA project. Therefore, for purposes of securing FFP, the failure by the state to consider the initial inclusion of all possible programs for participation in the planning phase of such a project due to the issue of cost is neither reasonable nor acceptable.

E. Do I need to submit for approval one all-encompassing IAPD incorporating all participating agencies in the EA project, or separate IAPDs to each respective Federal agency participating in the EA?

A state must submit a single IAPD to each of the different Federal agencies providing funding for the project. Federal regulations at 45 CFR 95.605 delineate requirements for APD submissions and the fiscal thresholds that apply to IT projects seeking FFP.

The IAPD, and subsequent Annual APD Updates should not only supply the informational content required by Federal regulations, but in doing so also highlight any EA-specific information, as summarized below by section:

In the section of an APD detailing security and interfaces, the narrative descriptions of each of the electronic interfaces to be built as part of the EA project should identify the agency(s) being supported, and the purpose and frequency of each interface.

In the Project Management Plan section, additional discussion of the EA project's distinctive organization and governance is useful, including, an organization chart depicting where the EA project falls within a larger Departmental or even statewide umbrella agency, with narrative describing how governance in such a matrix-based organization will be accomplished.

In the section detailing the proposed budget, in addition to the traditional IAPD budget format and information, Federal reviewers need a second budget view presenting each fiscal year's budget allocated by participating program. This allocated view of the budget will also need to include a sufficiently detailed narrative description and explanation of the "developmental" cost allocation methodology to be used by the EA project.

Finally, for EA projects, the Federal reviewers will request a copy of the Feasibility Study as part of the IAPD submission. States are encouraged to work with their Federal funding partners during the creation of the Feasibility Study for an EA, including the submission in draft of pertinent sections of the study in advance of final IAPD submission. Such collaboration has been shown to not only reduce time-consuming rework, but also expedite the review and approval determinations by the Federal funding agencies.

F. Where do I send my IAPD for acquisition of an EA solution?

Usually, if only one program is funding the development of a project, then a state would send their IAPD for funding directly to the applicable Federal program office for approval. For EA projects, however, multiple Federal funding programs will likely become involved over the life of the project. Therefore, states must submit a hard copy of their IAPD, along with a copy of the underlying Feasibility Study to:

Deputy Assistant Secretary for Administration
Administration for Children and Families, 6th Floor
370 L'Enfant Promenade, SW
Washington, DC 20447
Attn: State Systems Coordinator

Submission of electronic copies of the submitted IAPD and Feasibility Study are encouraged and should be sent to the respective program offices funding any part of the project.

Note that a state agency may also need to submit the IAPD to the Food and Nutrition Service (FNS) if FNS programs are included in the plans.

G. How should I handle the situation of a state program that does not have a Federal administration or agency that reviews IT expenditures, such as the Department of Labor, decides some years after the planning and initial design phases of an EA project are completed, to join in and participate in the EA effort? Do they have to retroactively participate in the prior costs of planning?

No. Despite a state's best efforts, future changes in the level and degree of stakeholder participation in an EA project are bound to occur. Again, as previously stated, we believe that the costs of the planning and initial design phases are minor by comparison to the costs of the construction phases that follow. Therefore, a reallocation and "buy-in" of those already expended planning and design costs, solely in order to reimburse the existing EA stakeholders for their past planning and initial design expenditures, is not warranted.

However, any new planning and/or design costs accruing to the EA project, incurred chiefly to accommodate and incorporate a new stakeholder's participation, shall be borne by that new participating program, and not be allocated among all existing EA stakeholders.

H. How should I handle the issue of cost reimbursement where another state program, such as Labor, decides some years after the design and development phases of the EA project began or were completed, to subsequently join in and participate in the EA?

While payments for costs incurred in prior cycles, if warranted, may be necessary, we believe that in general, retroactive adjustments place an undue reporting burden on state agencies. Appropriate application of the following cost principles will be further monitored through the APD process.

As an aid to costing out the project development, we will be requiring the establishment of measurable, clearly defined phases, wherein groups of costs will be accumulated. These cycles, roughly 2 to 3 years in length, will be based on project stages, state funding cycles, or other tangible measures.

Once a cycle is completed, all costs incurred are allocated to all benefiting agencies. If an additional agency joins during a latter phase, no retroactive adjustment is necessary if the adjustment would be less than $100,000 per quarter. That is, if a re-allocation of all costs from Phase I results in a charge of less than $100,000 per quarter for the newest program, no retroactive adjustments will be necessary. In future phases the newest agency will be added to the allocation plan and charged for common costs, with no obligation to pay for common costs incurred in earlier phases.

If costs greater than $100,000 per quarter, per joining agency, are to be re-allocated, then only the immediately previous cycle's costs need to be re-allocated. Any previous cycles beyond the one immediately prior, including planning phases, need not be re-allocated.

I. Do all benefiting human service programs have to participate in the costs of the EA?

Yes. All benefiting stakeholders, regardless of the percentage of their participation, however large or small, must equitably participate in the costs of the EA through a federally approved cost allocation methodology. The willingness or ability to pay by a benefiting program or agency is not relevant to the assignment of charges.

The Federal funding partners may have a number of specific concerns, foremost being the need to ensure fair and equitable cost distributions. The state should articulate a clear vision of the programs to be included in the EA endeavor. The IAPD must also provide a complete description of the benefits to be received as a result of the expenditure of Federal funds for the project.

We strongly encourage states to consider employing the Cost Allocation Methodology (CAM) Toolkit to generate an acceptable cost allocation plan. As the toolkit was developed specifically for this purpose, it represents a "safe harbor" approach for states. The CAM Toolkit is available at: http://www.acf.hhs.gov/programs/cse/stsys/dsts_plan_ca.html

J. How should I specify the tools and components (operating hardware, software, and services) to be used in the EA?

Tools and components should be specified by use or objective, not by brand name. The intent of the requirement for specification is for any specification used to be cited as an example and not as the only acceptable solution. An overly-definitive specification of architecture can cause the Federal funding agencies to determine the requirements to be arbitrarily prescriptive and grounds for rejection. In order to maximize free and open competition, longstanding Federal regulation and policy prohibits state procurements from stipulating "brand names" in acquisitions unless a state can demonstrate a state standard has been officially adopted. The same policy applies to acquisitions of EA components.

Therefore, it is incumbent on states to ensure that the Feasibility Study for an EA includes the evaluation of various technical requirements or state standards that would meet the specificity identified in the solicitation document. This technical analysis may then provide a rational basis for the subsequent identification of a specific approach, be it a transfer effort, using a Commercial-Off-The-Shelf (COTS) product line, custom development, or a hybrid solution.

K. Is there a specific cost allocation methodology I must use for my EA project?

No. However, it is strongly recommended that the state consider using the CAM Toolkit, developed collaboratively by ACF and CMS within the Department of Health and Human Services, and the Department of Agriculture's FNS. The CAM Toolkit is available online at: http://www.acf.hhs.gov/programs/cse/stsys/dsts_plan_ca.html, and includes a very good question and answer-based section on systems and software development cost allocation principles and practices. If using the CAM Toolkit, please be aware that costs associated with the child welfare program area require an additional level of effort beyond the results arrived at from the use of the tool (see Appendix E of the CAM Toolkit). This is necessary because the CAM Toolkit does not effectively address all of the different funding sources used in the child welfare program area.

Regardless of whether a state chooses to use the CAM Toolkit, or develops a different cost allocation methodology, to receive Federal funding the methodology must be submitted in an approvable APD.

The Federal agencies may consider approving a simplified cost allocation methodology for planning activities that share all costs equally by each participating program. In the event there are very small programs involved, either state or Federal, a secondary cost allocation maybe used. For example, the small participating Federal and state programs could be combined into a single group and assigned a weighted share of the cost based on the relative size of the combined group. Within this combined group, planning costs would be allocated according to the size of the individual program.

For development, the CAM Toolkit handbook recognizes two different program sizes, large and small (refer to question 1.2 in CAM handbook). Considering the number of children in the Foster Care system, we recognize that the program will oftentimes be classified as small. In comparison to the Medicaid, Food Stamps, Child Care, Child Support, and TANF programs, Foster Care is a small program. Nationally, the total Foster Care population is significantly less than one percent of the combined populations of recipients receiving services from the Medicaid, Food Stamps, Child Care, Child Support, and TANF programs.

In developing a cost allocation methodology, the state must consider the relative size of the Foster Care caseload, along with its unique and shared functional requirements. As is the case with all program areas, unique functional requirements must be direct charged to the specific program area(s) benefiting from the unique requirement. The combination of charging small and large programs for unique functional requirements and consideration of the relative sizes of the different programs should result in a more equitable cost allocation being applied across all programs, and limit the impact of undue cost allocation burdens on smaller program areas.

The following information and terms may be of use in understanding cost allocation for software development, such as with an EA project.

1. Cost allocation methodology means the specific method, or approach, a state agency uses to determine each benefiting program's portion of the shared system costs. There is no single "right" cost allocation methodology. For each system development effort, stakeholders in the state agency and Federal benefiting programs work together to develop a mutually agreeable cost allocation methodology. Using this methodology, they determine the proportionate percentage and dollar amount of cost sharing applicable to each benefiting program. The cost allocation methodology documents the proposed Program Share of Cost (%) and Share Amount ($) for each benefiting program. Each Federal benefiting program must approve the state agency's cost allocation methodology submitted in the APD.

2. Cost Allocation Plan (CAP) is the document that state agencies submit to the Department of Health and Human Services' Division of Cost Allocation to describe the cost distribution methodology for system operational costs and other administrative costs not included in the APD.

3. A cost allocation methodology for software development is generally a complex allocation based on "Benefit Received." Benefit Received takes into account the benefiting programs' overall and specific usage of system capabilities, and the level of effort involved to create or modify these system capabilities, adjusted for complexity. It should be noted that "Benefit Received" as used in a cost allocation methodology should not be confused with benefits such as cash assistance or Food Stamps distributed to recipients eligible for public assistance. Refer to Chapter 4 of the CAM Toolkit's Handbook for a more detailed definition and process description for software development cost allocation.

4. Cost allocation methodology for system planning is generally a more simplified allocation based on "any reasonable method." For example, when allocating shared costs for planning a state's system upgrade, the state agency may propose to simply allocate equal cost shares to major benefiting programs. Refer to Chapter 3 of the CAM Toolkit's Handbook for a defined process for distribution of system planning costs.

5. Cost allocation is a decision reached following a process in which state agencies identify, measure, and equitably distribute system costs among benefiting state and Federal public assistance programs.

6. Benefiting program means a state or Federal program that uses capabilities in a state's automated system to help its personnel perform a program function. As an example, if a state's system helps caseworkers determine an applicant's eligibility for different services offered through multiple programs, including Temporary Assistance to Needy Families (TANF), Food Stamps, and Medicaid, all these are considered "benefiting programs" of the state's system and share its costs.

7. Cost allocation involves identifying:

1. Direct costs: Costs that are for functions that exclusively benefit one program. Direct costs are charged only to the single benefiting program.
2. Shared costs: Costs that are for system functions benefiting two or more Federal or state programs. Shared costs must be allocated, or fairly distributed, among all the benefiting programs.

For additional information, please refer to Office of Management and Budget (OMB) Circular A-87 for applicable accounting principles and standards at 2 CFR Part 225.

Finally, states need to be aware that the cost distribution methodology for operations and maintenance expenditures is different from the cost allocation methodology submitted in an APD for software and systems development. For information on cost allocation related to operations and maintenance, please seek assistance from the Division of Cost Allocation (DCA), U.S. Department of Health and Human Services, Office of the Secretary, Office of the Assistant Secretary for Administration and Management, Program Support Center, Financial Management Service. The DCA Website is: http://rates.psc.gov/.

Consistent with their fiduciary and programmatic oversight responsibilities, these Federal agencies support technological solutions that drive down programmatic, developmental, and operational costs, while yielding automated systems that are complete and compliant, fully support program administration responsibilities, and generate substantial financial benefits, all within the context of current Federal statutes and regulations.

To that end, jurisdictions are encouraged to consider the deployment of Enterprise Architectures as part of any future automated human services systems modernization effort.