What is our primary use case?
ActiveBatch is used for scheduling our nightly batch processes. That is our main use at this point. It includes billing, processing, claims, commission statements, and a lot of reporting. It's all tied into that batch process.
We do use the built-in REST call process for nightly printing, coming out of that batch cycle. We distribute the nightly reports out of the batch cycle to different departments using ActiveBatch. It's used for FTP processing every week coming out of the weekly commissions process.
The most important part to us is to keep those nightly batch cycles in an easy to read format, which is where ActiveBatch Plans come into play. We run these cycles in four different environments, from development to production and a couple stops in between. Keeping all of those jobs separate from one another is key for us.
Outside of batch, we do run a process every five minutes throughout the day during business hours to scrape data from our mainframe entry system to our new policy administration system. As people enter claims into the mainframe system, those claims get moved over within five minutes, rather than waiting for the mainframe batch cycle to run that night and those claims not being seen until the next day. That saves us up to 24 hours. The business end-users can get that data within five minutes now.
How has it helped my organization?
ActiveBatch has allowed us to move forward quickly with our modernization effort, to get off of the mainframe and to move that data to a distributed environment. It has been huge for us to use ActiveBatch to run these nightly processes: everything from Dev to QA, UAT, and Production. Those are all cycles that we run every night to allow different users to test processes that they're working on in each of those stages, to get them into production and off the mainframe.
With the systems we're using now, it's a lot easier with ActiveBatch. The mainframe is so manual. If there's a problem with some mainframe code, it requires a call to a developer, but our new system works great with ActiveBatch because everything is built into that system. There's no JCL code or mainframe COBOL code, up front. Our batches just work seamlessly between ActiveBatch and our new administration system. We've had no problem with our batch processing from that point of view. Whereas with the mainframe, it's a struggle at times. If we have a problem with a job and it cancels, we may be waiting three hours for a developer to get online, troubleshoot, test, and get a fix in place so we can finish the cycle. We've not had that issue with ActiveBatch.
What is most valuable?
A lot of the built-in processes are among the most valuable features because when just starting out, although I went through the ActiveBatch Boot Camp — and I've got a couple of other people who went through it as well — it was a little overwhelming, not having used the product.
We found it easier once we were using the product and then doing refreshers on the Boot Camp or doing the deep dives that ActiveBatch provides. Even the Knowledge Base articles allow us to grow and let us know what we can use in our environment.
We're able to use the Plans, rather than seeing individual jobs within all four of our environments. Seeing all of these jobs individually would be overwhelming to try to easily decipher workflows, whereas everything is nested nicely within each Plan for us. It makes it very easy to read the next day, and to look at how each cycle ran. It also helps with troubleshooting if there's an issue with one of them at night.
As far as centralization goes it's nice because we can see all these processes that are tied to this larger process. The commissions, FTP processing, the reporting, the file moves to the business users — all that is right there. It's very easy to read. It's easy to tie it together, visually, and see where each of these steps fits into the bigger picture.
Other important features for us are file triggers, file constraints, and job constraints, because of the sequential nature of the batch process. The file triggers have made our processes more efficient and reduced delays. It might be minimal at this point, but it would still be a manual process that would have had to be done. Our second-shift operator would have to wait each night for that mainframe cycle to finish and then manually trigger certain processes within each of our ActiveBatch cycles.
It's also a very flexible product. We're just over a year in and we're still getting our feet wet and realizing its potential. One thing I am anxious to roll out — and I've tried to push some business end-user meetings, but it's still a little early in the process as everyone has been so busy with the overall modernization effort — is the Self-Service Portal. It will allow the business users to run processes on-demand, rather than putting in a ticket to have IT do it for them. This would also allow other IT users to see any processes they may be testing, in the ActiveBatch environment.
In addition, the Jobs Library has been a tremendous asset. For the most part, that's what we use. There are some outliers, but we pretty much integrate those Jobs Library steps throughout the process, whether it's REST calls, FTP processes, or file copies and moves. We do use some process job steps to call out external batch processing through external scripts, but most of what we're using is what is built-in, at this point. That has helped us to build end-to-end workflows.
What needs improvement?
When our mainframe process ends each night it sends out an email to certain users that the system is up, so that they can log on and do work on the mainframe at that point. We tried to use that email as a trigger for our ActiveBatch printing processes but it didn't work out too well. I believe it ended up being a bug that they're going to address in a future release.
But at the same time, that was an easy fix. We were able to change that from an email trigger to a file trigger. Now we have the mainframe job, in addition to sending out that email, create four text files that will trigger our four batch cycles through ActiveBatch. That has worked out great for us.
One thing I've noticed is that navigation can be difficult unless you are familiar with the structure that we have in place. If someone else had to look at our ActiveBatch console and find a job, they might not know where to find it. That being said, I have been using that search function a lot lately. That search function is definitely your friend.
For how long have I used the solution?
I have been using ActiveBatch for about a year-and-a-half.
What do I think about the stability of the solution?
I've not had any major issues with ActiveBatch at all. It seems extremely stable. We've not had any downtime. We've had issues here and there with different processes, but nothing that has affected the overall environment. Granted, we don't have very many users on it; it's mostly processing at this point.
What do I think about the scalability of the solution?
In terms of bandwidth, we've not had an issue. There are no limitations that I can see.
How are customer service and technical support?
The email support can be hit-or-miss. Overall, I've had a pretty good experience with it. They're quick to reply and they let you know exactly what they need. You get it to them and they dig into it and get back to you. Sometimes it can be cumbersome emailing back and forth and waiting for replies. Overall, it's been good.
Which solution did I use previously and why did I switch?
We didn't have a previous solution.
We were looking for a product that could handle a company-wide insurance systems modernization project. This project has been in the making for years. It boiled down to putting new products on our distributed systems, migrating data from the mainframe to those distributed systems, and eventually sun-setting the mainframe. This approach makes more sense since it's simpler to start with new products rather than migration to begin with and this also allowed us a nice starting point with ActiveBatch.
How was the initial setup?
Out-of-the-box, it was a challenge to understand the best way to structure it for our system. Obviously you don't know what you don't know. Once we started using it, we realized the best way to lay it out for ourselves and it became easier and easier over time. I've had to move things around a great deal to make it easier because we weren't sure, when starting, how to set it up, as far as our environment goes with its file structure and object structure.
As far as objects go, it's pretty straightforward. It's like any other file structure. It's just a matter of knowing what you need for your environment, which is something you learn as you go: You need these things in this folder, you need those items in that folder. Do you want all your FTP processes in one folder or do you want them underneath a certain project that they're tied to?
As far as setup and configuration go, they're very straightforward. I've never seen an issue with that or with upgrading.
The planning stage took a while. We got the product and then I and another operator went through the training, which we did in a week. The actual deployment has been scattered. The initial deployment went well, but it was staggered because there were, and still are, different pieces flowing in, a little at a time. It won't be really set until we get all of our business on this platform. It's as set as it can be right now. The actual deployment slowly fell into place. I hate to say it took two months to deploy this product. It didn't. But to get to where we were comfortable running that first batch cycle, it probably did, but that's no fault of ActiveBatch. That's just developers getting the pieces to us and then us figuring out how to use ActiveBatch in the most efficient manner.
What about the implementation team?
We implemented ActiveBatch on our own, but we did work closely with the provider of our new policy administration system and learning how the two products would work together for batch processing. I have worked very closely with someone there to tie in with ActiveBatch. I don't believe he had experience with ActiveBatch prior to that, but one of his coworkers did and he called on that coworker from time to time. We mostly worked on using ActiveBatch to call those external processes through the scripts that were provided to us. That's where we had to get them involved because that was also a new product to us, and it still is. So we were trying to learn how that product worked, how ActiveBatch worked, and how to get them to work together.
For ActiveBatch there were five or six people within Operations/Infrastructure involved in the deployment. We're a small-to-midsize company with a couple of hundred employees.
What was our ROI?
It's hard to say how many hours it has saved because it is new. There have been a lot of hours put into learning the product. For instance, putting SSIS packages in has required a lot of Knowledge Base research on ActiveBatch's site. The Knowledge Base is tremendous there. I've really never had an issue finding plenty of information, sometimes more than enough information, to decipher. But in terms of man-hours, at this point, it's just figuring out the system and how to set up these jobs to work together. Those savings will definitely really be seen down the road.
But our return on investment is because it has allowed us to move forward with this project. Even with just using new business, it's allowed us to move incredibly fast when it comes to putting these batch processes in place. So far there's limited data and each cycle runs in 10-20 minutes, but at the same time, on the back end, it's providing that foundation. So we'll know what we need to do when we have more data. For example, currently, load-balancing is counterproductive. There's so little processing going on that it would take longer to load balance this 10-minute cycle than it would be to just run straight through.
What's my experience with pricing, setup cost, and licensing?
The cost is outside the scope of my job responsibilities. Obviously we're using it, so it was worth the cost. I think it's a tremendous product. I don't know what the cost is compared to others, but having seen the results, it's worth it.
We recently signed up for the certification courses and training, which is money well spent. Anything involving training is money well spent, but especially with a new product that is going to be a major part of your environment and your business. From what I've seen, the videos and online training through ActiveBatch are tremendous. They provide examples, and they actually provide a test environment with jobs that you can put into ActiveBatch. You're able to run these jobs, make changes to them and work through the training with them.
Which other solutions did I evaluate?
Maybe at a higher level in our company there was some research into other solutions and came to ActiveBatch as the best solution. As far as I know, it has always been ActiveBatch. I was hearing that name long before we had it in hand.
What other advice do I have?
Jump in. That's what we did and we're seeing the results. I can't stress enough how much it's allowed us to move forward with this modernization project. Overall, it really has been seamless. There have been a lot of hours on my part, learning the system and researching different processes that I need to put in place for the cycles. But to anyone else, the end result probably appears seamless. It is a lot of work learning it, especially if you have no prior knowledge of enterprise job schedulers and that type of flow. But ActiveBatch provides a wealth of information; their Knowledge Base is tremendous. The support gets back to you pretty much immediately. It might take them a couple of days here and there while they're researching or working with their engineers to replicate a problem.
And sign up for the training, for sure, as well as the additional training certification. In the year since I took the Boot Camp and worked my way through putting this in place to meet our immediate needs, when I revisited the Boot Camp, I found there was a ton of stuff that you forget that you can be using. In that initial Boot Camp, you're really not sure exactly what you're going to use it for. Once you start seeing ActiveBatch processes in your system and go through that training again, you realize, "Oh yeah, I can definitely see where I can tie this in," or "Yeah, we can definitely use that here or we could use this function in this way instead of that way." It will definitely help you become more efficient.
It's easy to learn the basics. It's just a matter of knowing what you need to know, what you need to use it for. At that point the ball is in your court because, while it can definitely be challenging, at the same time it's very rewarding to see things fall into place the way you pictured them. It is a very powerful tool and we've only barely scratched the surface. Keep learning. I'm learning more and more processes within ActiveBatch every day. It's definitely an ongoing process.
What I've learned from using ActiveBatch is that the sky's the limit. With all the additional, third-party licenses — Active Directory, System Manager — at this point it seems endless for us. I honestly don't know where we would be without it at this point.
We just started testing SSIS packages, as we're trying to move those off of the SQL environment and into ActiveBatch, rather than setting up schedules within SQL. We started testing one, out-of-the-box, and we're ready to move that to production this week. There will be more after that.
We aren't leveraging the cloud. We are trying to get into that area but, at the same time, we're focused on this part of our modernization project right now, getting off of the mainframe first and onto the distributed systems. Then we can take it another step. We don't have any of those additional licenses for integration with things like SharePoint, Informatica, or ServiceNow. Those options are definitely something my manager has his finger on. He knows those are available and he realizes ActiveBatch can definitely be leveraged to a greater extent.
Our developers work outside of ActiveBatch. It's mostly me who puts together the ActiveBatch jobs. The developers are mainly mainframe developers who don't touch ActiveBatch, or they are application developers who tie everything together into this entire modernization effort. There are a ton of products tied into that effort, ActiveBatch being one. ActiveBatch "brings the others together," such as printing from a third-party vendo, our insurance suite for billing, claims, commissions, etc. A new underwriting tool will also be tied in eventually. So most of the developers are working on those other applications. Direct users of ActiveBatch boil down to me and a couple others who are familiar with Activebatch but who are not as familiar with it as I am.
Currently, any issues with the batch processes are more the result of a learning curve for us.
I would rate the solution at eight out of 10. I'm a stickler with ratings. Nine would be the highest I would ever give anything because nothing is perfect. Here, it comes down to the fact that the navigation can be clunky at times, but I think that's more on you to learn. One thing ActiveBatch could do is provide more examples of real-life business use and business case examples, that show how others have structured their systems. That would probably be a big help. They do tell you how to organize jobs within Plans and you can nest things that way, but more real-life examples would probably have helped me to see how other businesses are using it or how their folder or their object structures are set up.
I love the product. It's exactly what we were looking for.
Which deployment model are you using for this solution?