I was happy to be invited by Brian Prince at eWeek to answer some questions he had posed to Pythian, NTirety and industry analysts Noel Yuhanna of Forrester and Peter O’Kelley of the Burton Group.

You can take a look at the end result here: How to Decide if Remote Database Admins are Right for you.

I found the process interesting. I had actually provided a lot more content, which I include below, and I strenuously disagree with some of the analyst statements, especially the statement that the processes must be totally licked before engaging an external vendor. Are all the other vendors staffed with rookies following established processes and that’s it? It’s a very strange statement to make given that many, most of our customers turn to us to help them define best processes in terms of capacity planning, availability optimization, and security. It’s specifically contradicted by Corey’s statement about how his shop optimizes and automates processes. We do the same thing, of course, and we routinely inherit shops with tons of low-hanging fruit where we can dramatically streamline the efforts.

Then again, maybe Noel is thinking of dbaDirect. If I may say, “eeks!”. Anyway, not all companies in this space are made alike, I guess.

I think it would be interesting for most to read the article linked above, and compare with the following answers to his questions that I provided to Brian, mostly because it generates some respect for the challenge of cutting down content, and also because it illustrates to what degree the media selects sources and answers in support of its pre-established story. Fascinating, no?

1)What are some of the benefits of taking a remote DBA approach to database administration?

There are several benefits that I could list, but ultimately it becomes a matter of resource availability and agility. With an outsourced provider, more technical skills are on tap, at all hours of the day, with more escalation support and for more weeks of the year than with a fully insourced strategy. Furthermore, agility is greatly increased as the service provider can scale with the project needs and the likelihood that the service provider has already performed a task or a project is much, much higher than for a single in-house hire. This can dramatically reduce technology adoption inertia. In larger teams, I might mention that Pythian’s blended insourced/outsourced model allows a best of both worlds strategy to be implemented.

2)Talk about Pythian’s business model. How do you price your services to make them competitive with paying a FT DBA?

Pythian’s service model is a no lock-in, scopeless, linear cost-to-effort model that is disruptive to the traditional outsourcing model of flat monthly rates over a lock-in period.

In the traditional outsourcing contract, services are limited to a service level agreement (SLA) covering a strict scope of work, and the vendor’s profit model is centered around minimizing their costs associated with delivering that scope of work. This means that in traditional outsourcing, the vendor is literally motivated by the contract to deliver the minimum value-add as possible while still satisfying the arbitrary SLA, which is set during the lifetime of the contract, sometimes as long as 5 or more years. This problem is at the heart of what is wrong with outsourcing as currently conceived: no matter how successful the vendor is at automating, streamlining, tuning, and improving processes, the customer does not see any of those savings as they are paying a previously-negotiated rate.

Pythian’s model allows customers to subscribe to a fraction of a small team of engineers, with no lock in whatsoever so that the quantity of effort the customer requires is changeable on 30 days’ notice or can be cancelled for convenience at any time. This means that Pythian is constantly earning our next month’s renewal, which keeps us on our toes and keeps us motivated to add as much value as we can within the allotted effort level. Our profit model is customer-friendly and well understood: it is a simple mark-up model on our costs of service delivery. This means that as we automate, streamline, tune, and improve processes the customer gets to tap into those efficiencies, either by re-sizing the contract downwards to claim cash savings with no morale penalty, or by increasing the responsibilities that flow to Pythian without needing to increase the allotment of hours.

In smaller shops that might only need one or fewer full-time DBAs, our model is cost competitive because only the effort required to run the shop needs to be provisioned, and our processes, delivery model and expertise all couple to outpace our markup quite handily. Often, it is not an insourced vs. outsourced decision, however. In many larger shops, Pythian is engaged alongside the in-house team in order to dramatically increase the team’s capabilities, technical experience, availability at all hours and project support. Both use cases work very well.

3)How does an organization get in touch with Pythian in the event of an emergency? (ie, the database suddenly fails). How fast can they expect a response?

In the event of an emergency, the likelihood is that our monitoring software will have already alerted us and we will be on the job immediately. Generally, Pythian acts as an extension of the customer’s existing team and as such any method that the customer has adopted to collaborate is supported by Pythian. For instance, we use every third party instant messaging platform alongside internal platforms, email of course and telephones, and also videoconferencing and telepresence technology. Whatever the customer is using to collaborate with a resource working on another floor of the same building, we are also using. It is completely seamless.

Our response guidelines set the expectation that, in an emergency, a Pythian resource should be available on the affected system in single-digit minutes or less, all year round. Customers have live access to a backup engineer at all times as well as to a service delivery manager, for a total of three resources on-call. Our escalation guidelines allow our customers to engage the backup engineer and the service delivery manager immediately with no mandatory waiting period. Some of the systems we manage have downtime costs in the six figures per hour range, so this is the standard of care that we have implemented as a result.

4)What about other functions DBAs perform like providing end user and developer support?

This is a key advantage of the scopeless model that Pythian champions. Any work that the client wishes to flow to Pythian, we can do. This includes end user support, developer support, back-end development of triggers and functions, data modeling, data warehousing dimensional modeling, building transforms, input on best practices for security, business continuity planning and change control, you name it.

5)How does the process work with Pythian - are customers assigned a specific DBA for all their needs?

Customers are assigned to a small team of three to five engineers with an appropriate skillset to support the customer’s implemented technology. That team is led by a team lead which takes primary responsibility for the excellence in service delivery for the team, however a primary DBA is specifically not assigned, because one of the goals of the service is to isolate the customer from the pain of turnover, vacation, sick days, etc. and that goal would be compromised if we failed to disseminate the client knowledge evenly over a large enough team to be able to absorb that kind of change. Each team maintains an on-call schedule of its own, so that it’s always the same small group of people doing the customer’s support, which creates a client intimacy that results in Pythian becoming a seamless extension of the client’s tech team. Furthermore, each team reports to a service delivery manager, which has on-call responsibilities as well, so that the client has management support from Pythian at any time.

6)Doesn’t doing this effectively require an understanding of a business’s apps and processes? How does Pythian deal with that?

Of course. In this regard, engaging the Pythian team is no different than making a new in-house hire that happens to work in another office, or another floor of the same office. On day one, we will be contributing primarily our technical expertise while being complete rookies on the internal company-specific applications and processes. As time goes on, however, our expertise on the in-house specifics will increase much in the same way a new hire will gain that expertise over time. Among our 110 customers, Pythian has two customers that have been customers continuously since 1999, and ten customers that have been customers continuously since 2002 or earlier. For those customers, we are in a real sense the “old-timers” in the shop and are a key source of organizational knowledge for application structure, data model, and processes!