The ops folks that work in the trenches, appreciate how important their roles and scripting are to the business. But often times, they don't identify themselves as developers nor do they see their home grown tools as "real" software, but rather just expedient simple time savers. The trouble is this collection of scripts and tools is important to keeping the business running and should be seen as business software. The authors and users of these management scripts appreciate this and do envision better designed, implemented and tested code since their jobs rely on the reliability of their performance. Like any software, requirements change and the software must change with it. What once started off as a simple script, turns into a monolithic, inflexible morass of code.

More often then not, the most used and relied upon programming construct is extremely rudimentary and crude: a loop that iterates over a set of host machines, executing some sequence of system commands. As the scripts importance increases, and the requirements drive its evolution, you also see the need to include logging, notification, security, modularity, data, configuration, etc... Wait. Doesn't this sound like stuff frameworks usually provide?

So what the service operations team needs is a new breed of framework, a domain-specific framework that helps them develop "management applications". Like traditional application development frameworks, it should include features like:

• notification: Forward events to email or monitoring stations
  
• security: Control access to only specified actions
  
• modularity: Allow packaging functionality so it can be reused
  
• data: Enable the design and maintenance of a data model
  
• configuration: Allow the management software to be externally configured so it can be used across environments
  

A domain-specific framework should also include:

• development tooling: Something like an IDE for development management applications
  
• packaging and deployment infrastructure: It's a distributed world so the framework should include the ability to package new code modules and deploy them to where they need to go
  
• canned functionality: There should be a set of common utilities that can be used as a starting point to create new management applications
  
• multi-language support: certain languages are better suited to different problems so the framework should allow the definition of new components in multiple implementation languages
  

Operations doesn't need to undergo a paradigm shift but rather alignment with their application developer brethren by using a development framework of their own. The business also needs to acknowledge this second, yet equally important software project: the one that keeps the service going.