118:. The FEAF provides an enduring standard for developing and documenting architecture descriptions of high-priority areas. It provides guidance in describing architectures for multi-organizational functional segments of the Federal Government. At the time of release, the Government's IT focus on Y2K issues and then the events of September 2001 diverted attention from EA implementation, though its practice in advance and subsequent to this may have ameliorated the impact of these events. As part of the President's Management Agenda, in August 2001, the E-Government Task Force project was initiated (unofficially called Project Quicksilver). A key finding in that strategy was that the substantial overlap and redundant agency systems constrained the ability to achieve the Bush administration strategy of making the government "citizen centered". The Task Force recommended the creation a Federal Enterprise Architecture Project and the creation of the FEA Office at OMB. This was a shift from the FEAF focus on Information Engineering, to a J2EE object re-use approach using reference models comprising taxonomies that linked performance outcomes to lines of business, process services components, types of data, and technology components. Interim releases since that time have provided successive increases in definition for the core reference models (see below), as well as a very robust methodology for actually developing an architecture in a series of templates forming the Federal Segment Architecture Methodology (FSAM) and its next generation replacement, the Collaborative Planning Methodology (CPM), which was designed to be more flexible, more widely applicable, and more inclusive of the larger set of planning disciplines.
720:" defines agency IT assets such as applications or components used to automate and improve individual agency business functions. The scope of a solution architecture is typically limited to a single project and is used to implement all or part of a system or business solution. The primary stakeholders for solution architecture are system users and developers. Solution architecture is commonly related to segment architecture and enterprise architecture through definitions and constraints. For example, segment architecture provides definitions of data or service interfaces used within a core mission area or service, which are accessed by individual solutions. Equally, a solution may be constrained to specific technologies and standards that are defined at the enterprise level.
695:(EA) is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems, or technologies. EA is driven by strategy; it helps an agency identify whether its resources are properly aligned to the agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. Consequently, the primary stakeholders of the EA are the senior managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible.
702:" defines a simple roadmap for a core mission area, business service, or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers. Segment architecture is related to EA through three principles:
673:
476:" is a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them. This business reference model provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government using a functionally driven approach. The BRM is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology.
510:
273:
103:
395:
609:
563:
574:(DRM) describes, at an aggregate level, the data and information that support government program and business line operations. This model enables agencies to describe the types of interaction and exchanges that occur between the federal government and citizens. The DRM categorizes government information into greater levels of detail. It also establishes a classification for federal data and identifies duplicative data resources. A
627: : represent a technical tier supporting the secure construction, exchange, and delivery of Service Components. Each Service Area aggregates the standards and technologies into lower-level functional areas. Each Service Area consists of multiple Service Categories and Service Standards. This hierarchy provides the framework to group standards and technologies that directly support the Service Area. (Purple headings)
138:
Enterprise
Architecture in the Federal Government. The Common Approach promotes increased levels of mission effectiveness by standardizing the development and use of architectures within and between Federal Agencies. This includes principles for using EA to help agencies eliminate waste and duplication, increase shared services, close performance gaps, and promote engagement among government, industry, and citizens.
343:
212:
465:
518:
application
Service Components in IT investments and assets. The SRM is structured across horizontal and vertical service domains that, independent of the business functions, can provide a leverage-able foundation to support the reuse of applications, application capabilities, components, and business services.
651:
by identifying and reusing the best solutions and technologies to support their business functions, mission, and target architecture. Organized in a hierarchy, the TRM categorizes the standards and technologies that collectively support the secure delivery, exchange, and construction of business and
500:
While the BRM does provide an improved way of thinking about government operations, it is only a model; its true utility can only be realized when it is effectively used. The functional approach promoted by the BRM will do little to help accomplish the goals of E-Government if it is not incorporated
496:
The
Business Reference Model provides a framework that facilitates a functional (as opposed to organizational) view of the federal government's LoBs, including its internal operations and its services for the citizens, independent of the agencies, bureaus and offices that perform them. By describing
285:
designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of federal agency operations in a common and
197:
The
Collaborative Planning Methodology (CPM) is a simple, repeatable process that consists of integrated, multi-disciplinary analysis that results in recommendations formed in collaboration with leaders, stakeholders, planners, and implementers. It is intended as a full planning and implementation
303:
This reference model, which combines the
Business and Service Component Reference Models from FEAF v1, supports architectural analysis and reporting in the business services sub-architecture view of the overall EA. The BRM describes an organization through a taxonomy of common mission and support
137:
In May 2012 OMB published a full new guide, the "Common
Approach to Federal Enterprise Architecture". Released as part of the federal CIO's policy guidance and management tools for increasing shared approaches to IT service delivery, the guide presents an overall approach to developing and using
121:
These federal architectural segments collectively constitute the federal enterprise architecture. In 2001, the
Federal Architecture Working Group (FAWG) was sponsoring the development of Enterprise Architecture products for trade and grant Federal architecture segments. Methods prescribed way of
547:
Each
Service Domain is decomposed into Service Types. For example, the three Service Types associated with the Customer Services Domain are: Customer Preferences; Customer Relationship Management; and Customer Initiated Assistance. And each Service Type is decomposed further into components. For
141:
On
January 29, 2013, the White House released Version 2 of the Federal Enterprise Architecture Framework (FEAF-II), to government agencies, making it public about a year later. The document meets the criteria set forth by Common Approach, emphasizing that strategic goals drive business services,
616:
The TRM is a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of
Service Components and capabilities. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of
517:
The Service Component Reference Model (SRM) is a business and performance-driven, functional framework that classifies Service Components with respect to how they support business and/or performance objectives. The SRM is intended for use to support the discovery of government-wide business and
736:
The official report to the U.S. Congress in 2011 reported that "most departments and agencies reported they expect to realize the benefits from their respective enterprise architecture programs sometime in the future. What this suggests is that the real value in the federal government from
668:
In the FEA, enterprise, segment, and solution architectures provide different business perspectives by varying the level of detail and addressing related but distinct concerns. Just as enterprises are themselves hierarchically organized, so are the different views provided by each type of
732:
Stanley Gaver, a participant of the FEA program, reports that "Enterprise Architecture within the federal government hasn't been working, and far more often than not hasn't delivered useful results. Moreover, significant parts of the federal EA program have been complete and utter
296:
This reference model supports architectural analysis and reporting in the strategy sub-architecture view of the overall EA. The PRM links agency strategy, internal business components, and investments, providing a means to measure the impact of those investments on strategic
122:
approaching a particular problem. As shown in the figure, the FEAF partitions a given architecture into business, data, applications, and technology architectures. The FEAF overall framework created at that time (see image) includes the first three columns of the
83:, Office of E-Government and IT, that aims to realize the value of enterprise architecture within the U.S. Federal Government. Enterprise Architecture became a recognized strategic and management best practice in U.S. Federal Government with the passage of the
142:
which in turn provide the requirements for enabling technologies. At its core is the Consolidated Reference Model (CRM), which equips OMB and Federal agencies with a common language and framework to describe and analyze investments.
76:. An EA describes the current and future state of the agency, and lays out a plan for transitioning from the current state to the desired future state. A federal enterprise architecture is a work in progress to achieve these goals.
280:
The Consolidated Reference Model of the Federal Enterprise Architecture Framework (FEAF) equips OMB and Federal agencies with a common language and framework to describe and analyze investments. It consists of a set of interrelated
639: : define the standards and technologies that support a Service Category. To support agency mapping into the TRM, many of the Service Standards provide illustrative specifications or technologies as examples.(Plain text)
71:
Enterprise architecture (EA) is a management best practice for aligning business and technology resources to achieve strategic outcomes, improve organizational performance and guide federal agencies to better execute their
599:
The DRM is the starting point from which data architects should develop modeling standards and concepts. The combined volumes of the DRM support data classification and enable horizontal and vertical information sharing.
286:
consistent way. Through the use of the FEAF and its vocabulary, IT portfolios can be better managed and leveraged across the federal government, enhancing collaboration and ultimately transforming the Federal government.
633: : classify lower levels of technologies and standards with respect to the business or technology function they serve. In turn, each Service Category comprises one or more Service Standards. (Bold-face groupings)
646:
Aligning agency capital investments to the TRM leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability. Agencies and the federal government will benefit from
497:
the federal government around common business areas instead of by a stovepiped, agency-by-agency view, the BRM promotes agency collaboration and serves as the underlying foundation for the FEA and E-Gov strategies.
316:
The ARM categorizes the system- and application-related standards and technologies that support the delivery of service capabilities, allowing agencies to share and reuse common solutions and benefit from
90:
There are numerous benefits that accrue from implementing and using an enterprise architecture within the U.S. Federal Government. Among them is to provide a common approach for IT acquisition in the
114:(EA) within any Federal Agency for a system that transcends multiple inter-agency boundaries. It builds on common business practices and designs that cross organizational boundaries, among others the
310:
The DRM facilitates discovery of existing data holdings residing in "silos" and enables understanding the meaning of the data, how to access it, and how to leverage it to support performance results.
59:, the U.S. "Federal Enterprise Architecture" (FEA) and the corresponding U.S. "Federal Enterprise Architecture Framework" (FEAF). This lemma will focus on this particular enterprise architecture and
706:
structure: segment architecture inherits the framework used by the EA, although it may be extended and specialized to meet the specific needs of a core mission area or common or shared service.
198:
lifecycle for use at all levels of scope defined in the Common Approach to Federal Enterprise Architecture: International, National, Federal, Sector, Agency, Segment, System, and Application.
900:
873:
973:
709:
reuse : segment architecture reuses important assets defined at the enterprise level including: data; common business processes and investments; and applications and technologies.
1041:
847:
327:
The IRM categorizes the network/cloud related standards and technologies to support and enable the delivery of voice, data, video, and mobile service components and capabilities.
168:
712:
alignment : segment architecture aligns with elements defined at the enterprise level, such as business strategies, mandates, standards, and performance measures.
402:
The PRM is a standardized framework to measure the performance of major IT investments and their contribution to program performance. The PRM has three main purposes:
233:
548:
example, the four components within the Customer Preferences Service Type include: Personalization; Subscriptions; Alerts and Notifications; and Profile Management.
48:. It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement.
409:
Improve the alignment — and better articulate the contribution of — inputs to outputs and outcomes, thereby creating a clear "line of sight" to desired results;
378:
It is designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services. It is an initiative of the US
752:
1046:
333:
The SRM provides a common language and methodology for discussing security and privacy in the context of federal agencies' business and performance goals.
772:
589:
893:
843:
91:
56:
868:
757:
970:
653:
110:
In September 1999, the Federal CIO Council published the "Federal Enterprise Architecture Framework" (FEAF) Version 1.1 for developing an
94:. It is also designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services.
145:
Overall the Federal Enterprise Architecture (FEA) is mandated by a series of federal laws and mandates. These federal laws have been:
115:
259:
60:
819:
581:
Volume One of the DRM provides a high-level overview of the structure, usage, and data-identification constructs. This document:
131:
933:
578:
will streamline information exchange processes within the federal government and between government and external stakeholders.
379:
80:
237:
304:
service areas instead of through a stove-piped organizational view, thereby promoting intra- and inter-agency collaboration.
920:
657:
1016:
421:
222:
669:
architecture. The Federal Enterprise Architecture Practice Guidance (2006) has defined three types of architecture:
585:
Provides an introduction and high-level overview of the contents that will be detailed in Volumes 2–4 of the model;
241:
226:
747:
473:
459:
432:. In addition, the PRM was informed by what agencies are currently measuring through PART assessments, GPRA,
412:
Identify performance improvement opportunities that span traditional organizational structures and boundaries
289:
The five reference models in version 1 (see below) have been regrouped and expanded into six in the FEAF-II.
692:
433:
153:
111:
52:
41:
991:
Opportunities to Reduce Potential Duplication in Government Programs, Save Tax Dollars, and Enhance Revenue
436:, and Capital Planning and Investment Control. The PRM is currently composed of four measurement areas:
717:
672:
429:
106:
Structure of the U.S. "Federal Enterprise Architecture Framework" (FEAF) Components, presented in 2001.
509:
699:
571:
557:
272:
102:
762:
648:
417:
355:
318:
185:
45:
358:
for describing IT resources. FEA Version 1 reference models (see image) included the following:
17:
575:
394:
383:
159:
123:
84:
501:
into EA business architectures and the management processes of all Federal agencies and OMB.
406:
Help produce enhanced performance information to improve strategic and daily decision-making;
958:
608:
562:
977:
941:
877:
851:
767:
351:
282:
416:
The PRM uses a number of existing approaches to performance measurement, including the
728:
Results of the Federal Enterprise Architecture program are considered unsatisfactory:
595:
Provides the basic concepts, strategy, and structure to be used in future development.
1035:
127:
73:
342:
940:. National Institute of Standards and Technology. January 15, 2015. Archived from
425:
211:
79:
The U.S. Federal Enterprise Architecture (FEA) is an initiative of the U.S.
1021:
737:
developing and using enterprise architectures remains largely unrealized".
464:
188:
Management of Federal Information Resources, first issued in December 1985
617:
technology and Service Components from a government-wide perspective.
643:
The figure on the right provides a high-level depiction of the TRM.
652:
application Service Components that may be used and leveraged in a
842:
Federal Enterprise Architecture Program Management Office (2007).
341:
271:
1026:
1006:
181:
A-11 : Preparation, Submission and Execution of the Budget
205:
164:
GPEA 1998 : The Government Paperwork Elimination Act
51:
The most familiar federal enterprise architecture is the
27:
Reference enterprise architecture of a federal government
971:"Why Doesn’t the Federal Enterprise Architecture Work?"
1011:
149:
GPRA 1993 : Government Performance and Reform Act
888:
886:
820:
FEA Consolidated Reference Model Document Version 2.3
676:
Federal Enterprise Architecture levels and attributes
894:"Common Approach to Federal Enterprise Architecture"
870:
A Practical Guide to Federal Enterprise Architecture
993:. Washington, DC: Government Accountability Office.
921:
Federal Enterprise Architecture Framework version 2
1012:Federal Chief Information Officers Council website
1007:Federal Enterprise Architecture Institute website
1017:DoD CIO Enterprise Architecture & Standards
1042:United States Office of Management and Budget
899:. Office of Management and Budget. May 2012.
8:
753:Department of Defense Architecture Framework
959:FEA Records Management Profile, Version 1.0
919:FEA Consolidated Reference Model Document.
521:The SRM establishes the following domains:
240:. Unsourced material may be challenged and
169:Federal Information Security Management Act
838:
836:
834:
832:
830:
828:
818:FEA Consolidated Reference Model Document.
773:Treasury Enterprise Architecture Framework
934:"2015–2016 Baldrige Excellence Framework"
867:Chief Information Officer Council (2001)
592:development of the remaining volumes; and
260:Learn how and when to remove this message
34:federal enterprise architecture framework
980:, Stanley B. Gaver, visited 19 May 2016.
923:January 29, 2013. Accessed 2 April 2015.
863:
861:
859:
671:
607:
561:
508:
479:The BRM is broken down into four areas:
463:
393:
350:The FEA is built using an assortment of
101:
1027:Baldrige Performance Excellence Program
953:
951:
938:Baldrige Performance Excellence Program
814:
812:
810:
808:
784:
505:Service Component Reference Model (SRM)
177:Supplementary OMB circulars have been:
173:E-Gov 2002 : Electronic Government
57:Federal government of the United States
915:
913:
906:from the original on January 22, 2017.
806:
804:
802:
800:
798:
796:
794:
792:
790:
788:
758:FDIC Enterprise Architecture Framework
822:October 2007. Accessed 28 April 2009.
7:
324:Infrastructure Reference Model (IRM)
238:adding citations to reliable sources
1047:Enterprise architecture frameworks
513:Service Component Reference Model.
492:Management of Government Resources
468:Business Reference Model overview.
398:Performance reference model, 2005.
368:service component reference model,
193:Collaborative planning methodology
116:NIST Enterprise Architecture Model
25:
390:Performance Reference Model (PRM)
313:Application Reference Model (ARM)
293:Performance Reference Model (PRM)
61:enterprise architecture framework
346:Federal Enterprise Architecture.
276:Federal Enterprise Architecture.
210:
132:Enterprise Architecture Planning
92:United States federal government
604:Technical Reference Model (TRM)
380:Office of Management and Budget
81:Office of Management and Budget
18:Federal Enterprise Architecture
566:The DRM Collaboration Process.
454:Business Reference Model (BRM)
330:Security Reference Model (SRM)
300:Business Reference Model (BRM)
1:
658:service-oriented architecture
382:that aims to comply with the
537:Business Analytical Services
531:Business Management Services
489:Support Delivery of Services
440:Mission and Business Results
362:performance reference model,
528:Process Automation Services
428:, the value chain, and the
422:value measuring methodology
1063:
612:Technical Reference Model.
555:
552:Data Reference Model (DRM)
457:
374:technical reference model.
338:Version 1 reference models
307:Data Reference Model (DRM)
202:Version 2 reference models
850:October 16, 2010, at the
684:Segment architecture, and
365:business reference model,
748:Business reference model
681:Enterprise architecture,
474:business reference model
460:Business Reference Model
446:Processes and Activities
371:data reference model and
40:) is the U.S. reference
693:Enterprise Architecture
434:enterprise architecture
154:Paperwork Reduction Act
112:Enterprise Architecture
53:enterprise architecture
42:enterprise architecture
976:June 11, 2016, at the
687:Solution architecture.
677:
613:
567:
534:Digital Asset Services
514:
469:
399:
354:that develop a common
347:
277:
107:
844:FEA Practice Guidance
718:Solution architecture
675:
620:The TRM consists of:
611:
590:community of interest
565:
512:
483:Services for Citizens
467:
430:Theory of Constraints
420:, Baldrige Criteria,
397:
345:
275:
105:
961:. December 15, 2005.
700:segment architecture
572:Data Reference Model
558:Data Reference Model
540:Back Office Services
426:program logic models
234:improve this section
763:Physical data model
664:Architecture levels
944:on August 4, 2016.
876:2008-10-10 at the
678:
649:economies of scale
631:Service Categories
614:
568:
515:
470:
418:Balanced Scorecard
400:
348:
319:economies of scale
278:
186:OMB Circular A-130
167:FISMA 2002 :
108:
46:federal government
637:Service Standards
576:common data model
525:Customer Services
384:Clinger-Cohen Act
270:
269:
262:
160:Clinger-Cohen Act
124:Zachman Framework
85:Clinger-Cohen Act
16:(Redirected from
1054:
994:
987:
981:
968:
962:
955:
946:
945:
930:
924:
917:
908:
907:
905:
898:
890:
881:
865:
854:
840:
823:
816:
543:Support Services
486:Mode of Delivery
443:Customer Results
352:reference models
283:reference models
265:
258:
254:
251:
245:
214:
206:
158:CCA 1996 :
152:PRA 1995 :
21:
1062:
1061:
1057:
1056:
1055:
1053:
1052:
1051:
1032:
1031:
1003:
998:
997:
988:
984:
978:Wayback Machine
969:
965:
956:
949:
932:
931:
927:
918:
911:
903:
896:
892:
891:
884:
878:Wayback Machine
866:
857:
852:Wayback Machine
841:
826:
817:
786:
781:
768:Reference model
744:
726:
724:Program results
691:By definition,
666:
654:component-based
606:
560:
554:
507:
462:
456:
392:
340:
266:
255:
249:
246:
231:
215:
204:
195:
100:
69:
28:
23:
22:
15:
12:
11:
5:
1060:
1058:
1050:
1049:
1044:
1034:
1033:
1030:
1029:
1024:
1022:FEA with ADOit
1019:
1014:
1009:
1002:
1001:External links
999:
996:
995:
982:
963:
947:
925:
909:
882:
855:
824:
783:
782:
780:
777:
776:
775:
770:
765:
760:
755:
750:
743:
740:
739:
738:
734:
725:
722:
714:
713:
710:
707:
698:By contrast, "
689:
688:
685:
682:
665:
662:
641:
640:
634:
628:
605:
602:
597:
596:
593:
586:
556:Main article:
553:
550:
545:
544:
541:
538:
535:
532:
529:
526:
506:
503:
494:
493:
490:
487:
484:
458:Main article:
455:
452:
451:
450:
447:
444:
441:
414:
413:
410:
407:
391:
388:
376:
375:
372:
369:
366:
363:
339:
336:
335:
334:
331:
328:
325:
322:
314:
311:
308:
305:
301:
298:
294:
268:
267:
218:
216:
209:
203:
200:
194:
191:
190:
189:
182:
175:
174:
171:
165:
162:
156:
150:
99:
96:
68:
65:
26:
24:
14:
13:
10:
9:
6:
4:
3:
2:
1059:
1048:
1045:
1043:
1040:
1039:
1037:
1028:
1025:
1023:
1020:
1018:
1015:
1013:
1010:
1008:
1005:
1004:
1000:
992:
986:
983:
979:
975:
972:
967:
964:
960:
954:
952:
948:
943:
939:
935:
929:
926:
922:
916:
914:
910:
902:
895:
889:
887:
883:
879:
875:
872:
871:
864:
862:
860:
856:
853:
849:
845:
839:
837:
835:
833:
831:
829:
825:
821:
815:
813:
811:
809:
807:
805:
803:
801:
799:
797:
795:
793:
791:
789:
785:
778:
774:
771:
769:
766:
764:
761:
759:
756:
754:
751:
749:
746:
745:
741:
735:
731:
730:
729:
723:
721:
719:
711:
708:
705:
704:
703:
701:
696:
694:
686:
683:
680:
679:
674:
670:
663:
661:
659:
655:
650:
644:
638:
635:
632:
629:
626:
625:Service Areas
623:
622:
621:
618:
610:
603:
601:
594:
591:
587:
584:
583:
582:
579:
577:
573:
564:
559:
551:
549:
542:
539:
536:
533:
530:
527:
524:
523:
522:
519:
511:
504:
502:
498:
491:
488:
485:
482:
481:
480:
477:
475:
466:
461:
453:
448:
445:
442:
439:
438:
437:
435:
431:
427:
423:
419:
411:
408:
405:
404:
403:
396:
389:
387:
385:
381:
373:
370:
367:
364:
361:
360:
359:
357:
353:
344:
337:
332:
329:
326:
323:
320:
315:
312:
309:
306:
302:
299:
295:
292:
291:
290:
287:
284:
274:
264:
261:
253:
250:February 2017
243:
239:
235:
229:
228:
224:
219:This section
217:
213:
208:
207:
201:
199:
192:
187:
184:A-130 :
183:
180:
179:
178:
172:
170:
166:
163:
161:
157:
155:
151:
148:
147:
146:
143:
139:
135:
134:methodology.
133:
129:
125:
119:
117:
113:
104:
97:
95:
93:
88:
86:
82:
77:
75:
74:core missions
66:
64:
62:
58:
54:
49:
47:
43:
39:
35:
30:
19:
990:
989:GAO (2011).
985:
966:
942:the original
937:
928:
880:. Feb. 2001.
869:
727:
715:
697:
690:
667:
645:
642:
636:
630:
624:
619:
615:
598:
580:
569:
546:
520:
516:
499:
495:
478:
471:
415:
401:
377:
349:
288:
279:
256:
247:
232:Please help
220:
196:
176:
144:
140:
136:
120:
109:
89:
78:
70:
50:
37:
33:
31:
29:
957:FEA (2005)
588:Encourages
1036:Categories
779:References
733:failures".
449:Technology
472:The "FEA
297:outcomes.
221:does not
87:in 1996.
974:Archived
901:Archived
874:Archived
848:Archived
742:See also
356:taxonomy
126:and the
67:Overview
242:removed
227:sources
98:History
55:of the
128:Spewak
904:(PDF)
897:(PDF)
44:of a
570:The
225:any
223:cite
38:FEAF
656:or
236:by
130:'s
1038::
950:^
936:.
912:^
885:^
858:^
846:.
827:^
787:^
660:.
424:,
386:.
63:.
32:A
716:"
321:.
263:)
257:(
252:)
248:(
244:.
230:.
36:(
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
