SEARCH Podcast #2: Understanding the Justice Reference Architecture

Global Justice Reference Architecture (JRA)

Interviewer Jim Douglas (JD):  The following is another conversation in our series of podcasts on justice information sharing national initiatives for 2009.  These podcasts are presented by SEARCH, The National Consortium for Justice Information and Statistics.  This series is made possible through a grant from the U.S. Department of Justice, Office of Justice Programs, Bureau of Justice Assistance.  Today’s topic is the Global Justice Reference Architecture. 

The Global JRA and related documents are considered the definitive source for justice and public safety agencies for guidance on implementing a service-oriented approach to information sharing.  With us today, we have Dr. Thomas Clarke, Vice President of Research and Technology for the National Center for State Courts.  We also have Scott Came, Director of the Systems and Technology Program for SEARCH. 

JD:  Tom, I would like to start off with a general question for you.  Could you provide us with some background on the origins of the Justice Reference Architecture.

Dr. Thomas Clarke (TC):  Sure, Jim, I would be happy to.  It actually dates back to around 2003 and 2004 when Global had done a pretty successful job of initiating a project for standardizing the semantics of data content, which was known back then as the GJXDM and now is NIEM , and they were realizing that there was a lot more to sharing information and technical interoperability than just the data content of the exchanges.  And so they started to think about how they could attack that larger problem, and they decided as a policy decision in 2004 that they wanted to use service-oriented architecture approach to designing these exchanges in the future for sharing information.  The Justice Reference Architecture project grew out of that as an attempt to take a service-oriented approach to a set of implementation standards and best practices for sharing justice information. 

Scott Came (SC):  So, Jim, just to follow up on what Tom said, it is probably important for your listeners to know that the genesis of the JRA really grew out of a couple of other SOA efforts.  One was the OASIS Industry Standards by the Organization for the Advancement of Structure Information Standards.  The information standards body started working on a reference model for service-oriented architecture, which attempted to define what the scope of SOA is and what some of the key concept definitions are, and we decided early on to leverage that good work and even participate in it to a certain extent, so that we could make sure we were as aligned as we could be with the broader industry efforts that the larger vender community was participating in, knowing that that would resonate better with the vender community that we rely on for many of our solutions on the justice phase.  And, also, so we could avoid redoing a lot of that work.  The second piece that it grew out of was an early effort that Tom and I and others were involved in to develop a new version of the electronic court filing specifications, which predated the Global decision that Tom mentioned by at least a couple of years and decided to take a service oriented approach to defining the interfaces and information exchange points between litigants and attorneys and parties in the case that need to file information electronically with the court and in the court itself.  We started a specification development effort that followed on the Global policy decision that Tom mentioned .  We were in a good position to leverage a lot of that work as well.  Things kind of grew from that.

JD:  Scott, what benefits does the SOA in general and the JRA in particular provide?  And why should our audience be interested in using the JRA?

SC:  Well, that’s a good question, Jim, and one that we’re often asked to address when we speak at conferences on this.  The primary business value of adopting service-oriented architecture is to gain agility.  As you do a better job of tying information systems together in the justice base, you want to do that in a way that avoids a lot of tight coupling and tight dependencies between what we know in our space to be very autonomous independent business organizations, so the better you are at drawing fairly clear boundaries and minimizing those dependencies, the more agile and responsive to business change those solutions will be.  So, that’s kind of the main benefit of service-oriented architecture itself.  One of the challenges is that developing an SOA is really hard and the folks in our community, IT professionals and justice practitioners at the state, local, and tribal levels, who are in a position to benefit from SOA, are generally busy people with a lot on their plates already.  They may be aware of their problem, be aware of SOA, give them the  prevalence of that topic in the trade press and at conferences and so forth.  They are almost certainly aware of things like the National Information Exchange Model that Tom mentioned and the Justice Information Exchange Model, OASIS, and other components that are part of an SOA but is far from clear when you look at that range of topics, technologies, and techniques.  It’s far from how you assemble cohesive architecture that adheres to these industry best practices of SOA.  So, what the JRA is, is a good starting point for the several documents that you can start with as a state, local, or tribal justice practitioner to get the benefit of SOA while significantly reducing the startup costs and investment that you need to make to get there.   

TC:  The JRA is really intended to be used in two more specific circumstances.  At least, that’s the way we thought about it as we worked on it.  One way is for a state and local regional projects where you are trying to do information sharing and as Scott said, it’s really hard to do SOA in general and it’s hard to do best practices on it, in particular, and so the JRA really can be used as an 80 or 85 percent starting point of best practices, as I said earlier, and even if you don’t use everything exactly as it is, it can save an organization a tremendous amount of time and costs and just sweat trying to figure out what is the best way to do certain things.  So, that’s one major use of it.  A second one is as a true reference architecture where the services that are defined in some of the other pieces that lie underneath the services are really used as standards and that certainly can get organizations a long ways down the road on technical interoperability.  A good example of that, that is evolving right now is the work being done on SAR services for fusion centers where there really is a business case for national sharing of data that needs to be done in a standardized way for it to be economic and there having to reference service that people adhere to and really enhance interoperability and get those projects moving faster.  

JD:  Tom, how does the JRA connect with the other work going on within Global, such as NIEM, and what is being done to coordinate these Global efforts?

TC:  Well, that’s a great question, too.  Actually, you can kind of think of JRA as the grand solution that coordinates and links up all these various projects that Global is working on in a coherent way.  For example, NIEM, which is the data content project, is the preferred source for content for JRA services and the JRA talks about that as a piece of the information model but basically, it’s taking NIEM IEPDs or XML Schema with standard content and incorporating it into the service that’s built.  In the same way, the Federated Identity Management project that the Global Security Working Group has done, commonly called GFIPM, gets incorporated as part of the JRA security model in appropriate places and in a similar fashion, the really integrated technical privacy work that the Privacy and Data Quality Working Group has done as it matures will get incorporated into the technical specifications of the JRA as well.  And then finally, really our only link to the Intelligence Working Group right now, but it is a strong and active one, is the work that is being done and what SEARCH is involved in to build JRA services for fusion centers.  I think it’s doing a good job so far being coordinated.  Most of this coordination work for Global has been through its Executive Steering Committee and then the chairs of the various working groups. 

JD:  Tom, as a follow up, what does a JRA road map for 2008 and 2009 look like?

TC:  Well, we are going to shift gears a little bit in the next couple of years.  We’ve done a lot of work in the last year or two on basic specifications and guidelines and have some fairly solid versions of most of those pieces out now or they will be out shortly.  So, what we’re going to really concentrate on in the next couple of years is where the rubber meets the road.  And that really comes in two pieces.  One is identifying and defining actual JRA services for various justice organizations and roles.  And then the second piece is helping people start to implement the JRA reference architecture in the real world.  And to that end, we will probably be providing some additional documentation like an implementation road map and a conformance matrix, but primarily, we will be working on specific services and trying to help people.

JD:  Scott, could you describe for our audience the current term JRA publications.

SC:  Sure, well I can talk to the deliverables we are working on in my committee, the Services Implementation Committee, and then Tom can probably address the ones the Management Policy Committee is working on.  Our current deliverables that we are working on right now merely focus on three questions or issues.  One of the first issues that people run into in implementing service-oriented architecture is trying to determine what services they are going to implement and describe and pursue.  It is a little bit more complex than the question than just asking what information exchanges exist between your organizations.  There are lots of industry best practices about how to identify services properly and draw the appropriate boundaries around them and so forth.  So, in this first deliverable, which we call the Service Identification and Design Guidelines, a group of us have looked at a number of industry best practices and methodologies for doing that and then assembled those into some guidelines that people can use for identifying those services.  The second question is after you have identified services, how do you describe and specify them in a way that people can discover them and be able to use them, that they can go into registries and repositories and be searched and discovered properly, all aimed at making sure that the interfaces and the descriptions of the services are clear and the right information so people know how to use them and that’s going to manifest into what we call the Service Specifications Guidelines, that will address that issue.  The third thing we are working on is what we called Shared Execution Context Guidelines.  It derives from the terms of our Justice Reference Architecture and the OASIS Reference Model called execution context which sets out the environment that the service lives in that makes it reachable and accessible and usable.  This is where we get into the requirements of infrastructure necessary to support SOA and things like transports and support for intermediaries like routing and transforming those kinds of things that are typically associated with SOA infrastructure.  So, all three of these deliverables—the Service Identification and Design Guidelines, the Service Specification Guidelines, and the Shared Execution Context Guidelines—should be finished and out of our committee by the end of the year and available for people to grab off of it.ojp.gov.

TC:  Beyond Scott’s committee, the other active committee in our working group, which is the Management and Policy Committee, has been working on several major deliverables in the near term as well.  The first I will describe is kind of a high-level memorandum of understanding template, which provides a really good model for people to resolve the basic business issues of policy in governments going into a decision to share or expose a service.  And that’s actually already been found useful by at least one jurisdiction even though it’s not even officially out on the site yet.  And then as a kind of a second level of governance and policy, there is a template being working on for service-level agreements as well, and it’s intended to be two documents to be used in parallel with the MOU being the more general document and the SLA—the Service-Level Agreement—being more specific to particular services.  So, I think that’s going to be a good addition to our stable of templates and guidelines when they come out in the very near future.  And then, a third product that’s a little bit further down the road, but not much, is this conformance matrix that I alluded to earlier, and that really is not intended to be some kind of oversight beliefs on how people do the JRA but to be an aid to them, because the JRA is pretty complex and it comes in a lot of moving parts and pieces and there are choices you can make about what combinations to use.  So this will really be a helpful guide to people on how the pieces fit together and what they need and what they don’t

JD:  Scott, say my organization has reviewed the documentation that is currently available regarding the JRA and we decided that this is a good thing for us and we want to move forward.  Where should we start our process?

SC:  Well, the first place that I advise people to start is to request some technical assistance, a provider that is involved in the JRA initiative.  The Bureau of Justice Assistance funds a number of organizations to provide technical assistance—SEARCH is one, Tom’s organization—the National Center for State Courts is another, the IJIS Institute is a nonprofit industry consortium can also provide technical assistance.  We all coordinate under BJA’s leadership.  We are all aware of what JRA is and are actively involved in developing it, so we can provide technical assistance.  I think it is really important to start off with an understanding of why you are adopting service-oriented architecture and why you intend to use the JRA.  It’s not something you should do just because it’s sort of the latest fad or the cool thing to do.  We certainly see that advice if you look at some of the blogs that are out there on service-oriented architecture.  It is really about strategy for information sharing, strategy for cross-organizational partnerships.  We really need to understand what those partnerships are trying to achieve and what your goals are and that’s where technical assistance can play a really strong and important role in helping facilitate and work with your business partners in your jurisdiction in your environment, trying to understand what you are trying to accomplish.  So, depending on the outcome of that, we can recommend specific things that you might want to focus on.  Another piece of advice I give to people is to recognize that service-oriented architecture is really a continuum.  You can get some of the agility benefits that I mentioned a little bit ago.  You can achieve those benefits in certain areas without doing the whole range of possible activities or implementing all of the elements of the JRA.  For instance, if you’re not using NIEM for your information exchanges and going through the process of defining specifications in NIEM for those exchanges, you can get a lot of benefit just from doing that.  Now, probably a lot of SOA experts would not consider defining NIEM IEPDs for your exchanges to be implementing SOA, but the point is that it’s a step on the road that it will provide you some tangible benefit really with perhaps minimal investment.  You don’t necessarily need to buy any infrastructure or make significant new investments in technology to make that happen.  You can also start by taking some initial incremental steps in gaining some maturity and then moving down the road.  But I should also say that we certainly encourage anybody to go out to it.ojp.gov.  There’s a link there for the Global Justice Reference Architecture, and as we completed our documents, we publish them all there and certainly, encourage anyone to grab those and take a look and ask questions.  There is opportunity to do that and provide feedback.  Those are a few of the things I would suggest to get started.

TC:  I certainly would advise people to start by going out to the it.ojp.gov site that Scott mentioned a minute ago.  It has out there all of the officially approved documents that the JRA has produced to date.  What is doesn’t have, of course, is the documents that are in draft, even if they are close to being done, what the JRA does and what’s available already.  Certainly, the partners in the project, Scott mentioned SEARCH and the National Center, and there are many others, are good sources to contact directly for technical assistance.  You can find the names of the committee chair, which is myself, the working group chair, out on the Web site, and I can certainly put you in contact with members of the committees who would be helpful in particular instances.  The IJIS Institute is an active partner for industry in the project, and they certainly can provide support and steer you toward individual contractors for hire, who are experienced in working with the JRA already.  So, there are a variety of sources and resources available, depending on what your needs are.

JD:  I know we talked a little about the fusion center pilot.  What current pilots and projects are currently using JRA as their guide for implementing SOA?

SC:  I can talk about some of the things that I’m aware of and I’m sure Tom is aware of some as well.  The team at SEARCH is working with a couple of states right now—Maine and Hawaii—to use the JRA that’s more or less what I mentioned a few minutes ago, assessing what the business goals are and then finding out which area deliverables and in what order will provide the best boost to those initiatives in achieving those goals.  Both of those states are intending to develop statewide architectures for information sharing based on SOA and are finding that the JRA really accelerates that effort by not having to start from scratch for an understanding of the questions and issues and the architecture decisions are and then having draft architectural deliverables that address those issues and answer those questions as proving valuable.  There are a couple of other projects I would mention that members of our committee are involved in, SEARCH is not directly involved in them, so this is a bit of secondhand information, but the CONNECT project is a multistate effort for cross-state interstate information sharing that is leveraging and actually contributing to the JRA through the lessons that they are learning.  I would also like to mention the JANA effort in Pennsylvania, which has actually been a pioneer in adopting service-oriented architecture for justice information sharing.  And again, they are both leveraging and contributing lessons learned to the JRA as we go along and I’m sure there are others out there, but those are fully active ongoing efforts that I’m aware of.

TC:  A second project is one that’s being done by New York Corrections, and it’s a little bit early days for that one, but they are going to make a pretty serious attempt to use a lot of parts of the JRA as well.

JD:  You have been listening to a podcast on the Global Justice Reference Architecture.  These podcasts are presented by SEARCH, The National Consortium for Justice Information and Statistics.  This series is made possible through a grant from the U.S. Department of Justice, Office of Justice Programs, Bureau of Justice Assistance.  We would like to thank our guests, Dr. Thomas Clarke and Scott Came for their participation in this podcast.