ESP Workload Automation Intelligence

 View Only

From Pillar to Post - At Your Peril

By Antony Askew posted Jun 03, 2015 06:55 AM

  

Every discipline in I.T. has its own history, its own personality and its own set of challenges.  Workload Automation (often still inaccurately referred to as "job scheduling" or "batch") is no exception.  But one of the big difficulties facing both the people who run Workload Automation (let's call it WA for now) and those who "own" it, is not such a common one: "Where does it live?" Or more often, "Where shall we put it this time?"

 

Think about the majority of I.T. organisations, be they in house or outsourced.  Its easy for everyone to understand where to put the server team, storage, networks, UNIX, windows, operations, development, DBA, Middleware and so on. It’s a pretty lengthy list, but the roles of these functions are well understood, so the I.T. organisation falls together by default.  Yes, the lines between all these blur depending on the size of organisations and how I.T. gets used (with the rise of DevOps for example).

 

Now what about WA - exactly who in I.T. should own it?

Over the years, I've seen, worked in and run WA teams that have belonged to (deep breath)…

 

  • The Unix team
  • The Windows team
  • The Database team
  • The Operations team
  • The Incident, Problem and Change Team
  • The Storage Team
  • The Enterprise Management Team
  • The Monitoring Team

 

…to name but a few.

 

Worse than this though, is trying to run the WA function while it is passed around between teams, managers, verticals and business units. I used to have a written script ready, to explain to the next poor manager what WA was, what I did and so on.

 

Part of the problem is that very often, WA slips under everyone's radar.  Because the correct operation of WA tends to be so critical, it must be run successfully and with basically zero issues.  This is great, this is achievable, but the wider perception that therefore "it just works" means that WA is often ignored.  The technology and the people in WA can be left to their own devices, and they may struggle to develop or get traction on things like upgrades or adoption of new technologies.

 

This can be a big problem, and therefore it becomes a big risk. Because…Workload Automation does not run itself.  The people looking after it are actually pretty smart.  They have to know about a lot of different I.T. disciplines - networking, servers, operating systems, databases and scripting to name the usual ones. They very often deal across the board with I.T. colleagues, developers and business users.   They have to operate a critical service 24 hours a day, 365 days a year. "That's just like the server team" or "the network team" you might say - and you'd be absolutely right.  And so, the WA team and their function or service, should be valued exactly like those teams too.

 

It does not "just work" by itself, and if it does go wrong, you will definitely know about it.  The failure of Workload Automation has resulted in some very costly problems over the years.

 

Underestimate the importance of Workload Automation at your peril!

1 comment
0 views