The Design View is intended to assist technical managers, architects, and their development teams to identity more technical components of the architecture - what web service capabilities are needed, the concepts and best practices of Service Oriented Architecture, and available references and resources. The Design View contains the services and service interaction process models, provides content on designing exchanges, information on published service specification packages, and technology standards. The Design View will describe the implementation initiatives at state and local agencies, what national networks and infrastructure elements are in place to support information sharing, and what technical principles can assist in decisions of provisioning strategies.
The design view contains the services and service interaction model sub-categories, provides content on designing exchanges, links to published service specification packages, and technology standards. The ‘Designing an Information Exchange’ page provides an overview of service-oriented concepts, principles, and a design methodology. The ‘Service Identification Methodology’ provides a detailed process that, if continually followed, will provide an ever-growing catalog of services. As the service catalog expands the cost-effectiveness of using services increases, integration efforts are reduced, and deployment time decreases.
Questions to be answered by Design View:
- What is the typical state of implementation of supporting technology at the state and local levels of government?
- What networks and other national technology infrastructure elements are in place to support information sharing?
- What technical principles can inform choices of technology provisioning strategy (e.g., cloud or shared services)?
- Where are there gaps in what the operational and planning views require?
Technologists must become more outward facing and knowledgeable about the business side of the broader justice enterprise. While they do not need to become experts in the business, they need an understanding of the language that allows them to talk with business analysts about the business. Architects, in particular, provide the communications channel and the link between the justice business requirements (Operational View) and the resulting technology solution (Design View). They need to ensure that business requirements and solutions are traceable and interdependent. This interdependence can be achieved by working very closely with business analysts to ensure that the solutions proposed fully align with the justice business requirements. In common SOA vernacular, it’s called “exposing the business architecture.”
The Design View of the NJDA provides this perspective by decomposing the Business Process Models (Operational View) into services. (“Services” in the context of this view of the tool are a technical means for exchanging data between systems.) This aids architects and designers in arriving at the right service granularity for their capabilities and business services identified and building an enterprise service catalog. By using a standard process to identify an organization’s capabilities, even non-experts in a given business domain (justice enterprise) can facilitate a useful discussion about business requirements and can surface important information on function, metrics, performance, maturity, interconnectedness, governance, and compliance. Because business process practitioners are answering questions from a technical architect, the architect in fact helps to expose a view that the practitioners may not yet have. The introduction of a service model between the business model and the technology model is a key factor that can help achieve this goal, which leads into Model-Driven Architecture as another premise of the NJDA.
Services are the core organizational category of the Design View and based upon the standards for NIEM IEPDs and GRA Service Specifications. The meta-model includes scope, real-world effect, associated documents, archetype, and service actions as depicted below. If a national reference IEPD or GRA Service Specification is published these are noted.
This category has the following 2 subcategories, out of 2 total.