I used the word compelling in the headline to this interview. I believe this is a story all Alpha Five users should read. Here's why; this is the largest network I've heard of running Alpha Five as the main database engine. It is running in a very data-intensive environment, storing and retrieving very sensitive information. It does this across many different departments, providing the vital information that keeps this modern office running. Tom Henkel's approach to the development of this gigantic application is very interesting, and, it is all being run on the back of Alpha Five version 1, Alpha Software's first Windows database, designed for Window 3.1. I see this as a grass roots endeavor. Tom, Chris, and their co-workers are creating a solution that works, from the ground up, rather than having an expensive top-down boardroom-determined software package handed to them.
Next month we will have an interview with Chris Barbariantz, the hardware guru of this endeavor. Join us as Chris tells us about the hardware side of this application, and shares a few tips along the way.
I am inviting all readers who are interested, in either the application development or the hardware/configuration aspects of this network, to send questions you'd like to ask Tom or Chris to me at: jc@cknet.net. If we receive enough responses, we'll have a third question-and-answer session with Tom and Chris in the July issue of the newsletter.
Q: Tom, you work for an agency of state government, do you not?
Sort of. Our agency, The Bergen County Board of Social Services (New Jersey), is a part of the county government. Under our County's Administrative Code, our Board is established as an autonomous agency responsible for administration of the major Federal and/or State need-based programs for low-income families and individuals (Welfare, Food Stamps, and Medicaid). What is interesting is that welfare is only a very small part of what we do. We also handle many other programs that might be handled by the private sector or other organizations in other counties or states. Some of these are Home care case management, Adult protective services, emergency assistance, Homeless assistance, Child Support enforcement management, Work compliance, etc. As you can see, we have a lot going on.
When Chris and I were hired, the director of our agency asked what we would be doing in two years, after we finished setting things up. I'm still waiting for even the slightest lull in the workload. Our ability to rapidly deploy hardware and software solutions to our users has spoiled them. Chris has managed to make hardware deployment a very simple process. He can explain that himself. I don't want to take away his thunder. Alpha Software has made it almost magical for us to create an application and get it out to the users. One of the agency's supervisors is convinced that we have a "magic wand" because every time she requests something new or a change to a system, IT HAPPENS.
Q: How long have you worked for Bergen County Social Services and what is your background?
I've been with the agency since October of 1993. I actually have a degree in Computer Science. After college, I went to work as a technical support analyst with a major computer vendor. I was responsible for pre- and post-sales implementation support for mainframe systems. I worked for them for 16 years until it got just too expensive to keep me on staff. In the late eighties and early nineties, sales slumped dramatically, and I was "downsized". That was pretty traumatic. The upside was that I purchased a trial copy of Alpha 3 and was hooked.
Q: Are you the software IT guy in general, or are you specifically dedicated to Alpha Five?
For the most part, I am primarily responsible for application development with Alpha Five. Chris and I overlap when necessary, but we try to keep it so that he handles hardware, network, and operating system issues and I handle application software issues. Don't read this wrong, I couldn't do it all myself. A while back, we realized that I couldn't handle all of the development requests. We decided to look for people internally who knew their jobs and were interested in computers. I have two excellent people, George Kenny and Hubert Haider, working with me who have done some AMAZING things with Alpha Five. They both came out of the work units and had some computer training. Our theory was that the software was simple enough to learn, but knowing the requirements of the workers was paramount. We are, however, actively looking for someone else to join our team (any takers??).
Q: Do you, George, and Hubert divide up development responsibilities and duties, or are you all 'generalists'?
We all share responsibilities, but we do have our specialties. George is a wizard at interfaces to state systems. He came from a welfare/food stamps unit, so he knows the requirements of those people. He built a checkwrite procedure in Xbasic that would knock your socks off. He has a very strong knowledge of how to make sure that record filtering is correct. Hubert came from one of our Medicaid units, and wrote our Medicaid eligibility application. We are the only county in the state to have written an eligibility system. Most of the other counties still do the work by hand. Two counties have asked for our system, and are trying to implement it. We developed it for our use, so there is quite a bit of cosmetic modification to be done. The state is just now trying to put some sort of program together. We offered our system to them, but they didn't want to learn another application language. Medicaid is such an intense program that Hubert is pretty much dedicated to it.
Along with the responsibilities of developing and maintaining our internal application systems, we (Chris, George, Hubert, and I) are first call for anything that happens with any computer, printer, state network hiccups, etc. Like most MIS departments, we don't have the luxury of just doing development and maintenance. Chris and I sit on numerous committees at the state level, so we are dispatched to meetings quite often. George has taken over the roll that was once assigned to an entire department. He needs to attend meetings 2-3 times per month. We are involved with anything that might affect computer operations.
Q: It is my understanding that you have approximately 300 computer nodes on your network Although sheer numbers do not necessarily translate into file size, I'd bet that you have quite a large data repository. This is probably a difficult question to answer, but at any given time, can you estimate the number of records in your system?
I couldn't even begin to estimate, but the number is very, very large. Our Client table has over 90,000 records. There is a household table connected to the client, as well as a case table. The case table is over 110,000 records. Our largest table is the fileroom transaction log table. We maintain a log of all transactions in and out of the filerooms. We try to maintain 18 months of info on the live system, after which we archive to a history file. Both tables are over 500,000 records. On our server, we have over 50 subfolders full of tables for our agency use. This doesn't even count the personnel system, which is elsewhere in a hidden folder not available for general browsing. Without an adding machine and a lot of time, I checked our nightly backup log. The backup of the drive on our server that contains our Alpha shared databases is over 7GB.
Q: I would assume that your data is not only important, but extremely confidential. Have you instituted any security measures in your application?
Absolutely. We have network-level security, application-level security, and we make sure that back-ups are done nightly. We try to leave nothing to chance. Chris can speak more on the networking security, but basically, we use NT's network level security and all of the features it offers.
Application-wise, we maintain a user-id/password file that is marked when a user signs into the system. Each user has a unique user-id. Their password must be changed every 3 months. By their job function, they are assigned a level of access. This access code is passed throughout the application(s) where it is queried on button presses or when opening forms. If their access level is not appropriate for viewing a specific form, or getting into the application, they are denied. We needed to maintain this level of security checking. For auditing purposes, we stamp any database changes with the access code of the user making the last change along with the date. It could be much more intense if we used a history type of auditing, but we just couldn't see how to do it without completely bogging down the entire system.
Q: Alpha Five version 1 is your database environment. Version 1 is the Windows 3.1 specific version. Could you tell us your history with Alpha Software's database environments?
We got started using Alpha Four. (I still have a box full of disks for each license we purchased). When Ver 1 of Alpha Five came out, We saw an opportunity to get out of DOS and go to a true Windows environment. Development efforts went crazy for a number of years, and the user requests have still not stopped. The application became so massive and such an integral part of our business that conversion to subsequent versions of Alpha Five seemed like an insurmountable task. Time to do the conversion is the problem. It would be impossible to tell the users that they can't request anything for the next year or so while we convert to a new version. We took advantage of every little bit of Xbasic that we could when we converted from Alpha Four to Alpha Five.
We use the "card system" extensively. It is nice since, in Alpha Five version 1, an application doesn't need to be tied to any specific table. Tables can just be opened and closed as needed. We also have a strong need for accountability. When a user signs onto the system, we capture who they are in a variable, and if they change any data, we stamp it.
Q: So your application is composed of many sub-applications. With an application this large, organization has to be an important issue. How do you approach your directory structure for such a large application?
Just to clear things up, I have not actually counted, but there are probably more than 15 distinct applications. Our directory structure is fairly simple. The root folder on our server contains the main calling application. There are really no tables or sets at the root level. All of our sub-folders contain sub-application-specific tables and sets. All of our security files are in one folder, client information is in another, etc. Since the client information is used throughout most of the other applications, it is the most heavily used folder, but, once again, Alpha has been up to the task. Modularity has made the job of maintenance much simpler. We can actually do emergency maintenance on a sub-application without taking down the entire agency. For main application maintenance, we have the honor and privilege of working at night or on the weekend.
Q: Many Alpha users are probably used to thinking of Alpha Five running in a small network or a stand-alone environment. What have you found in using Alpha Five in such a large network -- has it performed to your expectations?
Our response times are remarkably good, considering the size of our network, and the size of our tables. There are times, usually when monthly reports get run, that it does bog down, and response times do lag. Those are the exception. We never really thought about what this system would grow to, we just kept expanding with each new request. Alpha kept up with the requests.
Q: You have a very interesting approach to building your application. Tell us a little about the application.
Got a week?? Our original charter was to convert from an old, proprietary system running on DEC PDP11's. When we first looked at it, we saw that there was massive duplication of information since everything was based on a case, not a client. If one client had numerous cases, their demographics were duplicated for each case. We decided to base things on the client. One point for demographics. Things sort of just grew from there. We try to tie ALL of our client-based programs to this one table. It reduces the chances of incorrect information.
Our menu-driven system is great because we can develop new applications and, only when they are fully tested and ready, we add a new button to the main menu making the new application available.
We maintain user access security using a security table. This table maintains security levels for each user. Based on our assigned level of security, we are granted or denied access to any part of the system. This access level is passed from the main app to any called app, and even down to the user screens.
Q: When we spoke earlier, you mentioned that you have key people identified in each department that you have trained to 'build' their portion of the application. This appears to be a novel approach to building a large application. Tell us how you settled on this approach and how it has worked for you.
Throughout the agency, we have identified a few people who have strong knowledge in their area, and who showed interest in writing an application. With a little guidance, they have worked out very well. Still, the major part of our system was written by 3 or 4 of us. We spend a lot of time with the users to determine what it is that they really need. Most times, higher level administrators cannot express what it is that needs to be done. This is not to say that the requests don't come from them, just that to determine how a job gets done, you need to talk to the person doing the job.
Case-in-point: We have a very involved personnel system. It is tied to our time clocks and exports information to our county payroll department. All aspects of time and personnel matters are computerized. Our deputy director's assistant (secretary) Lorraine Tichenor developed the application. She has been with the agency for 26 years, and through most of those years, she has been the default personnel manager. If there was a personnel issue, you went to her. With a little guidance on database structure and design, she developed the entire system. What I am getting at here is that if you know the function of your job, you would know the best way to automate it. Alpha Software provides the tools to do this in a very simple manner.
Q: What kind of training do these 'app builders' have?
No special training, just a strong knowledge of what they need to accomplish and a desire to work with the database. One of us will sit with these users to set up the table in the most efficient manner, and off they go!
Q: Tom, do any of these 'special' developers get hooked on Alpha Five? How far do they go in the development process, ie: do they write any Xbasic?
A couple of them will attempt Xbasic, but mostly in cut-and-paste mode. We have so many routines already written that one will usually work with minor modifications. Do they really like working in Alpha? Yes they do, it is a means to an end. It will give them something that will make their job easier to perform. They see the value and go from there.
Q: How does management view these 'special' developers? I've got to think that they have their own work to do. Does management allow them extra time or pay to work with Alpha Five?
As far as I know, there is no special dispensation for the non-MIS developers. It is looked on as just part of their job. In Lorraine's case, her boss has really just let her run with it. It is really in the agency's best interest to do so. People are taking their knowledge and applying it so that others can benefit. They get the experience of programming and application development. It really is a win/win situation.
Q: Tom, how do you keep continuity between the different sub-applications in this Alpha Five version 1 application?
It is an interesting juggling act. We do have a small set of standards for programming consistency, but after that, the programmers are free to write what they will. The continuity is within the card system. Through the card calls, we can pass variable data back and forth ensuring who is doing what, where, and when. Any data that the users have the ability to change has a user and date stamp field which is updated with the user-id variable and date on a save.
Q: Do these key people have the right to change the application at any time or as they choose?
No. Our administration needs to know why an app needs to be changed. Modifications must pass through me since I am still, ultimately, responsible for the integrity of the system.
Q: Tom, I think your story is very important because I see this software project, at your agency, to have been initiated at the grass roots level. In other words, your application was not imposed upon you from management. It appears that you have chosen to built a software solution that works and does what you want it to, rather than work with a solution imposed from above. Have you received any pressure to go another route with you in-house development environment?
Only from the state, but that is a whole different story. Our administration is great in this regard. Their objective is to have us empower the workers to do their jobs as efficiently as possible. When they see a need for a system, we are asked to research it and come up with a solution. We are free to develop any application in whatever manner we see as best.
I'm not talking only about Alpha Software as a solution. One of our senior accountants, Scott Modery, developed a system in Excel that eliminated a very tedious process where the workers would need to either hold or release a payment. It was very paper- and time-intensive. His system completely eliminates the paper and all is done through input screens. The requests are routed to the worker's supervisor, then to finance. No more lost paperwork.
Should we see a need for new, different hardware or specialized software, as long as we can show justification, we usually get it.
As an example, workers would go to the file rooms to retrieve case folders. They would fill out a card, give it to the clerk, and wait for the case to be retrieved. Sometimes, this took 20 to 30 minutes. We developed a case request system, integrating Alpha with Excel, where the workers could request a folder from their computer. The "request file" button on the workers form triggers an Excel routine to print a card with bar code in the file room, the clerk gets the case, then informs the worker that the case is ready. Using a touch screen and a bar code scanner, the clerk marks the case out to the specific worker using an "out to worker" button on the screen and a barcode on the folder. This is saving an incredible amount of time that would have been otherwise lost. The file room clerks do not need to type anything. Accuracy of data entry is an added bonus.
Administration still has final say, but, as opposed to micro-managing our development, they just want RESULTS. It makes our job much easier in that we have full freedom in design. We work with the end-users to build systems that work for them.
Q: Can you speak to the affordability issue of using Alpha Five as your database environment?
Money is always a concern. With Alpha Five, we deploy a runtime module to every machine in the agency, and off we go! We have a very limited number of development licenses, but the unlimited runtime is what makes it so cost effective. Development and runtime licenses costs have been very affordable for our agency. Over the years, we have evaluated other "more robust" database systems, but the cost for licenses, education, and the personnel necessary to maintain them were prohibitive.
A few years ago, marketing people from "a major database management software firm" came here to demonstrate how easy it was to implement their solution. We sat politely through their demonstration and concluded that there wasn't anything that they did with their "new" tools that we didn't already have with Alpha.
Q: Tom, we were just at Ira Perlow's Alpha Five Developers Conference. Alpha Five version 5 was the center piece of the conference. What are your thought on Alpha Five version 5?
Version 5 looks terrific. I have been beta testing since the fall, and it just seems to get better. Since the conference, I really have a renewed desire to convert. My administration asks weekly how the conversion is going. I try to work on it as often as possible, but those pesky users still want their systems maintained.
Q: What are some of the features of version 5 that were of most interest to you and your application?
I especially liked the dialog boxes. I have been testing our main menu to eliminate one form by popping a dialog box for the users to enter the variables for user-id and password. It has really made us sit up and take notice as to where we can do things differently. Some of the conversion will be a re-engineering task instead of just a conversion.
Q: Tom, at the conference co-founder and co-owner of Alpha Software Incorporated, Selwyn Rabins, announced that a web-enabled version of Alpha Five and a front-end client version of Alpha Five were in the works. Do either of these product announcements give you any ideas for your application?
Of course. Remote access is now handled through a Citrix server. If we could go through the web, life would be easier. Citrix is fairly rigid as to who is calling and where from. It really isn't a hard stretch to envision potential customers signing on to a pre-screening application to see if they might be eligible for one or more of our programs. Our agency is always looking for ways to outreach to the community. The web would be a great help.
As far as a front-end client, again, Alpha would be terrific. The state utilizes Oracle extensively. If we had Alpha software as a front end to Oracle, our lives could, possibly, get much easier. Learning and managing Oracle is a pretty big task for a small department. Since we already know Alpha, we would just need to figure out the interface. Our users would be able to work within one, consistent system.