1	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
2	Raines’ Rules Issued October 25, 1996 (10^th Anniversary) Guidance under the Information Technology Management Reform Act (Clinger-Cohen Act) Criteria for IT Investments Included in President’s Budget Eight Broad “Rules” 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
3	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?
4	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:
5	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.
6	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.
7	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?
8	Service & Component Based Architecture (SCBA) Executive Strategy v. 3.5, 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.
9	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.
10	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
11	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, July 6, 2006
12	FTF Metamodel GOTS Products Implement TRM Service Standards “Customized” COTS? (RR#6) TRM Service Standards Map to Approved Federal Technology Standards Approval process? Inherently governmental in nature? (OMB Circulars A-76 & A-119) 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
13	GOTS in FTF Metamodel Graphic
14	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 SmartBUYing FAR subpart 11.105 prohibition on specifying brand names Larger stovepipes? Proprietary “interoperability”? Inflexibility in choice of suppliers (RR#5) Relationship to GOTS in FTF abstract model?
15	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
16	Lessons Learned Citizen centricity Crossing the chasm Difficulty identifying/comparing COTS Change is hard, particularly if large More?
17	Lesson #1 – Citizen-Centricity RR#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.
18	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://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
19	Lesson #3 – Discovery of COTS Is Difficult RR#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
20	Lesson #4 – Change Is Hard Particularly If Large RR#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”?
21	Roads Not Taken Chunking Standard components Data standards Citizen centricity Registries More?
22	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 (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
23	Roads Not Taken #2 – Standard Components Contrary to RR#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) 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?
24	Roads Not Taken #3 – Data Standards Data Reference Model (DRM) last FEA model issued Agencies pushed back on use of XML for DRM 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) Can we truly know our (We the People’s) “business” without understanding our data architecture? (RR#s 1, 5 & 7) Lack of .gov data standards leads to vendor lock in (RR#s 5 & 7) Proprietary large-scale “components” lead to integrator lock-in
25	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 not implemented All that is truly “inherently governmental” in nature are the data standards required to conduct We the People‘s business efficiently and effectively (RR#s 1 & 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
26	Roads Not Taken #5 – Registry(ies) Notwithstanding a ROI 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) Agencies pushed back on the thought of being expected to render their Data Reference Models (DRMs) in valid XML instance documents Some agencies have refused to publish their XML schemas on the Web (In spite of EEIRS report) Thus, it is far more difficult than it should and could be for agencies to discover data elements and schemas as reusable “chunks”/components
27	FBI Virtual Case File (VCF)
28	Case Study – VCF Violated All RRs Planned launch of new software all at once, with minimal testing RR# 6 & 7 – Pilots & chunks Program lacked common navigation features RR# 2, 3 & 8 – COTS FBI left identifying/defining essential processes to outsiders RR# 1, 3 & 5 – Inherently governmental functions, simplified “legal fiction … that government knows what it’s doing ..” RR# 3, 5 & 8 – EA, simplified functions, appropriate risk sharing Scope expanded by 80 percent RR# 3, 5 & 7 – Narrow chunks, EA, simplified processes Nineteen gov personnel changes in three years RR# 5, 6 & 7 – EA, brief chunks & user acceptance If new system didn’t work would put FBI out of business RR# 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
29	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!
30	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
31	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
32	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
33	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
34	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
35	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
36	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
37	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