Automic Automation Reviews

To automate our processes, they run on batches.

Performance has been very good, actually.

Having automated, real-time notifications. If something is not available it's automatic where or whom to notify. And it's continuous processing.

There are a lot of ways it helps us, especially on the operations side, that it doesn't require manual intervention, that's one of them.

Ease of migration to a newer version.

Regarding stability, so far it's working fine with us.

So far scalability is good.

It's rare that we use technical support. Usually we take care of it, and if support is required they're able to get back to us right away. We're satisified with the support.

Straightforward.

It works for the company, so far. Most of our team is familiar with it, so I think we are going to have it for a long time, which is a good thing. 

It's not the only application that we have, we also have the other version. I came from a different company that ACI bought, and ACI had the other version of the Automic Workload Automation. So now we have two, they have the operations manager, we have the application manager.

In terms of looking at vendors, what's important is the reputation of the company.

I gave it a 10 out of 10 because, so far, I haven't had an issue with this product. And it works for the company.

If you need some automation, especially in batch processing, it's easy to handle and also the support that they provide is excellent, so I don't think you are going to have a problem with it.

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. 

Our objective is to sell this product in the name of CA, as we are a CA partner. We are trying to develop this new solution and provide it to our customers.

It will increase all delivery due to an impact on efficiency, in terms of time and faster resources.

Time is improved because somebody does not need to tell you that they are finished for you to start. In terms of personnel, you can use less manpower resources, and this is good for the business from a cost perspective.

The most valuable feature is that it can be installed on any type of application on every kind of operating system and the agent can use it on these applications and systems.

I would like more training on workload automation, because I do not have a complete insight of the product yet.

The user interface could be a little more user-friendly, as it is not the best out there.

It is very stable. I have set up a personal environment on some virtual machines, and it was very smooth and fast. Thus, the performance is very good.

It has zero downtime, which is very good. This is impressive for anyone who wants to use this solution.

I have not tested scalability. From what I read, it has a very high scalability without downtime. 

The techncial support is very good, because I had a problem with an agent not being updated, and it was not starting. Therefore, I was having some problems, and the technical support immediately understood the problem, and helped me to resolve it.

The initial setup was quite simple because they have a manual which tells you in a simple way of how to install it step-by-step. Therefore, I didn't have any problems. You do need to have a background in operating systems, then it is not so difficult to install.

I did the initial setup myself.

CA was the only vendor on our shortlist.

We are a partner of CA technology. They let us know that they wanted us to invest in this product, particularly in Italy, because they work in Italy. That is why I started to learn this product.

Most important criteria when selecting a vendor: 

1. The brand.
2. Ease of use.
   

We use it for simple job scheduling, mainly for SAP. Two to three parts are for SAP, job scheduling, and smaller and larger workflows. It performs well.

Our customers appreciate it mostly because it takes a lot of effort away from them. You can trust the system. If the system works well, the customers are satisfied. 

Most of our issues are related to the system, not the job scheduling, such as, bugs and unexpected downtime of the application or database.

Content of file transfers cannot be searched by the system, but has to be done by the user interface. This is not good, as it has been erased often.

One of the previous bug fix issues created new bugs, which was not good. 

The main part of it is stable, though.

It is scalable. We can grow it out.

We use the technical support often. 

Our recent experience with technical support has not been good, because it took a couple of months to get feedback. Traces and reports were sent, but were not analyzed for at least two months before providing feedback, and they did not give the right traces. This took two months to find out, so that was not too good.

Primary use case is for scheduling of our LCM, our Loyal Customer Mailers. Mailers go out with coupon packets for different households. Automic is used for scheduling all of the jobs that build those mailers, and send them off to the printer.

Performance-wise, we do run into problems sometimes, because we've only had it for about a year and a half. We're still working out some kinks as far as performance goes. But overall the performance of the tool itself has been pretty good. At first, it was a little bit slow, but we've worked out a lot of those performance issues over time, it's working a lot better now.

For me the biggest one is flexibility. It allows you to do so many things on so many different platforms. We have an Oracle shop that runs off of Oracle packages that are executed from Linux boxes. With that, whatever platform it touches, it can allow you to do so many different things. We can take the power of Linux, the power of Oracle and, inside Automic, we can just build our own little packages, and our own little toys, to go out there and do things.

For instance, one that I'm working on right now is to build test data to run extracts against production data. To build smaller tables, subset tables, for the development teams on the test side. It's a little bit like building my own version of TDM. But Automic allows me to do that, and to be able to schedule it, to go out on its own and do copies of these tables, on a regularly planned schedule. It makes it very powerful.

Number one, A+, is the scripting language, and the ability to go in, and take an already robust, consistent, strong tool, and turn it into an incredibly scalable, flexible tool, that you can literally do anything you want to with.

Back in the old days, I would think, "Okay, if I need a specific job done, I would think, what type of Shell script, or maybe a Python program, would I have to right to get this done?" Now I can do everything inside of Automic itself, using Shell scripts, or using the Automic scripting language itself; makes it very powerful.

A problem we've had is where file transfers are being kicked-off from one server to another, without us doing it. It's something internal to Automic that's doing it. And it is costing a little bit of performance, and it's a time issue, on the zero client. But otherwise, it's not affecting the other product issues.

I would also like to see a little bit more connectivity, more, "Play nice with other toys." For instance, we have IServ as our primary tool for our service request tickets. In order for it to play nice with Automic, we had to actually create a file and put it somewhere, where Automic can see it. I would like to see more connectivity with other tools, or more compatibility with other tools.

A little less button clicking, in the navigation of the tool itself would also help. There is a lot out there, and I understand that's what keeps the tool robust. It keeps our options open, but it's a bit click-y sometimes. To get where you need to go, you have to go through 10 levels.

The stability of the tool is fantastic. In the year and a half, it's really only gone down a couple of times. The tool itself is very stable.

What's nice is that it splits it up into clients. We have our own client where we do our own work. We don't have to cross into the path of other people; they can do their own work on their own client. From an organizational standpoint, that makes it very easy to use. The stability of the piece itself, has been proven pretty well.

The scalability is out of this world. We're a shop that has about 40 clients. When I say "clients", we have our own group, our own area to work in - production - and a couple of test environments. That's three clients. We've got about forty or fifty clients in our company. Different groups have their production, test, and development areas. But we can scale that out to 300 or 500 clients if we need to, without changing anything. It's a logical division, not a physical one.

The scalability of the tool itself, is really fantastic. It lets you work in your own silo, and you can have as many silos as you want.

We changed out from Chronicle to Automic in 90 days, without a single outage to our business. That has never been done with Automic. The Automic people were even saying, "How the heck did y'all do that?"

But we had some people from Automic, this was before CA bought them out. Some guys from Automic came over to our site, stayed in Cincinnati for a couple weeks, to help us with this initial setup, because it was such a time crunch. We had 90 days to get it in, and we had to pull the switch on Chronicle, or else it was going to cost us $1.5 million. It was a big time crunch, and they helped us get it in, get it working. We did not have any outage, we did not miss any Loyal Customer campaigns. Nobody missed the coupons because of our switch to Automic.

In terms of selecting tools, the important criteria are 

• the fit of the tool
• cost of the tool
• support of the tool. 

That's the one, two, three I think everybody would answer.

Do the demo, and don't be scared of the Automic scripting language, because it's easy, if your team is technical at all. It's good to learn, it's easy to learn, and it just makes the tool explode with possibilities.

We use it for scheduling our batch systems and interfacing with our developers and our test systems.

It has performed very well. We've had the product for a number of years, since 2013, but before that we had another product called AppWorks for a dozen years or so. And then AppWorks was acquired by Automic. We keep moving up.

The new release is web-based, so that's a big, big improvement. A lot of our products that we use right now are going to that platform.

It's easy to train other people. A new developer could come in and learn it very quickly.

Better escalation process for alert notifications. When there's an error or a problem, the automation part of it could be easily programmed to escalate it up to the developers or whoever is going to work on it. We had to home-grow that within the product because third-party products are so expensive. Having that would be a wonderful improvement.

It's super. It's solid. Never goes down. For me as a user of it, it's solid.

We have a lot of legacy systems and we're implementing new systems and applications to take over the old things. We're an insurance company so we have claims, and policies, and AP, and financials, and payroll. Old systems get old, and as we're implementing new systems, AppWorks or Automic now, just fits. It's just the best there is, so, it was a no-brainer. 

We had such success with AppWorks. And then we went to this big RFI to figure out what we were going to change to because we didn't want to upgrade AppWorks anymore. But the success that we had with AppWorks - and then when Automic bought it - it was like a no-brainer. We would just go with them.

It was good. We had customer support who came onsite to install it and to train everybody and I was right there. It's mainly a product for our department, and then, as an administrator, we assign everybody, all the users and train them.

The whole thing is just a great product. We're really happy with it. 

In terms of selecting a vendor, I'm not the one who does that but they go through a pretty extensive process of looking at the cost, the reputation. I would think it would be a combination of things including reviews. Management takes care of that stuff.

Do your homework. Do your research. The product we have is the best. I don't know what you can afford or how big your company is, and what your needs are. It might not fit into every company, so do your research.

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.

You gain a lot of time and effort because you can automatize many things. Repetitive tasks costs us, so we can reduce them to zero effort and minimal costs by using the product.

The most valuable parts are the scalability and flexibility, where you can do whatever you think, then you can realize it in the product and have many ways to do it. So, there is not one road you can take, but many roads.

There is one missing part in the product concerning recurring tasks. You can schedule a recurring task by a context action, and run it as recurrent, but it creates a time container which can be quit and disappears. So, it doesn't remain in the system. I would like there to be some time container objects which exist and remain in objects which you can also handle and add. For example, inside the schedule to be able to schedule recurring tasks.

This is a very stable product. When it comes to a new release, you sometimes have to be a bit more careful. For the rest, it is very stable. Over the years, it has also become more stable.

It is very scalable. You can use it for a small or big company, so it works in both cases, and also with little or big development teams.

The technical support is very available and competent. They have a lot of know-how, which they are willing to share. If you have big issues, they will quickly help you.

In the beginning, we used a banking solution which was running on one platform. It was AS/400 at the time. We were changing the banking platform so it moved to a new platform. The old scheduler did not exist for the new platform. 

Additionally, the new banking solution needed an adapter, so we also needed a solution which could interact with this banking solution. We had more satellite systems, so we also had to handle the planning between different systems and the old scheduler, which was one platform based and it could not handle it. That was the initiative to choose a new scheduler.

Implementing the solution in 2009, the setup was easy (straightforward).

Other parts, meaning implementation of all the processes, this was very complex. We had to think about steps, like name conventions, standards to introduce, common objects the users should use, and the training that users should receive about how to use the product.

I would rate it as a nine out of 10, not the best one. It gets a minus one because of the new web interface, because it is not so easy to handle nor is it intuitive to use like the old one. As for the rest, you can do everything you want. It is scalable, flexible, and it does what you want it to do.