We use this solution for automating the workloads of an application. For example, if an application in an organization has a lot of manual tasks, it can be automated in a batch with the help of Control-M.
The solution is deployed on-premises. Helix Control-M is cloud-based, but most of the companies that use Control-M deploy it on-premises.
MFT is one of the most valuable features. There's another feature called Workload Archiving, where the data for all the jobs can be stored for however many days that we want, which is very useful for any historical analytics.
There's a feature called Workflow Insights. There are eight different kinds of dashboards in Workflow Insights, but there could be more because there is third party software that provides more dashboard styles.
I have worked with this solution for about 12 years.
It's very stable. It's the leading workload automation tool in the market.
It's very scalable.
I have used customer support from the BMC. There's also a community that has a knowledge base for all of the possible issues. When we can't find the answers, we use technical support.
Setup is straightforward.
Deployment took about three months because we had to plan the infrastructure.
We did the implementation internally.
The license is paid yearly.
Apart from the standard license, if we avail any additional features, there's an extra cost. For example, Workload Archiving is an additional feature from the standard product, so we pay extra for that.
I would rate this solution as eight out of ten.
I would recommend this solution to other people who are interested in using it.
I've been with the same company for 22 years. The use case started out truly as a batch processing solution. That was what we originally got it for back in the day to help us automate what was being done manually or being done through homegrown tools or scripts, et cetera. The use cases evolved through the years. Now, we use it to orchestrate workflows that are touching traditional data centers and that are going out to the cloud and bringing it back.
From one spot, we have a single pane of glass. Like many companies, our systems are getting more complex and more diverse, with cloud and edge computing, containerization, et cetera. However, we have one place where we can go and look and see what's going on. If something happens, we can check what happened and where it happened. Today, we're dependent upon a lot of services and cloud technology that sometimes we don't know the ins and outs of.
A big challenge is to make sure that we have certain things run daily or on a periodic basis. That really was the driving use case. We had a lot of manual tasks going on and if someone, for example, left on vacation, something may not get done for two or three days, a week or two weeks. This solution takes all that away.
The main use case was to get away from having to stare at a system or a screen, and just let things run, let the workflows flow, and only be notified if there's something wrong. That was really a big driving use case.
It freed up people to work on exciting work instead of mundane work. No one has to sit around and stare at that screen all day long. No one has to reinvent the wheel for the 50th or 500th time to do tasks like maybe put a file out into an S3 bucket or out into an HDFS Hadoop file store since it's already there. It's already done for them. They just drag, drop, click and they're done. It's freed people up and they can do the exciting work that is really what we should be doing anyway. No one wants to be doing boring work.
I am a big proponent of an automation API and Jobs-as-Code. That is Control-M in the DevOps world. It opens up the tool to a traditional operations tool. Developers can jump right in there now, giving them that ownership, and integrating the existing DevOps tools that they have. That is a huge feature that I just love.
There's an application integrator. It doesn't matter if you're trying to integrate with on-premises, off-premises, API, container, or serverless functions, it's easy for you to design. You just design that integration and then it's available instantly, and that's a huge time saver.
It's rather easy to create, integrate and automate data pipelines with Control-M. I can give a broad answer. It can be as easy as drag and drop, or it can be as complex as designing the integrations. If you use customization, you can access a data lake that your organization developed. For the typical user out there, the difference is on a scale of one to five, with one being easy and five being hard, you're probably looking at a two and a half. For most people, it's very easy. It's getting easier as it's all web-based nowadays. Alternatively, it can be all code-based.
I have not explored Python Client too much. I've tinkered with it and that's been the limit of my exploration. Now, with the integrations like AWS, we've made extensive use of it, and it is very easy for anybody to do. Python Client has a lot of great possibilities, especially in the data science arena, however, sadly we have not had an opportunity as of yet to play with it.
The Control-M interface for creating, monitoring, and ensuring delivery of files as parts of your data pipeline has gotten better. It is not perfect. That said, it’s come a long way over the years. Nowadays, most of it is web-driven. A lot of it can be API driven if you so wish. There's still probably some future work to be done there, however, for the average user that's coming in, starting to use it for the first time, they're going to need a little training and handholding at the beginning for maybe the first week or so. Then you can start setting them free to go out and use it on their own.
The orchestration of our data pipelines and workflows has been able to give a single point of view too. Management doesn’t care about the bits and pieces. A workflow or a data pipeline could have 100 or 1,000 components behind it, and management does not care about that. Management cares whether the SLA has been met or not. They want that easy-to-see red light or green light. We can provide them with that. The solution drives self-service and it helps. A manager doesn't have to call somebody in IT and wait around for an answer.
They can immediately get that information for themselves, consume it and be able to understand that, "Hey, you know what, this data pipeline over here, we're going to be 15 minutes off our SLA for today." Then, they can start asking why. I like parts of Control-M like Batch SLA Impact, is they can start doing some of that analysis themselves, for example, “this late due to the fact that maybe the system was down for maintenance for two hours last night." That's really beneficial in today's business world.
The automation of Control-M has sped up everything. We can integrate directly into existing pipelines and the DevOps teams can get anything integrated with their Jenkins deployments. They don't have to wait for traditional operation functions. This is all built-in. It validates and checks. In some cases, it automatically deploys the agents and deploys the configurations. That's something that years ago you'd have to wait for. The speed of delivery has vastly improved.
Nowadays, auditing is as simple as running a report. If this falls under an auditable category, we can just hit a button and the report is done. Control-M audits everything, even if it is not under the regulatory or audit spotlight. Every process, every movement, and every change is logged by the system. If there's ever a question, you’ll be able to find a why and a when. There’s an audit trail.
It certainly helped speed processes up. I can eliminate what I call the manual gaps between certain features. I don't have to send an email to somebody to say, "Hey, guess what? That file's ready. Now you can run process X, Y, Z." The system just says "Hey, the file is there, let's go." It's eliminated those gaps between parts of the workflow. It also helped optimize the infrastructure needed as it's like a Tetris Puzzle. I have these ten different workflows that I'm trying to run and before I may have had ten dedicated systems for them. Now I know that I don't need that.
We use this model all the time. We can run those ten processes on three systems and be just fine. That saves money. The solution is not only speedy, but it also saves money.
They are doing a great job with continuing to drive the open-source model of it. Five years ago, if you looked for Control-M anywhere, you would not have found it. Today, that model has changed. They're actively publishing on GitHub.
You can download for free an entire container and run Control-M at home if you want to tinker with it. That was unheard of a few years ago. You can type a query in Google and start to see all sorts of documentation that is now available to the public. The major strides that they have made there are pretty darn good.
If you want to take it and ramp it up to doing some very heavy-duty integrations, you can find yourself at first dealing with a difficult integration. However, once you get that integration going for maybe a month or so, the next person after you will have less difficulty. That's the power.
They can improve their interface. They're going through huge modernization efforts and they're getting there. They're probably 75% there, however, there's still another 25% to go.
I've been using the solution for 22 years.
Since it supports business, it has to be stable. It's very stable. We have not had major outages or anything. That's always a good thing, however, like with any solution, its stability is going to depend on how you deploy it and what safeguards you put in place, including high availability and disaster recovery, et cetera. All the hooks for that are in the product, however, it's up to you to decide how you're going to use those hooks.
It's highly scalable. You can run five things in it today and easily scale up to run 1,005 things tomorrow. In terms of scalability, there are no issues there.
Technical support tends to be very helpful.
Positive
I used to work for an insurance company and I used Computer Associates. It was called CA-7 and CA-11, which are similar tools.
We tried to use Computer Associates before this, but it didn't support the systems we needed and the integration was next to impossible.
I was involved in the deployment and initial setup of the solution right from the beginning.
We had jobs and workflows running within the first day. That was pretty good. We don't use the Helix model, however, there is a Helix model you can purchase, in which everything's hosted by BMC. You can be up and running literally in hours which is reasonable. There's a learning curve, however, if you do not get some value out of it within two days, you're probably doing something wrong.
At the time, there were only two of us deploying the solution. Today there are only three of us.
It's business-wide. Everything from data to marketing, to finance, even though it probably wouldn't make sense to anybody else, it touches everything. It's deployed across Windows, Linux, containers, VM, cloud, et cetera.
If anybody has a use case or wants to learn more about it, we'll show them. Anybody in our organization can get basic access and can tinker around in an alpha test environment. This includes non-technical people. We have non-IT people that use it.
If they can self-service and maybe design some parts themselves, that's a huge win right there. We have a very open model of deployment.
There are occasional patching and vulnerabilities that come out. Most of the patching nowadays can be automated if you're using the Helix-based solution. A lot of that is handled by BMC.
We did not use an integrator, reseller, or consultant for the deployment.
I can't speak to the exact licensing costs.
Every few years we go through a reevaluation. We'll go through and look at what's on the market and what companies have come up with or released new versions. We'll go through and we'll say, "Okay, let's compare these, what do we need and what are all the tools offered out there?" We do that roughly every five years and it keeps us on our toes.
The biggest difference as of late is the API and Jobs-as-code. Control-M is light years ahead of others. It is light years ahead of the competitors and what they're offering. Other competitors are starting to get APIs, however, only BMC is working with Job-as-code and is in the lead. To my knowledge, they're really one of the only ones who can define your entire workflow as code.
Control-M is pretty critical to our business as it runs many different business processes every day, and if it wasn't there, we would probably hire many more people, be a lot slower, and be more prone to error.
We use a hybrid deployment. We have parts in the traditional data center. We have parts in the cloud. We sometimes have parts that live on containers. They only exist for two minutes. It is very much a hybrid mix of goodies with our deployment.
I'd advise potential new users to examine it today and not think about what it did ten years ago. Control-M is an old product. It has been around since we all used mainframes, however, just because something's been around for a long time, doesn't mean it's a piece of junk or doesn't work with modern technologies. It has adapted and grown with the times. Control-M did cloud-based work before many of us were even talking about the cloud. It's hard to get rid of negative perceptions sometimes, however, the best thing for people to do is to head out to the internet, look it up, and go out to GitHub.
If you have a technical team, send them out to GitHub. You can download everything in an image or in a container and try it yourself. It doesn't cost you a nickel.
I'd rate the solution nine out of ten.
The biggest advice I can give is to try it out. Don't only believe what the PowerPoints tell you. There's no excuse that you can't have a deployment running clearly within hours. Be willing to think about how it can solve problems in new ways. Sometimes we try to find a new tool as we have a square problem and we get upset as all the tools we're looking at only have round solutions. Sometimes the reason that it only has round solutions is due to the fact that that's the proper way to solve the problem. You have got to be willing to break down whatever you're trying to do, whatever workflow you're trying to automate or integrate, and take it in pieces.
If all you want to do is save yourself a lot of money, use Cron, and use Windows Task Scheduler. However, if you want to take your business to the next level and start to get to the point where you can automate to remediate and audit, that's where tools like Control-M come into play.
We use the solution in Western Mutual Insurance Group's environment for the daily scheduling of around 11,000 jobs. Our number of end-users is in the hundreds, across 18 to 20 teams. We have three different physical locations as a company. Since COVID, we are a partially remote workforce as well, so we have multiple locations.
It's essential that the solution orchestrates our workflows. Regarding processes like file transfers and data workflows, we want one source for that. We want one area where we can check and see how things are progressing, and Control-M is invaluable. Everyone has access in our environment to Control-M, and we all use it heavily. We utilize a ton of plugins in our environment. We started the transition into servers and are seeing what our license allows in that area. We try to take advantage of everything we can.
We use Control-M to replace a lot of our manual logging of job data. It's been very valuable in terms of logs that can output alerts.
I just did an audit earlier this year, and it was a swift process using the product. It took me less than a few hours, and without the solution, it would potentially take a couple of days to a week.
We essentially have a nightly batch cycle. We process data overnight, so it's available for end-users during the day. Using manual execution, instead of Control-M, this nightly batch cycle would transition into a weekly or monthly batch cycle instead.
I recently took over as admin of Control-M about a year ago. Since then, the question has been how we can further utilize Control-M in our environment. We haven't yet found the limits of what Control-M can do. We're finding better ways to apply it every day. From the old days when we manually scheduled jobs to the current paradigm of using an automation tool. This made the process much more manageable.
We define Control-M internally as a "critical business application." I would say that if Control-M were not available, the impact would be catastrophic to our business.
The reporting is top-notch. I haven't found any other applications on the market that can replicate what Control-M offers. The alerting is very good, and I think their service monitoring is the best in the industry.
The solution is a key part of our system and I have not seen any significant limitations with it. It's very reliable and performs as advertised.
We're just starting our data pipeline journey. Compared to other products in the market, I believe Control-M's is the easiest to use. Theirs came out ahead in terms of ease of use every time. I rate them very highly in that area. We're primarily an Azure corporation. We found that the solution's built-in integrations with Azure are straightforward to use.
We actively build out methods of alerting, for instance, when workflows in Control-M don't complete, as this impacts our end-users and our managers that support the teams attempting to provide data for the end-users. I think Control-M has a ton of built-in integrations that make alerting when that data is unavailable more visible to end-users. I think that's been very useful in our environment.
The stability could be improved. I ran into an issue with a recent Control-M patch. The environment would become unstable if security ports were scanned. This is an area they need to improve on, but ultimately it's a relatively small improvement.
We have been using the solution for around seven years.
One patch had some issues, but the fix pack was very helpful. Other than that, we haven't had any stability issues with this product. So I'd rate it very highly.
The scalability is excellent, we're looking into options in Azure for scaling up and down in our environment, and Control-M has been essential in accommodating that.
Technical support would be a 10. They're always available. They've been very helpful with any questions I have. There are multiple means of contacting them, and they've always been responsive. The technical account partner, Jake, has been very helpful. The account rep, Chris, has also been very responsive.
Positive
Control-M in our environment predates my time. I believe the company first implemented the solution around 15 years ago.
The initial setup was before my time. We started off as a mainframe exclusive influence of Control-M, and then we transitioned to distributed servers from there. I am a team of one.
The solution's automation has improved our business service delivery speed. Our big push this year has been toil reduction and automation of manual tasks that ultimately take time away from our engineers. Control-M is factored into probably north of 80% of those reductions with its ability to automate tasks. So far this year, we're at about 4,000 hours of toil reduced. I would say Control-M has played a factor in 3000 of those hours.
I would rate this solution a ten out of ten. Control-M is critical to our business.
There are other solutions like Control-M out on the market, but in every recent market evaluation, Control-M has always come out on top. I think they are becoming more cloud-native as they progress with their Control-M Web Services. They're more reliable than the others on the market right now.
I would advise anyone to start with a trial version of this product. I think they'll be very impressed with it.
We don't use Python to a significant degree at all in our environment. We have been looking into that, but nothing solid yet. We don't use AWS but are looking to get into it in 2024.
We use Control-M to schedule jobs in it, to run critical business processes as batches. We also use it to transfer files from one location to the other. We use it for reporting and to monitor critical batches that are running in the business.
The best feature of Control-M is the UI, the user interface. It is very user-friendly, and it has ease of use for an end user. I appreciate the centralized monitoring capability of this application where with one glance, we can get all the information. We don't need to run here and there for getting the information. Its main feature, the Batch Impact Manager feature in Control-M, is the best by far to monitor all the critical batches in one place.
BMC could do better in the reporting capabilities of Control-M. Currently, what they have is very limited in reporting. We may have some work going in place in the reporting area so that they can give more customized reports for users.
I have been using Control-M for the last nine years.
Control-M is mostly stable. It doesn't require regular maintenance, unlike other applications. It's stable, and we don't face any regular issues with the application unless something breaks over the network or on the server level. At the application level, we have very few issues even from the past few years.
Control-M has the capability to integrate with many other applications, so it's really scalable in that area. It even has the application integrator facility to talk to any other application that has the REST capability. It's more scalable in that aspect.
We have reached out to BMC a lot of times. They are good, but this is an honest opinion, the service for Control-M has had a slight downfall in recent times. It used to be very good in the past few years, but now they have slightly degraded service in terms of delay in response and the way they ask questions. They are asking repetitive questions even though we've provided the information to them. That's what I felt based on my past few cases with them. Overall, they are good but not very good.
Positive
I have used another scheduling tool, Autosys, but not to an extreme extent. Compared to Autosys, Control-M is by far the best. Control-M's capabilities to integrate with other platforms, such as SAP, AWS, and various web services, make it stand out among competitors. Control-M excels in these integrations and offers superior functionality. Additionally, I appreciate the user interface of Control-M; it is one of the features I like the most about the application. It's truly well-designed and user-friendly.
It was already deployed before I joined the organization. Learning to use Control-M is very user-friendly, unlike other scheduling tools in the market. The setup is very easy. We have all the documentation and required support videos available on YouTube in the official channel of BMC Control-M. Following the guide, we can easily set up the application. For use, we have a huge knowledge base in their support central page where we can search for anything, and we can find the solution for most things. If something is not there, then we can reach out to their support by logging in a case with them, and we will get a response with all the details. The features are there with good names, not confusing the user about why the feature was there or what's the use of it. It's very easy to use, all in one.
In terms of maintenance, we are the administrator, and we manage the application.
I'm not involved in any sales discussions related to Control-M, but I'll give my general opinion. I heard that Control-M is a bit pricey compared to other competitors. Given its features and capabilities, I think that's justified.
My relationship with BMC regarding Control-M is more transformative. We usually talk to them about the cases. For product-related discussions, if they need some information or reports from our end, we were involved and were over the calls talking with them. For all the critical cases that we raised with them, we were on the call discussing all the technical aspects. It was all good.
I would rate Control-M a nine out of ten.
My company uses BMC Control-M to manage our applications from SAP and Informatica ETL.
I don't see any area where improvements are needed in the product since the tool has a lot of capabilities. One can opt for either a job-based license or a job execution-based license, which sometimes can be troublesome. If the job count exceeds a limit, you may need to procure additional licenses from BMC. I don't see any issue with the product's capability or functionality apart from the aforementioned issue where improvements are needed.
The price of the product is an area with certain shortcomings that stem from the expensive nature of the product and can be considered for improvement by BMC.
I have been using BMC Control-M for ten years. In my company, we use BMC Control-M Version 9.0.21. My company is a customer of BMC.
It is a stable solution. Stability-wise, I rate the solution an eight out of ten.
It is a highly scalable solution. Scalability-wise, I rate the solution a nine out of ten.
More than 300 users, consisting of batch operators, job schedulers, analysts, and administrators, use BMC Control-M in my company.
In my company, we use the solution daily.
I rate the technical support a nine out of ten.
Positive
I rate the product's initial setup a nine on a scale of one to ten, where one is difficult, and ten is easy.
The solution is deployed on an on-premises model.
The deployment process of BMC Control-M took less than an hour.
My company had an in-house team to take care of the product's deployment phase.
I rate the solution's price a nine on a scale of one to ten, where one is low or really affordable, and ten is high or really expensive. It is a really expensive tool.
I recommend the solution to those who plan to use it.
I rate the overall product an eight out of ten.
It is used for file transfer, both inbound and outbound, including B2B.
Dashboard and recovery are the features I found most valuable in the solution.
I think that in the latest version, they have already improved. We still have to work on the latest one since we are still installing it. So we have not completed the installation. Post that, I think we'll see what needs improvement.
We have some issues on the SAP side of BMC Control-M Managed File Transfer. When I talk about non-SAP and SAP sides, I think with large volumes, one needs to install multiple agents. So that is something which should not be there. But at times, it is recommended by BMC. So, there are some stability issues when it comes to SAP side. The aforementioned details can be considered for improvement.
I have been using BMC Control-M Managed File Transfer for ten years. They released the latest version two days ago, and we are going to upgrade it to the latest version.
Stability-wise, I rate the solution a nine out of ten.
It is a standard pre-requisite that if we grow, then we have to double your CPs and other stuff. So, scalability is not an issue.
Since we are using the enterprise version, there are maybe more than 100 users that are concurrently logged in to the application.
We have used BMC's technical support, and we found it to be great. BMC has very good knowledge articles and other stuff, so that is good.
The initial setup is simple. Last time, it took around one and a half or two and a half hours to get the whole installation and migration done. So, now it can be done in less than one hour. BMC provides an AMIGO plan, and we follow that for deployment.
We handle multiple customers. So, the staff needed for the deployment and maintenance really depends on the number of customers.
I would definitely recommend the solution to those planning to use it since it is good to use.
There are some stability issues when it comes to SAP side, and hence I rate the product a nine out of ten. However, considering the Non-SAP side, I rate the overall product a ten out of ten. So, an average rating of the overall solution would be nine out of ten.
Control-M supports a lot of business processes. It supports some of the HR functions. I don't know if payroll is directly supported, but we do run jobs through PeopleSoft, which obviously impacts HR. Recently, we've started using the SAP module. So, we're making a transition from PeopleSoft to SAP, and I also see some payroll functions happening there.
We use Control-M to orchestrate a diverse landscape of vendor products such as Pega, MuleSoft, etc. File transfers and data feeds fetching are quite important for us. So, a lot of data processing happens through Control-M.
Control-M provides us with a unified view where we can easily define, orchestrate, and monitor all of our application workflows and data pipelines. Of course, such a diverse landscape requires you to make the effort to utilize Control-M to tie everything together or to act as the glue. Once you do that, everything is clearly defined, and you can view these disparate systems using one unified pane. If you don't define it correctly, then obviously Control-M won't have that insight, and so you'll have to go to multiple locations to go look at your job statuses.
We use its web interface. It is primarily for the application support teams to go monitor their own jobs. The jobs defined within Control-M are tightly controlled by a specific group of people. There are also people who need access to view that the jobs were completed successfully or why the jobs may have failed. These people are given access through Control-M web to view and monitor the jobs that they support or the applications they support. They're usually able to log on without having to install any client on their personal workstations. So, it's quite convenient. We have not implemented its mobile interface.
The integrated file transfers with our application workflows have certainly sped up our business service delivery by 80%. It has allowed the business to integrate file transfers more readily. Prior to utilizing the Control-M module, people had to write their own file transfer scripts in a scripting language of their choice to vary degrees of effectiveness. With the integrated File Transfer solution within Control-M, there is a standardized way of performing file transfers along with the capability of file watching and grabbing the file names that were transferred, making it much more versatile.
Control-M can immediately report when a job fails. If you have proper monitoring in place, you're notified immediately when your business flows are impacted. In the past, when you run jobs using Cron or just wrote shell scripts, you're really left in the dark because they don't necessarily report even from within Control-M. Implementing Control-M has made the business realize how critical and important it is to have proper error coding within the scripts that they schedule. If the scripts don't necessarily report any errors or redirect the system output into log files, when a job fails, there is no way to detect that.
We've automated many time-consuming business reports and other things that were very manual and took a tremendous amount of manhours. We've also automated a lot of maintenance using Control-M. We've integrated with Ansible Tower. So, we now are able to run Ansible playbooks and Ansible job templates. With the scheduling capability and the multitude of integrations that Control-M offers, it really acts as the unifying glue and as a communicator and orchestrator across the enterprise. With Ansible Tower, you can run a number of playbooks through it to perform patching and reboots and whatever maintenance that the infrastructure teams require, but you can't really do it when the business is still operating, or you can't do it when that business is operating, but you could do it for another business that's not operating at the moment. It is very hard to coordinate that without knowing which lines of business have jobs running or things like that. With Control-M, you can see that and you can actually enact workload policies to put jobs on hold prior to running Ansible playbooks. Once your Ansible playbook is complete, you can release the jobs again by deactivating the workload policies. So, it makes those processes very streamlined.
We do use the Role-Based Administration feature. We have been allowing other groups to gain more control over their agents so that they can define connection profiles, and they can do a little bit more on their side without inundating the main team with a lot of tasks. Everybody is happier. They can get things done faster, and they have immediate feedback and response because they're in control. The main Control-M team is not inundated with a lot of different requests from various teams to do a number of mechanical tasks. They don't get asked to create the connection profile for a database. People have all the information there, and they can do it themselves. They can define it in a way so that only they have access to it.
It has helped us to achieve faster issue resolution. Control-M reports on the error. It is easier to view the system output of that job. Whether it is an Informatica job, a scripted job, or a database job, it is easier to go in and view the issue and then troubleshoot from there. Most of the time, you can be running from the point of failure if the jobs aren't defined correctly. In a properly defined job, I would estimate that there is a 70% to 90% reduction in the meantime to resolution.
It has helped us by improving our service-level operations performance. We've built integration between Control-M and our ITSM, which is ServiceNow, and that has certainly allowed us to gain more visibility within our community through ServiceNow. Every time a production job fails, an incident ticket is cut, and that's highly visible. That needs to be escalated too, and there is a much more defined process to be able to resolve that issue. In the past, obviously, when you didn't have that level of visibility or that integration, there was always time lost in identifying what the issue is.
The File Transfer component is quite valuable. The integration with products such as Informatica and SAP is very valuable to us as well. Rather than having to build our own interface into those products, we can use the ones that come out of the box. The integration with databases is valuable as well. We use database jobs quite a bit. The file watcher component is also indispensable when integrating with other applications that generate files, instead of triggering a workflow based on time.
We have been experimenting with centralized connection profiles. There are some bugs to be worked out. So, we don't feel 100% comfortable with only using centralized connection profiles. We do have a mix of control on agents out there, which leads to some complications because earlier agents do not support centralized connection profiles.
A lot of the areas of improvement revolve around Automation API because that area is constantly evolving. It is constantly changing, and it is constantly being updated. There are some bugs that are introduced from one version to the next. So, the regression testing doesn't seem to capture some of the bugs that have been fixed in prior versions, and those bugs are then reintroduced in later versions. One particular example is that we were trying to use the Automation API to fetch a number of run ads users from the environment. The username had special characters and backspace characters because it was a Windows User ID. In the documentation, there is a documented workaround for that. However, that relied on two particular settings in the Tomcat web server. I later found out that these settings work out-of-the-box for version 9.0.19, but those two options were not included in the config file for 9.0.20. So, it led to a little bit of confusion and a lot of time trying to diagnose, both with support and the BMC community, what is the issue. Ultimately, we did resolve that, but that is time spent that really shouldn't have been spent. It had obviously been working in 9.0.19, and I don't know why that was missed in 9.0.20, but that's a primary example of an improvement that can happen.
We've also noticed that the Control-M agents themselves now run Java components. Over time, they tend to destabilize. It could be because garbage collection isn't happening, or something is not happening. We then realize that the agent is consuming quite a large amount of memory resources on the servers themselves. After recycling the agents and releasing that memory, things go back to normal, but there are times when the agent becomes unresponsive. The jobs get submitted, and nothing executes, but we don't know about it until somebody says, "Hey, but my job isn't running." When we look at it, it says Executing within the GUI, but there is no actual process running on the server. So, there is some disconnect there. There is no alerting function or the agent there that says, "Hey, I'm not responding." It is not showing up in the x alerts or anything like that.
The integrated guides have not been that helpful to us. I do find a lot of the how-to videos on the knowledge portal to be useful. However, there are some videos where the directions don't always match with some of the implementations. There are some typos here and there, but overall, those have been more helpful for us.
Its pricing and licensing could be a little bit better. The regular Managed File Transfer piece, is a little overpriced, especially for folks who already have licensed Advanced File Transfer.
What I'm also noticing when I'm trying to recruit for Control-M positions is that the talent pool is quite small. There's not a whole lot of companies that utilize Control-M, and if they do, most people don't want to let their Control-M resources go if they're good. There is a high barrier of entry for most people to learn Control-M. There are Workbench, Automation API, and so forth mainly for developers to learn, but there are not a whole lot of resources out there for people to get more familiar with administering Control-M or things like that in terms of the technology or even awareness. So, it becomes very challenging to acquire new resources for that. A lot of the newer people coming out of college don't even know what is Control-M. If they do, they think of it as a batch scheduler, which is certainly not true in its current transformation.
Control-M is a very powerful enterprise tool, but the overall perception has not changed in the past five to six years that I've been working with Control-M. There's not much incentive for people to dive into that world. It is a very small community, and overall, the value of Control-M is not being showcased adequately, maybe at the C-level for corporations. I've had multiple conversations with other people and other companies who have already exit using Control-M. About 70% of the companies out there do not take full advantage of the capabilities in Control-M. So, that type of utilization really hampers and hinders the reputation of Control-M. That's because people then acquire this untrue concept that Control-M can only do X, Y, and Z, rather than the fact that Control-M can do so much more. I don't know if it needs a grassroots marketing movement or a top-down marketing movement, but this is what the perception is because that's what I'm hearing and that's what I'm seeing. For some of the challenges that I face working in Control-M, when I go back to my management and say, "Hey, I want to spend more money in this space," they're like, "Why? Can you justify it? This is what we see Control-M as it is. It's not going to bring us value in this area or that area." I have to go back and develop a new business case to say, "Hey, we need to upgrade to MFT enterprise or something like that." So, it definitely requires a lot more work convincing management in order to get all these components. In the past, we had to justify acquiring a workload change manager. We had to justify acquiring the workload archive. All of these bring benefits not only to our audit environment but also to the development environment, but the fact that we had to fight so hard to acquire these is challenging.
I've been using Control-M for about eight years.
Version 9 was very stable. Once they started adding a lot of the newer Java components, the stability suffered. It seems to have gotten better in version 9.0.20, but that's could be my basic perception.
We run a lot of database client jobs. There are some things that we've implemented that I understand can contribute to the agent instability. We sometimes extract a lot of database output and massage that output using other scripts. I've noticed there are certain things that you cannot do with it, or there are some things that contribute to the instability. For example, in the output scanning functionality, there certainly is a size limit. You probably don't want to scan anything too large because that's going to put a lot of resources on the environment.
In addition, there are times when the agent becomes unresponsive. The jobs get submitted, but nothing executes. There is no alerting function. These are the examples of instability that I've noticed. Overall, the main application itself, the EM, and the scheduler have been pretty stable.
It is very scalable in terms of job execution. I haven't really explored scaling Control-M and the EM environment to a point where we have hundreds of users accessing it at a given time. That's because I don't have a hundred users who want to access that at a given time, but I do understand that you can distribute the web server more, and then have a load balancer to balance the load. I would think Control-M is a fairly scalable application.
In terms of its users, we have a lot of application support folks. We do have some developers who access Control-M mostly for the non-prod environments to execute and monitor their own jobs. There are some software engineers and operational engineers who are part of the application support teams that access Control-M. As for size or concurrent users, we have about 50 concurrent users at the max.
I would probably give them a nine out of 10. For the most part, they're very helpful, but there's always an initial standard dialogue. For an issue, you have to collect from EM logs, agent logs, and so forth, and you submit that. Sometimes, we have done all the advanced work and submitted it, but they still come back and say, "Hey, we need the logs." It seems like that's a canned response without looking at the tickets.
Positive
We've been with Control-M for quite a long time. We have not been using anything else in my history with this organization.
I have not looked at anything recently. I am aware there are other application orchestration solutions out there, but I have not felt the need to go explore those options at the time.
If you're deploying using out-of-the-box options, the process is fairly straightforward. If there is some customization that needs to happen, then the process can be complex, and the documentation does not cover some of those complexities.
For the most part, we are standard out of the box. We have run into some performance issues where we had to, later on, go in and maybe make some modifications. For example, we had to stand up different gateways for various purposes just because one singular gateway was not enough to take the load in particular because we had installed a workload archive, and that was just taking up a lot of resources. Other human users were not able to perform their actions because the archive user was consuming so much of the server's resources. So, there was a lot of tweaking there, and we had to basically break out and distribute some of the components.
In terms of implementation strategy or deployment plan for Control-M, the environment always had Control-M, and we just had to upgrade the Control-M environment. We've had Control-M in our environment for quite a long time, probably when it was still version 6. So, as we progressed through different versions, we obviously had to expand the environment and the platforms. We initially started off with Control-M on AIX, and we later moved to Control-M on Linux. As you go to Linux, obviously, there is planning for high availability and production environments, disaster recovery environments, and so forth. So, you have to plan for marrying a lot of the BMC Control-M components and identifying where a load balancer may be required, or DNS ALIAS is required so that you can quickly flip over in the event something happens. Then, of course, there is sizing for the environment in terms of how many jobs are running, how many executions are happening, and so forth. This is how we plan.
We've used the AMIGO program, and then we've performed the upgrades ourselves.
For its day-to-day administration, we have a team of five people. They're administrators and schedulers.
Its return on investment is quite high, and that's mostly because we use so many of Control-M's capabilities. We also extend those capabilities. We write our own scripts to be able to integrate Control-M with so many other applications such as Automation Anywhere, Alteryx. We have also done vice versa. We have helped other teams develop their capabilities in integrating with the REST API and Control-M. So, the ROI is quite high for our use case, but based on the conversation with some of the community partners out there, their ROI is probably quite low because they're not making use of all these new features. I don't know if it is because they don't have the skillset to make use of these new features, or their management structure or process structure is hampering them from going out there. A lot of large companies I know like to maintain the status quo, and that's why they're slow to adapt and slow to move, which is going to hurt them in the long run, but in the meantime, it can hurt the adoption of Control-M as well.
Its pricing and licensing could be a little bit better. Based on my experience and discussions with other existing customers, everybody feels that the regular Managed File Transfer piece, not the enterprise one, is a little overpriced, especially for folks who already have licensed Advanced File Transfer. We understand that Advanced File Transfer is going away and is going to be the end of life, and there is some additional functionality built into MFT, but the additional functionality does not really correlate with the huge price increase over what we're paying for AFT already. This has actually driven a lot of people to look for alternative solutions.
I know they are now moving more towards endpoint licensing or task-based licensing. In my eyes, the value of Control-M is the ability to break down jobs from monolithic scripts. You don't want to have to wrap everything up in one monolithic script and say, "Hey, I'm executing one task because I want to save money." That defeats the purpose of controlling, and that defeats the value of Control-M. By being able to take that monolithic script and break it down into the 10 most basic components, you can monitor each step. It is self-documenting because, within Control-M, you can see how the flow will work, and you can recover from any one of those 10 steps rather than having to rerun the monolithic script should something fail. That being said, the endpoint licensing does make more sense, but maybe pricing or things like that can be more forgiving.
N/A
It is worth the time and money investment to learn more about Control-M. You should learn all the features of Control-M and really explore and test out the capabilities of Control-M. That's the only way people get comfortable with what Control-M can implement. A lot of people aren't aware of just how flexible a platform Control-M is, especially with all the new features that are being added via the Automation API. These features are helping to drive Control-M and things developed in Control-M more towards a microservices model.
We are just beginning to explore using Control-M as part of our DevOps automation toolchains and leverage its “as-code” interfaces for developers. Obviously, there is a little bit of a learning curve for developers as well in order to see the value of developing Jobs-as-Code. Currently, we're walking developers through it, and we're holding their hands a little bit in terms of developing Jobs-as-Code, but we are heading in that direction because it does provide artifacts that you can version control and change quickly and easily. You can redeploy much quicker than just having the jobs defined in the graphical user interface. Previously, when you had to modify it, you either did it via the GUI, or you exported it via XML and then modified those components. Once you get the developers closer to their job flows, then you can theoretically speed up the delivery of applications along with scheduled jobs.
I don't have a whole lot of experience with other scheduling orchestration environments, but from everything that I've heard while speaking with other colleagues, I would say Control-M ranks fairly high. I would rate it a nine out of 10. Control-M usually is the platform that people are moving to, not moving away from.
Our primary use case for this solution is the data flow between our locations, between systems, and B2B data flow, which includes the data to the endpoints, the schemes and other lines. We deploy the solution on-premises.
For the IQ operation flow, we have to do a lot of planning with data resources and keeping the resources in front of the system. However, the solution has improved our organization by minimizing software dependency and managing data for our clients and regional schemes.
The file transfer, database, and integration features are the most valuable.
The solution can be improved by upgrading its features to compete with premium software in MFT. Additionally, Math and dollar features, along with product samples and VR functionalities, can be included in the next release.
We have been using the solution for approximately 15 years and are currently using version 20.200.
The solution is scalable. I rate it a nine out of ten.
The customer service and support team are very knowledgeable. I rate them a nine out of ten.
Positive
The initial setup is quite easy and depends on the speed of the background. So basically, if you're in the background, it's an eight out of ten.
We have seen a return on investment. The solution has saved us about 30% to 40% on additional investments in resources.
I rate the pricing a seven out of ten because there is room for improvement.
I rate the solution a nine out of ten. The solution is good, but its current functionalities can be upgraded. I recommend the solution to users considering it.
We are using the solution for maintaining the infrastructure jobs like database Genesys and NICE. All jobs have been integrated into a single frame and a BMC Control-M readme page. Basically, we create jobs and modify the jobs. We have to analyze if any jobs fail. We settle the issues so that the jobs are up to date and should run.
The solution can communicate with the cluster. It can redirect any alarms or failures, and we remediate those actions.
We create new job scenarios and workarounds. We have special access to incidents and monitor controller operations.
The solution is good in terms of working with other products. The integration is useful.
Once you understand the solution, the initial setup isn't too bad.
The solution is stable.
It's scalable.
We need the updates to be able to maintain interoperability. We still want to be able to verify testing in production and the environment and want upgrades to go smoothly so as not to disrupt our applications. The more seamless it can be, the better remediation will go.
We'd like it to be easier to maintain the administrative side. Transferring files should be easier. There are a lot of dependencies. We'd also like there to be less space consumption.
There's a bit of a learning curve for new users.
When we pull job applications, if we configure multiple tenants under multiple environments with a single frame while we are logging into the applications, it sometimes freezes and takes too much time.
I've used the solution for about one year.
From what I have seen so far, it is stable and reliable.
We do have frequent version upgrades and maintenance and therefore haven't seen many issues.
It's a scalable product. I'd rate it eight out of ten in the ability to scale.
We have 11 people on our team and about four people who handle administration and maintenance tasks. We're in four regions: Australia, Singapore, India and New Zealand. In these regions, there are two configured clusters - one in Australia and one in New Zealand.
We have an administrative team that has the privilege of raising technical support. We will do the Genesys part, however, for BMC, they run the people. They will take care of coordination with the vendor and the business unit.
We use a lot of different solutions, including Genesys, NICE, Control-M ESPL, WFM, and workforce management. All are interoperable.
The company has used this solution for about seven years, and I have only been around for one. I'm not sure why they first initiated usage.
The initial setup is easy once you have some experience. It can be somewhat difficult otherwise.
We have four people that are able to handle maintenance tasks.
Once our teams have tested and validated the scenarios are working fine, then they will move from Genesys into services. Once Genesys services have been integrated, Genesys engineers will come and will monitor everyday operations for Control-M. If they identify any files or any jobs that have instability, they'll look for a permanent fix.
We are mediators between the vendor and customers.
We are using around version nine. I'm not sure of the exact version number.
I'd rate the solution seven out of ten. I do need more time with the product. However, I haven't seen the product causing many issues. It's been sustainable, and we've liked having all operations in one single cluster.
Our use case was mainly about consolidating our data pipeline from different sources and doing some data transformations and changes. We needed to get data from different sources into a state where we could act on it into one consolidated data set.
It gave us the ability to consolidate a diverse set of solutions into one comprehensive solution that streamlined our development processes. It was straightforward to adopt and we could build on existing skills without having to have 10 solutions for 10 problems.
And when it came to creating actionable data, it gave us the ability to move faster and at scale. By adopting a solution like Control-M, we were able to scale and deliver faster data transformations and maneuvers, turning data into insights in a more efficient and scalable way.
The ability to deliver faster and at scale was important. Business and management always wanted us to deliver faster and bigger and we were able to do both with the solution that we implemented using Control-M. We were able to respond faster to changes and business needs, at scale.
Having a feature-rich solution enabled us to aggregate all of our processes into it, and that made the overall execution, from a project and portfolio perspective, a lot more efficient.
We were also able to respond to audit requests, because it's centralized, in a much more efficient way.
There isn't a single feature that is most valuable, but if I had to choose one, it would be the rich ability it gave us for making customized scripts. That was probably the most unique feature set for our situation. We used Control-M's Python Client and cloud data service integrations with AWS and, as a feature, it was very customizable. It gave us a lot of flexibility for customizing whatever data maneuver we wanted to do within a pipeline.
The Python Client and cloud data service integrations have a rich set of features with flexibility. It did not require additional, crazy skills or experience to deal with it. It was a nice transition into enabling a data scientist to leverage existing skills to build those pipelines.
Creating, integrating, and automating data pipelines with Control-M was straightforward. It did require some knowledge and training, but compared to other solutions, it was a lot simpler. Working with data workflows, with the data-coding language integrated into Control-M, was straightforward. The level of difficulty was somewhere between "medium" and "easy." It was not that hard to leverage existing skills and knowledge within this specific feature.
The user interface for creating, monitoring, and ensuring delivery of files as part of the data pipeline was very actionable. It was almost self-explanatory. Somebody with basic user-interface experience could navigate the calls to action and the configuration that is required. It was well-designed.
I would like to see them adopt more cloud. Most companies don't have a single cloud, meaning we have data sources that come from different cloud providers. That may have been solved already, but supporting Azure would be an improvement because companies tend not to have only AWS and GCP.
I used it for a couple of years.
It's fairly stable. I don't recall any specific issues.
It's fairly scalable. For our needs, it scaled very nicely.
We have a shared model where we have a centralized, shared service organization when it comes to data. Different people will use it, but it's centralized.
We used other solutions from BMC as well, and their customer support was always great. I give them a 10 out of 10.
Training or a Knowledge Base were available or you could ask a question by submitting a ticket.
Positive
We had DataStage from IBM and SSIS.
The switch was really about streamlining the process. We had other tools that only did partial processes or were not doing it with the speed and efficiency that we were looking for. We were looking for a solution that could streamline things and solve 90 percent of our data challenges.
The analysis that I saw validated that the ROI was within a couple of years.
The pricing was competitive, from what I understand.
We looked at continuing to use the same solutions we had been using, and there were a couple of other cloud-based solutions that we evaluated. One of them was Matillion. The ease of use was one component of our decision, as was the flexibility of scripting with Python. Those were the key differentiators.
For the on-prem solution, we had to do the patching and whatever was required by the vendor, but the cloud implementation was a model that was usable. The upgrades, changes, and patching are done directly by the vendor.
Control-M was a critical piece of the puzzle, to help us with all the data transformation and projects that we had to do. It was part of either one specific project or even a larger project that required that middle data transformation so that we could get to analytics or any other consumption of that data.
