Achieving Information Interoperability and Business Agility

1. Achieving Information Interoperability and Business Agility The Justice Reference Architecture: A Global Project

2. 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 (IJIS)

3. The Usual Business Justifications • Do it quicker. • Do it cheaper. • Do it better. These are still valid and very important. The business cases still work, but there is more.

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

5. E-Government Best Practices • Based on the real-world experience of major e-government vendors. • The real goal is business flexibility, because our business needs are always changing in ways that are not predictable • The paradox is that business flexibility requires adherence to technology standards constituting an implementation architecture

6. Barriers to Interoperability • Information sharing reference architectures are an efficient way to create IT standards • The main purpose of a reference architecture is to eliminate interoperability problems by establishing comprehensive technical standards for information sharing • There are multiple interoperability issues

7. 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. • Adopters: DoD, Adobe, Canada, etc.

8. United States Department of Justice The Moving Parts

9. Barriers to Interoperability (2) • Information Model Issues (GJXDM, NIEM, etc.) • Data and document models (concepts, definitions, schema) • Document model (domain model, schema) • Service Model Issues • Core (enterprise) or shared • Line of business • Individual agency

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

11. Barriers to Interoperability (4) • Service Interaction Profile (messaging) Issues • Standards-based profiles • Compatible profiles • Special Service (intermediary) Issues • Routing and orchestration • Transformations • Validation

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

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

14. A Plug-and-Play Architecture • Think about stereo connectors • The reference architecture needs to be modular • Cleanly separated components • Substitutable components • Rigorous technical standards are required to make this a reality

15. The Modular Pieces • Information Model • Interchangeable vocabularies (GJXDM/NIEM, EDXL, HL7) and exchange schemas (IEPDs) • 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

16. 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)

18. Some Specific Solutions (1) • Reference Model • OASIS SOA Reference Model • Appropriate only for service-oriented architectures • Conceptual Reference Architectures • Conceptual Justice Reference Architecture • Emergency Services Enterprise Framework • ??

19. Some Specific Solutions (2) • Some Actual Reference Architectures • Justice Reference Architecture (incomplete) • Emergency Management: CAP, DE (incomplete) • HealthIT (incomplete) • PHIN (incomplete) • Information Sharing Environment (incomplete) • Etc.

20. What Is a Realistic Strategy? • We actually need cross-domain solutions for real problems like terrorism, pandemics, hurricanes, etc., but there are NONE YET!! • We should reuse architectural components where there are vacuums now (messaging, security, privacy). • We should map between reference architectures where it is not practical to reuse or mature solutions already exist.

21. 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)

22. 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)

23. Hot off the Press • JRA specification 0.1 out soon. • First service interaction profiles out soon (web services, JMS, ebXML, MQ Series, first wireless). • Formal efforts to coordinate with DOJ architecture (NEISP, NIEM, etc.). • Encouraging conversations with DHS and DNI (ISE).