Automic Automation Reviews

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. 

We use it to automate our business processes. It is just for automation and scheduling.

We have worked about 20 years with this product. We have migrated for 20 years from CA to Automic. It is very interesting. Now, we are back to CA, because they have taken over the Automic company. The benefits also include the automation of our processes. We have worked mostly with SAP software, and we have other things in our plans. We want to automate the distribution of servers, so clients can make a request from ServiceNow. That way, companies can order servers on the internet that we normally we would build during the process for internal use. Because developers sometimes need a very fast machine for testing, you can click in ServiceNow to request a machine after two hours, then you can have a machine to plug into. At the moment, we have tried to make this a digitalized process, although we have a problem with ServiceNow.

It is easy to integrate different systems in one platform, then to automate it. You have a job, then one part of the job is going to the SAP system, and the other one is going to ServiceNow or to another system. Then, they all combine into one process.

The very special feature that we use is the connection to ServiceNow.

It does not have the same functions as the old version, which makes our developers angry because because they must work with this tool. We going forward it may not be possible.

CA has missed the product's focus. We have a lot of developers in our company, and we are experiencing the same problem. However, the CA company has not seen that developers and clients are having a problem, which is not good for the product that we do. CA took over the Automic company last year, and we do not think this was a good direction for the product.

I would like to see the rich client with the product for the developers.

It is more important for us to have a longer, stabler releases. We do not need so many features. This is a problem of bigger companies where the management wants new features, but the product has no stability after that.

It would be good to have a mobile app, where you can monitor your process, just to see if it is running or if it is blocked. The user interface on the web is not good for the developers. Features are missing, and for the client, it is too complex. At the moment, we build our own UI. We have programmers in Java API, and we have a Client which works on the mobile phone. It can start jobs, make the schedules stop and start, and see the statistics on a smartphone.

We have had issues with the performance. We have a job now in production, but the product is not very stable. ServiceNow creates problems with the Automic entry of the connector, so the stability could be a little bit better with this product.

Sometimes, we have some performance problems. I am not sure it is because of the software. It might be because we have a huge amount of objects in our system. In this case, it can happen that we often have performance problems. I am not sure if it is because of the product, it is more because of the objects in our system.

Because the product is based on the SQL Database, we have too many activations. The scalability is limited by the SQL in the background, and that is a problem. If you want to take jobs to other systems, you must build the developer our way. At the moment, we are building a new system. We have it for every country and have separated it for machines. It is mostly getting better, but the scalability to build it on new systems or to split it is not so easy.

We have technical support. We also have a connection in Austria with the support colleagues there. 

The first step: You must describe the problem. At the most, filling in a checklist.

Then: It helps to take the telephone, and talk to a technical engineer directly. 

That is why their technical support is very good.

Mostly, we contact support because our problems are very complex. Normally, we find problems that they have never knew about before. We have new technology and build actions on the automation system, then we find objects which can work with those actions, because we have technical limitations. 

We have a contact within the support, and also with a freelance in Austria. We have worked together with several people to find a solution for this new philosophy. Automic states you should build everything with actions and take multiple actions with business processes. However, not all objects are usable for actions that we see.

If you would have to start all your jobs manually, it would cost you a lot of time and money.

You do not need any humans to start jobs, so you can save a lot of money.

From the bad products, the Automic is the best. All products in the market are not good since they are simple workload scheduling. There are some things are missing in the Automic product, which our management does not see.

I would recommend using Automic.

The primary use case is to automate jobs which run at night on SAP, Unix jobs, and Windows. It has performed well.

It has improved the way my organization functions, in terms of efficiency, time, and costs.

The night processing helps to have data just-in-time for the morning. It is also very important to have the possibility to create incidents or emails if there is a problem, so operations can investigate and do something.

At the moment, we are only using the workload automation and the job scheduling. I think there are more possibilities to automate and connect them to the whole business process.

The most valuable feature is it always runs things automatically that you normally have to do manually, like download files. We also use the FTP agent, where you have to download and upload files at a specific date.

The only thing that we would like improved is the FTP agent. It only supports SOCKS proxy, and we would like it to also support an HTTP proxy.

We would like the feature to implement the privileged access management. However, we have heard that it is already supported.

It is very stable.

Technical support is very good.

We had a previous solution. It was Control-M. We switched because there were some issues around the costs. Automic's costs were lower.

We had some consultants when we started with it. They gave us an introduction and training. We also have training every year at CA Automic in Nürnberg.

We did not evaluate anyone else for job scheduling.

Most important criteria when selecting a vendor:

• Support
• It is a fast solution.
• The product minimizes downtime.
• Good reputation.