1 / 10

GISWG Services Committee Report

This report discusses the agreement of the Services Committee to adopt a services capability approach and the need for two documents: Service Identification Methodology and Service Specification. The focus is on capability identification in the law enforcement domain, specifically Fingerprint Identification. The draft Services Definition Principles document has been tentatively approved pending further review. The report also highlights the need to address user/system-level security concerns in the service specification.

ccunningham
Download Presentation

GISWG Services Committee Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GISWG Services Committee Report Scott Fairholm, Chair October 5, 2006 Alexandria, Virginia

  2. 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.

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

  4. 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

  5. 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 Assignment to Services Interaction Committee

  6. 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

  7. 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:

  8. 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.

  9. 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

  10. Services Specification Document: Draft Outline • Visibility (Taxonomy) • Naming • Versioning • Lifecycle Management • Considerations • Security • Service Interaction Profiles (SIPs) • Execution Context • Performance • Deployment • Enabling

More Related