Service-oriented Architecture _{Removing the Obstacles to Integrated Justice Data Exchanges}

Service-Oriented Architecture

It seems a cruel irony that in the age of globalization information technology would do more to constrict agency processes than to facilitate them. Recent years, however, have seen the emergence of a new methodology for the use and development of software that can move organizations away from brittle one-to-one solutions for information exchanges to more flexible one-to-many solutions. This methodology, called Service-Oriented Architecture (SOA) is basically a blueprint or design plan to ensure that technologies remain aligned with agency needs and goals.

Justice agencies rarely develop any kind of comprehensive plan for the development and update of their software. More often than not, they simply build or purchase new software whenever the need for new functionality arises. This lack of planning leads to incredible inefficiencies, as individual agencies often invest a great deal of time and money into the creation and implementation of multiple software packages that essentially serve the same purpose.

Adhering to SOA principles, however, helps agencies to do away with these inefficiencies. Among other things, SOAs define how programs communicate, how data is stored and how users interact. It does this by breaking programs down into chunks called components. Components are small, self-contained programs that have a very narrow scope (i.e. they perform a very limited number of functions). In the process of breaking programs down into components, functionalities of similar programs are consolidated and unnecessary redundancies are eliminated.

These individual components serve as building blocks for applications and can be “snapped” or linked together in any way to create a new program. Building programs from these simple, self-contained components gives them a level of flexibility that traditional software applications simply do not have. If any customization needs to be made to a program built according to SOA principles, changes can be made to individual components without having to rebuild the entire software package. Similarly, if there is ever a problem with the software, it can be isolated and treated in the individual components

For example, imagine that a prosecutor’s office has been utilizing both case management software (CMS) and a calendering tool to track appointments, court appearances and cases for the past five years. While these two programs may seem very different on the surface, they share much of the same functionality, such as scheduling, event tracking, etc. If the prosecutor’s office were using traditional methods, they would need to purchase or develop in-house any new versions of this software. Taking an SOA approach, however, would involve breaking the different functions of the two programs down into components. These components could then be snapped together to form one program that would serves all of the same purposes that the originals did while eliminating redundancies.		Service-oriented Architecture breaks programs down into individual components or "building blocks." These components can then be "snapped" together in any way to create a new program.
		Pages 1 | 2 | 3 | 4