Thinking about acquiring or developing some jail automation services? Looking at buying or building some jail management applications? Fed up with those central mainframe services that seem to be holding your organization hostage? Hoping to squeeze a few PCs into this year's budget so your staff can do some word processing, spreadsheets and run a head-count application? Anticipating the creation of a huge, ambitious RFP soliciting bids for a complete jail management system?
Think again -- and read this before you make your next move.
This case study looks at how one organization, Marion County Department of Corrections (MCDC) in Salem, Oregon, has fared in its ongoing efforts to provide computer support to its staff and management. MCDC has been in the self-supported automation game since 1986, with war-stories and lessons to share. We'll look back over this 10-year history to highlight what to do, what not to do, and how to avoid the pitfalls.
MCDC serves Marion County, population 253,000, and Oregon's capital, Salem, the state's third largest city with a population of 117,000. The county's commerce is a mix of agricultural, light industry and, of course, state government and supporting business infrastructure. MCDC contends with an offender population of approximately 2,800 individuals. Jail population is currently averaging 380 inmates per day (89% males, 11% females); field supervision's current workload 2300 active cases. A separate work center houses another 75 inmates per day. Director Billy Wasson heads the Department, which consists of 182 employees (115 certified officers, 24 administrative staff and 41 support staff). Cmdr. Ted Nelson manages the jail division; Mike Wilkerson manages the field services division.
The Marion County Correctional Facility (MCCF) and Work Center (MCWC) are direct supervision facilities; line staff and management are intensively trained in direct inmate supervision management methods, contributing to a safe, efficient and effectively run jail. Since its opening in 1989, the staff and facility have received the highest commendations from their peers -- NIC has repeatedly proclaimed MCDC to be one of the country's top corrections organizations, and MCCF as one of the top five jails in America. Independent professional and operational audits have reiterated this praise. Each commendation has noted MCDC's automation system as a contributing factor to their success.
The Department commenced its journey into computer self-determination in early 1986. Up to that time, automation services were delivered in a way that is prevalent in many jurisdictions to this day: MCDC used a mainframe-based application, "RAIN" (Regional Automated Information Network), to record data about each offender at booking and during incarceration. RAIN was developed and administered by mainframe computer staff whose primary mission was general county-wide data processing services; this did not include any special expertise in corrections problems, needs or operations.
Old jail at courthouse 
Before the construction of MCCF in
1989, the jail was located on the top floor of the downtown
county courthouse. Bookings occurred in a caged area in the
basement, with primary access to the jail floor via a
decrepit elevator. The place was old-fashioned, over-crowded,
dirty, run-down and dangerous -- clearly in need of
replacement.
Probation at Senator Meanwhile, probation and field
supervision work was headquartered across the street in
offices carved out of the old Senator Hotel. There were very
few computer services available to probation staff -- manual
records were the norm. What data they did have was separate
from that maintained by the jail. Yes, there was a RAIN
terminal or two around, but that didn't mean that data was
shared effectively or efficiently.
RAIN system The computing upshot was this: The users hated
RAIN. It was slow, clumsy, ineffective, inaccurate and
ill-conceived -- when it ran-- most of the time, it was
"down." RAIN was a classic instance of a
corrections data system developed by non-corrections
personnel. Data entry screens were 1960-style relics:
cramped, confusing, hard to operate, nearly impossible to
decipher. Of course, this meant that any data that was
actually entered was also inaccurate and incomplete.
Garbage in, garbage out As a result, whatever management
information was being generated in the form of RAIN reports
was itself largely useless. Jail census information was wrong
more than it was right. It was impossible to develop an
accurate overall picture of who was in jail and why. Staff
relied on manual methods to account for daily operations,
inputting data only because it was required by policy, not
because it helped them with their jobs. Management made
decisions "with blinders on," and developed its own
mythology about the state of affairs in their correctional
system.
Decision: Matters in our own
handsClearly, something had to change. Fortunately, one individual had vision and was willing to take a chance. Jean Hill had been with the Department for a couple of years, tasked to do information analysis, among other things -- she discovered that there really was no data to analyze. What little information she had to work with was gleaned by hand-sorting paper files to compile statistical analyses.
1986: A computer in the corner Hill managed to
get approval to purchase some computer gear and basic
software; however, that first procurement budget only went so
far, and at first the bare-bones minicomputer, a Digital
Equipment Corp. MicroVAX II*, sat powered off in a corner, with no
software to run, and no one to develop it. Hill contacted her
computer vendor for some help, and was directed to a
fledgling business startup. Could they help install some
relational database software?
In walk a couple of computer guys Hill's newly found
computer consultants, LockWorks LLC, had
the right mix of technical and business skills to get that
minicomputer to run a relational database package -- but then
what? Its a long way from basic data collection to a fully
formed corrections application suite, and the Department was
really starting from scratch.
An idea, a vision Jean Hill had a firm vision of what she
wanted to build: a offender database which was "owned
and operated" by the Department, independent from
outside control and influence. She knew that this was the
best, perhaps only, way to develop the information that she
and management needed: define their own data elements,
specify the processing, generate the reports that made sense
to them, in their terms. In this regard, she had, at that
point, the tentative commitment of MCDC's Director, Billy
Wasson.
Evans and Ricker were her missing ingredient -- they had the applications and database development skills to actually realize this vision.
Try something simple E&R knew something else: it was
important to "start small," to build incrementally
rather than all at once. Their experience told them that
trying to design a complete and comprehensive corrections
system would be foolish and doomed to fail. Instead, they
would pick the simple parts for development first, and then
build onto this foundation in small, evolutionary steps. Part
of this advice was just common sense, but part of it was
selfishly motivated -- they had to learn the corrections
business from scratch.
The prototype development effort had several purposes: it was a "proof of concept" exercise, a test to qualify the consultants as viable partners for the Department, and a means to get something useful into operation rather quickly.
1987: A "client" database Under Hill's
guidance, the basic data elements for an offender database
were put together quickly. Initial efforts were focused on
developing offender risk assessment instruments, with simple
data entry, automatic scoring and classification, historical
records tracking and basic reporting. And the experiment was
more successful than originally hoped: within two weeks, data
entry was being done by a department volunteer, an elderly
lady who had never used a computer terminal before.
Go-ahead was granted for additional increments: other probation programs were developed one-at-a-time, including supervision, community service and restitution records, including fee tracking and conditions of supervision. Basic offender record keeping, including demographics, aliases and identifiers, addresses and employers, was enhanced and refined, quickly reaching a level of stability, accuracy and completeness never seen in the mainframe system. From the very beginning, MCDC staff members were deeply involved in the design and implementation of each new component.
The design rule One basic premise was enforced from the outset:
Build the system to support operational needs, not
management reporting. Hill insisted that if the data
supported operations requirements, and if the users could
actually use the system effectively, then the data would be
reliable. And if the data was good, then management reports
would follow naturally as needed, and would represent
reality, not fiction. She assured everyone that deferring
management reporting was the right thing to do -- good,
reliable data had to accumulate first.
What had started as an experiment in mid-1986 was, just a few months later in 1987, a self-supported, internally owned and operated, reliable and accurate data system. Jean Hill's vision could indeed be made a practical reality, and from there the Department never looked back.
Turning point: New facility,
full supportBilly Wasson was encouraged, if not fully convinced. Now it was his turn to play the visionary role. He knew that major changes were in store for his Department, and that a more ambitious information system was going to be key to the new ways of doing things.
1988: Planning for a combined operation As members of the
probation unit were gaining experience with the new database
and applications, Wasson was helping to plan the construction
of a whole new corrections campus, including a new jail, work
center, administrative offices and court annex. Convinced
that the internal automation efforts were on the right track,
he was negotiating to upscale the effort to fully support the
new facility.
A politically unpopular move? You bet -- this direction seemed risky to some county commissioners, and the county's data center personnel were getting peeved. To them, department-level computing appeared to be out of (their) control, non-standard, and downright heretical. Data center management was sure that they had identified a great new mainframe application to run the jail, and were unimpressed by the probation database developments.
"Hey, they're the same customers..." What Wasson
realized, and conveyed convincingly to the developers, was
that the Department needed a single, unified offender
database for both jail and field supervision operations, not
two separate, distinct sets of data and applications.
"When they leave our jail, they enter our programs, and
many end up back in our jail," he argued. "We need
to be able to handle the same set of data for the offender as
he moves cyclically through our system -- doesn't that mean
we need a single database?"
What now seems obvious in retrospect seemed at that time rather revolutionary, even a bit brilliant. It did make the internal system look like the "only game in town," and funds were allocated in the new facility's budget for an upgraded computer system, plus more database and applications development.
1989: Opening the new jail and work center Throughout 1988,
E&R worked with MCDC staff to prototype and refine data
and applications modules for jail operation. As before, the
goals remained constant: "Keep it simple. Build only
what you know for sure. Build for evolution and change. We'll
figure it out as we get into it. Keep the focus on
operations."
Basic jail operations capabilities were added, including: booking and release processing; housing assignments and movements; case, charge and sentencing data; time-served records; sentence duration and release date calculations; and much more.
Staff involvement was crucial during this time, for two reasons: First, they had the expertise, and had to convey it to the development consultants. Second, it was decided early that the staff members involved in development would also be responsible for delivering applications training to the rest of the new user community. Having the consultants do the training was never a viable option -- they're "too techie," they don't know corrections procedures and jargon, they'll never be accepted as professional peers. Given the pressure to open a new jail facility using new, untried software with novice users, this training decision proved to be the only feasible one. Fortunately, it worked well, too.
The first system upgrade The prototype offender database
supported a handful of probation application users on the
original MicroVAX minicomputer. The new jail application
would be used by nearly ten times more people, on a 24´7
basis, in addition to supporting all original and new
applications. Growth and evolution was inevitable, and system
up-time was now critical. Therefore, an upgraded system (same
vendor, same type, just bigger and faster: a VAX 6210) was
purchased and installed in time for the new jail facility's
opening, and the database and applications were moved onto
this system.
The original minicomputer was reconfigured to handle network traffic, including access to Oregon State Department of Corrections (DOC) AS/400-based data and applications, and remote terminal access to the Oregon Law Enforcement Data System (LEDS).
Emphasis was also placed on conforming to emerging industry standards for open systems and open data access, primarily via attention to network protocols and SQL-based tools -- fortunately, the systems and database vendor made these requirements easy to reach.
The new jail and work center facility was successfully opened in April, 1989 -- the data system came online without a hitch, and has been in operation ever since. Things have not, however, been standing still.
From 1990 to present After stabilizing basic operational
requirements and features during the first year of production
use, additional capabilities were developed, always on an
incremental, evolutionary basis. In addition to ongoing
refinement of existing operational features, new capabilities
included: detainer records; disciplinary incident tracking,
reporting and outcomes; inmate information kiosks; commissary
vending automation, with mag-stripe debit cards; employee
meals records; inmate trust accounting; visitor logging and
control; plus many additional refinements and capabilities
for field supervision and probation.
Finally, management reports During this same
period, effort was devoted to developing management reports
which could exploit the rich depth of data obtained through
jail and probation operations. A large number of
"canned" production reports were implemented by the
developers -- however, a significant number of ad hoc
reports were developed by administrative and management
users, using client-server (PC-based) report generation tools
and techniques. This strategy eliminated the
"techie-developer" middleman from the report
implementation cycle, and puts the user, who has the vested
interest in the report, directly in control of the data and
the way it is processed and presented on paper. Finally, the
means to control report content, layout and production was
placed in the hands of the actual information user, where it
remains to this day.
Although it seemed to take a long time to mature, this strategy of "operations first, management reports later" has had a tangible payoff: the quality, accuracy and timeliness of the information now available has had a significant, constructive impact on management and policy decisions. The Department uses concrete data, not conjecture and opinion, to effectively argue its positions, support its outcomes, and justify its budgets and allocations to the judicial, legislative and law enforcement policy-makers to which it must answer.
The client-server paradigm shift The advent of
management reporting capabilities permitted a significant
paradigm shift to occur in how information was to be managed
within the Department. This shift was based on two
realizations: 1) That MCDC now owned and controlled
its own data resources; and 2) That management reports would
always be ad hoc, changing and evolving. This led to
the conclusion that a static set of production reports,
tended by developers, would never be sufficient for
management's needs.
Instead, administrative personnel needed to take charge of their own reporting needs, and suitable client-server applications were becoming available just in time. Earlier decisions to adhere to open systems and industry-standard data access methods made the selection of easy-to-use report generator applications straightforward and relatively trouble-free. Most importantly, the content and format of management reports was in the hands of MCDC's administrators and managers, bypassing dependence on development staff for time-critical reporting. Conversely, that staff could now focus on database accessibility to support client-server reporting.
Support staff In the earliest, experimental days, computer
system administration could be a casual, part-time effort.
Once the system became a critical, round-the-clock part of
jail facility operations, the stakes were raised and system
support became a major consideration. The Department now
required its own full-time system administrator, and a user
support specialist was needed to handle user questions and
problems.
Currently, these two support staff members handle all routine system operations tasks, including data backups, user authorizations, system security, production report generation, and user support. Their efforts are backstopped by external technical resources, including E&R and the computer systems vendor, to handle any and all extenuating problems and circumstances. E&R provided a suite of automated system management tools, known as the System Manager's Automated Resource Toolkit (SMART), which included a Database Manager utility (DBM), automated backup, user authorization, application and security management tools.
User input It was apparent during the early stages that
there was another factor which was driving the success of the
system; it came to be known as user ownership. As
staff were involved with the development process, they
acquired a sense of "holding a stake" in the
evolving product; as if by proxy, other users began to share
that sense of ownership too. The stakes included everything
from screen layouts to field labels, from workflow process to
the actual data values entered. And, not surprisingly, the
users themselves started generating the best ideas for new
features and directions to extend the applications.
This ownership extended from the applications to the database itself, manifesting itself both in pride for the product and concern for the quality of information contained in the database. It was contagious -- peer pressure started to ensure a high degree of data consistency and integrity. User cross-training and self-support became the rule. And the users finally named the system: it became "our MIS." This did not mean "information for the managers" -- they've always meant "the system that helps us manage our inmates and facilities."
Resistance, transition and adaptation During the initial
months of MIS operation, management adopted the notion that
all COs and staff would share all data entry responsibilities
coequally. Considerable time and effort was expended to
provide effective levels of training to everyone on nearly
all aspects of the MIS applications. While this seemed like a
good idea at the time, it encountered sufficient obstacles to
warrant some mid-course corrections.
At first, resistance by some COs was rooted in old-fashioned computer-phobia: "I can't type," "I don't have time to do that," and "It'll threaten my job," were among the excuses and concerns voiced by a few during early training and use. After a suitable break-in and transition period, some of these concerns were found to be valid.
The assumption that all COs could spend equal amounts of time doing data entry was causing problems. For some posts, it detracted from other important duties, most notably security-related issues. At others, data quality began to suffer, mostly because officers who rotated through posts and shifts never developed sufficient data entry skills to handle a heavy data workload. It looked like there really was a need for some special focus on data entry and maintenance skills, and that not all COs were suited for that task.
Instead of letting this become an organizational crisis, however, management turned it into a new career path opportunity. What evolved was a group of correctional data support specialists who are trained and tasked with maintaining data entry, quality and reliability in support of all operations. Even so, note that all COs, administrators and staff continue to have full access to all MIS applications and data to support their duties. The shared sense of data and system ownership is undiminished; tasks and priorities have adapted to the realities of the facility, rather than forcing rigid adherence to that initial notion.
The e-mail monster One measure of the success of the
system, and its acceptance by the users, came in an
unexpected form. Since electronic mail (e-mail) was available
to all users, Department management decided to use it as an
inducement to get reluctant staff onto the system: they
adopted e-mail as the only means of disseminating
internal information, such as staff postings, briefing
notices, memoranda and other internal messages. Very quickly,
those technology-reluctant staff members found that MIS was
the only way that they could stay in touch with necessary
daily activities and information.
Once indoctrinated, even the reticent users found that e-mail was somewhat addictive. This facility quickly became the most used, and useful, application on the system. Elaborate personal message filing systems were born, and mail traffic grew nearly geometrically, at times causing support staff some grief as they tried to recover usable disk space. Most notably, COs who worked on different shifts found a way to keep each other informed of potentially difficult inmates and dangerous situations -- a whole new level of ad hoc communications and coordination was developed to everyone's advantage.
MIS goes to market: Lock&Track is born In 1991, after
nearly six years of continued development of MCDC's
applications and database, the principals at E&R decided
to redirect their own business to completely focus on the
needs of corrections automation. With the county's blessing
and approval, they commenced efforts to take the capabilities
of MCDC's MIS to a wider market, consisting of a complete
re-engineering of the database and all applications. This
enabled them to offer a foundation product, tailored for
site-specific requirements, to any jail, prison or
corrections organization in the country, including
boot-camps, juvenile facilities, managed either publicly or
privately. Evans & Ricker, Inc. introduced the Lock&TrackSM Corrections Information System to
the marketplace in early 1994.
1993: Second system upgrade After the first
four years of operations, with no significant system downtime
experienced, it was time to consider retiring the VAX 6210 in
favor of a newer, faster, smaller, higher-capacity model. Not
surprisingly, this new-generation system would also be much
less expensive to operate and maintain.
It seemed prudent to also consider additional design safeguards against system downtime -- since a dual-redundant system configuration (two computers in a "cluster") was only marginally more expensive than a single system, the Department upgraded to twin MicroVAX 4100 systems.
These systems now supported more than 100 departmental and affiliated users; the database contained records for more than 30,000 offenders; and the entire campus was networked, including about 116 computer terminals and 18 PC workstations. Interagency network connections continued to support access to LEDS for warrants and searches, and to State Corrections, where MCDC probation officers gained access to DOC's ISIS probation/parole applications, including offender chronos and contact tracking.
Two years later in 1995, the MCDC community has grown to about 280 users; about 80 active users are online during a typical daytime shift. The database has grown to 655 megabytes, representing about 36,000 offenders, and grows by about 8% annually. There is heavier reliance on windows-based PC workstations to support both MIS applications access and standard office automation (word processing, spreadsheets and reporting). Ultimately, we anticipate that all of the 100 or so remaining traditional data terminals will be replaced by PC workstations, although there will be a substantial per-PC support cost differential which offsets the obvious benefits.
Although the MIS application is considered mature and stable, user ownership is still strongly felt, and the best ideas for new features are still championed by users who face the problems and needs. The emphasis remains focused on reliable operational data which supports accurate management reporting.
Open data access and interconnection to other agencies remains an area active support and refinement. We are constantly challenged to find new and better ways to share our data resources with other law enforcement agencies and partners, and to enhance the quality and content of the information which is shared.
As an example, during the past year MCDC became a member of a regional consortium which funded acquisition of several photo-image capture and display workstations. The Department's development staff undertook to connect several of these workstations to their LAN, providing a means of coordinating photo-image physicals and demographics data with that same data in the MIS database. In addition to equipment installation and coordination of operational efforts between agencies, this also required the addition of industry-standard TCP/IP network protocols, LAN software upgrades and the development of new inter-application link software.
The Department continues to support and fund aggressive plans for improving and maintaining its automation -- these include:
Network rebuild Since the original network wiring was installed
in 1989, significant technology advances have occurred which
can enhance performance, capacity and capabilities. A plan
has already been approved to upgrade LAN hardware and cabling
which will resolve some existing problems and reduce network
support overhead.
MIS to Lock&Track Now that Lock&Track is
itself a commercially viable and mature product, MCDC plans
to fund additional evolution and conversion of the original
MIS applications and data structures to conform to the latest
Lock&Track technology. In particular, this will
allow the Department to take advantage of features in the
commercial product which were not available when MIS was
developed.
Photo image integration Additional work is anticipated to fully
integrate photo and document imaging into MIS. Ultimately,
inmate mug-shots and electronic documents will be available
for display, along with data records, on each user's PC
workstation.
Summary: Lessons learnedThroughout all of this effort, MCDC staff, management and its business partners have learned several important lessons, which we summarize here:
Own it yourself During the '80s and '90s, commercial businesses
have learned to exploit the computer systems downsizing
trend, moving from mainframe-dependent applications and data
to departmental computing and PC-LANs. MCDC's experience
paralleled that trend, demonstrating that the Department
itself could indeed own, operate and succeed with its own
data system.
It's the data that's important MCDC learned that,
in terms of its automation systems investment, it is the data
which is its most important asset, not the hardware, network,
software or applications. Though perhaps costly to procure,
hardware and software are transient and not
particularly valuable to the organization in the
long-run; it's the database (information) which persists and
has value over a considerable timespan.
Staff and management come to depend heavily on that data for critical operations and policy decisions; the data becomes a strong foundation for successfully carrying out the mission of the Department. The validity and value of this information persists and accrues for many years. Conversely, the hardware and software components are only tools, a means to an ends, serving only to support access to the data asset.
The upgrade cycle never ends MCDC has also
learned that success has a cost, and no computer system
configuration lasts forever. As a data system becomes more
useful and more successful, ever-increasing demands are
placed on it -- data volumes grow, more users start accessing
it, applications are enhanced and become more complex, and
network demands consume more system resources. Don't be
alarmed: this is good, and is to be expected in a
normally healthy, successful system development plan.
One of the biggest mistakes made by many government agencies is attempting to justify and procure computer systems acquisitions based on long-term (five- to seven-year) needs projections. This often leads to acquisitions in which the system is over-configured, and therefore far too costly, compared to the actual requirements, which in turn is justified by the notion that "we only get one budget shot, and it has to last us until... "
In the face of current technological development rates and business demands, this is simply unreasonable. In this age of downsized systems (from PCs to departmental systems), any computer which is "earning its way" and successfully used will have been outgrown and due for replacement within three years of installation.
A more realistic strategy is to purchase only what is necessary to meet current needs, basing a successful implementation on equipment which will be all used up within a three-year horizon. Within those three years, the technology will have advanced so significantly, and costs will have fallen (again) so dramatically, that it is actually cost-effective to completely replace existing hardware with next-generation systems. It's critical to preserve the investment in the data assets across such upgrades.
MCDC currently evaluates its computing infrastructure on a regular basis with the expectation of significant system upgrades every three to four years.
Evolution, not revolution It is important to start small, not to
try to accomplish everything at once, building incrementally.
We found that by planning automation as a series of step-wise
mini-projects, each virtually guaranteed by their modest
definitions to succeed, we were able to build both unshakable
confidence in and unstoppable momentum towards the eventual
goals.
An automation project has major social as well as operational consequences. The evolutionary approach permits the organization to adapt to the profound changes that automation brings; a revolutionary, "big-bang" approach often encounters fatal resistance and insurmountable obstacles.
No free lunch MCDC's benefits have not come for free. The
Department has spent approximately $1.6M on computer
hardware, software, development, support staff salaries and
consultant services over the 91/2 years
described herein -- this is a reasonable figure, and probably
is considerably less than it would have expended on other,
more traditional methods of automation.
However, there is more to automation than dollars -- MCDC has invested a substantial amount of staff and management time in developing applications software and operational procedures which exploit its data system, training and supporting users, and maintaining its automation infrastructure.
Operations first We are convinced that the original
decision to focus on operational needs first, and management
reporting second, was absolutely correct. Good management
reports simply cannot emerge unless there is a sound, high
quality data foundation present.
Rock-solid management commitment Although
automation enthusiasm and support can come from any level, a
project is doomed to fail without committed support from top
management. Throughout MCDC's journey, the guidance and
support of Mr. Wasson and his management team has been strong
and consistent, focused on quality products, practical
benefits and congruence with the Department's goals and
mission.
User ownership The "pride of ownership" which
developed in the MIS user community was initially unexpected,
but certainly became a critical aspect for the overall
project success. We have learned to seek and encourage this
ownership attitude as we continue the system's evolution.
Training, always more training The Department
knows that it must continually invest in quality training for
its employees to make best use of its data resource. MIS and
computer training are never done, which makes sense in an
ever-changing, improving environment.
MCDC provides a rich array of both formal and on-the-job training opportunities, many of which are lead by users themselves. Furthermore, specific automation skills are now written into job descriptions and responsibilities at all levels, from management to clerical, and employees are held accountable for adequate performance.
Public/private teamwork For nearly a decade, the Department and
its consultants have enjoyed a synergy which has lead to the
development of a mission-critical capability for MCDC and a
marketable product for E&R. Each partner brought
complementary expertise and experience to the project, and
each has profited by their participation.
To build?... or buy? The Marion County Department of
Corrections' computer story is rich with instructive lessons,
and is a good model to emulate. The social and organizational
changes brought about by an effective automation plan and
program are difficult to "just transplant" from one
corrections department to the next. However, now the
pioneering is done: the foundation and framework for a
mission-critical corrections and jail management system have
been put in place, and other departments should not need to
"reinvent the wheel."
In 1986, the Department had little choice: in order to get what they needed, they were forced to build their own. Today, after nearly ten years, there is a small but healthy marketplace which offers complete product solutions to corrections professionals, and MCDC played a vital, defining role in the development of one of these products. Lock&Track is robust, mature, and easily obtainable, and MCDC's automation experience and expertise can be readily shared with other correctional organizations nationwide.
* VAX, MicroVAX, VMS, OpenVMS, Alpha, AlphaServer and AXP are trademarks of Digital Equipment Corp. Windows is a trademark of Microsoft Corp. AS/400 is a trademark of International Business Machines.