Posted by Blogger@ dsiiti.com on Fri, Mar 19, 2010 @ 02:00 PM
After a bit of a hiatus, I am finally starting back up with my blog. On tap for the next couple posts are certainly a few things about integration concerns and NIEM specification. But today, I want to take a look at a general topic that hits all of us in this highly technical world...simplicity!
A few months ago, I received the Roku (www.roku.com) device. If you haven’t heard of it, it is a device that connects to your TV and uses an internet connection to stream movies from Netflix, Amazon, or live out of market MLB games. I’m a fan of the Cleveland Indians, and since I live in central PA, I don't get to see them on TV very often.
This little device is pretty small and un-assuming (and being a tech guy I know what kind of work and technology needs to go in this thing) yet it’s quite impressive. However, what was more impressive to me was how it just works. Within 10 minutes of getting the thing out of the box, my son was streaming Thomas the Tank Engine and I was enjoying some piece and quiet!
I would love to get to the point where we can drop off an OMS system (or an OCS system) and have it up and running in 10 minutes. Unfortunately, this functionality is a long way off! Due to the fact that every correctional facility (that I've seen) operates its business processes and describes operations differently from one another, the implementation process often becomes long and complex. What is standing in our way, in this case, is the lack of standardization. The NIEM spec is looking to address some of this standardization, at least as far as system integration and data sharing are concerned however, the business processes is another matter. The NIEM spec also suffers from the lack of standardization and consistency within the corrections world because it makes the specification have to handle everything that anyone may try to use it for, greatly increasing the complexity factor.
Most of the time, facilities may not even be aware that they are doing things slightly differently than someone else. That’s why it is always interesting to be a fly on the wall at our annual User Group conference, where we get to hear individuals from different facilities talk to each other and compare notes. But until those notes are a shared on only one piece of paper, I’m afraid that the simplicity factor of the Roku isn’t coming to the deployment process just yet. But we can all dream, right?
Posted by Mark Johnson on Tue, Aug 18, 2009 @ 08:37 AM
Last weekend I was on my Saturday morning run when I ran by the McLanahan Corporation headquarters (http://www.mclanahan.com/). They are a Blair County, PA based corporation that produces, among other things, large machinery used in agriculture and the mining industry. Outside of one of their buildings they had a big machine that presumably does something equally big, I have no idea what, but it was cool. It had large metal doors on the side, a large motor, fans and wires and pipes, etc. It made me a little jealous.
Working in the software industry, we don't produce big large machinery that you can touch and feel. Sure, we could print out the hundreds of thousands of lines of code we have written, but that really doesn't do anyone any good. We just don't have that tactile satisfaction that results from a physical product.
But that's why, as a software engineer, I particularly look forward to our Tech Hall at User Group. Our Tech Hall is where we get the once a year chance to showcase our products and directly show them off to our customers.
The nature of software lends itself to being caught up in vaporware and hype and customers and potential customers often think we are trying to sell them something that doesn't exist. The Tech Hall allows us to show off what we can do and allow our customers to interact directly with our products and give us feedback.
So, I really hope to see you in the Tech Hall at the 2009 DSI/ITI User Group. Please come say Hi!
Posted by Mark Johnson on Fri, Jun 19, 2009 @ 08:26 AM
Sometimes the latest and greatest may not be the greatest for you. As DSI/ITI's software architect, I am faced with technology driven decisions on a daily basis. Often I receive emails from our other software engineers suggesting a new product, or new technology that we should use in our application. Sometimes these suggestions even come in the form of sales pitches from other vendors that want us to use their technology instead of their competitor's technology. Sometimes it makes sense to use the latest and greatest product or technique in our applications, but many times I have to stand my ground and explain why it is a better idea to use a tried and proven or more universally accepted method or technology instead. And I will tell you, that can be hard!
As a guy who loves technology, I love the opportunity to play with the latest and greatest stuff in the software world. There are technologies to improve your quality, improve your speed, improve your time to market, reduce development time, and on and on. Many times, there are things that have no direct bearing on the customers, such as the particular way we write the code. I think there is something in the genes of a software engineer that wants us to use these new cool things.
But, here is the kicker. We are software engineers, not people who are hired to play with new gadgets or write something just because it is cool. We are here to build software to serve our customers. Sometimes these two things coincide and sometimes they do not. It is far too easy to lose sight of what we are supposed to do.
So, let me ask these questions of my readers in the corrections realm:
What, as software engineers, are we not understanding?
Is there some aspect to our products that, while it may meet some technical goal, falls short of what you expect?
On the flip-side, are there any areas where we've been too conservative?
Is there anywhere we could have used a new product, but didn't and your experience as a customer has suffered?
I'd love to hear your comments on the subject, so use the "Click here to read/write comments" button and leave your thoughts.
Posted by Mark Johnson on Thu, Jun 18, 2009 @ 09:47 AM
I'm a runner. Not a very fast one, mind you, but I like to run. Prodded by a few friends, I got the idea late in 2008 to train to run a half marathon. I chose the Pittsburgh Marathon, held on May 3, as my target race. For anyone unfamiliar with the event, a half marathon is a distance of 13.1 miles. Since most mere mortals, like myself and the ten thousand other runners that day, can't just get up one day and run 13.1 miles, it takes a lot of training.
I began my training right around New Years 2009. That gave me about 4 months of training time. In that time I learned a lot about the sport of running that I didn't even know existed. I had really just thought that it was as simple as getting out the door and start moving your feet. While that may work for a shorter race, such as a 5k (3.1 miles), it's a whole different game for longer distances. You need to have a long-term plan and a specific, but realistic goal.
You are reading this blog because you are interested in corrections, or software, or maybe even corrections software, so at this point, I am sure you are wondering why I am discussing my training plan. What does the fact that I willingly put myself through such torture have to do with software development?
Developing software isn't easy. It takes a long time to do what seems like relatively small items. Small interruptions during the training, er, I mean development cycle can have major impacts on the final overall product. Making the wrong decisions early on can impact things greatly down the road. The final event, whether it is race day, or the release of a new product isn't the hard part; it is the dedication and sacrifice leading up to the event that is hard. I enjoyed my 13.1 miles through the city of Pittsburgh, just as I enjoy rolling out a new product to a customer and showing it off.
Any training or development cycle can get off track and that is frustrating to both developers and customers. That is why, for the sake of the product as a whole, we often have to say no to certain features or delay what seems like a small task.
I tried to change my training after the Pittsburgh race to increase my intensity. My goal was to run a 15k (9.3 mile) race here in Altoona on July 4 at a faster pace. The result of this training change? I got injured. I am still planning on running the race, but at a slower pace than I ran the half marathon. My injury was an unexpected setback that is throwing off my entire goal.
As an engineer, I try to learn something from the failure of my last race training. While I will still be making it to the starting and (hopefully) the finish line, I won't be in top form due to my mistake of trying to do too much too fast.
At this point, I do not know if I will be satisfied with my race performance. I know I am not satisfied if a product release date slips, or the product wasn't as good as we intended.
The good thing is that it is this dissatisfaction with our own shortcomings that leads to better results the next time down the road!
Posted by Mark Johnson on Wed, May 13, 2009 @ 12:45 PM
In today's climate, integration of the Offender Management System to external products is becoming a central theme to all OMS installations. Unfortunately every integration project has its own quirks and problems to overcome, and rarely are integrations reusable across city, county, or state lines. But, due to our experience in the industry, I can provide some points that we've utilized to make integration projects go as smoothly as possible.
-
Don't lose focus on what you are trying to accomplish. Do not immediately jump in and figure out how to integrate products without first having a clear, written goal in mind. Make it specific and concrete. A general goal of ‘I want to integrate OMS with my current
Medical Provider is too broad. A more specific statement of ‘I want inmate demographics and housing to move from the OMS to the medical provider, and I want lab results to come from the medical provider into the status screen of OMS' will go a long way in reducing costs and meeting implementation guidelines.
-
Don't get hung up on technology or transport too early. Whether integration uses XML, sockets, Web Services, FTP, or any other acronym doesn't address the basic need of the integration: 'Does it do what I want it to do?' While I realize that often times IT departments restrict the types of communication between systems, most vendors - DSI/ITI included - have written our products to be flexible, and have the experience necessary to get the job done.
-
Be realistic. In the ideal world, you will need to enter a piece of data only once and it will automatically flow from one system to the next, without fail. There are many reasons why this is not possible. Take an OMS to Medical System integration for example. The OMS system uses a booking record as the main item of record. Each time an inmate is booked into the system, a new entry is created. Charges, cases, housing, etc are tied to a booking record. Individual Bookings are tied together via a permanent number. But a medical system works differently. The main item of record in a medical system is an individual. No matter how many times an inmate is re-booked into the system, there is to be only a single record in medical. Generally, we can make this work because the permanent number field in the booking record can be used as the unique identifier in the medical system. This falls apart when an inmate is incorrectly identified at booking, however, as we've now tied this booking record to the incorrect individual in the medical system. This leads me to the last point for today...
-
Garbage In, Garbage Out! Integration projects do not fix business processes, they enhance them. Bad data entered at one point in a system due to an incorrect process can now have much more far reaching effects as incorrect data is now transferred from one system to the next automatically. It is even more critical when systems are integrated to have a defined business process. For the OMS, this is especially critical upon the initial booking steps; an extra few seconds spent properly identifying the individual will save hours of time fixing issues later across multiple systems.
Since I know integration is a huge topic with a lot of interest, this won't be my last entry on the subject. I welcome your comments!
Posted by Mark Johnson on Tue, May 05, 2009 @ 12:31 PM
Hello, I'd like to welcome you to my first blog post!
I'm starting this blog to help share my knowledge about technology and software and how it can be specifically applied within a corrections setting.
My name is Mark Johnson, I am the Software Architect at Digital Solutions and Inmate Telephone, Inc. I am responsible for the overall software design, architecture, and deployment strategies utilized by DSI for our flagship jail management and inmate telephone systems, as well as our newer banking products.
I have 10 years of experience developing enterprise software, and currently hold a Bachelor of Science and a Master's degree in Computer Science from Millersville University of PA and Penn State University, respectively.
In my upcoming blog posts, I intend to touch on integration concerns, NIEM (the National Information Exchange Model), software deployment strategies, software lifecycles, and maybe even some of the behind the scenes aspects of software development.
I am encouraging an open dialog between myself and my readers, so if you have a question, or an idea for a topic, please let me know. I'll do my best to get it answered.