This paper is available from http://openpdq.com/OpenSystems.
The author can be contacted at mailto:p.henderson@ecs.soton.ac.uk
The following is a preliminary list of topics that an Architecture team will need to consider as they establish a project intended to develop a solution with an Open System Architecture. These are not presented in any particular order (and certainly not priority order). Indeed, the Architectural Design process will be an iterative process of moving forward on all these fronts.
1. Obtain Training in Open System principles. There are key concepts that are specific to open systems, that go beyond mere modularity and interoperability. These need to be understood.
2. Obtain Training in Open System Architecture Definition Methods. The architects need a clear understanding of topics like UML, SysML, MoDAF viewpoints and an ability to draw up guidelines on how these tools are going to be used.
3. Establish Boundary of System of Interest. A harder problem than it sounds, but one that needs early attention.
4. Establish First-Cut Architecture. The Architecture is a shared resource around which the entire team functions, so having an early candidate is important. Granularity is an important issue. Not too course, not too fine?
5. Establish Infrastructure to be built from COTS. On the assumption that a significant part of the solution will be built on readily-sourced infrastructure, the distinction between infrastructure and domain-specific applications needs to be identified early.
6. Study Legacy solutions and harvest reusable components (Asset Mapping). Even for Open Systems, most of the components in a solution will be reengineered legacy. Knowing what these components are is essential. Some legacy systems may need to be opened.
7. Establish Governance for Open Architecture in Application Domain. Establish a body that is responsible for the development of the Architecture and the Specification of Interfaces. This body will need to have commercial/legal strength to maintain openness of solution.
8. Understand Standards available in Application Domain and provided by Infrastructure. There will be some obvious protocols and standards that can be adopted in the infrastructure. These will be dictated by the available COTS. There will also be suitable standards available where the infrastructure supports the Domain Specific Applications (e.g. DDS)
9. Determine Interfaces to Components that need Specification. Some interfaces will need new definitions, especially those between the Application components. Architects agree what those are. The Governing body is responsible for procuring and maintaining these definitions as new Open Standards.
10. Establish Vision System and Incremental Capability Builds. An Open System will have a long life and will comprise many capability builds. Having a vision system (a far target) and a series of interim solutions is an important tool for keeping the Architecture team pointing in the same direction.
11. Establish Test and Acceptance for Open System. Modularity and Openness introduce new prospects for reduced cost in the areas of Test, Accreditation and Certification, based on modular reasoning.
12. Establish Procurement for Integration. Notwithstanding the intention that Open Systems are intended to reduce incumbency, it is anticipated that the integration role will be procured from one organization and that role needs to be assigned early. The integration supplier will be contracted to supply an integration environment supporting open procurement.
13. Establish Procurement for Components. There is a role here for the architect. They must take the prospects for procurement into account when designing the architecture.
14. Establish Architecture and Specification maintenance process. Part of the role of the governing body, involves publication, voting, releasing etc.
15. Establish means of maintaining Consistency and measuring completeness of builds. We mean Architecture builds. Measures of completeness are vital for planning downstream activities. Both tolerating and then removing inconsistencies (in the architecture) are essential for rapid progress in architecture definition.