What advice do you have for others considering ActiveBatch Workload Automation?

The software is definitely the best. With minor fixes, it could be great and remain very competitive.

Active Batch is my go-to option for all my automation-related work.

I have no concerns about the application, as it has worked very well for me and my team. I recommend the solution to others. They could take advantage of this application by reducing their manual work.

We ask the company to please try to reduce the cost and provide it as a tool rather than a web interface.

I'm using version 12 of ActiveBatch Workload Automation. Ten to fifteen people use ActiveBatch Workload Automation within the company. Between three to four people take care of the deployment and maintenance of the solution. Right now, there isn't any plan to increase the usage of ActiveBatch Workload Automation. My advice to anyone looking to implement ActiveBatch Workload Automation is that it's a good tool for small requirements, for example, a few hundred scheduling workflows. For that, it should be a good tool, with good stability. I'm rating ActiveBatch Workload Automation as eight out of ten.

This is a very good tool and I'm really missing it in my new company because I don't have a robust enterprise-wide scheduling tool and a really good tool for automating end-to-end. I rate this solution eight out of 10.

I rate ActiveBatch Workload Automation an eight out of ten. I rated ActiveBatch Workload Automation high because the licensing model is way better than other solutions, such as Control-M or other companies that charge a lot more. I like their agentless model because most of the scheduling companies put in the rules saying, that for each server you touch, you need an agent. Otherwise, they cannot communicate, and will not work. This is a large advantage for ActiveBatch Workload Automation their Agent model is great.

Jump in and really look at what you are looking at, i.e. don't be afraid to question the vendor, and say, "Can it do this? Can it do that?" So, when you make the decision to use the software, you have done your due diligence and this solution will work for you. I personally think far too many people jump into the decision to buy an automated software piece without really understanding what they are asking it to do. You really have to know, "What am I looking for this software to do for me?" If you don't do that, you are probably going to find yourself unhappy at some point in time, saying, "Well, this really isn't what I thought I was getting." Then, that will end up being your own fault: The more effort you put in ahead of time, the better off you're going to be. Know ahead of time, "What am I going after here that will work for me?" I may not know when a client municipality is going to deliver a file to us. So, a lot of our jobs run as events, not by time. In other words, it may run at three o'clock tomorrow morning or may not run until five o'clock the next morning, because the municipality wasn't ready to send us the data yet. It is a combination of what we have scheduled, as opposed to what we react to when a file is delivered to us. I would rate this solution as an eight and a half (out of 10).

I would recommend taking the time to understand the different objects and features so that, as you grow as an enterprise, the architecture is already in place and you're not figuring it out as you go, like we did. The ability to automate predictable, repeatable processes is something that we haven't leveraged as much. It's the Heuristic Queue Allocation where it can schedule and manage execution of workflows with whatever resource is available. With that said, I do notice that it does track, by default, the average run time and how long jobs run. There are some default analytics that it provides.

We have been able to learn it pretty quickly. We were kind of thrown right in after we got the proof of concept up and going. We had a couple of use cases drawn up and implemented, and they showed us how to do it. Our boss ended up buying the software, and said, "Ready, set, go. We're going to start migrating all these different processes over." We really didn't get time to learn it. Based on what we knew about our previous application that we were using for automation, we were able to step right in and do the best we could. We have been doing weekly, one- to two-hour sessions where three of us get together, just understand the solution, and try to work through all the details. We have been able to learn it pretty quickly without having too much training or knowledge. We have gone through and given the business units a demo of what the possibilities are for sharing knowledge and ideas. At the end of the day, there is a team of three of us who are actually implementing all the processes so we keep a kind of standard. However, to give a business unit an idea of what the functionality is and how we could best utilize it, we at least give them the 30,000 foot view of what ActiveBatch could do, then we build it. We mainly use it for console apps, but we haven't explored them in real depth. I know that we could get even deeper. At some point down the road, a lot of the console apps that our developer teams create will more than likely become native ActiveBatch processes which we will no longer need the console apps to run. For the admins, the biggest lesson learnt would be in those first 30 days going through and learning through the Academy. They have an online Academy that they have out on their website. The biggest struggle that we had was just the fact that we were trying to do this migration not knowing all the different features of the software. We ran into trouble where we would try and implement something (and we wanted to do it by best practices because we want to get it right the first time), but there were features that we were discovering along the way that we had no idea about until all of a sudden we needed that feature. Then, we would go back, and go, "Oh, you know what? That last procedure that we just implemented. It would've been really cool if we would have known that at the time." If we would have taken the first 30 to 60 days, or even a week long crash course, in ActiveBatch development to get all the highlights of everything that the software could physically do, that would have helped us immensely just to make sure that we knew what was going on and how it worked. We probably would have implemented some of our migrations a little differently than we have them done today. So, we will have to circle back and revisit some of those processes and reinvent them. Take that time and learn the solution. Make sure you understand the software, at least at a higher level, maybe not the 30,000 foot view, but maybe the 1,000 foot view and get through the Academy first. Once you get through the Academy, then you can go ahead and start implementing the job libraries and how you want it to lay out and be implemented. Even after nine months of working with the software, we're still discovering features that we wish we would have known nine months ago coming into the migration. I would probably rate the software as a nine and a half or 10. I would rate the tech support as probably a six, but they are improving immensely. If I had to give it an overall score, I would go with an eight (out of 10).

My advice would be to jump on it straight away. With the ease of installation, the expandability or scalability of the product across multiple servers with different agents, the ability to not only use Windows but Linux as well, and the fact that you can build complex plans that have multiple constraints, multiple types of scheduling, and multiple types of alert mechanisms, it's highly expandable. You're going to have a lot of fun with it. It's highly flexible and easy to use. In terms of what we can do, we still haven't gone to the Nth degree of what we can't do with ActiveBatch. It's incredibly flexible. We're running shell scripts that run Python scripts. We've got PowerShell scripts and batch scripts. We tie into different applications. We still haven't exhausted the potential of ActiveBatch. That's what I've learned. Predictability is something that is out of the control of ActiveBatch. We can set a job to run against a database, but it's really going to be the network or the database that will impact ActiveBatch. ActiveBatch will continue to run. There is an average run time that we look at, but if the network has high latency or the database is under load, the time will increase. ActiveBatch will continue to run as normal. The frequency of ActiveBatch failing is quite rare. We use the ActiveBatch interface up to a certain point, and then we start looking at running Python and shell scripts. That's why we have the Linux agent. We call a shell script which runs a Python script that does some manipulation and passes that information back. And then there are a number of plans that manipulate the process. In this particular plan, the CSV file is created and it's dropped into a file location. ActiveBatch is polling for that location. It sees that file. Then a Python script runs and creates an MD5 hash. When you download a file from the internet, there's an alphanumeric number that indicates whether that file is valid or not. The MD5 hash is generated on the file and when it's moved to another location, another MD5 hash is generated to determine whether there was a change in that file when it moved from A to B. It's a validation to make sure that no data was corrupted during the movement from where the file was dropped to where the file landed. Once it has been validated, the file is then moved into another location where it's uploaded into the Greenplum database and a notification is sent to whomever was involved in that particular process. It's quite involved. If a job fails, we have set it to wait for a few minutes and to then re-run. If that fails, we can trigger another job to continue on in that process flow, if the failed job isn't critical. Some of the plans are quite complicated and have a certain amount of logic involved, but that enables us to navigate around problems that might otherwise need a developer's assistance, if it doesn't affect the overall plan process. As long as there are no constraints involved that require the next job to run, and it can move around that job and continue on, that's how we set it up. We're looking forward to version 12 to see how that goes as well. We've also mirrored the database, the backend database that ActiveBatch uses. We have a failover process which was just recently installed. If one database fails, we can switch over immediately to the other database in real time. Overall, we're really comfortable with how ActiveBatch is performing and with what it's doing.

I would recommend reaching out to a client who has used it, especially if you have questions. While talking with customer support is great, people who use it on the build have better knowledge of how to use it in the business area. We haven't used any of the APIs directly through ActiveBatch yet. We have started playing around with having our own little outside website which allows our end users to trigger jobs directly within ActiveBatch. But, we have not fully implemented that yet. We have started looking at cloud solutions for bringing Azure sites up and down. We have not implemented that yet. I would rate this solution as a nine out of 10.

We look at different products and this is definitely a very good one. I do not have much familiarity with the cloud-based solutions but on a Windows platform, this one is pretty good. Overall, this is a good product but there are a lot of improvements that can be made to the interface to make it more user-friendly. Also, if I were rating the reporting then I would only score it a six and a half. Finally, we do need a solution that can reach out to cloud environments. I would rate this solution an eight out of ten.

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.

Start with a simple, small version and try some simple tasks to see how effective it is. Using ActiveBatch I have learned that the potential for reducing costs using an automation tool is huge, and that when the business becomes aware of it they really embrace the product.

The breakthrough for us was when we were able to take completely different software tools and integrate them into one long flow of data. We have our Informatica jobs which then trigger some PLC to SQL jobs in ActiveBatch, but they also trigger Alteryx jobs, which is its own software tool. It can integrate and execute iCEDQ, which is its own software, as well as Tableau. The ability to trigger those jobs from completely different software tools, in one flow, has saved us a lot of time and a lot of headaches. Don't be afraid to dig in and try things. I said one of the weaknesses is the Help, but the Help function has helped me figure a few things out. We have jobs that update the pager email to go from an offsite pager to an onsite pager and back again. So don't be afraid to take the time to try to figure something different out. There are some useful things in the Help. I'm the primary person using ActiveBatch in the warehouse. A month ago, we had a lot more people using it, but in the travel industry we've already had some severe layoffs. There were 10 people using ActiveBatch. They were all data analysts or data quality analysts, and I am the data warehouse developer. There were also business intelligence developers.

Right now, we only use the Informatica AI and Informatica PowerCenter. We are looking at a ServiceNow integration. Some of the other ones, like Azure, we don't need right now as we continue to grow it organically. It's more as teams migrate technologies. We want to have an opportunity to have a conversation with them, and say, "Hey, come in and do it this way." We are not using all the features yet. E.g. we don't use any load balancing variables. I would rate the solution as an eight to nine (out of 10).

Take the time to get a good feel for how it works. That's the biggest thing. Once you have that, start creating the jobs. I would expect that people will be very satisfied with how well it runs and the flexibility that the tool has. In terms of execution on hybrid machines or across on-prem and cloud systems, it's not applicable for us at this point. All our stuff is hosted. We're not doing anything in the cloud right now, although that may be something that's in our future. But right now, it's just used for servers that we have in our data center. We have a team of about six or seven people who use ActiveBatch at least a little bit. But only three of us are the "power users." ActiveBatch is designed to have different roles but all three of us do a little bit of all of them. So we haven't divided it out yet in terms of having an operations person or a design person. My role leans more toward designing jobs. The technician that found ActiveBatch, his role leans more towards the operation and administrative side of getting things installed and working on upgrading the application. The third guy does a little of both. We're pretty satisfied with everything. Their support is great. It does everything we need it to do. There isn't anything that we're having to find workarounds for.

It is a great product. I can't speak enough about it. We haven't found anything that we can't overcome in ActiveBatch. When they put this product out, they thought it out and put a lot of nice stuff into it. There are features we haven't touched yet, even though we have been on it for so many years. We have never really uncovered anything that's a problem. It is a well-thought-out product and one of the best that I've ever worked with. I would rate this product as a 10 out of 10. I really like this product. Think about what you want to automate, then put a process flow in place. For somebody who wants to start this, take one job and put a process flow in place, then develop it within the system. Once you get one product in place, it is pretty easy to replicate it. Initially, to get started on some of this, it can be a horrifying effort. It looks overwhelming, but once you get going on this stuff, get one job in place, and figure out what to do, then it's pretty easy to replicate across the board. All our back-end systems are Oracle driven from an integration standpoint. Oracle interfaces are very nice which helps us a lot because we can do a lot of coding and take care of a lot of the back-end Oracle stuff. However, we don't use external things, like Amazon, as that is against our security We just started looking at email triggers, but have not implemented any at this point.