Joint Financial Management Improvement Program

Forum Highlights: Keys to Successful Integration/Interoperability of Business Management Systems

 May 27, 2004

## Key Points

The Private Sector Council, the Chief Financial Officers (CFO) Council Systems/E-Government Committee, and the Joint Financial Management Improvement Program (JFMIP) sponsored this forum to surface interoperability challenges, concerns from management, and perspectives of stakeholders.  “Interoperability” is a multi-dimensional aspect of system engineering.  Sound business and financial practice requires standardized financial management applications that support integrated business processes operating efficiently on common data.  

Participants included key stakeholders from the Office of Management and Budget, the CFO Council, the Federal Acquisition Council (former Procurement Executive Council), and invited representatives from the vendor community.  The Private Sector Council brought the key leaders from Software Engineering Institute, Carnegie Mellon University, IBM Business Consulting Services, Lockheed Martin, and the Council for Excellence in Government. (Attachment 1) 

Forum participants noted that the business and financial management challenge is to optimize the promise of integrated systems with integrated web and information system exchanges.  However, achieving the promise is difficult in an environment where a high degree of information standards is essential.  However, systems, processes, data governance and accountability are distributed, and changes may occur through external directives, vertical functional decisions, and horizontal functional decisions.  Under current policy, business case and program management focus are on costs, schedules, and functionality of the defined project.  The impact outside the specific project scope may not be defined, anticipated, or funded.  Also, federal financial management increasingly relies on commercial off-the-shelf (COTS) components, services, and systems acquired through procurement processes.  The market evolves over time, in some cases closing functional or operating gaps and in other cases causing them.

Organizational and management challenges expand as the result of integrating multiple business management systems.  As systems become more complex, interoperability issues increase.  As operations become more agile, systems must become dynamically reconfigurable.  Financial management performance requires high levels of information integrity, standardization and interdependent processes, but it increasingly relies on “a system of systems” over which there is no single controlling authority.  Moreover, the scope and complexity is expanding.  This is a classic interoperability (in the broad sense) conundrum.

Participants identified the following key issues:

· The inherent challenge of integration/interoperability of business management systems needs to be recognized and understood.  Problems exist in governance/accountability, organization, funding, communications, system management, technical areas, and data integrity with business rules.  The failure to recognize this results in unmet performance expectations, increased cost to integrate systems, and unanticipated risk.

· Governance and accountability issues need to be defined.  Governance and accountability need to be changed to meet this challenge.  Statutory responsibility for interoperability across agencies is not assigned and relies on collaboration.  These collaborative efforts may not be up to the challenge or well supported.  What is OMB’s role?  Where does ownership reside?  What is the agency’s role—how are the CIOs and Procurement Executives involved?  What is the appropriate role of the vendor community?   What is JFMIP’s role?

· Funding mechanisms are a concern.  Achieving interoperability of business processes is a complex undertaking, and not well supported by current government funding and accountability structure.

· Confusion exists about data and business rules.  Which rules must apply to all agencies?  Which ones are system- specific?  Data standardization and compatibility are not addressed.  Who owns and manages the data in systems?

· Communication remains a challenge.  There is a lack of precision in the process.  Vendor representatives stressed that interoperability is a spiral rather than linear development—systems must be defined to deal with ambiguity and change because it is impossible to identify all requirements and circumstances upfront.  Hardwired systems, however, are not designed to deal with ambiguities.  Interoperability is an iterative process; assumptions cannot be cast in stone and changes create interdependencies which must be communicated to all stakeholders.

· Project management needs to take into account the spiral nature of the interoperability process and not allow the “schedule” to drive events.  When there is a schedule or funding problem for system implementation, agencies tend to drop interoperability.  Agencies must find the balance between ambiguity and iterative development.  

· Changing requirements must be managed with more realism.  Realistic deadlines to implement system changes and better understanding of the impact of changes throughout the broader environment are necessary for success.

· Ensuring efficient and effective mission support of agency programs must be the primary consideration for managing “system of systems” tradeoffs. 

## Opening Remarks

Karen Cleary Alderman, Executive Director, JFMIP, opened the session and thanked everyone for attending.  She noted that presenters would focus on interoperability issues and keys to successful integration, and acknowledged that forum participants represented the full spectrum of the community responsible for achieving successful systems integration.  She introduced the panel participants.

Mark Carney, Deputy Chief Financial Officer, Department of Education, and Chair, Systems and E-Government Committee, CFO Council, thanked Linda Springer, Karen Evans, and Karen Alderman for helping to organize this meeting, noting that the rollout of the E-government initiative made the timing even more opportune.  He reminded the audience that they are the ones who have to make it work.  “We’ve been told what to do, but not how to do it.”  A lot of concern has been expressed about deadlines set by OMB, and agencies are expected to make their systems work with various e-government initiatives.  Technology is available to help agencies do things better; but the government is not organized to facilitate making technology work better. 

The Federal Financial Management Improvement Act (FFMIA) requires that agency systems produce financial statements and that agencies maintain integrated financial systems that comply with Federal accounting standards, JFMIP system requirements, U.S. Standard General Ledger, and other federal requirements.  Agencies have done a lot of things right, but have not focused on everything needed to meet all the requirements.  He noted that requirements are clearer and testing is more transparent for JFMIP core financial system qualification testing.  Agencies are increasingly implementing systems without having to customize the code.  However, the systems are not “plug and play.” Agencies are complex organizations. The Department of Education (ED) organizations implemented two systems independently and they are limited in talking to one another through an interface.  He noted the challenge of pulling things together with the line of business effort.  He concluded by thanking partners in the vendor community for working with the agencies on interoperability/integration issues.

Wayne Leiss, OMB, stated that he did not like the word “interoperability” – the problem is better communicated by focusing on business process integration in a truly distributed processing environment. OMB’s role is to provide leadership for this effort.  The government needs to learn from the successes of industry, particularly in how companies have integrated different brands of COTS in areas such as human resources, financial system, and e-travel.  This kind of integration is required for the e-Gov efforts to produce significant business process savings.  E-travel is an example of an opportunity missed by OMB--it will be a batch process to get the obligations booked into the financial system.  With effective coordination, travel transactions could be budget-checked and recorded on-the-fly.  OMB will provide the leadership, but will depend on JFMIP as a resource.  JFMIP does a great job and may need to expand its efforts. JFMIP is well respected and is a appropriate body for setting interoperability standards for financial data.  He expressed concern about fragmenting responsibilities for standardization among additional or new organizations.  

Pete Smith, Private Sector Council (PSC), offered his outside perspective.  He noted enormous difficulties in trying to integrate things both within and across departments. The entity needs a direct line of accountability to someone who cares and has time to be concerned about operations.  This is a luxury of the private sector; it is not present in government. He is encouraged that the government has meetings such as this forum, and praised the collegiality between agencies and the coordination by OMB and JFMIP.  He concluded by reminding the audience that the topics were far reaching and they had a full agenda, so he wanted everyone to help ensure a good discussion on each topic.

## Key Points from the Private Sector 

Following Pete Smith’s remarks, a panel of representatives from the private sector provided introductory comments and thoughts on keys to successful integration/interoperability of business management systems.

Jim Smith, Software Engineering Institute (SEI), noted that problems of interoperability were being addressed by SEI. Line of business is a common thread. Trying to understand the dimensions of interoperability is difficult because of the size and complexity of the issue.  If an entity only attempts to standardize interfaces, then something will be missing.  He identified several models of interoperability. More information can be found on the SEI website (Attachment 3). 

Hans Polzer, Lockheed Martin, presented his perspectives on interoperability drawing on information from his slide presentation (Attachment 3).  There are 15 dimensions in his model, many of which measure business functionality attributes rather than just technical issues.  While it is easy to understand that tight integration at the enterprise level is desirable, there may be a problem because of the need for the ability to adapt and interact with other enterprises

Mr. Polzer addressed the ad hoc nature of virtual enterprises and the question of balance this creates with interoperability between enterprises.  It is easy to decree standards and dictate integration; but enterprises are not hierarchical with respect to each other and all the enterprises/entities must work together to accomplish real world goals.  System design decisions tend to be made locally rather than enterprise-wide, and interoperability with other systems and other enterprises must be considered.  He favors the single budget, single sponsorship concept when achievable, but this is often not the case.  Systems operate among multiple virtual enterprises that come and go. He sees an ongoing evolution of systems with ad hoc connections to other systems.  Agencies need to work on building systems to be more conscious of that larger variability, many of which cannot be predicted today.  It is important to design systems with that kind of flexibility.  

Agencies tend to impose enterprise scope boundaries that limit system of systems interoperability. Interfaces tend to be hardwired to other systems; agencies know which internal system they should talk to in order to get certain information—that is a reasonable expectation. However, agencies do not have universal agreement as to what systems contain what information. Representing the operational context in the system interface itself is the challenge. Another need is naming conventions/identifiers and naming authorities. Providing cross-enterprise naming services would greatly facilitate systems interoperability.  In summary, he offered three key points that must be considered: the dynamic and ad hoc nature of enterprise; specifying interfaces, which provide information that are discoverable and provide explicit context; and cross-enterprise naming services. 

Jim Cook, IBM Business Consulting Services, viewed interoperability/integration from a business perspective.  The focus on technology management is misleading.  Success can be defined as achieving the following:  functional integration, end-to-end process, data, and governance of plan.  Both end-to-end process and data are well understood, while governance of plan is good.  Managers need to understand process at the operational level and implications to its strategy, then quantify gaps and implement a transition plan to get the agency where it wants to be.  The right level of process analysis upfront and knowing the intersection points are keys to success.  The technology exists to do this, so why is this so hard?  Governance, business process change, and data considerations need to be addressed. 

David McClure, Council for Excellence in Government, stated that there is no holy grail to address the multi-dimensional nature of this task.  There is a consensus on financial management transactions, but the issue of integrating the systems into the programmatic areas needs to be addressed.  There is a need to divide these tasks and get people to focus on short-term, midterm and long-term efforts.  The next issue concerns using the enterprise architecture as a framework to define common business requirements.  Federal enterprise architecture tools that are provided can help agencies deal with these issues.  In the area of financial line of business, each agency has its own enterprise resource planning (ERP) system or a hybrid and this is a factor in the common systems being built across the government.  He stated that interoperability is a means, not an end.  “If you get caught up on the means and not the end, success has to be measured on how it is improving management and integrating with the core mission and functions of the agency.”  He noted that getting consensus on those measures is important.  

## Facilitated Discussion

After the presentations, the audience and the panelists participated in a wide-ranging, free-flowing discussion.  The questions that were addressed can be found in Attachment 2.  The consensus expressed on the major topics is described below.  

Recognize the Problem

Participants concurred that the inherent challenge of integration/interoperability of business management systems needs to be recognized and understood.  Failure to recognize the problems in many areas resulted in unmet performance expectations, increased cost to integrate systems and unanticipated risk.

Governance and Accountability

Participants agreed strongly that leadership must come from OMB.  The government should act as one corporate structure, headquartered at OMB.  OMB and Congress will continue to set the policy, and JFMIP will continue to develop system requirements.  There was strong consensus that everyone needs to work together; this issue cannot be the sole domain of CFO or CIO, because it is too big.  

Agencies need to look at issues of governance, including the sources of funding and who is in charge. Schedules, budgets, and technical performance need to be managed.   When agencies involved in interagency collaborations examined interoperability, the problem of ownership of the middle ground was a common theme.  There is no organization to “manage the middle” other than OMB.  

The participants endorsed the concept of an institutionalized, crosscutting organization that acts as an advisory committee to OMB.  This committee needs to address level of control and governing authorities. Agencies want to participate, but they do not want to join in haphazardly. Agencies need to know where they are going. OMB needs to consider the impact of requirements on the agencies.

The government makes decisions sometimes with unintended consequences or impacts that were not anticipated. Systems do not have doorways to pass the information on; they may have interfaces in, but not interfaces back out. 

Participants agreed that the government is still the most complex enterprise in the world.  ERP standards are a good thing. Agencies do not look across their enterprises.  They need to focus on the human capital component and develop future project managers.

There was a sense that the federal government was not doing a good job communicating the interoperability needed to the vendors.

Funding Concerns

Achieving interoperability is a complex undertaking that is not supported by the current funding and accountability structure. Agencies commented that the government does not budget well for technology change.  OMB requests funding for governmentwide initiatives from all of the agencies, but each agency is closely guarded by Hill committees and does not have extra money to give even if something is a good idea.  One example is the funding for e-government initiatives, administratively supported by the General Services Administration.  However, Congress recently has not supported the funding.  Passing the hat among government agencies has problems.  

“A vision without resources is an hallucination.” “We’re going to continue to limp along until the funding issue is resolved.”

System Management and Technical Considerations

Interoperability only can be defined by including all stakeholders.  Confusion exists about the data and business rules.  Which rules apply to all agencies, and which ones are system-specific?  Data standardization and compatibility issues need to be addressed.  Who owns and manages the data in systems?

Not everyone agrees with the definition of interoperability.  Several participants noted that until interoperability is understood at the lower level, agencies do not understand the implications until it is too late.  Interoperability cannot be achieved outside the context of enterprise architecture; it must be as a framework to define common business requirements. The federal enterprise architecture tools can help with some of these issues.  It is important to look at financial management as a line of business in the government. Each agency has its own ERP system or a hybrid and is a factor in the common systems being built across government. Interoperability is a means, not an end. 

There was a sense that, while enterprise architectures are useful things, today there are too many of them. Agencies tend to focus on their primary enterprise, but they really are part of someone else’s enterprise as well. Enterprise architecture does not address interoperability outside its scope. Agencies need to design systems that are cognizant of their role with others.  Government has relationships with state governments, who have relationships with each other. Agencies should be explicit with any information system transactions they are providing and not assume they are talking only to each other.  Systems do not identify that they are the U.S. government; the individual providing the information tells the receiver that it is from the government.

Everyone agreed that interoperability is broader than a technical problem.  It is a business-modeling problem.  The interdependent business process and associated data must be transparent in order to define required information exchange.  Government can define the informational need.  There is a need for a parallel discussion on the policy issues to achieve technology necessary to support information flow.  The lack of common name protocols, for example, is a management problem when no one is assigned responsibility to address the problem.  Which part of government should act as a broker?  

It is an engineering problem as well. The common thread of success is a spiral, iterative approach.  A fixed schedule is a key to failure. 

Government information models are not structured to deal with the evolution and how agencies represent their businesses in the systems. Adding flexibility adds cost to the system, but everything does not have to be implemented upfront. Agencies can build the interface they need for now, and add change later. They should ask: Where is this going? With what other enterprises will the agency interact? How will that impact the agency’s information model?

Communications Challenges Faced by Agencies

People are committed to doing the right thing, but are having trouble doing it.

Agencies noted that they had systems in place to handle internal business, and common components of systems are being mandated.  Now these include the use of a central vendor file, and the use of e-travel vendors, travel, grants, and financial management systems.  Agencies are concerned because they are not receiving money and help/advice on how to make these changes.  If agencies do not deal with technical and governance issues, they have a hard time complying with requirements. 

Private sector representatives noted that agencies need a longer period of time to migrate to these changes.  They pointed out the difficulty of what the government has to accomplish in its financial system.  The rules are complex, but are they are serving a real government purpose? Upward and downward adjustments to obligations were offered as an example of a highly complex federal requirement that adds to system complexity.

The line of business effort was created to save money to use towards an agency’s core mission and thus provide the best use of taxpayer resources.  Assumptions are that agencies are not unique and can use providers that administer payroll and travel in the same way.  Agencies need to commit to a common purpose and collaborate.  Some agencies commented that their costs would increase because they have to disassemble their current systems to go to what they perceive as inferior, but more expensive systems.  Does everything have to be integrated?  The sense was agencies should do what they have to do, and stop at that, rather than to have everything integrated.

Two reasons to resist change: you hate it, and it doesn’t make sense.  In many cases the cost of reintegration far outweighs benefits of change in the near term. What is the purpose of the integration and interoperability? Where must it be enforced? Sometimes agencies assume they have to be on the same system when they do not. Agencies must determine upfront what they are trying to achieve. Those agencies that spent the most integrating their own little world will be most resistant to adopting government-wide integration efforts.  Agencies need to think broader when planning these efforts and provide generality at the system interface level.

Project Management

Project management needs to take into account the spiral nature of the interoperability process and not allow the “schedule” to drive events.  When there is a schedule or funding problem for system implementation, agencies tend to drop interoperability.  Agencies must find the balance between ambiguity and iterative development.

Agencies are losing experienced people for a variety of reasons. Organizations are relying excessively on outside contractors because they have no other choice.  Internally the staff does not have the technical expertise.  Concern was expressed that agencies overseeing implementation have all the expertise on the general requirements, but that vendors and integrators have little expertise. This is extremely high risk and costly, and greater oversight and close management of contractors is needed.

Other Issues

Participants expressed strong support for JFMIP.  There was general agreement that the role of JFMIP should be expanded to look at feeder systems to ensure that they are integrated successfully.  With JFMIP requirements, agencies always have a baseline. Agencies do not have baseline requirements for human resources and procurement, but they should have a baseline that addresses what to do, but not how to do it. 

The JFMIP Steering Committee is a good vehicle to get things done.  It agreed that for the next set of requirements it does not want to limit to lowest common denominator. The requirements need to serve more sophisticated needs.  Agencies have to pay a higher cost for the greater good sometimes, but not usually. Line of business and e-travel are examples where everyone should benefit. OMB’s approach is to determine the right time in an agency’s system lifecycle to migrate to the new system.

Maintaining integration and data standardization are important factors to consider.  The driving principle is to increase standardization unless there is a business reason not to. OMB sees JFMIP as the way to standardization and implementation.   Most business systems are either financial systems or mixed financial systems, and the JFMIP should set the standards for all of their interactions.

JFMIP’s new test received praise. It does not give the agencies the least common denominator, but allows small agencies get the best package. JFMIP included both the agencies and the vendors in the test development process. It provided vendors with understanding of what is unique and what is not.  It was a collaborative effort to set baseline standards with good examples, and this should be encouraged.

Participants were interested especially in some kind of institutionalized forum to discuss systems issues. Agencies are not doing a good job of addressing instantaneous transactional information and measuring performance and how to do both.  This effort needs all of the right people involved with all of the elements of business management.  Participants were invited to send agenda ideas to Karen Alderman or Mark Carney.  It is important that the group has a very clear charter and relationship to the other groups.

A good example where JFMIP was able to get the definition clarified was on the Treasury payment format. Any efforts like this are beneficial to the government and software providers. Also, when looking to expand, let the vendors be part of the dialogue. There may be subtleties that they identify that might not have been identified by government upfront.

Some final thoughts from industry representatives are as follows.

Hans Polzer, Lockheed Martin, will provide the dimensions in the model. His slides are posted at http://www.jfmip.gov/jfmip/data/LISI_like_levels7.PPT 

Jim Cook, IBM Business Consulting Services, stated that looking at interoperability is a means to an end—it is not an end itself.  He emphasized the need to improve the performance of government.

David McClure, Council for Excellence in Government, stated that the definition of interoperability should go beyond the people in this room.  We need talk to all of the stakeholders and empower them to define what needs to be focused on and the ability to move things forward.

Jim Smith, SEI, said that the grand solution does not work.  Some pilot efforts are needed to demonstrate this fact. Interoperability is only meaningful in a certain context.  What are the legislative and regulatory impediments?

## Concluding Remarks 

Mark Carney, ED, summarized that the Federal agencies have to have integrated systems and processes that work together. He did not have an issue with the greater good, but it makes it harder to justify if the agency is constantly trying to “plug things into it”. 

By prioritizing things, we get them done. Wherever interoperability sits in the spectrum of importance, we need to get it to a higher level of importance. The road we are currently going down needs to be changed. He noted that this discussion was a good first step..

Karen Alderman, JFMIP, thanked Pete Smith, Private Sector Council and Mark Carney, CFO Council Systems/E-Government Committee, for sponsoring this forum and advised participants that forum highlights will be developed and posted on the JFMIP website.

## Attachment 1. Forum Participants

## Attachment 2. Questions At Forum

## · Policy – How the current law/policy address the integration/interoperability challenge?

· Factors 

· Opportunities

· Risk Factors

· Governance and Ownership - What governance options would improve performance outcomes or reduce risk?

· What organization should have the controlling authority or ownership? 

· Is there a strong leader who is responsible?  Are there adequate resources to successful complete the integration? 

· Standards – How are standards integrated throughout the system of systems?

These include business rules, data, applications, and technology.

· What are some of the management issues, i.e., configuration management and how are they being resolved?

· What are the success factors for integrating business management systems?

· How should success be measured?

· Interoperability must be quantifiable to be achievable

· Interoperability must be sustainable and sustained

· One of the goals is to meet business informational needs of program (line) managers.  What is the best approach to do this?

· Integration/Interoperability Attribute Issues

· Communications – Currency of data.  Timeliness of data.  Rate of data exchange. 

· Data Management – The storage, distribution and synchronization of data

· Dynamism – How capabilities or services are made available, identified and located, and composed into composite systems on-the-fly or at runtime

· Evolution – Expected changes of whole and its parts.  Rates of change and their consistency.  Expected change of the technology itself.

· Planning – What is understood about systems and the composite system of systems at the point of their construction.  Includes boundedness and autonomy.

· Semantic Consistency – The meaning of data, functionality, transformation

· Ownership – Controlling authorities are for the systems and processes.

· Usage Patterns – The expected pattern of use for systems and composite systems.

· How does outsourcing impact governance and system integration?

## Attachment 3. References

1. Slide presentation on “Perspectives on Interoperability”, dated March 2004 by Hans Polzer. (http://www.jfmip.gov/jfmip/data/LISI_like_levels7.PPT )

2. Software Engineering Institute, http://www.sei.cmu.edu

� GAO’s role with respect to requirements and testing is limited to that of providing technical advice.

� GAO’s role with respect to requirements and testing is limited to that of technical advice.

1

DRAFT— MACROBUTTON NoMacro [Click **here** and type report #)] —7/29/044-Forum Highlights_7-28-04.doc

4