Editor's Notes
- #6: Discuss OPNAV request for this information and how it has evolved into the need for a Technical Authority and governance of SOA efforts across the Navy
- #7: Discuss OPNAV request for this information and how it has evolved into the need for a Technical Authority and governance of SOA efforts across the Navy
- #10: The TRM currently exists and was defined by ongoing SOA implementations in the Navy and PEO C4I Core Services Stack promulgationThe SRM incorporates how, when, and to what extent legacy and emerging enterprise services are utilized in a SOAThe BRM which is yet to be defined is the key to the GiG integration of SOA and use of services between DoD as a whole. It is the key to the interoperability of the Navy
- #11: TRM * is a combination of :Component Driven, technical framework that categorizes standards Associated guidance for the implementation and use of these standardsMapping and reuse of standards to technology and business processesSOA TRMDeveloped a SOA TRM Based on web services standardsCovers these categories for applications and infrastructureMediationCollaborationMessagingSecurityVisualizationOrchestrationDiscovery
- #13: Mansfield notes:Programmatic:Throughout the course of systems (or system of systems) development and delivery, the programmatic sphere is subjected to a series of requirement checks and functional assessments based on a milestone schedule that is implemented to justify continued funding. This makes the programmatic sphere (i.e., Program Manager) reluctant to accept any changes to requirements for fear of disrupting the process and loss of funding. There is actually a counter-incentive to introducing new (i.e., Net-centric) review cycles for fear of program revocation based on time and funding constraints. That is to say, new requirements equals more time meaning breaking of milestone schedule which puts the project at risk of having its funding cut. Therefore there is no incentive to follow interoperability path, especially without moneys specifically provided to pay for the requirements derived from the need for Net-Centricity. Without the flexibility (and inThe operations sphere has roles and responsibilities that are applied at different points in the lifecycle of a program. Operations:The operations sphere is heavily tasked in the beginning of the process to establish the plan and requirements. In subsequent phases of the process, Operations is less involved as the solution is developed and produced and does not get fully re-engaged until deployment. As the missions change throughout the lifecycle, it is difficult for these changes to be inserted into the process. Additionally, since the Operations sphere doesn’t get full re-engaged until deployment, the end-user employs the new capabilities using the old tactics, not being given time to fully develop a better mental model based on access to now information and capability. The end result is that money is wasted constantly adopting and fielding new technologies without adapting the TTPs/CONOPs. This ultimately is why \"Force Transformation\" Technical:The technology sphere is generally handed functional requirements and asked to develop solutions. Once the architecture and technical baseline is approved and funded, any changes in the design or technologies (large or small) can cause undue burden at many levels of the process and therefore are avoided except at major delivery milestones. These cycles are typically not less than a couple years per milestone. Additionally, the acquisition sphere often attempts to force solutions on the technology sphere to immediately cut costs and “simplify” the architecture by applying a “just buy” or “just reuse” of product set or other baseline philosophy. It is not as simple as architectural “copy/paste”. The result is increased cost to integrate improper solutions into the baseline and support the solutions, and potential failure to meet technical performance and schedule.
- #34: For ISNS but adopted by CANES as a starting point in the absecce of governance.
- #45: Tech Authority for SOA
- #46: Multi-Service SOA Consortium workDISR and GESPWeb ServicesIndustry