-by Joe Goldberg, Control-M Solutions Marketing, BMC Software Inc.
So here are some points to ponder:
- Google Play has already hit one million apps and the iOS App store is not far behind.
- According to mobile web platform provider Kinvey, the average app takes about 18 weeks to develop and that is considered by many to be a long time.
- iOS App Store is adding about 20,000 apps a month; that is about 645 new apps each day
- Etsy performs over 25 deployments into production every single day (watch a video interview or see slide deck)
Yes, that is mainly in the consumer market but whether you call it consumerization or SMAC or “Nexus of Forces”, similar patterns and expectations are emerging in the corporate and enterprise worlds. Companies who fail to adapt will be severely challenged to maintain their competitive positions and those who do will be able to seize significant advantages.
One of the manifestations of this demand for accelerated new functionality is new development methodology such as Scrum and Agile. The need to deploy these new applications as quickly as they are developed has given rise to DevOps.
Batch is Still King
One factor that has not changed significantly is that workload automation (batch job scheduling) continues to manage a major portion of business processing performed by enterprise IT (some put the number at 70%). In fact, in a recent survey of BMC customers, almost 90% expect their batch workload to increase. Many of the most real-time, interactive and mission critical applications have a significant batch component that is an indispensable part of the processing.
Given this technology landscape, it seems reasonable to examine the process by which batch services are created, maintained and deployed. One of the first points to consider is why batch is almost completely absent from the DevOps discussion. If DevOps tools can manage artifacts like config files, jar files, properties files, etc. Why not batch workflow definitions too?
Why DevOps Forgot Batch
Perhaps the answer lies in the way workload automation or job scheduling tools are used by organizations today. Workload Automation is frequently seen as an IT Operations tool. Developers may write scripts and run them manually or via cron (or something similar) and it’s not until the application is being handed off to IT that the topic of scheduling and workflow comes up. Developers may be very knowledgeable in setting up and configuring web application servers or defining tables and objects in relational databases but when it comes to job flow relationships, calendars, abstract resources and post processing actions, they may not have a clue.
This may account for some of the arcane processes that customers have implemented to manage job scheduling requests submitted to IT, usually from application developers. Some use Excel spreadsheets, Word documents, custom forms and other such methods. They all share an underlying acknowledgement that application developers are not schedulers and are not very familiar with the concepts or the details of workload automation tools even of those used by the organization in which they are employed.
In this context, we can now discuss how changes are made to workflows and consider ways to improve on the current state. Let’s take the example of a utility provider which runs tens of thousands of jobs daily. When a job flow is changed or modified, the application development team submits a document detailing the requirements. According to the IT folks, Application Developers have only a rudimentary understanding of scheduling principles. If left to their own devices, jobs would run serially one after the other, taking significantly longer to complete and completely failing to take advantage of concurrency capabilities in the installed workload automation tool that is available. Each development team largely ignores all other teams and fails to consider the impact of different applications competing for the same resources. And finally, developers show little interest in operational requirements like auditing, reporting and incident management.
What A Solution May Look Like
So if this indeed is the current state, what would a solution look like? That was the question that BMC set out to answer about two years ago. The culmination of that effort has just been released and it is called BMC Control-M Workload Change Manager. This new solution finds a balance that enables developers to transfer their knowledge of the application to IT without having to become scheduling experts, capture that information to automate construction of workflows, provide IT schedulers with the ability to enrich the workflows with their knowledge and expertise and provide a collaboration platform that enables all parties to exchange questions, comments and requirements in a structured and managed fashion.
This solution has been necessary and ardently sought for decades but today is becoming indispensable. There are several ways you can learn more about this solution including taking a live test drive. Please post your comments and observations or tell us what you do today in your environment so that this solution can benefit from the collective wisdom of the entire community of workload automation users (and you just might win an iPad mini).
The postings in this blog are my own and do not necessarily represent the opinions or positions of BMC Software