Automic Automation Reviews

We use it for assisted process change, and we are using it for basic operating system-level UPROCs or jobs, and there are certain jobs that it runs for the net backup.

The solution has been here for the past ten years, there is a definite business value-add; the batch/shell scripts running in the environment can be controlled centrally, SAP Processing; Backup Jobs and many more with no or minimal interventions.

In general, in any environment where there are more than 500 or 600 servers, each server will have settings and scripts doing their jobs, moving files, etc. There may be a bunch of scripts that run in a workflow. If you don't have a centralized tool for workload automation, it becomes problematic down the line because, as the environment grows, as IT grows in any organization, the number of scripts grows accordingly. If you have a centralized workload automation tool, you can completely control such jobs, or file transfers, or any job that is critical to a specific application/server. So it provides ease in handling scripts.

Also, it helps with manpower. If you have server admins to take care of those scripts, you need more admins, of course. But if you have one such workload automation tool, a single person can control, monitor, and see the behavior of the scripts in the environment: How well they are running and, if they are failing, which scripts are failing. That's the business value-add that I see in having any workload automation tool, like CA Dollar Universe, which is the one we have here.

The most valuable feature is the one for SAP batch processing. It's not just ordinary job processing. There are certain other mid-level workload automation tools which can handle the OS level, but SAP is something which is really very critical. Automic stands out from the ordinary tools because handling SAP processes is absolutely easy with it. Integrating SAP applications with Dollar U is very easy. It's just a few considerations and there you go. You can initiate your processing.

We are currently at version 6.7.41. One improvement area that I can see would be a centralized licensing part. I've heard that has been already taken care of in the latest version. I'm not sure how true that is, but that's one thing that should be there: centralized licensing.

Another issue is that at times there are certain jobs that are triggered one after another. It would be helpful to have a more user-friendly way of seeing how those jobs are connecting from one server to another. Suppose there is a workflow that is running between ten and 15 servers. It's always challenging to figure out which job is connected to which job on which server, for a newbie, if you haven't designed it. That has to be more user-friendly where you can see the complete workflow of a process or a job.

I haven't seen any issues regarding stability.

It's very scalable. It's easy. You just add on the resources and you are there. The management server doesn't get loaded up, it doesn't have to process anything. That makes it cheaper as well. Scalability is pretty easy.

On a scale of one to 10, with 10 being highest, I would rate technical support a nine. So far, I haven't gone unanswered for any of the queries, except one. Their response time is pretty fast. It depends on how severe the case is. If it's just a general query, they respond within a day. If it's really critical, where your business is impacted, they respond within half-an-hour or an hour. I have had a really good experience with the tech support.

I have been an admin on other tools as well. I was a contributor to and implemented BMC Control-M.

I haven't done the initial setup, but I think it's pretty straightforward from what I have seen in the documents. My feeling is it should not take more than an hour or two to get it up and running. If everything is ready, your database is there, and you have the right amount of resources on the server, it shouldn't take more than an hour or two hours.

In terms of an implementation strategy: 

1. You should have a database. 
2. You need to figure out what components you're going to go for.
3. You need an estimation of the number of jobs you are looking for to plan out the resources on the server. 
4. Finally, you need to think about how you will roll out access to the users: a thick client or a web console. 

Those are the things that need to be factored in before beginning the installation. The accessibility part can be dealt with later, but the resourcing of the database on the server and the management server have to be spec'd out before.

I understand that AWA is cheaper than Control-M, but I'm not certain about the numbers.

What makes it stand out from the competitors I have seen is it has distributed architecture. If you look at BMC Control-M vs Automic Workload Automation, the brain is the central, enterprise management server. That's where all the jobs reside. Every day, a new set of jobs loads onto the agent, and then the agent executes. If the central server is down, there will be no jobs executing across the environment.

However, when it comes to CA Automic, it has a distributed architecture which means all the logic, all the jobs, reside on the agent itself. Irrespective of whether the management server is running or not, your jobs will execute in a timely way. The only challenge could be that you will not be able to see their outcome. You will not be able to monitor them. That could be a challenge. But again, at least the jobs are executing in a timely fashion, as they're supposed to, in your environment.

It's the same for any end tool we implement: Be clear with the requirements. Apart from that, everything is pretty smooth and straightforward. You can look at the tool and understand where things are going. There is no rocket science that you need to be worried about. But you do need to be aware of what you're doing.

Regarding the number of staff for maintenance, it depends on how exactly you want to maintain it. We always keep all the UPROCS, all the jobs that we have in an environment, on a centralised server as a backup. The maintenance is up to the individual organization, how robust or how limited they want it to be on the day of a crisis.

In our organization, we have a team of nine people handling the tool. We have more than 12,000 tasks that are scheduled to run each day, and more than 100,000 job iterations happen every day. It's actually a really big environment. We have more than 1,400 nodes connected to it, and we are bringing in 300 more. At each of those additional nodes we are expecting four to five jobs. So that will add about 1,500 tasks. The number of iterations expected is still unknown.

Right now, we execute jobs in three regions: Europe, Asia-Pacific, and America. We are only using AWA in the European region. We are taking it into Asia as well. That's the next expansion of the tool.

The admin roles include handling new requests for creation of the tasks and sessions, as well as the changes to existing jobs, including notification, and daily scheduling. In addition, there is the daily maintenance part. We check for jobs that are failing every day, why they are failing, and we will try to mitigate the problem. It could be the agent needs to be purged, or the agent is not running, or the credentials that were given for a specific job are not there anymore. Those are the sorts of checks we do on a daily basis to keep it healthy.

I rate Automic Workload Automation at eight out of ten. What comes to mind when I consider that rating is the distributed licensing, that every server has to be licensed individually. The second is the workflow of jobs connected on multiple servers.

We use it to automate infrastructure and business. We do quite a lot of different stuff: sometimes orchestration, sometimes more automation.

It saves a lot of time and mistakes, because we used to do a lot of manual work. Since we added automation a little bit over a year now, it has enhanced our daily work, especially for the very repetitive tasks that we did.

We can use anything on the server, like PowerShell and flash. We can use whatever language that will make things easier.

Depending on the properties of the jobs and pre- and post-conditions, there needs to be more flexible and richer conditions that I can check for. This would be a great addition.

It is stable 99% of the time.

Our issues have been mostly because of the Tomcat interface. The other interface, the fat client, has been stable until now, and looks good.

It is very scalable.

Technical support is very good.

If the environment is straightforward, then the initial setup will be straightforward.

It saves us from making a lot of mistakes. It is now easier to align complex things.

Automic is gaining much more ground than other products. The other one is the BMC, but it is not as good. 

The main use case at the moment is to automate workloads. We have more than one automation tool, but the workload automation tool was chosen to do automatic manual workloads. That is why it is called workload automation. 

We are automating very manual, robust tasks, which are very time consuming and not error-free. This is our first main use case, and we do this also to glue some holes. For example, we orchestrate backups, where we take one system down to start a backup, etc. In addition, we are processing big data from the Hadoop platform and Informatica systems, and we orchestrate using scripts. We call it simple scheduling services, where we simply schedule batch jobs from scripts.

For our organization, this was a very big project. The issue of automation is a hot topic now, and that is where workload automation fits in.

It provides time savings on manual tasks. For example, imagine an operator is getting a task, but it would take him three to four hours. Therefore, he is slow to even pick up this task. Now, when we automate these task, it is just one click for the user, or sometimes it is even triggered on its own. Then, this task is already solves the problem. 

Also, we impose some standards for backup and restore operations. We have some standard naming conventions, where previously the operator would have to restart a VM. When he did, he would have to remember about setting a specific name. Therefore, we imposed this standardization. Our three main valuable features that we have imposed through automation:

• Standardization
• Error-free
• Time consuming.

The most valuable feature is the automation. There is the possibility to understand its different components. It is very open, where you can run different scripts or program scripts in PowerShell or Bash. Thus, it is open for various languages, and not closed to Java, where some other tools might be.

I do not think it is as valued as it should be because it is not user-friendly. There could be a better user interface for end users. They should make it more intuitive, not based on Java.

They should also fix all the bugs.

We do use technical support. Unfortunately, that is the bad side about working with Automic. With every new version, things that would previously work, Automic breaks them. So, we have to report the new bugs. Therefore, every time when we patch the system, there is usually a new bug or a feature that was working, then it stops working.

In general, the technical support's response is very quick. Maybe we are just a new customer, and we are on special care. However, if there is a major issue in production, then we simply get a call within five to 10 minutes, a call, not an email. They call directly to my desk.

We were previously doing manual work. There was an initiative coming from the senior management to automate more things, which is how this came about. When I joined the project, this product was already selected. I had no real say about the product. I had to learn it, because I was given CA Automic Workload Automation, and told this is what you are going to implement. 

I was responsible to design and build the system. The project was an agile project, which was a pilot, because our company was not very agile. 

While we are a public institution, we are very old school. This was a first attempt at doing new things. I was the only technical resource that had the proper knowledge and skills. Therefore, I was the one who designed the system and build it.

The initial setup was complex, because of our specific requirements.

The installer that had been given to us by Automic (now CA) was installing too many things that our security would not like. So, we went through a manual procedure, which was very hard and complex. What we did was, I wrote a script that ran through all the procedures. Then, at the end of installation, where it took me three weeks to write the script, the installation took only five minutes. 

I love it, and I am happy working with it. Though, it was hard to comprehend at the beginning.

Do not be scared with the user interface. It is not that hard. If you like to script, this is the tool for you.

We use Automic Workload Automation to schedule the batch processes for all systems within the University of Colorado. We use file transfer jobs to send or receive files with each incoming file authenticated through Automic. We code Automic jobs to update PeopleSoft run controls automatically, continuously run processes for real-time results, bounce application servers, and we notify all process failures through text and email.

In 2014, we saved over 9000 hours on an annualized basis when we removed the manual updating of Run Controls. Removing manual updating also improves efficiencies, productivity, and human errors.

Another example of how Automic has improved how we function is the ability to automate our abend notifications. This ability has improved our work/life balance during the weekends when we are on-call. Instead of being tasked with monitoring the system during the weekend, the abend notifications are automated to send a text to our cell phones. That enables us to go about our daily lives and only log on if something breaks. This has also enabled us to staff 24/5 instead of 24/7, saving two FTEs who would otherwise work 12-hour shifts throughout the weekend to just monitor batch.

Currently, we are in the process of rebuilding our student information system jobs in Automic. The reconstructed jobs will use Automic capabilities and coding to automatically update college terms, financial aid years, census dates, etc which will fully automate our data processing. The code uses a calendar and variable tables to update the run control values as necessary depending on the date. Fully automating term changes will eliminate 90% of our ticket load and remove the manual updating of 7000 Peoplesoft run controls per year. This will also improve our customer's end experience, they will no longer be required to submit cumbersome tickets detailing run control changes. 

An important feature is the ability to modify PeopleSoft Run Controls at run-time. We run all of the batch processes for the Student Information Systems, Finance, and HCM, which use Peoplesoft in our shop. The ability to modify dates, query names, batch numbers, etc., is paramount to my team. The ability of the Automic script/coding is also a valuable asset as it provides a way for us to meet any customer's requirements, no matter what it is, we can do it with Automic scripting.

There are some scripting elements that could be added like being able to reset a task in a schedule through Automic scripting. 

Also, some of the things we don't use are mainly because we don't know how to use them. Hands-on training can be expensive, so we find other ways to work around things to forgo the hands-on training. It is also an issue because we are a Linux shop and most trainers are Windows-based.

The product itself is very stable; we have not encountered stability issues with it.

No issues with scalability.

The technical support team is fantastic. Any ticket submitted is worked on quickly and professionally. The team is very good about following up to make sure the solution worked and, if it didn't, they will work with you until the issue is resolved. They are hands-down the most efficient support team I have come across and they are the one team that will always provide results.

We ran our Finance, HCM, and CIW processes through Unicenter. I don't believe that Unicenter was very user-friendly and they found it difficult to integrate with other applications.

We ran the Student Information System batch on the mainframe using CA7 as the batch scheduler. We switched from Unicenter to Automic and from the mainframe to Automic, mainly because Automic can integrate easily with any other application or service. When we got off of the mainframe and moved the student side to PeopleSoft, it only made sense to use Automic as the batch scheduler.

The initial setup of Automic is simple and easy. As long as it can talk to what it needs to talk to, there are no issues with the installation.

Initial setup was with a support representative. I can't say the level of expertise because I was not there when it was first installed. I can say that since I have taken over this department, any contact with Automic support has always met or exceeded expectations and any rep has always been well skilled at most things, other than Peoplesoft. 

The overall cost of Automic is minimal compared to what we can do with the product. Our return on investment far outweighs the cost each year.

Certain licenses can be a bit expensive. The PeopleSoft agents, in particular, are a bit pricey. We are using agent groups in our development environment which allows us to switch between the different Peoplesoft instances without having to change the host names in the jobs and without the need for multiple PS licenses.

I believe we looked at BMC and other CA products but chose Automic because of its ability to easily integrate with other applications and services, and because of how user-friendly it is.

It is hands-down the best product out there. You might find others that are cheaper, you might find others that sound better and cost more, but in the end, the best automation product on the market is Automic. Save yourself some time and start with the best first. It is easy to install, easy to maintain, reliable, stable, user-friendly, and versatile. One can achieve great automation with Automic.

We want to automate our processes. Before, we used to execute more than more than 250 jobs manually, along with a number of things related to backups, and putting files on FTP. 

Previously, in IT Operations, this function was used to induct resources. It's a type of training platform for them to understand operations as an entry point. We used to take four to six months to train a resource. After the implementation of Automic, it hardly takes a month to develop a resource.

Most of the monotonous types of jobs have been automated. We have been able to train our resources very quickly, so we can put their focus on high value things. Also, it has created a knowledge base, which has helped us to pinpoint problems. After a month, we found out that seven out of ten times, there was a specific problem. So, we fixed these issues, optimized them, and now, we have a situation where we are running with zero errors.

The best thing about the product is its agility. 

It is a complete solution: people, process, and technology.

CA needs to add a few more products in this suite, because right now they have automation, DR switching, and the third one is relief management. They could add change and release management.

It's pretty stable. After implementation, there hasn't been a single event where we shifted our jobs for the day from automated to manual.

We haven't seen any issues related to scalability.

The tech support trained our resources to be self-sufficient.

Automic has been a Greenfield project. We were the first implementation and a number of banks went with this solution after us.

The implementation was not straightforward, though it is not that complex. During installation, some database elective issues popped up. These took some time to fix, but after some back and forth communication, these issues were resolved.

A few things were out-of-the-box. However, during the implementation, a number of things popped up which required coding, implementation, or electrical work, and the Automic team was able to fix these very quickly. 

The implementation people were very good, along with the experience. They know their job. They know the product. They understood the requirements very well. It took three to four months time to rollout this project into production.

This is a support system for us, not our core business, so we purchased this product inexpensively. Later on, we came to a very good deal, but it took us three years to finalize.

We recently purchased the whole suite. 

Anything that can be automated, should be automated. The world is changing and new things are coming out a daily basis. These things take away your day-to-day spend, give you ample time to look forward, and streamline your workflow.

• Workload and system automation 
• We run our batch schedules through the system and have also automated very complex processes to allow Operations perform tasks that were previously done by Sys Admins.

Allowed us to almost fully automate our batch schedule and to provide our Operations team with a single interface for monitoring batch and automated system processes.

• File transfer is excellent 
• Very intuitive interface (Java version) 
• Process flows are very easy to build.
• Events are useful to trigger process flows based on external factors.
• Zero downtime upgrade is a great idea!

• New web interface is not fit for purpose
• Users should continue to have access to the Java GUI 
• Support can be a bit slow responding to non-critical issues

Our primary use case would just be our production batch processing.

It's been great. We've had a few bumps in years past but it's been rock solid since the last couple versions.  We also perform all internal file transfers and many of our company's external file transfers.

We have a lot of jobs that have to run, and it's easy to see what the status is.

We've been using it for around 15 years now. We're very comfortable with it, that's probably the biggest thing. I've been using it for a long time, so the comfort level is there. I don't see any reason I would want to switch to anything else. It does everything we need. Actually, we're not even utilizing it to its fullest ability. We're probably a couple versions behind what the latest version is. And there are a lot of features we want to get to, to start utilizing, but it all takes time and does require the correct resources available.

The usability of the user interface.  It just makes sense and it is easy to see the flow of the processes.  We have been slowly migrating to the web-based user interface, which has some of the older features missing, but also introduces additional new features.

In terms of additional features, it's probably stuff they already have available that we haven't started utilizing yet. 

I really like the idea of the Zero Downtime Upgrade, but really excited to be able to use the centralized agent upgrade. That's probably one of our biggest pain points right now. When we go to a new version, the agents have to all be upgraded. We have several thousand agents and that's a painful process because it's slow and time-consuming to upgrade. Now they have the ability to automate it, we're working on getting to that point.  The analytics that are available show great potential.

Stability has been great. My team, we call ourselves "the invisibles" because things run so well that sometimes you almost feel like you have to try to break something to actually get acknowledged.

In terms of scalability, it's been able to do everything we want and we're probably using one percent of the resources, day to day. We'll have up to 100 people logged into the system and it just runs. It still gets good response.

We've used technical support on occasion. Every once in a while you run into something that you're unsure about or not sure how to utilize it. I've been happy with the support we've received. It's definitely improved, like I said, over the years. It's been great. The response has been much quicker.

For the open system side, I don't believe we were using anything previously. Probably anything that they would have been using would have been Microsoft Task Scheduler or a Unix cron. But we were not using anything that I know of at the time. We did have CA-7 on the mainframe, which we still actually use on a limited basis, but that is being sunsetted. So we were not using anything really.

I wasn't involved in the initial setup. I actually used it from an operator's standpoint. I did not start maintaining the system until about a year and a half after we brought this system in.

It was implemented prior to my time of working with the application.

I am unsure as it was before I started administering the application.

When our company is investing in a new vendor, our top criteria are 

• support
• features
• stability is probably the biggest.

I don't have a whole lot of experience with other automation systems, other than CA-7, which we're on a very old version of, but I really like the Automic Workload Automation due to its ease of use.

We use it for multiple system automation and file transfers to secure POS networks.

The speed in which data is collected form all POS terminals has changed the way our industry has started analyzing how to schedule showtimes, drive advertisements, and change concession pricing. IT is no longer a quarterly process but something that the business can change within 24 hours.

The ability the system has to dynamically create groups, schedules, and workflows is crucial to AMC. In a fast-paced, agile environment, the teams at AMC are very lean. Monitoring and maintaining of all the approximately 2,000,000 executions of Automic jobs are managed by only three employees. The system has been designed to be as dynamic and versatile as the business processes and teams that own them.

The direction in which the UI is going is concerning to me. It does not offer the security context we would need to implement future versions. While I see benefit in the Web UI, the security it would lack in separating a user's experience from an administrator's experience is an issue for us. MFA functionality is required since we're dealing with connectivity to the POS and for PCI/SOX compliance.

Another area for improvement would be SQL performance. While tracing SQL traffic, we noticed a lot of commands that cause contention/locks as well as forced waits. The efficiency of the SQL could be greatly improved (in some cases by simply replacing nested Selects and using NOLOCK hints).

Finally, re-evaluating the security model that the ECC uses would be very beneficial. While granularity is very powerful, some intelligence around it is the only way it is manageable. I should be able to grant a user access to execute a job without having to directly list every include, prompt set, output scan, script, login, etc. An inherited read for execution purposes would accomplish the same results without making the admin list every single object every time, as well as deny the user the ability to edit.

There have been some issues with performance when there is slowness with database resources. We have also discovered issues with some objects if file size/count is high. I believe a patch has been created for that though.

We do not have any scalability issues.

Technical support is amazing. They always follow through and are extremely personable. They help as much as they can, and have no problem asking others on their team for help to make sure the right answer is given.

We did not have a previous solution.

The initial setup was very straightforward. The consulting team for implementation was great to work with and taught us the system very well.

The team at Automic are great with understanding your needs as a business. They are always willing to go the extra mile to make sure the solution works for you. This is not only something they do in their software but also in their licensing.

We looked at BMC, Tidal Software, ORSYP, and ActiveBatch.

I would advise anyone purchasing this product to do the architecture work ahead of implementation. While it is easy to move objects between non-prod and prod or other environments, if you put the work up-front into designing how to move things or manage outages, etc., it makes your world a lot easier.