170 likes | 259 Views
Achieving Justice Information Interoperability. The Justice Reference Architecture: A Global Project. What the JRA is. Based on Service orientation Based on open standards Supports implementation interoperability Supports state and local justice agency exchanges
E N D
Achieving Justice Information Interoperability The Justice Reference Architecture: A Global Project
What the JRA is • Based on Service orientation • Based on open standards • Supports implementation interoperability • Supports state and local justice agency exchanges • Partnership of government practitioners and industry vendors
The Usual Business Justifications • Do it quicker. • Do it cheaper. • Do it better. • Increase business flexibility
Motivations to Share Information • Core justice business needs (ongoing) • Terrorist attacks—September 11, 2001 • Natural disasters—Hurricane Katrina (2005) • Pandemics—Avian Flu (????) • What next??? • It is hard to predict future information sharing needs, so flexibility is critical
Barriers to Interoperability (1) • It is very difficult to even hold a conversation about interoperability unless there is a common vocabulary for reference architectures • The OASIS SOA Reference Model (SOA RM)—a choice rapidly gaining traction in the vendor community • Tested the SOA RM concepts with several other domains and expanded it as a conceptual reference architecture.
United States Department of Justice The Moving Parts
Barriers to Interoperability (2) • Information Model Issues • Data and document models (concepts, definitions, schema) • Document model (domain model, schema) • Service Model Issues • Core (enterprise) or shared • Line of business • Individual agency
Barriers to Interoperability (3) • Services Issues (consistent definitions and interfaces) • Repository Issues • Standards-based interfaces • Support for federation • Standard metadata for types of services • Service Interaction Requirement (messaging) Issues • Consistent requirements across service interaction profiles (security, privacy, etc.) • Consistent requirements by service
Barriers to Interoperability (4) • Service Interaction Profile (messaging) Issues • Standards-based profiles • Compatible profiles • Special Service (intermediary) Issues • Routing and orchestration • Transformations • Validation
Barriers to Interoperability (5) • Policy/Agreement/Contract Issues • Consistent business rules (privacy, security, etc.) • Consistent service level agreements • Governance Issues • Agreement on reference standards • Process for maintenance and versions • Execution Context (implementation) Issues • Network roll-ups, simplified business rules, etc.
What is Needed? • Something complementary to both the federal, NASCIO, and agency enterprise architectures • An implementation reference architecture for information sharing • Partly generic standards for information sharing • Partly standards specific to a domain
The Modular Pieces • Information Model • Interchangeable vocabularies (GJXDM, EDXL > NIEM) and reference exchange schemas • Composable components to create new exchange schemas quickly and easily • Service Interaction Profiles (messaging) • Interchangeable profiles like Web services, MQ, wireless, etc. • Composable micro-services to create new services quickly and easily
The Generic Solutions • A Reference Model • Provides a common language to talk about different implementation architectures (the concept of a kitchen) • A Conceptual Reference Architecture • Provides common concepts for mapping across different implementation architectures (a generic kitchen) • A Domain Reference Architecture • Provides an actual set of implementation standards that enables interoperability (a specific kitchen design)
What Is Reusable Across Domains? • Information Model • Core components like name and address (NIEM) • Service Interaction Requirements (messaging) • Some requirements definitions • Service Interaction Profiles (messaging) • Some profiles (at least partially) • Some specific technical solutions—Web services, MQ, wireless (maybe)
What Needs to Behave Nicely? • Repositories (federation, shared architectural components—data, services, etc.) • Identification Mechanisms (compatible security, access) • Security and Privacy (business rules, security controls, role codes, and data category)
Hot off the Press • JRA specification 1.0 out very soon. • First service interaction profiles in 0.7 draft (web services, JMS, ebXML, MQ Series, first wireless). • Formal efforts to coordinate with DOJ architecture (LEISP, NIEM, etc.). • Encouraging conversations with DHS and DNI (ISE). • Initial conversations with HealthIT, EPA, and others.