Stonebranch Universal Automation Center Other Advice

Sr. System Programmer at a retailer with 1,001-5,000 employees
If I were to go to another company, this would probably be the tool I would push for. It's a very sound product. I feel Stonebranch is on the technical edge. I've been to a couple of their conferences. They are going into areas and blowing my mind with where they're going with some of this stuff. They're trying to stay on top of the cutting edge. When you go to their conferences, you hear how other people are utilizing the tools. Something might spark a concept, where I say, "Maybe I can do that." We use ServiceNow as our problem management tool, so I'm trying to automate tickets to go into that, but we haven't made it that far yet. We send an email on every task failure over to a public folder, and that's what our operations team copies and pastes. Then they update another gauge in our dashboard so they know that somebody's working on that. Then we have some warning issues. We have things that go into define states, because they could be a sub-apple of a main workflow. Or we have workflows that stack up behind each other because they're the same name. We use resources to control everything. If we do have a maintenance window, I'm using a resource to set it to zero, so any workload coming in after that is waiting for our operations team to release or get the okay after a maintenance window has been performed. I'm the primary for the maintenance. I have a backup, but he's more my MQ guy. I support MQ as well. I do all the maintenance and controller, so it's one person primarily doing it all. We have three production-control people who do batch scheduling, for new schedules, obsoletions. They reverse their procedures every week. One's doing scheduling, we have one doing user-requests, ad-hoc requests that are coming in on a daily basis to insert into the schedules to run. We have a schedule that we call Production Control and that's where all our user requests go; users who want to run this or that today, that's where they would insert it and run it. We have about 120 users. They include our DevOps team. We used some business services to lock down some of their pseudo test schedules. We run a production internet environment, and the data that comes out of that actually goes into our development environment, for their testing. We use business services to lock that down. They have eight people who can update tasks, create tasks, etc. That's the only place we're using business services. We have seven groups. The Administrative group and the "Everything" group comes with the tool. But then we created seven more groups. We strayed away from the default groups and made our own. We have ops-wise-admin, which is the administrative group. We have an ops-wise-all group, which is just readability. Somebody can get into that group and they can see ops-wise, they just can't make changes. Developers is our biggest group. In production, they only have read access, but in our development areas they have full-blown access. We manipulated the permissions to help control production over development. Ops-wise-IT is another group similar to ops-wise-all. I don't know why we had to have that one to give IT some extra abilities, but that's what we did. And we have an operations group for our system operators. They have capabilities to restart workload based on a programmer's request, a plan of failure. They can make modifications to the active instance, but they can't make modifications to the definition. That's how our change control comes into play. Product control has the same access as ops-wise-admin, but they just can't do upgrades. In terms of the prospect of increasing our usage of the solution, we're looking into the cloud situations, but I haven't been asked how to go that route. Doing it would be a matter of putting an agent out there in the cloud world. Security is the biggest hurdle for me, sometimes; trying to get access. Some of our servers are behind firewalls. It's usually a matter of talking to the right people to get the job done, but I probably have seven agents that are behind firewalls and working just fine. I run four controllers, but I have six in place. I have two that are high-availability. We were struggling and this is probably an issue with Stonebranch. We had developers who were making changes in our test and development areas, and then we would promote them up to production, but we started having conflicts with sysids. What would happen was that a developer would make a copy of what he wanted to change, and he would go back and rename the original task to "old" or something like that, and then rename the new one to the originally named task. The sysids were now out of sync. Sometimes they would bundle up okay, but once we started seeing a larger volume of them, we started having bundling issues and failures. We elected to go with what we call our change-control environment. It's almost a mimic of our production environment, but now our production control team actually updates the original task upon request. They make the changes in their development and then they submit a change request to have this copied into production or updated into our change-control environment, so we can keep the sysids from getting out of sync. Sysids were probably one of our bigger hurdles, after the fact. There are no agents running on our product-control system. We variable-ized all our agent definitions and we variable-ized all our credentials. With scheduling, if you hard-code the agent name or the credential, it will actually bundle it up like that, but if you variable-ize them, you can keep them unique between the two systems. In production, this is a production credential, but in test they use an LE-dev credential name. When we go to move that up, it still thinks it's just LE, because we variable-zed it. Especially when going to a new server - if they want to rebuild a whole new server - all I do is install a new agent as "_new," and the alias name will be whatever, and then, go-live, I just swap the names and scheduling isn't impacted at all. It's pretty sweet the way that works, using the aliases. I can remember with ESP, we had to have tons of schedule changes and agent name changes to the new one, whereas ops-wise took a lot of that away with the use of variables. View full review »
Earl Diem
Manager Performance and Automation Engineering at PSCU Financial Services
My advice applies to the implementation of any automation platform. Have a solid plan for what your approach is to automation and develop a common approach to workflows. That is what we did. We took a step back and looked at what our workflows actually do. We really only have four fundamental workflows so we built templates for those, and all but a couple of our workflows fit into those templates. So analyze your workflows, understand what they do, build templates to do that, and then go off and do the automation once you've got the templates built up. I'm not getting any complaints from my automation team about the platform. The guys are really happy with it. I really haven't spent a whole lot of time in the Stonebranch Marketplace. We looked at Stonebranch's file-mover product for internal file movement in our workflows where we're moving files. We did a PoC with it and we decided to go with another product. We have three managed file-transfer platforms in our enterprise. The biggest one that we move most of our files with is IBM's Sterling File Gateway. One of the biggest challenges there, when you're moving data across the enterprise and doing workflows, is managed file-transfers platforms. They drop them in in the landing zone where processes will consume them. What we found was that those files were just sitting there waiting for somebody to manually do something with them. In the meantime, we've automated all that. We moved it from the landing zone to a retention zone where they sit in tier-two storage for 60 days. We then move them off to the data domain, which is tier-three storage, archives. The automation really helps slow down the eating up of tier-two storage platters at $40,000 a pop. Everybody's has this problem, but we've automated that process. We've even automated deleting those files off of tier-three storage and realized a savings with our Storage Spend. We have an automation team of three employees. We have another six members of that team who are offshore contractors. We have four users and the analytics team which are actually doing workflows on their side as well. The way that works is that we have a dev, a test, and a production environment with Stonebranch. We have a Controller running in each of those environments. The analytics team builds its workflows up in dev. We do basic testing there and then push them to the test environment where the automation team makes them work. Then we push into production. We're mostly working with the analytics team, the dev environment, with them developing their triggers there. For deployment and maintenance of the solution we need three people on the automation team. View full review »
Senior Technical Analyst at a financial services firm with 10,001+ employees
Look at also having the database solution be HA as well, because the product is highly available and you can stretch it to also be your BCP where you just fail over from one data center to the other. We suffer because our database solution is not. I would urge everybody to go down that path and set it and forget it. If you lose a part of your data center, this thing will stay up. The universal task is something that we started dabbling with. We haven't used it fully yet. We don't rely on the Stonebranch Marketplace a lot. It was something that we discussed with Stonebranch over a period of time. It's something that we, as a culture, need to look into internally as a company. We tend to trust the things that we write, versus looking into things like a marketplace where we can extract thoughts or automation or universal tasks that other people have put out there. If it breaks, we need to be able to call somebody when it does. At last count we had around 650 defined users, and around 50 logged in at once. Right now, to do the scheduling and maintain the environment, it's two bodies, and we have one to help support the file-transfer piece. Those three bodies are responsible for administrating the environment. If somebody needs to be onboarded, that's all automated. You come in, AD groups are created, the security stuff is in, it's all automated via ServiceNow. All that those three guys do, from an admin perspective, is troubleshoot production issues. If something breaks, the app goes, they sit down with the application and explain why it broke. The other roles that we have are operators, schedulers, and the read-only users. The applications are broken into dev and production teams. Dev teams usually have access to schedule and promote to production. Operators only have access to production, and they do the operations role. The scheduler basically has read, write, delete, update access to everything. The operator only has that access on the tasks so operators are able to rerun, stop, that type of role. Those are the four roles that we have defined. I would estimate that ten percent of the business uses this product. Are we going to expand it? Anybody is welcome to use it. It's slowly growing by itself. As soon as you mention the file transfer solution to people, they say, "Okay, I'm on board. Let's go." Are we going to make it a strategic tool that everybody has to use? It's just one of the many tools that we have in the toolbox. I think within our organization, we probably have in excess of 500 tools. I would rate Stonebranch at nine out of ten. I would never give anybody a perfect ten. I always want people to work harder. I'd give them a nine because, if you deal with all the other vendors, you're used to a sales guy coming in with an agenda - that he needs to maximize the sale. I didn't get that from this vendor. It was very weird dealing with them because all the other vendors act a certain way, except them. They show up, very transparent, very honest, and they're always willing to negotiate. View full review »
Find out what your peers are saying about Stonebranch, BMC, IBM and others in Workload Automation. Updated: February 2020.
399,757 professionals have used our research since 2012.
Frank Burkhardt
Application and Database Administrator at Blue Bird Corporation
It is a really great solution if you have your jobs and tasks well-defined and know what they are doing, It's a good solution for allowing you to shorten the windows between tasks. However, you need to get your back-end straight before you can start using Stonebranch to its full advantage. We had planned on doing all this stuff with workflows, but it turns out a lot of people don't really know why we run jobs at certain times when we do. So, we are having to rediscover that before we can take full advantage of Stonebranch. The Universal Controller is very nice. It was sort of a foreign concept to me. It broke things down a little differently than I was used to or expecting. I come from a background where I used cron a lot. Therefore, I am used to the idea of scheduling jobs. However, with this product, everything was so interconnected with good error reporting. It was just a little new with a learning curve. It seems to be very capable, but it took a change of mindset. As long as you're using standard Unix or Windows Task Scheduler, compatibility with other vendors is fine. It does not interoperate well with proprietary scheduling systems used by other groups. We have Crystal, which might have some problems interacting with them. There is some other proprietary stuff that we are really working with Stonebranch on trying to get a better interface with. However, as long as you're using standard out-of-the-box Unix or Windows Task Scheduler, this solution is rock solid. View full review »
Mike Booher
Systems Programmer II at a insurance company with 501-1,000 employees
Try it out, get to know the product and see how it works. We have two system admins or schedulers, master schedulers, me and my co-worker. In our test and dev environment, we have four staff involved, counting me and my co-worker. Since everything was cut over to production and stabilized, we have had to spend about ten hours a week on it. We have operators monitoring it 24/7. I would rate it at nine out of ten. I work with it every day and it does what I need it to do. I can't think of anything off the top of my head that I need as an enhancement at the moment. View full review »
Doug Perseghetti
Consulting Systems Engineer at a healthcare company with 10,001+ employees
If you're looking at this or a similar solution, get with a company that's done it before. We have consulted with other companies and helped out a number of them to go to this solution. We've already done digital transformation, so Stonebranch is part of our continuous improvement. I'm not going to say it's transformational, it's just continuous improvement, using our tools to exploit them for the betterment of supporting company goals. In terms of the solution's users, we have people who build things in order to use it. We have a core of about five people who set up workloads to use them. They perform somewhat traditional scheduling roles. For deployment and maintenance, we do it all with those five. The agents are a ten out of ten, the Controller is a nine. The agents are top-notch, Controller has some room to grow. View full review »
Application Manager at a insurance company with 10,001+ employees
No additional comments. View full review »
User at a insurance company with 501-1,000 employees
UAC is a wonderful product, and as an end user, I would fully suggest looking into this product. View full review »
User at a financial services firm with 10,001+ employees
Keep up the great work and awesome support! View full review »
BI - BO Data Services Architect with 1,001-5,000 employees
Charvi Sharma
Technology Analyst at a retailer with 10,001+ employees
Find out what your peers are saying about Stonebranch, BMC, IBM and others in Workload Automation. Updated: February 2020.
399,757 professionals have used our research since 2012.