What Is Cincinnati Bell?
Industry: Telecommunications
Customer Site: Cincinnati, Ohio, United States
Cincinnati Bell is the dominant telephone company for Cincinnati, Ohio and its nearby suburbs in the states of Ohio, Indiana and Kentucky. Cincinnati Bell is a leading provider of home phone, high speed internet, wireless and digital TV services to consumers and businesses.
Success Story Highlights
- Adopting workload automation as a cornerstone to automating telecom processes
- Robust automation solution to execute series of DTS and SFTP jobs
- Passing data and files between various internal accounting and transactional systems
- Capture failures before they affect the customers and the business
Workload Automation As The Cornerstone To Automating Business Processes
As one of the oldest and most well respected multi-service telecommunication providers in the country, Cincinnati Bell has a long history that started in 1873 in the telegraph business. Rates were fixed at $300 a year for one line not more than a mile in length.
Fast forward to today, and Cincinnati Bell now serves customers with multiple telecommunication products and services across three states, including portions of Ohio, Kentucky and Indiana. The rates have changed, and so has the way customers pay those rates. In today’s 24/7, Internet-driven world, Cincinnati Bell’s IT organization has grown and innovated with the times, and that includes adopting workload automation as a cornerstone to automating many of the telecoms critical business processes.
DTS, SFTP, SQL Server Agent And More...
Mark Kemen, senior application analyst at Cincinnati Bell, was looking for a more robust workload automation solution to execute a series of DTS and SFTP jobs critical to Cincinnati Bell’s banking and accounting processes, including passing data and files between various internal accounting and transactional systems or sending and receiving data files from banks.
Previously, these processes were stored as individual jobs in a SQL Server 2000 database and scheduled and executed via SQL Server Agent. Scheduling each job individually via SQL Server Agent meant creating and maintaining over 100 individual jobs that shared many of the same variables. “It was very repetitive in nature,” Kemen says. “There were only small differences between many of the jobs. For example, we’d need to FTP a series of files to a system, the only difference being the file name. In SQL Server Agent, that meant creating a job for each file. The workload quickly adds up.”
And if a job failed, SQL Server Agent’s limited alerting capabilities meant a problem wouldn’t be discovered until a user logged in to manually check on the process, or worse, a bank called inquiring about a missing or incomplete file. “It was a pretty tedious process. If a job failed, you’d have to go into SQL Server Agent and figure out which one failed, and if I wasn’t around, other users wouldn’t know where to go or which job to look for.”
Moreover, updating from SQL Server 2000 to a newer version presented its own challenges to both Kemen’s team and the database admin team. “SQL Server 2000 was the last version to support DTS jobs and our database admin didn’t want to have to convert them over to SSIS packages. We needed a more robust automation tool that would support our needs.”
A Workload Automation Solution For The 21st Century
After researching various solutions, Kemen looked into ActiveBatch Workload Automation from Advanced Systems Concepts, Inc. in 2010 and liked what he saw. The ability to pass variables between job steps meant simplifying the repetitive and time consuming nature of developing and maintaining individual jobs. Using the FTP job step in the ActiveBatch Integrated Jobs Library, Kemen can designate certain variables, such as a file name, as part of a job step and share that variable with other jobs. Rather than creating an individual job for each file name, Kemen has set up a single Plan within ActiveBatch that calls the same job multiple times, creating multiple reports. “It’s reduced a lot of the workload associated with managing individual jobs because we’ve consolidated all of it into a few Plans within ActiveBatch.” As a result, Kemen has been able to take approximately 100 SQL Server Agent jobs and consolidate them into four plans within ActiveBatch.
For other banking processes, Cincinnati Bell leverages ActiveBatch to proactively prevent a failure of an FTP before it happens. In the past, files would be created and sent via FTP. If the FTP failed for any reason or if the file was incomplete, “we wouldn’t know about it until someone called and asked where the file was or why was it incomplete,” Kemen says.
With ActiveBatch now in place, Kemen uses ActiveBatch alerting to receive an email or text message in the event of an FTP failure. But to proactively check the file prior to it being sent, Kemen has taken things a step further. As part of the workflow, a database query compares the output file from the creation of the file to the database the data is stored in, verifying that the two match before the workflow proceeds to initiate the FTP. The result? “There’s been a few times we caught a problem before we sent the file because the job would fail, so the file was never sent,” Kemen says. “We go in, fix the file and send it, and that saves us a phone call and a lot of time in the long run.”
Cincinnati Bell is now expanding the role of ActiveBatch to other departments throughout the organization that have similar banking and batch processes. “ActiveBatch is a great application. It’s scalable and easy to use,” Kemen says, “and we plan on continuing to expand its role as we look to streamline processes and save time and money.”