Architecture Use Details
The accompanying figure zooms in on ARC-IT artifacts that are accessed by RAD-IT to support regional ITS architecture development and SET-IT to support project development/systems engineering.Architecture Use Details
As shown, RAD-IT uses service packages as a primary entry point that allows the regional architect to select the ITS services of interest and then gather all of the relevant ARC-IT artifacts for those ITS services. The regional architect uses RAD-IT to develop a regional architecture customized to his region. This architecture focuses on:- Stakeholders, their roles within the architecture with respect to services offered, which address concerns related to responsibility and delivery of services to end users.
- Services offered in terms of service package
- Elements that exist or will exist in the region - these are instantiations of physical objects.
- Information exchanges between elements - these are instantiations of information flows.
- Stakeholder roles and responsibilities - these usually concern the delivery of services or the exchange of information.
RAD-IT also provides the user with the ability to define projects within the region. These are subsets of the region that are "planned" or "future" and are partitioned into projects. A project will include all of the same material as the regional architecture, but only the portion that is applicable to the specific project; thus its scope is considerably smaller.
The project architect can take project specific information from RAD-IT and use it as a starting point in SET-IT to support the systems engineering process used in project development. As shown in the diagram, the starting point for SET-IT use is also Service Packages, which can be used to define the "scope" of the project. SET-IT can be used to develop a more detailed project architecture that can be used to support Concept of Operations and System Architecture Document development. This is necessarily considerably more detailed and technical than the regional content, and focuses on:
- Stakeholders, their roles within the project, captured as their operational role with respect to physical objects ("owns", "operates", "installs", etc.) which address concerns related to responsibility and delivery of services to end users.
- Services offered - these address the "mission" concern, and are typically illustrated by service packages. In SET-IT, service package diagrams may be graphically customized and modified to address specific project implementation choices and constraints.
- Elements that are part of the project, including those that already exist and those that will be built as part of the project - like those in the regional architecture these are instantiations of physical objects.
- Information exchanges between elements - these are instantiations of information flows, much like in the regional architecture.
- Relationships between stakeholders - these usually concern the delivery of services or the exchange of information. SET-IT affords the user the ability to document these graphically as well as in tabular form, and expands on the types of relationships, in particular to consider relationships between service providers and end users.
- Communications-specific content - communications stacks that are suitable for carrying information on each information flow, which can be used as system architecture content and directly drives the development of Interface Control Documents (ICD)
- Security-specific content - ARC-IT includes a FIPS-199 based analysis of all information flows and physical objects, which directly drives communications security requirements and device security requirements. This information is germane at the project level and can be used as part of ICDs and device specifications.
- Needs - Each service has a set of user needs that it meets. These can be tailored along with the service package .
- Requirements - Needs trace to requirements, which are associated with functional objects. Functional objects are included in the physical objects in each service package. Once the project architecture is complete, functional requirements associated with all services can be extracted through SET-IT.
As projects are completed, the state of elements in the regional architecture should change from "planned" to "existing." Additionally, once a project succeeds, the SET-IT artifacts that drove its design should be available for other, similar projects, which in the long run should improve interoperability and speed of deployment.