Automic Workload Automation Review

The scripting language makes an already robust tool incredibly flexible, very powerful


What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How was the initial setup?

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.

What other advice do I have?

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Add a Comment
Guest
Sign Up with Email