Data Center Automation Blueprint - made a round of updates - Adventures in Data Center Automation

Adventures in Data Center Automation

Apr 7 2008   7:08PM GMT

Data Center Automation Blueprint - made a round of updates



Posted by: Ryan Shopp
DataCenter, DCAB

It’s been a few weeks since I’ve taken a pass at the Data Center Automation Blueprint, so it was time for some additions and clean-up.First up I added descriptions for some of the categories and made sure the known vendor list was up to date (e.g., BladeLogic acquired by BMC).

Resource Reconciliation
Description - Automation that captures a complete view of all IT resources, assets, services, etc. and their relationships, layers 1 through 7. This comprehensive view of all IT resources is the “record of truth” and needs to always be 100% accurate. Once in place, this is the hub of information that keeps all other monitoring and management solutions on the same page so nothing is missed or overlooked.

Process Orchestration
Description - Cross-silo automation for mundane manual or high occurrence tasks. The capabilities are focused around helping individual technology domains (e.g., network, windows, unix, database, etc) communicate and collaborate to automate tasks that before required numerous people and passing around a trouble ticket.

Configuration & Change
Description - Automation around making configuration or software changes in mass or in a more controlled, systematic way even if at an individual level. Understanding what the potential impact or risks are associated with making that change and keeping tabs on what is changing and if it is authorized or in line with established standards.

Top Capabilities
1) Making changes easier through a simplified user interface - enables more junior administrators to make traditionally more complex changes that required senior individuals.
2) Abstraction layer that enables the same change to be applied to a numerous resources, which includes spanning multiple vendors.
3) Ability to recommend when a change is not recommended or even unauthorized…understanding the interdependencies and risks associated with a change.

One area I’m still pondering back and forth is Analytics.  The more I research and dig into things, I’m seeing that analytics automation is functional category specific (e.g., Config, Performance or Availability) with only a hint of cross DCAB category integration today.  Examples include:

  • Configuration & Change Management vendors offering analytics for servers/applications, integrates in details from help desk solutions around the changes tickets but does offer a hint of cross-functional with applicable incidents from an availability solution
  • Performance & Capacity Management vendors offering analytics for end-to-end applications/services with a hint of configuration & change specifics so they know what change and if it has an impact.
  • Performance & Capacity Management vendors offering analytics through real-time algorithms that perform dynamic thresholding and problem fingerprinting based on performance and availability conditions.

It seems the point it goes serious cross-functional, we find it discussed in terms of Business Intelligence, Business Service Management or Dashboards.So my gut is telling me to go back to these 6 areas of the Data Center Automation Blueprint where analytics is a key area of capabilities within each functional area…not it’s own stand alone category:

  • Resource Reconciliation (aka CMDB)
  • Process Orchestration (aka RBA)
  • Availability & Notification
  • Performance & Capacity
  • Security & Protection
  • Configuration & Change
  • Any thoughts on this please speak up!

    Comment on this Post


    You must be logged-in to post a comment. Log-in/Register

    Shenning  |   Apr 14 2008   4:28PM GMT

    After considering your comments and looking at the Blueprint again, I still feel that Analytics should stay as a separate category. Even though many Analytics products are specific to other categories as you point out, I think Analytics as a whole is important enough to warrant its own category. The main reason for even having the Blueprint is to educate on what is needed to achieve complete data center automation. With the size and complexity of today’s data centers, Analytics is a must have capability and subjugating it to a part of each of the other categories minimizes the impact these solutions can have. Additionally, while many IT leaders are aware of some Analytics solutions that are available (e.g., Capacity Planning), it is clear that they are not very familiar with the breadth and depth of solutions that are available today. By calling out Analytics as its own category, the complete set of capabilities can be defined and brought to the forefront. In a time when virtualization and SOA-based architectures are increasing complexity in a way that simply throwing more bodies at it won’t solve, the Blueprint can serve a valuable role in educating on the increased levels of automation that can be achieved across the board with Analytics.