Practical Guide to SOA Infrastructure (3FS7)
Develop infrastructures in enterprise space, not project space (3FS8)
Projects (stovepipes) should not be expected to build infrastructures that must be interoperable with other projects across the enterprise. Infrastructures should be developed in enterprise space; a separate space that is managed by the enterprise independently from all projects. Projects focus on building enterprise services within their own project space. These intercommunicate via an enterprise service bus, which the enterprise as a whole contributes to within enterprise space. (3FS9)
The distinction between enterprise and project spaces is modeled after a similar distinction made in the construction industry. Developers build houses (services) within a distinct project space for each house, independently of other developers' spaces. But the project spaces all share a common infrastructure (bus) that is developed and managed centrally for the enterprise as a whole (by the state, county, city, etc). The interface between project space and enterprise space occurs at a tightly specified demarcation point. This is typically in the basement, where the internal electrical/plumbing/water systems connect to the external infrastructure of the state, county or city. (3FSA)
Base interoperable infrastructures on enterprise-wide collaboration (3FSB)
Most project stovepipes are based on and funded by the government acquisition process. This requires each project to meet specified objectives within a specific timeframe. The acquisition process imposes considerable oversight to ensure that government's objectives are being met. This imposes a significant documentation burden on each project and leads to stovepipe mentality; overemphasis on project objectives at the expense of broader enterprise objectives such as interoperability. (3FSC)
Infrastructures develop and evolve over an extended life time that is far longer than any particular project. While traditional project acquisition processes are appropriate for finite-duration projects (services developing over months or years), they are not appropriate for enterprise infrastructures, which must remain operational for generations while evolving to stay abreast of continually changing base technologies (computers, networks) and evolving requirements. (3FSD)
Thanks to the reliance on cross-project collaboration, costs are affordable. For example, infrastructural management are drawn from managers already responsible for enterprise (non project-specific) objectives such as interoperability or security. Development staff is drawn from existing projects who are interested in building, improving or evolving the common infrastructure to meet their own project's mandated objectives. Existing information assurance and interoperability testing staff are not restricted to making a pass/fail judgment on something tossed 'over the transom' at the end. They work within the enterprise space as part of the collaborative team, contributing their detailed knowledge of interoperability or security requirements that other team members may well lack. (3FSE)
Standards and Interoperability Policy are necessary, not sufficient (3FSF)
The current project-centric acquisition process (3FSG)
Example Enterprise Space: http://giglite.org (3FSH)
The distinction between 'enterprise space' and 'project space' is not recognized by current government acquisition processes. This section will try to make it familiar by means of an specific example of the enterprise space at http://giglite.com. (3FSI)
First, notice that the difference between enterprise space and project space is not a matter of the tools provided there. GIGlite is based on CollabNet, which provides exactly the same tools as the CollabNet instances used by many projects today (NCES; others?). The difference is that the scope is enterprise-wide, and that management, development and testing staff is drawn from existing staff across government (Naval Postgraduate School, SPAWAR, JITC, DISA) and industry (Unisys, Binary, IONA, Gestalt). (3FSJ)