# Presentation: 259476

## Raines’ Rules Revisited:Lessons Learned & Roads Not Taken in the Era of Service-Oriented, Component-Based Architecture

- Owen Ambur, Chief XML Strategist
- Department of the Interior
- October 24, 2006

## Raines’ Rules

- Issued October 25, 1996 (10th Anniversary)
- Guidance under the Information Technology Management Reform Act (Clinger-Cohen Act)
- Criteria for IT Investments Included in President’s Budget
- Eight Broad “_[Rules](http://mysite.verizon.net/ambur/itmra.htm)__”_
- Including Three “Pesky Questions”
- Part of Our Nation’s History
- What Can We Learn from This Part of Our History?
- Can We Avoid Re-living the Mistakes of the Past?
**Those Who Refuse to Learn the Lessons of History**
** ****Are Doomed to Relive Them.**
** ****~Santayana, 1903**

**Notes:**
Change Slide to Future versus past tense.

## Raines’ “Pesky Question” Rules 1 - 3

- Does the Investment:
- Support core/priority mission functions that need to be performed by the Federal government?
- Need to be undertaken because ***no alternative private sector or governmental source*** can efficiently support the function?
- Support work processes that have been simplified or otherwise redesigned to
- reduce costs,
- improve effectiveness, and
- make ***maximum use of*** commercial off-the-shelf (***COTS***) technology?

## Raines’ Rules 4 & 5

- 4. Demonstrate a projected return on investment that is clearly better than alternative uses of available resources.
- 5. Be consistent with Federal, agency, and bureau information architectures which:

- integrate agency work processes and information flows with technology to achieve the agency's strategic goals ... and
- specify ***standards that enable information exchange*** and resource sharing, while
- retaining ***flexibility in the choice of suppliers*** and in the design of local work processes.

## Raines’ Rules 6 & 7

- 6. Reduce risk by:
***avoiding*** or isolating ***custom-designed components***
- using ***fully tested pilots***, simulations, and prototypes
- establishing clear measures and accountability for project progress; and
- securing substantial involvement and buy-in ... from program officials who will use the system.
- 7. Implement in ***phased, successive chunks***
- as ***narrow in scope and brief in duration*** as practicable,
- each of which ***solves a specific part of an overall mission problem*** and
- delivers a measurable net benefit ***independent of future chunks***.

## Raines’ Rule 8

- Employ an acquisition strategy that
- appropriately allocates risk between government and the contractor,
- effectively uses competition,
- ties contract payments to accomplishments, and
- takes maximum advantage of ***commercial technology***.

## More Recent Guidance (Small Subset)

- Service & Component-Based Architecture Strategy
- Enterprise Architecture Principles
- Federal Transition Framework (FTF) & Catalog
- FEA Mapping Quick Guide
- Efficient & Effective Information Retrieval & Sharing (EEIRS) Report
- Other Relevant Guidance?

## Service & Component Based Architecture (SCBA)

- _[Executive Strategy v. 3.5](http://www.whitehouse.gov/omb/egov/documents/SCBA_Whitepaper_Chapter_1.pdf)__, January 31, 2006_
- Most important aspect is focus on **reuse of services and components – referred to as Service Components**
- information technology assets that perform useful business functions through a well-defined interface
- Despite emphasis on services, SCBA accommodates the concept of component reuse
- where cross-agency service sharing is not possible due to regulatory or security restrictions.

## SCBA-Oriented Changes

- SCBA emphasizes changes not only in technology but also:
**Policies – **alter policies to support reusing assets from any source, and set specific, measurable goals for levels of reuse.
**Strategies –** move from strategies that are narrowly focused on programs to focus on producing and integrating reusable services across the entire Federal government.
**Processes –** alter software development and capital planning processes in order to make identification of opportunities for reuse a core task.
**Culture –** change through a combination of executive recognition and incentive programs that strongly reward reuse.
**Governance –** change to take into account that a service may be used by multiple organizations and institute appropriate service level agreements.

## Architectural Principles for the Federal Government

- June 23, 2006
- Focus on ***Citizens***
***Single***, Unified ***Enterprise***
- Collaborate with Other Governments
- Mission-Driven
- Core Needs include Security, Privacy & Info Protection
- Information is a National Asset
- EA Simplifies Government Operations

## Federal Transition Framework (FTF)

- Purposes
- More consistent, complete and detailed information about ***cross-agency initiatives*** to more quickly to inform  EA, CPIC & implementation activities
- Use information describing cross-agency initiatives to make better informed decisions about IT investments
- Improve the effectiveness and efficiency of IT investments to realize service improvements and cost savings
- 					Karen Evans _[Memo](http://www.whitehouse.gov/omb/egov/documents/Pilot_FTF_Release_Memo_20060706.pdf)__, July 6, 2006_

## FTF Metamodel

- GOTS Products Implement
- TRM Service Standards
- “Customized” COTS? (_[RR#6](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_6)_)
- TRM Service Standards Map to
- Approved Federal Technology Standards
- Approval process?
- Inherently governmental in nature? (OMB Circulars _[A-76](http://www.whitehouse.gov/omb/circulars/a076/a76_incl_tech_correction.html)_ & _[A-119](http://www.whitehouse.gov/omb/circulars/a119/a119.html)_)
- Shared Components
- Are Implemented Using Approved Federal Technology Standards
- Available through a Component Repository
- CORE.gov
- Relationship to FTF Catalog?  To EEIRS report?
- COTS? GOTS? Customized COTS?
- FTF Metamodel, Pilot Version, June 2006 (Fig. 1, p. 7, PDF p. 8)
- _[http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_June_2006.pdf](http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_June_2006.pdf)_

## GOTS in FTF Metamodel Graphic

## FEA Reference Model Mapping Quick Guide

- Agencies should identify ***vendors & products*** (rather than technical specifications) in the Service Specification layer of the FEA TRM
- Bureaucratic double-speak
- _[SmartBUY](http://www.gsa.gov/Portal/gsa/ep/contentView.do?programId=8945&channelId=-13106&ooid=10430&contentId=15202&pageTypeId=8203&contentType=GSA_BASIC&programPage=%252Fep%252Fprogram%252FgsaBasic.jsp&P=MES)_ing
- FAR subpart 11.105 prohibition on specifying brand names
- Larger stovepipes?
- Proprietary “interoperability”?
- Inflexibility in choice of suppliers (_[RR#5](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_5)_)
- Relationship to GOTS in FTF abstract model?

## EEIRS Report

- December 2005
- Publishing directly to the Internet is the most cost-beneficial way to enable the efficient and effective retrieval and sharing (EEIRS) of government information
- However, as an organization moves from a passive or “casual” access model ... the need for ... indexes, taxonomies, or metadata tagging ... becomes apparent

## Lessons Learned

- Citizen centricity
- Crossing the chasm
- Difficulty identifying/comparing COTS
- Change is hard, particularly if large
- More?

## Lesson #1 – Citizen-Centricity

- _[RR#6](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_6)_ said agencies should reduce the risks associated with IT investments by "... securing substantial involvement and buy-in ... from ***program officials who will use the system*** ...“
-  However, it ***does not say anything about focusing on service to citizens***.
- Although it does reference GPRA, the terms "citizen" and "stakeholder" are nowhere to be found in the memo -- suggesting that the focus is basically inward, on the bureaucracy itself.
- Per the President’s Management Agenda (PMA) and FEA PMO's EA principles
***eGov projects should focus***, directly or indirectly, ***on serving the needs/interests of citizens***.

## Lesson #2 – The Product/Component Chasm

- Visionaries and pragmatists have different expectations
***Whole product*** is a generic product
- Augmented by everything needed for the customer to have a compelling reason to buy
- 				~Geoffrey Moore, *Crossing the Chasm*
- Crossing the “chasm" may not lead to profitability
- 				_[http://](http://en.wikipedia.org/wiki/Crossing_the_Chasm)__[en.wikipedia.org/wiki/Crossing_the_Chasm](http://en.wikipedia.org/wiki/Crossing_the_Chasm)_
- By definition, components are not whole products
- Customers may have no compelling reason to buy
- Pragmatists may actively resist

## Lesson #3 – Discovery of COTS Is Difficult

- _[RR#2](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_2)_: Need to be undertaken because ***no alternative private sector or governmental source*** can efficiently support the function
- Vendors sell marketing hype (“intergalactic solutions”)
- .gov Functions not mapped to COTS components
- Difficult to conduct apples-to-apples comparison of COTS *whole product* “solutions”
- Costly subscriptions to IT analyst reports
- COTS products & services not mapped to FEA SRM, DRM or TRM
- FTF Catalog (new) for GOTS

## Lesson #4 – Change Is Hard Particularly If Large

- _[RR#3](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_3)__: Work processes _***simplified or*** otherwise ***redesigned*** to reduce costs, improve effectiveness, and make maximum use of COTS
- Modernization Blueprints
- Lengthy documents
- Long time lines
- COTS? GOTS? Customized COTS?
- Components?
- Whole product (large) “components”?

## Roads Not Taken

- Chunking
- Standard components
- Data standards
- Citizen centricity
- Registries
- More?

## Roads Not Taken #1 - Chunking

- Rather than implementing IT in small, manageable, standards-compliant “chunks” each of which adds value in and of itself, agencies routinely acquire, implement, and customize relatively large, proprietary software “solutions”
- The SCBA _[executive strategy ](http://www.whitehouse.gov/omb/egov/documents/SCBA_Whitepaper_Chapter_1.pdf)__(written by integrators) says:_
- Experience with component-based architectures has shown that reuse can be successful when the reuse efforts focus on ***large-scale*** components ... (page 1-3, PDF p. 13, emphasis added)
- While innovation continues apace in start-ups and small companies, the trend seems to be toward consolidation through mergers and particularly acquisitions

## Roads Not Taken #2 – Standard Components

- Contrary to _[RR#7](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_7)_
- Vendors lack incentives to sell commodity components
- .Gov agencies may lack incentives to buy components
- COTS failure to comply with interoperability standards (_[RR#5](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_5)__)_
- Proprietary “whole product solutions” may be an easier sell
- But are they a better buy for the citizens (taxpayers)?
- So-called “large-scale components” make good business for integrators
- Integrator lock-in (as opposed to COTS vendor lock-in)
- GOTS “intergalactic solutions” even more likely to fail than COTS
- Except for the incredible inertia of bureaucratic legacy systems
- Good or bad thing?  Tried and proven?
- Honoring sunk costs.  Truly irrational?

## Roads Not Taken #3 – Data Standards

- Data Reference Model (_[DRM](http://www.whitehouse.gov/omb/egov/documents/DRM_2_0_Final.pdf)_) last FEA model issued
- Agencies pushed back on use of _[XML for DRM](http://xml.coverpages.org/FEA-DRM-SchemaDraftV04-20060103.xsd)_
- Preference for abstraction rather than implementation
- Inability to efficiently share DRM data descriptions
- The purpose of which is to facilitate the sharing of data
- Assumed that legacy applications will exist for long time
- Data mapping will be required for foreseeable future
- Failure to perceive, much less “implement” Government as a “single enterprise” (contrary to _[EA Principles](http://colab.cim3.net/file/work/BPC/2006-08-21/FedArchPrinciples2006_6_23_final.doc)_)
- Can we truly *know *our (_[We the People’s](http://www.archives.gov/national-archives-experience/charters/constitution_transcript.html)_) “business” without understanding our data architecture?  (RR#s _[1](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_1)_, _[5](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_5)_ & _[7](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_7)_)
- Lack of .gov data standards leads to *vendor* lock in (RR#s _[5](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_5)_ & _[7](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_7)_)
- Proprietary large-scale “components” lead to *integrator* lock-in

## Roads Not Taken #4 – Citizen-Centricity

- In many ways, the focus on so-called “one-stop” portals is a return to the mainframe stovepipe paradigm
- No citizen “lives” in any .gov portal
- FirstGov’s citizen-centered “life-events” _[taxonomy](http://xml.gov/draft/FirstGovLifeEventsTaxonomy.htm)_ not implemented
- All that is truly “_[inherently governmental](http://www.whitehouse.gov/omb/circulars/a076/a76_incl_tech_correction.html)_” in nature are the ***data standards*** required to conduct _[We the People‘s ](http://www.archives.gov/national-archives-experience/charters/constitution_transcript.html)_business efficiently and effectively (RR#s _[1](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_1)_ & _[2](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_2)_)
- Citizens should be free to use whatever client and server/host software interfaces ***they*** choose
- Via SOA, XML & Web Services
- Bureaucracies still are and may always be self-centered
- Particularly if Congress continues to insist on funding stovepipes
- Political legacies

## Roads Not Taken #5 – Registry(ies)

- Notwithstanding a _[ROI](http://xml.gov/documents/completed/bah/registryBusinessCase.htm#_Toc19694635)_ in the range of 500 – 1400 percent, Congress failed to fund the President’s request for $2.1 million for the XML Registry (In spite of _[RR#4](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_4)_)
- Agencies pushed back on the thought of being expected to render their Data Reference Models (DRMs) in _[valid XML ](http://xml.coverpages.org/FEA-DRM-SchemaDraftV04-20060103.xsd)_instance documents
- Some agencies have refused to publish their XML schemas on the Web (In spite of EEIRS _[report](http://www.cio.gov/documents/EEIRS_RFI_Response_Analysis.pdf#search=%22EEIRS%20OMB%22)_)
- Thus, it is far more difficult than it should and could be for agencies to discover data elements and schemas as reusable “_[chunks](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_7)_”/_[components](http://www.whitehouse.gov/omb/egov/documents/SCBA_Whitepaper_Chapter_1.pdf)_

## FBI Virtual Case File (VCF)

## Case Study – VCF Violated All RRs

- Planned launch of new software all at once, with minimal testing
-  RR# _[6](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_6)_ & _[7](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_7)_ – Pilots & chunks
- Program lacked common navigation features
- RR# _[2](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_2)_, _[3](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_3)_ & _[8](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_8)_ – COTS
- FBI left identifying/defining essential processes to outsiders
-  RR# _[1](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_1)_, _[3](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_3)_ & _[5](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_5)_ – Inherently governmental functions, simplified
- “legal fiction ... that government knows what it’s doing ..”
-  RR# _[3](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_3)_, _[5](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_5)_ & _[8](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_8)_ – EA, simplified functions, appropriate risk sharing
- Scope expanded by 80 percent
- RR# _[3](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRules)_, _[5](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_5)_ & _[7](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_7)_ – *Narrow* chunks, EA, simplified processes
- Nineteen gov personnel changes in three years
- RR# _[5](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_5)_, _[6](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_6)_ & _[7](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_7)_ – EA, *brief* chunks & user acceptance
- If new system didn’t work would put FBI out of business
- RR# _[4](http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_4)_ & 8 – Unacceptable risk, infinitely negative ROI?
- Replacement for VCF will not be *fully* operational until 2009
- RR# 3 & 7 – Successive (COTS/SOA) chunks? Simplified processes? Lesson learned?!
- 			The FBI’s Upgrade That Wasn’t, *The Washington Post*, August 18, 2006

## Want to Help?

- If you’d like to help document and share lessons learned and information on roads not taken relative to Raines’ Rules in the era of service-oriented, component-based architecture, please feel free to post your well-considered thoughts in the appropriate section(s) of the wiki at http://colab.cim3.net/cgi-bin/wiki.pl?RainesRules
- &/or
- Contact me at Owen_Ambur@ios.doi.gov
- Please share your lessons learned so that we can avoid reliving the mistakes of the past!

## Raines’ Rule #1 – Lessons & Roads Not Taken

- Support core/priority mission functions that need to be performed by the Federal government
- Lessons Learned?
- Roads Not Taken?
- Contribute at http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_1

## Raines’ Rule #2 – Lessons & Roads Not Taken

- Need to be undertaken because ***no alternative private sector or governmental source*** can efficiently support the function
- Lessons Learned?
- Roads Not Taken?
- Contribute at http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_2

## Raines’ Rule #3 – Lessons & Roads Not Taken

- Support work processes that have been simplified or otherwise redesigned to reduce costs, improve effectiveness, and make ***maximum use of*** commercial off-the-shelf (***COTS***) technology
- Lessons Learned?
- Roads Not Taken?
- Contribute at http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_3

## Raines’ Rule #4 – Lessons & Roads Not Taken

- Demonstrate a projected return on investment that is clearly better than alternative uses of available resources.
- Lessons Learned?
- Roads Not Taken?
- Contribute at http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_4

## Raines’ Rule #5 – Lessons & Roads Not Taken

- Be consistent with Federal, agency, and bureau information architectures which:
- integrate agency work processes and information flows with technology to achieve the agency's strategic goals ... and
- specify ***standards that enable information exchange*** and resource sharing, while
- retaining ***flexibility in the choice of suppliers*** and in the design of local work processes.
- Lessons Learned?
- Roads Not Taken?
- Contribute at http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_5

## Raines’ Rule #6 – Lessons & Roads Not Taken

- Reduce risk by:
***avoiding*** or isolating ***custom-designed components***
- using ***fully tested pilots***, simulations, and prototypes
- establishing clear measures and accountability for project progress; and
- securing substantial involvement and buy-in ... from program officials who will use the system.
- Lessons Learned?
- Roads Not Taken?
- Contribute at http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_6

## Raines’ Rule #7 – Lessons & Roads Not Taken

- Implement in ***phased, successive chunks***
- as ***narrow in scope and brief in duration*** as practicable,
- each of which solves a specific part of an overall mission problem and
- delivers a measurable net benefit ***independent of future chunks***.
- Lessons Learned?
- Roads Not Taken?
- Contribute at http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_7

## Raines’ Rule #8 – Lessons & Roads Not Taken

- Employ an acquisition strategy that
- appropriately allocates risk between government and the contractor,
- effectively uses competition,
- ties contract payments to accomplishments, and
- takes maximum advantage of ***commercial technology***.
- Lessons Learned?
- Roads Not Taken?
- Contribute at http://colab.cim3.net/cgi-bin/wiki.pl?RainesRule_8