Automic Automation Reviews

We use the CA Automic solution for our complete business batch. We have several use cases, depending on the subcompany. We have an ABS system with a great batch and the lean system, therefore we have three different main batches with approximately 900,000 objects in the CA system. 

We have mostly connected our complete systems on the web front-end for the customer, so they can choose their products, manage their contracts, and get a new contract. This is all put into the automation system and handled there until, at the end, we have the output for printing, then we send it back to the customer.

We are on the user side of CA, not system engineers. We control the different batches, and this way is better for handling the systems than the way that we did it before. I like the script engine of CA, where you can build everything you want. If there are features not implemented, then you can script something around it, and it works.

• The search is sometimes a little bit slow.
• The calculation of the calendars needs improvement, as I have problems from time to time.
• I am excited about the new web GUI from the B12. However, I am not sure about it, except for the main client that we had before needs improvement.

The system is very stable. I have very impressed with it. Also, it all depends on if it is Linux and Oracle or Windows and SQL. We have both in our company, and both are very stable.

We have a large batch with many objects in the CA system. Therefore, we are always at the upper end of the performance that the product can handle.

The search is sometimes very slow. I have heard in the B12 version that there is a new solution for this issue, but I don't know if it is usable because they duplicate the database and then you can search there, not the online database. We just moved to the B12 version, so we will see how it work. The rest of the performance is okay.

From what I hear, it's good support. They always try to support us in the best way. 

Last year, when moving from B8 to B10, they have changed several features. One of our highly used features was no longer available. While it had a similar name, it was a completely different function. After calling the support and checking with them, they implemented the old feature for us again on the newer version.

About 15 years ago, we had CA-7 from CA. Then, we changed to the UC4 Automic. Now, we are back to CA.

Before we have our main releases, we always check between other products for the batch. In the last few years, it has always been Automic which was best for our needs.

I have seen all different types of scheduling systems. It is the best for my company to handle.

It has an easy to handle GUI. Because of the script engine, you can do nearly everything you want. I prefer it to other solutions. 

Most important criteria when selecting a vendor: It has to handle our batches, because we use many objects. It is good how we can migrate from the new tool and how much work is accepted for the migration. At the moment, we have not found anything better than the CA solution.

We used Automic for a multinational pharmaceutical client.

In the latest version, we can access the solution through a web browser as well. 

The web-based edition is missing a lot of the most important features available in Automic, we have absence. For example, when I'm scheduling a job, there is normally a flag that you can toggle to activate and deactivate the task, but that doesn't work properly in the web version. It's missing a lot of the calendar and scheduling features. 

My organization used the tool for almost 10 years, but we were dissatisfied when we upgraded to web-based edition because it doesn't provide all the options. It's challenging to create a new job or edit and reconfigure an existing. The web version has to be improved on various levels. 

Previously, we were using Solaris with Automic, but now I think it's Unix and Windows. I don't know what version you are going to provide for the cloud. The cloud always supports Unix and Windows, so it means the tool is cloud compatible.

In the web version, everything is moving from the on-premise server to the cloud. So in this scenario, the Automic tool has to be more cloud-oriented. We are not sure how it will work in the cloud. Since 2011 or 2012, we have been using Automic on-prem only. It would be nice to have more documentation about using the cloud version of Automic. The tool could be more user-friendly as well. Most people consider Automic to be a difficult tool to understand and use.

I've been using Automic for six years, but we just switched to another tool called AutoSys six months ago.

Automic is 99 percent stable. We've never had a problem with stability.

The scalability could be improved because we have three kinds of tools on our hardware itself, and we don't know whether Automic will accommodate the other two jobs as well. We have 200 direct users and probably 1,000 who benefit from the tool indirectly.

It depends on the terms of the support contract, but sometimes it will take two or three days to fix an issue. The impact is high because this type of job scheduling solution is used mostly for finance. For example, let's say there are 3,000 jobs scheduled, and four jobs fail. That could mean millions of dollars lost.

It should be fine If they provide support within eight to 16 hours, but they typically take three days to get a response. That won't work because on the impact side. On the other hand, it's highly stable, so we are generally okay, but we still face some bugs every six months or so. When that happens, we expect a speedy response.

The initial setup was straightforward, but it gets complex when you start using it. It will only be complex if you're a new user. The total deployment time for the original and web version was about three months. That includes installation and testing. During the testing, we found missing features, so it took three months to set the solution up, configure it correctly, and test it. 

The personnel needed to manage and maintain the solution depends on staffing and scheduling. For example, If you are providing 24-hour support 365 days a year, you need six at the most. We need one person per shift, and we have three eight-hour shifts. Including backups, that's three to six people. 

I don't have any numbers about the return handy. We didn't renew the license, and we've already onboarded the other solution and started using it. It's costly and our companies are cutting costs. They consider this an extra cost, so we didn't renew for this year.

The license for Automic is around $7,000 per year, which is somewhat costly, but it includes enterprise support. 

I rate Automic Workload Automation eight out of 10.

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.

Our primary use case is automating and integrating different workloads and systems to populate data warehouses and different applications.

It allows us to free up developers' time from not having to set up environments, but actually using different environments. It allows us to have accountability and traceability of changes. It also allows us to be in the mainstream with what a lot of other companies are using, so it is easy to get a transfer of skills and be able to collaborate with other people in the field, because we are using a more popular tool. 

1. The modulation of some of the things, like how the things are connected and disconnected. You have different login objects that you can quickly put to other different objects and other objects that you create, which makes transporting things very easy from one environment to the next. 
2. I like the documentation that is out there. It is very good and the community that comes with it is really good. It provides a lot of different use cases similar to ours that people have for specific things which we can go out, look at, and receive some help on. 
3. It is very technology agnostic. It fits with pretty much all the different types of technology, different types of servers, and different other types of languages that we use; it fits in very well with everything.

There has to be a better way to visualize things in the application without having so many windows open. That is just an on its face type thing. If you get in deep into some of these processes, you may have 20 windows open, and there has to be an easier way to manage that. The actual components that they have are great. Just the presentation of it; sometimes I feel like there is too much on the screen and I want to simplify it. I want to get to the information that I need to without wasting my time trying to expand this window or trying to click this and do all that. So that is my one downside the tool. They need to figure out how to reduce the number of windows that you can have open. It is more of an aesthetic thing, but it helps your functionality out because you get to the crux of problems a little quicker when you do not have to surf through 20 different windows.

At my company, if there is a limit, we are going to find it. Everything has a finite limit. No matter what people tell you about any type of software, it is always a finite limit. However, compared to other competitors' software packages, this has been a lot more stable, but no software is completely stable. If there's a limit, we're gonna find it. Our company pushes the envelope when it comes to the data we process, display, and publish to our users, so sometimes we find those limits. Overall, especially since we have dealt with the competitor for a number of years before we switched over to Automic CA, it has been pretty stable. 

It seems very scalable. 

It is one of things, where there are a 100 ways to do something, and that is a good thing and a bad thing. You can do it the bad way and it will not be scalable, or you can do it the better way and it will be scalable. So, on its face, it is very scalable, but it definitely depends on how you implement it. 

They have been pretty good. We have had the professional services company uses some of the budget to bring some of those guys in to work on specific problems and they are very interactive and very responsive. 

I have not really had any issues. However, if there is a limit, we are going to find it. It does not matter what, and whose name is on the technology.

I was heavily involved in the initial setup. It was December 2015 that we had to migrate our entire workload automation suite of 1000s of jobs. We are publishing petabytes worth of data into this big relational data warehouse, publishings, all these different applications. We probably received 2000 files per week, and probably had 5000 jobs per week. Therefore, we had to migrate all that from one solution to another solution in 60 days. It was a contract thing that was going on, so we had to do it and I was heavily involved. We had some professional services people come down and we found out about it in mid-December and we were done by the first week of February. So, it was a heroic effort, but we did it.

I got brought in when they signed the contract.

There are some things that could be more intuitive in the tool. There is a lot of functionality, but the presentation of it could probably be better. It is a very powerful tool which allows for portability of code through different environments.

Get out there and research what the community is doing and different use cases. Take a look at the community and look at the feedback that the community is giving. It is a very user driven community. It is not driven from CA. It is driven from the users themselves, so I definitely go take a look at the user feedback, then think about the management and the implementation of this tool, which are very important. 

Back to the first thing, "There are 100 ways to do everything." Therefore, you have to come to a consensus on, "This is the way we are going to do it", and have some standards upfront, because it is going to be a harder once you get into it using the tool. With any workload automation tool, it is the backbone of your organization. Once you start using, it is hard to change. Think about the implementation and best practices upfront and listen to the feedback from the user community.

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.

Right now, we are working with version 10 of the product, it is very good. We are very happy with it. However, we have to upgrade to a different version and there are a lot of things that are different, and we are not completely convinced how it will work. 

Our normal functions, what we had in version 10, are lost or not there. So, we will have to see how it will work in the future. As a company and as a product, though, we are ready to upgrade.

It is a batch application. We have a daily batch that we have to start. This application controls the batching. So, this application is essential to our company.

We have a lot of places in Germany. For example, if there was someone in Munich who wants to send data to someone in Hamburg, it is very easy to do a production application safely and quickly, because we have everything in one system. We just do a file transfer. 

It depends for me as an administrator. There are a lot of features which help us get a stable application. It is easy to have a stable production line, because this app supports us very well.

I hope in the next release that they will solve all the bugs which they have found in development. 

I hope going forward they will make some changes to the documentation. I hope they will write into the documentation what has changed and what the new names are. For example, some features have a new name. I hope they will make a translation the names in the old version to the names in the newer version. This would be a very important thing.

Version 10 is very stable. We have no problems with the product. 

Some problems could happen in the future because the current version does not seem to be stable. There are a lot of things which could bring danger into the stability of our work process, because things have been changed, and it is not possible to work the product in the same way. We have to accept the changes, and we are not sure if our employees will be able to accept the changes in such a short time frame and perform them the way they should.

There are so many possibilities to be used from this product, and every company is using it in their own very special way. Though, I don't think every company is using it 100 percent for all of its possibilities. There are a lot of areas that you can go with it.

When I came to the company, they were already using Automic. They had been using it for a long time.

The complexity of the initial setup depends on the person who is performing it. It was okay for me, but I have some colleagues who have had some problems with it.

We have increased efficiency with this application.

I prefer this product.

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.

One key point for our selling is our business's dashboarding. It was something very important and we used it at the beginning very much. 

It is an easy product to use, and we can use it for end-to-end process automation. We also have the capabilities to do dashboarding, therefore we have an analytics product that can provide other things and value for us.

We would like to see more dashboarding into the product, maybe an embedded Java API which we would be able to load on our own objects into the system. We were writing them on our own, but we would like this standardized.

The system is a stable product overall. We did something maybe a little bit wrong at the beginning, so we had a little bit of an unstable product. Since we have merged to version 12, it has become a stable system.

It is a very scalable product, not only for Workload Automation, but also for the other products provided by Automic or CA Automic. You can use the baseline, the automation engine, and scale up what you need.

Technical support is excellent from our past experiences with Automic. At the moment, we are facing a few issues with the merge of CA and Automic. We hope these will be resolved soon.

Our old solution was not able to deliver a real end-to-end automation. It was embedded in SAP. An excellent product for SAP so far, but it is not able to be scalable for the end-to-end. 

This was the reason why we did research at our company to do an end-to-end product assessment. In the end, the decision was to made to go with Automic.

During our PoC, I was the guy who was implementing and installing the product. I thought with the help of a consultant that it was an easy installation. 

On the shortlist, when we purchased the product, we had CA, Stonebranch, BMC Control-M, Automic, and our current vendor in mind. A few of them were kicked out during the first session because they were not able to deliver everything. In the end, we had BMC and Automic.

I would like to rate it as an eight out of 10, because there is room for improvement, and I would like to see this from Automic. They should continue to work on the product to improve the product.

If my peers are looking for a real end-to-end solution, not only some siloed solution, they should go for Automic because it is an easy product to use. It is easy to install. I can recommend this product to other customers.

Most important criteria when selecting a vendor: The partnership between a vendor and customer is very important. You should have a good account manager in place who is dealing with the customer. This is something very important for us. Customer service and support are also important.