I was having a conversation earlier this week with the chief architect of a multinational (Top 3) IT services company regarding our company’s Data Palette automation product. He is no stranger to IT complexity since his company manages the IT departments and business processes of literally hundreds of organizations in the private, public and government sectors. He asked me an interesting question: if Data Palette could be used as an “orchestration platform” in calling different standard operating procedures not just related to database administration per se, but managing other components of the IT stack such as system level products and network level products.
That took me a bit by surprise since all along I have just been focused on database management while talking with him. I told him that Data Palette has traditionally been used to call other DB related product APIs and 3rd party routines within different SOPs (Data Palette’s standard operating procedures) if that 3rd party or DBMS product routine is the best way to accomplish a given task (for instance, a Data Palette SOP could call StatsPack if required for Oracle DBAs that are used to utilizing that functionality for macro-level performance diagnosis, or in the case of a more complex situation, execute an SOP based on receiving an SNMP trap from enterprise monitoring tools like HP Openview or Mercury Sitescope). He mentioned that while this was useful, Data Palette could potentially serve a larger role in the environment wherein its SOP Module could be deployed as a central administration and audit console and provide an abstraction layer around other niche applications.
Come to think of it, there's nothing to really stop an organization from using Data Palette (or any similar product) in such a capacity and I told him as such. In fact, this approach would help companies in two ways:
1. Allow companies that rely on a plethora of tools to simplify their environment by orchestrating tool usage via a central automation platform (Data Palette was the catalyst in my conversation, however any similar automation product could be used in this capacity).
2. Allow teams situated around the world, as well as newer hires to get upto speed faster by just having to learn one product interface, as opposed to having to come upto speed on several tools and point solutions.
Thinking further about it, one of the reasons automation efforts are seen as unrealistic in many complex environments is because of multiple people doing things their own way and using whichever tool they feel is appropriate for their situation. By having such an orchestration platform, it allows everyone (not just DBAs or specific administration staff) be on the same page about what tools are meant for what use and stick to that standard via a single command and control interface. If a team member really has a favorite tool for say, server provisioning, they can even introduce that tool to a larger audience via such orchestration and make that part of the standard. This encourages multiple team members to have a conversation about why a certain approach or tool is better for a task and win over others to their way of operating.
The chief architect’s suggestion is a stellar one that will allow IT environments with higher complexity to embrace automation in a faster and more meaningful manner. These are the kind of innovative thinkers and strong champions our IT industry in general, and automation efforts in particular need at this moment in dealing with complexity caused by silos of people and ongoing changes. It’s kinda like having your cake and eating it too by retaining the tools and technologies that one is most familiar with and weaving them into larger scale automation efforts.
Wednesday, November 22, 2006
Need for orchestration managers in IT automation
Posted by Venkat Devraj at 8:23 AM
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment