Data Palette Gets Better and BladeLogic Joins the BMC Camp

It’s just Tuesday, and already it’s been a hectic week for data center automation with Stratavia announcing Data Palette 5.0 and BMC acquiring BladeLogic for about $800M.

Let me start with what's more relevant to customers and end-users: Data Palette 5.0 is something the Stratavia engineers have been working on for almost 2 years now (in conjunction with version 4). It is a game-changer in that it is the first data center automation (DCA) platform to combine native provisioning capabilities with run book automation and database automation to address DCA needs across multiple domains – the sys admins (with server provisioning and hardening requirements), the Tier 1/Help Desk (with generic run book automation requirements) and the DBAs/App admins (with more advanced database/application automation requirements).

The traditional DCA products like BladeLogic and Opsware have essentially focused on provisioning. In the case of Opsware, they started out with server provisioning and then expanded into network and storage provisioning by acquiring Rendition and Creekpath respectively. However these vendors quickly figured out that provisioning without process automation forms an incomplete offering. After all, most admins would like to do “something” with newly provisioned hardware – like harden the server, install specific applications on it, create user accounts and so on – all of which require process automation capabilities. To address that, Opsware last year acquired run book automation vendor, iConclude. BladeLogic addressed that problem via an OEM with run book automation vendor, RealOps (relabeled as Orchestration Manager) and when the latter got acquired by BMC, established an OEM arrangement with another vendor Opalis.

Sounds nice, huh? Well not so much for customers, because as anyone who has tried to integrate multiple products together knows, leveraging disparate tools in a seamless manner is not as easy as it sounds. There are always different GUIs, configuration styles and architectural components to reckon with, in addition to competing terminology, metadata and redundant functionality. Such integration challenges have been more pronounced in the case of BladeLogic especially, since with an OEM, you only have so much control over another vendor’s offering… But I guess BladeLogic has an excellent bunch of sales guys that have been able to sell into large organizations in spite of these challenges. Either that, or customers didn’t know they had an alternative.

With Data Palette 5.0, this hurdle towards a coherent integration of provisioning and run book automation capabilities is a thing of the past. Data Palette’s new console provides both set of capabilities that tie into each other via a common architecture that includes a shared console, policies, rules, metadata and consistent terminology. Now you can define templates for provisioning Windows, Linux and UNIX servers, along with corresponding CIS policies and apply them via a generic run book/workflow. You can use the same console to discover existing servers and leverage an automated run book to scan for compliance and configuration policy violations, report on them and optionally, remediate them. No more having to go from one product screen to the other and having to re-enter rules and preferences.

The other improvement is the thin client for both defining and deploying workflows. Both administration functions (such as defining workflows) as well as user functions (executing the workflows) can be accomplished via the web GUI, built primarily with Ajax and Flash. The new GUI implements the concept of a “digital whiteboard” with easy drag-and-drop of reusable workflows steps to illustrate a custom process. Each of the workflow steps are chained together via an input/output mapping that allows users to create new workflows without the need for scripting or having to study the code within each step. However if you are a scripter, the code is available for viewing/edits and you can add additional steps to the library in any scripting language with built-in version control (in fact, you can mix and match steps in different languages – all within the same workflow!!!).

Data Palette 5.0 also brings in the concept of custom policies. I realize different vendors seem to gravitate towards a different definition for the word “policy”. Within Data Palette, policies are a collection of common attributes that you can use to treat multiple “like” servers (or other data center assets) as one. For example, let’s say you have 40 Windows 2003 machines and 10 VMware Windows virtual machines that you need to apply PCI rules to. You can create a PCI policy outlining the relevant Windows-specific rules and attributes and then apply that singular policy to all 50 machines. Corresponding automation workflows can then utilize the policy attributes to log onto those servers, do the appropriate checks and report on all of them in a consistent manner. Finally, Data Palette’s original forte in database administration automation and 5.0’s innovation in terms of functionality and ease of use makes it stand head and shoulders above anyone else in terms of out-of-the-box database and application related content and capabilities.

BTW, in case you are somewhat wondering how Data Palette differentiates from BladeLogic and Opsware (both in terms of current capability as well as future direction), here’s a quick picture to represent each vendor’s competencies.


Both BladeLogic and Stratavia share some customers (BladeLogic Operations Manager used for server provisioning and configuration management, and Stratavia Data Palette utilized for database and application automation). They do have a good team that knows what they are doing. I would hate to see a good team and good technology disrupted. And looks like BladeLogic had no dearth of suitors. In closing, I hope BladeLogic gets its fair share of mindshare at BMC.

Taking a Stab at a Shared Industry Definition for a "DBA Workbook"

Whenever I come across shops where business users, application support groups or infrastructure teams complain about the DBAs not meeting their expectations, the first question I ask is “OK, so what’s your DBA really supposed to do?”. And I’m amazed by the range of answers I get. It seems like there is quite a bit of vagueness regarding the DBA role. Just recently I blogged about measuring IT admin productivity, but in the case of DBAs, it appears there is not even a consistent set of expectations regarding what to expect from them, let alone measure their productivity.

Alright first things first! Has anyone come across a good DBA Workbook? I’m not even talking about a cookbook with step-by-step instructions on how to do different tasks, but just a preliminary workbook that documents exactly what the heck they are supposed to do.

So, what’s goes into an average DBA’s work-day? As I work at multiple companies, I see DBAs doing things all across the gamut - from ensuring backups are proper to tuning SQL statements to even writing stored procedures! It seems DBAs in many environments either gravitate towards what their predecessors used to do (and try to meet expectations that were set way before their time) or end up catering to whatever the loudest squeaky voice tends to ask. Sometimes I see DBAs being grouped into teams of specialists – like Operations DBAs (aka Systems DBAs), Application DBAs, Development DBAs and Engineering DBAs. I’m myself partial to having the DBAs segregated into not more than 3 groups: say, the Operations DBA team, a Development DBAteam and optionally, an Application DBA team (especially if the environment has large complex ERP/CRM type implementations). I don’t see the need for additional silos such as Engineering DBAs or Build DBAs; instead I view them as more of an area of focus for personnel within existing teams. For instance, each DBA team needs to have Tier 3 personnel that are responsible for Engineering-type DBA work like defining standardized database configurations. Anything more than 3 core teams tends to prevent economies of scale and can create workload imbalance in my experience (at any point in time, you may find one DBA group to be super-busy while another is relatively sitting idle or working on low priority activities). Similarly, creating too many silos can also lead to islands of institutional knowledge wherein none of the DBAs have a comprehensive understanding of the entire IT stack – from the database to the OS and storage, and all the way back to the application. A siloed lop-sided view can prevent effective root cause analysis during problem management.

It is also not uncommon to find sub-groups within the 3 main DBA groups based on DBMS platform (Oracle team versus SQL Server team, etc.) and OS platforms (UNIX DBAs versus Windows DBAs). The former sub-category tends to be more prevalent than the latter. However I’m increasing finding DBA managers interested in building cross-platform awareness. As leading DBMS platforms begin to display similar capabilities, databases are increasingly getting commoditized. Also with different 3rd party applications requiring multiple DBMS platforms as well as changing business requirements (say, the occasional M&A) casts more pressure on a DBA team to manage heterogeneous platforms. Furthermore, decision automation platforms like Data Palette help create an “abstraction layer” across physical DBMSs allowing DBAs skilled in one platform to be productive on others. So in the future, we may be seeing even less of a need for platform-based sub-categories.

Alright, so here’s a stab at a preliminary DBA workbook. Please feel free to adopt it as you see fit (since clearly there is no such thing as a “single size fits all” here.) This workbook is not supposed to be a precise guide for what DBAs in your specific organization should be working on, rather it’s meant to serve as a starting point template for you to customize per your business requirements. But do bear in mind that if you find the need to reinvent it completely, then perhaps you don’t really need a DBA, it’s some other role you are seeking to fill. So in other words, consider a 10-20% deviation from this definition as reasonable.

All you DBAs and DBA Managers out there – I would love to get your input on what you feel is right or missing here. Hopefully this can develop into a common definition of what should constitute a legitimate scope of work for DBAs. Such a definition sets expectations both within and outside the DBA team, and fosters higher collaboration. It should help managers analyze gaps in DBA scope of work in their own organizations, as well as identify gaps in skill-sets for future training and hiring. And the best part is that such a workbook can be linked to an SLA (that outlines the service levels the DBAs are responsible for achieving), and last but not least, be the pre-cursor for a more detailed cookbook comprising specific run-books for recurring (and some non-recurring yet complex) operations. The goal is to reduce surprises for other groups and avoid DBAs having to hear users and customers say things like “oh, I expected our DBAs to do more. In my previous company, they did so much more…”.

Also, if you ever venture into a DBA outsouring/co-sourcing arrangement with a 3rd party vendor, this can serve to delineate what you expect the vendor's DBAs to do versus your own team.

Operations/Systems DBA Workbook
- Database backups
- Database recovery
- Implementing robust change control and configuration management policies
- Capacity planning & system-level architecture
- OS/Storage/DB configuration and optimization
- Database security checks and audits, including compliance-related reporting & controls
- General database health checks
- Database monitoring
- Working with DBMS support (Oracle Support, Microsoft Support, etc.)
- Defining and maintaining quantitative SLAs and helping enhance current service levels
- Physical data model/architecture, DDL generation and maintenance
- DB server migrations and decommissioning
- Database creation and configuration
- Applying patches
- Upgrading the databases from version X to version X+Y
- Maintenance (proactive, reactive and automated); both scheduled and unscheduled
- Database refreshes
- Log-file review
- Trouble-shooting and repairs
- Reporting on state of databases
- Database tuning (proactive and reactive)
- Maintaining specialized environments such as log shipping, replication, cluster-based instances, etc.
- SOP (Std. Operating Procedure) definition & automation
- DBMS and related tools license management
- Documentation related to all Systems DBA areas
- Management of database-related tools (monitoring systems, tool repositories, etc.)
- Automated measurement of quantitative SLAs & any deviations thereof
- Development & utilization of detailed triage processes
- Detailed user workload analysis & segregation
- Infrastructure advise and planning
- Disaster recovery/failover services


Application DBA Workbook
- Setting up application/reporting environment
- Loading flatfile data into the database (script setup, automation & troubleshooting)
- Database cloning
- Application back-end process design and management
- Carry out application-specific trouble-shooting and reactive repairs
- Application configuration and setup
- New application implementation and upgrades
- Creating and implementing application security policy recommendations, including compliance-related reporting & controls
- Data management and manipulation. For example, ensuring data cleanliness, validating scrubbing rules, addressing batch job failures due to bad data (referential integrity violations, etc.)
- Perform application workflow analysis, characterization and segregation to reduce workflow and data-related failures
- Define triage and escalation procedures for each application failure such that appropriate parties can take ownership of specific issues during problem situations
- Liaison with 3rd party application vendors (e.g., Oracle/PeopleSoft Support) for support and trouble-shooting
- Work with in-house Development DBA and Development team in longer-term proactive application repair and re-architecture
- Application DBA related documentation and cross-training
- Assist QA in building and implementing test plans to validate and test application bug fixes, patches and upgrades
- Evaluate recurring/common application failures and define application “Repair SOPs” so that similar application failures get handled in a consistent manner.
- Strengthen application architecture for better performance and scalability and reduced failures - Working with the Systems DBAs on application/database integration (example: integrating two databases, etc.)
- Working with the Systems DBAs on configuring the database to optimally accommodate each application (example: providing consultative input on tasks such as data sizing, capacity planning, custom setup of memory structures and disk layouts, etc.)


Development DBA Workbook
- Specialized database SQL tuning
- Documentation related to all pre-production DBA areas and cross-training
- Participate in application and database design reviews
- New development projects implementation
- Logical data modeling and architecture
- Logical to physical design conversion
- SQL tuning
- Developing and deploying DDL/DML coding standards
- Coding (or recoding) of specific database modules for enhanced database/application performance
- Database code (DDL/DML) version control
- Scripting and testing schema builds and new rollouts
- DBMS software installation, configuration and management for development database environments as per standards set in Production (by Systems DBAs)
- Data cloning within development environments
- Training Developers on writing optimal SQL code
- General liaison between Systems DBAs and Developers
- General liaison between Systems DBAs and Application DBAs
- Change-control guidelines and provisions for new project implementations
- Assist QA in building and implementing test plans to validate and test pre-production DB bug fixes, patches and upgrades; as well as assist in stress/volume testing.

How Do You Measure IT Admin Productivity?

A key part of my job is to carry out operational maturity assessments for different organizations. This helps me understand where a given IT admin team (usually DBAs, sys admins or app support teams) currently is (chaotic, reactive, proactive, etc.), where the business needs them to be, and how to bridge the gap in the shortest amount of time.

During the course of these assessments, I run into two kinds of IT administrators – the folks that view the extent of automation I (or their managers) advocate as a somewhat scary proposition and state that they wouldn’t want to jeopardize their environment by automating beyond a certain (rather basic) level. They claim to take complete personal responsibility for their environment and do what it takes to minimize risk in the day-to-day functioning of the company, by manually performing tasks that are considered critical to keeping the lights on. Let’s call this group the reluctant automators.

Then there are the folks that are eager to push the envelope to see how far and how fast their environments can embrace automation. Let’s refer to this group as the eager automators.

The latter group seems to view their jobs as something beyond keeping the lights on; they view their role as that of an enabler - wherein they allow business groups to focus on the organization’s core competency. Take for instance, a brokerage firm whose primary business function is to trade stocks profitably for their customers. This creates a primary layer of business users - the traders that trade the stock, and multiple peripheral teams that support the primary users and enable them to be successful. In most organizations where technology is not the core offering, IT admins tend to be a part of the peripheral layer.

Reluctant automators often fret about formal interactions with other groups and are usually disassociated from the primary business users. They view meetings as a time-sink; something that takes them away from their “real work” – i.e., doing things on their computers – things like moving data, keeping the configuration current, viewing log files, etc. – all relevant things, no doubt. They frequently view the keyboard activities as the “brainy stuff” and a meeting tends to be an activity where they can actually space out… (you know what I’m talking about, you have run into those folks with the vacant stares in meetings…)

The eager automators on the other hand, often state that repeatable things (the same ol’ stuff like moving data around, viewing log file output and updating configuration) leave them brain-dead and hence they can’t wait to automate them off their day-to-day workload (or at least semi-automate them such that they can be reliably offloaded to less senior people!) They manage the mundane by exceptions and use the freed up time to instead work on defining crisper user requirements and service levels, measuring deviations in performance and managing them. These kinds of activities require them to spend a lot of their time in meetings – with users, project teams and infrastructure peer groups. Even though some of these meetings are badly run (and are indeed boring), they have learnt to embrace these as opportunities to get better aligned with the business, understand growth trends , share insight and influence behavior.

So here’s the paradox that I (and I’m sure, countless IT managers) frequently run into. Given these two IT admin profiles, who is more productive? There is often a tendency in corporate America to mistake hard-work for higher productivity. But here, I don’t necessarily mean more hard-working in the sense of someone working 80 hours a week. Rather, who gets more stuff done? (Assuming there is a standard and reasonable expectation of “stuff” or job output/quality, in the first place.)

Both groups comprise ethical, hard-working people who usually put in way more than 40 hours per week to earn their salaries. However both camps are equally adamant that their outlook is the right one for the company.

I have my own thoughts on the matter (will post them in a future blog), but which school of thought do *you* subscribe to? And why is that appropriate? Unfortunately, there is no universally accepted HR manual that helps us decide whether one notion is better than the other.

And more pertinently, regardless of immanent viewpoints regarding individual employee performance, how can a manager quantitatively measure something as seemingly subjective as productivity? Good processes such as ITIL seem to help some by allowing work activities better documented by exposing # of service requests, # of incidents handled, etc. as well as time put in. However this information is often too uni-dimensional and does not share the complete story. For instance, it does not always take into account factors such as which incidents were truly avoidable and which service requests were redundant or occurred due to incomplete work done in the first place! And often, in many environments, IT admins get away with incomplete ticketing records. (So not all activities are logged into the ticketing system, and the information that gets logged is not always consistent or complete.)

Conventional IT management does not appear to provide an easy answer to these questions… how do you deal with it?

3 Predictions for MySQL Post Sun Acquisition

The $1B acquisition of MySQL by Sun didn’t seem to get its fair share of publicity with the gargantuan $8.5B same-day acquisition of BEA by Oracle. Nevertheless it was a monster payout for MySQL, which finally has the opportunity come into its own. With Sun’s stewardship and products like Stratavia’s Data Palette providing automation functionality for MySQL, it finally has the opportunity to overcome its two primary weaknesses: (a) lack of proficient support tools and the resultant perceived lack of stability and scalability and (b) lack of personnel with adequate proficiency in managing enterprise class installations. These flaws have frequently relegated MySQL to a third-tier DBMS platform behind the usual suspects (Oracle, SQL Server, DB2), even legacy platforms (Sybase, Informix) and alas, nimbler open-source and pseudo open-source platforms (PostgreSQL and EnterpriseDB). The digerati have it pinned as being suited for merely small shops and/or small LAMP apps, in spite of some robust enterprise-class functionality in the newer releases.

With the acquisition, I predict 3 things to happen to MySQL in the next 12-24 months:
1. Enhanced native support (finally!) – More native tools for MySQL, especially better monitoring and ad-hoc GUI tools, which will greatly enhance DBA productivity and allow DBAs from other platforms to take on a more favorable disposition towards MySQL. Regardless, as in other DBMS platforms, there will always be gap between DBA demand and supply and MySQL-savvy automation products such as Data Palette will continue to be seen as a viable option to fill part of this gap.
2. More partner activity - With Sun’s partner-base being substantially larger than MySQL, more ISVs are likely to pay attention to the latter and begin to establish a tertiary tools eco-system – including better migration, upgrade and patching tools, data load/unload utilities and more robust maintenance and backup capabilities.
3. Higher innovation – With Sun’s reputation for innovation especially in areas open source, MySQL should come into its own with functionality matching and hopefully, surpassing the mainstream DBMS platforms (a smaller legacy footprint usually enables faster innovation…). Even table-stakes capabilities such as an enhanced SQL optimizer, partitioning and index-types for handling large data-sets without crashes/corruption would go a long way in building credibility for MySQL as a platform that can be relied on for mission-critical enterprise class deployments. These would also make it alluring for ISVs that are looking for more cost-effective options for embedding databases within their products. (I would think the latter would be an especially strong target market for MySQL, especially once the restrictive licensing issues are resolved…)

I still don’t expect a lot of automation capabilities for MySQL right out the chute. Funnily enough, I have been presciently upbeat about MySQL and had championed including out of the box support for MySQL within Data Palette a couple of years ago. While customers have appreciated that capability, ironically enough it was never a make or break deal for us (even with customers having some serious MySQL presence); just icing on the cake. However with the acquisition, I’m predicting MySQL will find more mainstream adopters for both itself and its supporting ecosystem making that early investment in MySQL automation capabilities worthwhile for Stratavia.

Go MySQL! And go Sun for stepping up to the plate! Pretty soon it’s going to be time to make it real… perhaps starting with fixing that open-source licensing model…?

Who is to blame for Oracle patch application failures... Is that even a real question?

I just read a revealing blog entry by Jaikumar Vijayan about how two-thirds of DBAs miss timely and accurate application of Oracle’s quarterly critical patch updates and subsequent objections from some quarters regarding how this is showing DBAs in a bad light! Wow, I gotta say I sure don't agree with the latter view-point!

Honestly, I don’t think the article quite alludes that DBAs are to blame for this. However that is indeed my assertion. I have been in databases for over 16 years and as a Systems DBA, I consider myself and others like me to be the primary custodian of my company’s (and clients’) most important asset - data. To imply that somehow lack of corporate security standards in this area or lack of visible threats such as Slammer is sufficient grounds for ignoring patches is hare-brained in my humble opinion. I consider it my job to come up to speed on the latest patch updates, document the decision to apply the patch (or not!), educate and work with the security auditors (internal and external) if any, and ensure the databases I’m responsible for are totally secure. Not doing that is akin to saying, “oh, it’s okay for me not to test my database backups unless some corporate mandate forces me to do so.” Database patches, like auditing backups, forms one of the most basic job functions of a DBA. Claiming ignorance or being over-worked in other areas doesn’t count as an excuse, especially after your customers’ credit card data has been stolen by a hacker!

A comment to the above story by Slavich Markovich (one of the people quoted there), says that DBAs are not lazy and goes on to state that they just have too many things they are working on. Since when has a DBA not been “over-worked”? Way too often, that’s been part of the DBA’s job description – even though it doesn’t have to be that way. I know many fine DBAs that regardless of their work-load or corporate politics or prevailing state of ignorance, don’t let themselves be stopped from applying the relevant CPUs. They research the patchset, educate their peers, security groups and auditors, evangelize the benefits to application managers, arrange to test it in non-production and coordinate the entire process with change control committees to ensure its success.

Markovich lists several items in his comment that supposedly deter DBAs from adhering to a regular patch cycle. I’m taking each of his points one by one (in red font below) and responding to it:
1. The need to test all applications using the database is a heavy burden => yeah? so is coordinating and testing backups, deal with it!

2. Oracle supports only the latest patchsets => Oracle’s patch-set frequency and support policies tend to vary from version to version. Rather than making bland, generic statements, log onto metalink, do the relevant research, see what patch-set applies to which databases in your environment and go, make it happen!

3. The lack of application vendor certification of the CPUs => sure, certain CPU patches sometimes impact application functionality, but the majority don’t. Regardless, that’s what testing is for – to ensure your application functionality is not negatively impacted by a patch-set. If the testing shows no adverse impact, do a limited deployment and then move to a full deployment of that patch-set. CPUs are released by Oracle almost every quarter, so don’t expect all 3rd party vendors to update their certification matrix quite so rapidly. And BTW, most application problems that are suspected to have been caused by an Oracle CPU can be traced back to an error in the patch application process (why bother reading all the patch-set release notes, right?)

4. The simple fact that it takes a huge amount of work to manually shutdown the database and apply the patch in an organization running hundreds if not thousands of instances => if I had a nickel for every time I heard this… dude, ever read of run book automation for databases? If you are still stuck dealing with manual task methods and scripts, you only have yourself to blame. (Do yourself a favor, check out the Data Palette automation platform. )

5. For production critical databases you have to consider maintenance windows which might come once a year => ever heard of rolling upgrades/patches? If your environment isn’t clustered or lacks a standby environment, work with the application and change control committees to negotiate more reasonable maintenance windows or even better, build a business case for a Data Guard implementation. Remember, to be a successful DBA in today’s complex IT environment, you can’t just be a command-line expert, you need to possess good communication skills, not to mention salesmanship. Use those skills to jockey for reliable service levels – which includes, a well-patched and secure database environment. Don’t just attempt to live within the constraints imposed on you.

6. The lack of understanding by some IT security personnel of the severity of the problem simply does not generate enough pressure in the organization => quit blaming others, you are responsible for those databases, not some arcane person with a fancy title that has “security” somewhere in there.

7. All in all, I know of companies that analyze and deploy CPUs as soon as three months after release but those companies are very few and usually have budgets in the millions for such things… => also, quit generalizing. There are many DBAs that work for small, private companies with miniscule budgets that take their Oracle CPUs very seriously and vice versa.

The truth is, a secure, stable and scalable database environment has very little to do with the size of the budget and everything to do with astute DBAs that think outside the box and take charge of their environment.

Gartner Show Highlights Need for More Intelligence in Data Center Automation

Gartner’s recent Data Center Conference was a blast! Between technical sessions, booth duty and a joint presentation on Data Center Economics with a client (Xcel Energy), I managed to sneak in a round of golf at Bali Hai (first time I ever played with a caddie…). While attendance at the event (3 to 4K maybe) was certainly not the highest in recent events, the conference sufficiently put the spotlight on 3 key areas: virtualization, automation and green data centers (in that order). Having been seen as the red-headed stepchild for the longest time (as compared to virtualization), it was good to see automation finally beginning to garner its fair share of attention (and IT budgets!).

There were dozens of tools and technologies with an automation theme. Not surprisingly, automation is also basking in the glory of the ripple effects from virtualization and green data centers. With virtualization boosting the number of “server environments”, each of which need to be individually monitored and managed, automation is being increasingly regarded as the other side of the virtualization coin. Similarly, with the awareness for green data centers increasing, I’m beginning to see innovation even in areas as obscure as automating the hibernation/shutdown of machines during periods of non-use to reduce energy consumption.

So given the plethora of tools and products, is every automation capability that is needed out there already invented and available? Not so. One of the biggest things lacking is “intelligence” in automation. Take for example run book automation toolsets. While many of them offer a nice GUI for administrators to define and orchestrate ITIL processes, they inherently introduce a degree of rigidness as well in the process. For instance, if there are 3 run books or process workflows that deal with server maintenance, the Maintenance Window is often hard-coded within each of the workflows. If the Window changes, all 3 of the workflows have to be individually updated. That creates a significant maintenance overhead. Similarly, if a workflow includes a step to open a ticket in BMC Remedy, the ticketing system’s details such as product type and version are often hard-coded. If the customer upgrades the Remedy ticketing system or migrates from Remedy to HP Peregrine, the workflow doesn’t function anymore! An intelligent process workflow engine would avoid these traps.

An intelligent automation engine is often characterized by the following attributes:

Centralized policy-driven automation – Policies allow human input to be recorded in a single (central) location and made available to multiple downstream automation routines. The Maintenance Window example above is a great candidate for such policy-driven automation. Besides service level policies (such as the Maintenance Window), areas such as configuration management, compliance, and security are well suited for being cast as policies.

Metadata injection & auto-discovery – Metadata is data describing the state of the environment. It is important for automation routines to have access to state data and especially be notified when there is a state change. For example, there is no point in starting the midnight “backup_to_tape” process as a 4-way stream when 2 of the 4 tape drives have had a sudden failure or are offline. The automation engine needs to be aware of what is available so it can launch dependent processes to optimally leverage existing resources. Such state data can be auto-discovered either natively, or via an existing CMDB, if applicable.

Event correlation and root cause analysis – Ability to acknowledge and correlate events from multiple sources and being able to leverage this information to identify problem patterns and root cause(s) would make automated error resolution more precise.

Rules processing – Being able to process complex event-driven rule-sets (not just simple boolean logic) allows triggering of automation in the right environments at the right times.

Analytics and modeling – Being able to apply dynamic thresholding as well as, analytical and mathematical models to metadata to discern future resource behavior is key for averting performance hiccups and application downtime.

During the Gartner show, I walked by many of the booths looking at what these supposedly “bleeding edge” vendors offered. Suffice it to say, I wasn’t dazzled. Rather than providing just asinine glue (which unfortunately, is what most of the current crop of process automation and orchestration tools are reduced to) to piece together multiple scripts and 3rd party tool interfaces and refer to it as “automation”, the customers I work with are increasingly interested in seeing offerings that leverage the above capabilities. Other than Data Palette, I don’t know of any products that do so. But then, you already knew that!

Data Palette 4.0 is out! Why should you care?

On October 1, Stratavia released version 4 of Data Palette. I have been looking forward to this event for the following reasons:

1. Version 4 extends Data Palette’s automation capabilities to areas outside the database - to cover the entire IT life-cycle. This extension centers around three core areas:

• provisioning, including server, storage and application provisioning;
• service request and change management automation (e.g., operating system patches, application rollouts, system upgrades, user account maintenance, data migration, etc.); and
• alert remediation and problem avoidance.

2. It expands Data Palette’s predictive analytics to storage management and capacity planning.

3. Further, it allows using these predictions, combined with root cause data and event correlating rule sets to enable decision automation for fast-changing heterogeneous environments.

I realize this release of Data Palette casts a rather wide net in the data center automation realm. However this is not mere bravado from Stratavia and it is certainly not mere coolness (“coolness” being a bunch of widgets that make for good market-speak, but don’t quite find their way into customer environments). If anything, it reflects the fact that data center automation is just not doable without a broad spectrum of capabilities. For an automation strategy to succeed, it simply needs to cast a comprehensive net, connecting all the diverse areas of functionality via a shared back-bone (the latter being especially key).

Let’s look at a couple of contrasts to understand this better. Take Opsware for example. They started out with basic server provisioning and then realized there’s more to automation. So they gobbled up a few more vendors (Rendition Networks for network provisioning, Creekpath Systems for storage provisioning and iConclude for run book automation) that couldn’t quite hack it on their own. Then before Opsware could expand any further, they ended up being bought by HP.

Another example is BMC – a relatively late entrant to the IT automation space. After wallowing in enterprise monitoring and incident management tool-sets for years, BMC made headlines a few months ago when it acquired run book automation vendor RealOps. It followed that up with the recent purchase of network automation provider Emprisa. I’m sure we will continue to see more purchases from HP, BMC and others as they continue to fill out the automation offerings in their portfolio (and try to stick them all together with bubble-gum, prayers and wads of marketing dollars!)

Buying a bunch of siloed (read, disjointed) tools does not an automation solution make! Why? Because there is no shared intelligence across all these tools. There is no singular policy engine commonly referenced by all of them. There are no central data collection, event detection and correlation abilities. When you define policies or rules in one tool, you often need to repeat the same definition in different ways in the other tools, significantly increasing maintenance overhead. When a policy or rule changes, one needs to go to N different places (N being all the locations where they are defined separately) – assuming it is even feasible to recall exactly all the areas that need to be updated. If you have more than a couple of dozen automation routines in place, good luck trying to reconcile what these things do, what areas they touch and what policies are duplicated across them.

In the case of Data Palette, this issue is addressed by its central Expert Engine architecture. This engine allows shared use of policy and metadata definitions. They get defined once and can be referenced across multiple automation routines and event rule sets. In other words, all the different areas of functionality and touch-points speak the same language.

Stratavia has dubbed its 4.0 release as the industry’s “most intelligent” data center automation platform. Obviously intelligence can be a subjective term. I actually see it as the most comprehensive data center automation platform of its kind (look Ma, no bubble-gum…).