# Presentation: 326694

## GISWG Services Committee Report

- Scott Fairholm, Chair
- October 5, 2006
- Alexandria, Virginia

## Resolution

- The Services Committee agrees with the EAC recommendation of a services capability approach.
- We agree that two documents are needed:  1)  Service Identification Methodology, and 2) Service Specification.
- The law enforcement domain was selected for capability identification.
- This was further initially narrowed to single class of capabilities (i.e., Fingerprint Identification)
- Rationale: Balancing risk and value, we believe that this set of capabilities gives high return, and the governance issues are largely understood (and acknowledged/considered by the Services Committee) and not anticipated to pose significant concerns/impediments.

## Resolution

- The Service Specification, with Fingerprint Identification as example, will be addressed first.
- Subsequently, the Committee will address the Methodology.

## Deliverable

- 	The draft ***Services Definition Principles*** document was tentatively approved, pending further Committee review
- Schedule:  next two weeks – final vetting
- To be incorporated into the JRA, *Services Specification,* and/or *Methodology *document

## Assignment to Services Interaction Committee 

- 	Develop a **Registry Taxonomy **that fully  specifies a service and facilitates input into a repository
- Will address metadata issues, for inclusion into the Services Specification document

## Issue for Resolution by the EAC 

- 	The JRA does not address user-specific issues.
- 	How do we address user/system-level security concerns in the JRA, and should we address this issue in the service specification?  E.g.:
- 	-- 	An agency has a policy that *X information* will 	only be provided to *Y people*; OR
- 	--	Juvenile information will not be provided to 	certain people?
- 	--	Don’t know until you see the data

## Product from this Meeting 

- Jim Douglas (with Iveta) will draft an initial *Service Identification Methodology* document
- Outline for *Services Specification* document
- Considering discussions in Alexandria, Sharad to flesh out outline, for vetting by Committee
- The next anticipated deliverable from this group, tentatively slated for completion by December
- To be validated by first instance
- Outline as follows:

## Services Specification Document:  Draft Outline

- Service Name – [Fingerprint Identification Service]
- Version
- Lifecycle management
- Context
- “Real world effect of this service is...”
- Applicability
- Service Overview
- Description
- Scope
- Business Scenarios (elaboration/illustration of the Overview)
- Assumptions and DependenciesPurpose:  Expectation management.

## Services Specification Document:  Draft Outline

- Information Model
- Includes logical description of model
- Include an IEPD(s) directly, or by reference
- If IEPD is unavailable, includes comparable artifacts
- Behavioral Model
- Processing Rules
- Functional model
- BPMN (recommended) for this specific use case (sequence diagram)
- Fault Handling
- Profiles
- Service Interface
- Including formal service interface specification (e.g., WSDL) service template

## Services Specification Document:  Draft Outline

- Visibility (Taxonomy)
- Naming
- Versioning
- Lifecycle Management
- Considerations
- Security
- Service Interaction Profiles (SIPs)
- Execution Context
- Performance
- Deployment
- Enabling