![]() |
| Home | Statistics | Documents | Catalog | StratEdit | XSLTForms | DNAOS | About | Portal | Glossary | Contact [!?] |
| Documents/PGFSOA/2: Architecture/4.2.5: Compliance and Alignment |
4.2.5: Compliance and Alignment Enable Automated Compliance and Alignment Other Information: Many EA efforts in the federal government are focused on compliance. It is not uncommon for organizations to resort to after-the-fact efforts to demonstrate compliance with the EA so that program funds will be approved. Enforcing the many compliance requirements that EA programs demand is a growing challenge; the default approach is to rely on teams of experts charged with sifting through inconsistent and often incorrect development lifecycle documentation of hundreds of projects. By adopting the SOA paradigm and the recommendations in this Guide, agencies should be able to use the EA to mitigate or even largely eliminate the compliance burden today’s EA programs place on projects. Since the move to SOA is an evolutionary sequence of steps, each program step will either take the agency closer to the target architecture or away from it. By placing more emphasis on architecting the solution and by employing model-driven architecture best practices in conjunction with the service portfolio planning technique discussed above, project teams can be provided with technologically compliant reference architectures that have service reuse requirements embedded in them. In this way, the EA becomes a benefit to programs rather than a burden. By using the portfolio approach described above, “core business services” can be developed for specific domains or verticals and “enterprise services” can be developed for common horizontal services. The Segment Architecture approach advocated by OMB is focused on this exact outcome of building out the EA incrementally in vertical and horizontal directions [OMB, 2007]. Developing services based on the service portfolio plan will ensure that the development efforts are automatically aligned with the EA and consistent with the principle of “architect, invest, implement” defined by OMB.” As a result, programs will be consumers and potentially providers of multiple services across the enterprise. Indicator(s):
|
| sitemap | Copyright 1971-2012 01 COMMUNICATIONS INC. ALL RIGHTS RESERVED. - Powered by DNAOS | contact |