DevOps engineers have existed since …..

DevOps engineers have existed since computing started….but they were called Engineers or sometimes Systems Engineers.

Engineers have not disappeared but they have changed.

Five things occurred which have had a serious impact on the ability of IT to deliver and they were mostly related to cost pressure and the limited skills available to support the enterprise. Each of the following have contributed:
1. the adoption of outsourcing is clearly one
2. increased IT compliance requirements and resulting regulation
3. the complexity that comes with increasingly complex products
4. off-shore development
5. workplace politics

Innovative people always have a response to these challenges, responses include automation, virtualisation and Cloud but they are not a silver bullet and you may notice that the contributors identified above are not technical but more closely linked to people and process.

In very few organisations are there sufficiently qualified, motivated and competent people to deliver working solutions. The system integrators operated in this field but their skills have been diluted by off-shoring.

Technical staff in the Enterprise have a huge wedge driven between operations and the business.

The most valuable resource any organisation has is its’ people. People who solve problems.

So perhaps the use of the term DevOps is helpful as it emphasises the capabilities of the real problem solvers in a business. Let’s just be careful because like too many other things in IT in particular everyone now seems to be a DevOps engineer.

The reinvention of Engineers who are focused on delivering fully functioning solutions is a positive thing; but did they disappear in the first place?

ps: a very smart boss of mine told me in 1996 that I was ‘build, implement and run’.
He used the term to help a failing project refocus; it was late, requirements and implementation were floundering and we were not being paid.

3 months later and after a lot of hard work with 3 people spending far too much time in one another company the project delivered and was hailed a success.

The phrase ‘build, implement and run’ sums up for me the whole DevOps movement. And the three adversaries in BIR are now my most trusted allies (a developer, DBA and system admin)


I’ve been thinking about self-healing and self-scaling computers recently – all of this really is quite achievable with todays’ technology but lack of insights into the business and fear are preventing it from happening.

The ever increasing speed of processors and advances brought about by cloud computing, especially in rapidly provisioned environments, make it possible.

The problem? IT Operations fear the use of these environments?

Are you a Thought Leader?

How is it possible to describe oneself as a thought leader?

Surely that accolade needs to come from ones peers and actually be reinforced by a consensus from many different sources.

Admission – I am not a thought leader ……

I have some great ideas and am able to articulate very well. I have hopefully helped others along the way solve problems, implement solutions but also develop their skills.

I am just a professional who studies hard, works on difficult things, is diligent and empathetic. If people get value from me in any way I am happy.



I currently work for Opscode who sponsor the Chef open-source project and supply commercial configuration management products.

I worked for Opsware Inc. a pioneer in the field of Data Centre Automation from May 2004 to July 2009. Including a short stay at HP who acquired Opsware in October 2007

Other previous employment (not chronologically ordered):

Aster Data: Now part of Teradata Corp.

Netuitive Inc. A Reston-based supplier of IT operational analytics software

VCE (the Virtual Computing Environment Company) formerly known as Acadia

Perot Systems Corp. Now part of Dell Services

Radan Computational: Now part of Planit

Digital Equipment Corporation (DEC): Now part of HP via Compaq

More on the shortcomings of pre-sales

Todays sales review call showed just how bad it can be.

The lead pre-sales engineer tells the team about a proof of concept he is just starting; no attempt is made to explain our objectivs or summarise  why we are talking. I see no understanding of value and qualification of the opportunity is zero; worse wtill he didn’t realise how lost he is.

If I ask what we are expected to prove to be successful and I hear a response that has no relevence to the client or their business I am dismayed and when the engineer recites the 3 or 4 features of the product I knew the game was lost. “We are going to prove our value by showing BAM, CE and correllation data”

I really cannot imagine that a customer would understand what this statement meant.

When proving a solution to the client the objectives must be stated using language and metrics that a client understands. While a technical requirement might be to capture customer experience data and business activity metrics the objective should be phrased in an entirely different manner.

“we will capture operational metrics in real-time that will help the client to detect fraudulent [erroneous, non-compliant] activities so that they can reduce operational risk [reduce IT costs through better utilisation] by ……”

The fact that no-one else on the executive team takes any real notice of the depths of the problem is most worrying.

After two iterations I still don’t know what the client needs, or whether they have even been asked to sign-up to any specific deliverables. And as for how to sell a vision and ultimately a solution – looks like I need to pull this back to the start and requalify.

It is no wonder why……

…our IT support departments have moved off-shore and I say that with no joy.

In my experience as an advisor to service providers I find the level of support and the manner in which it is delivered is poor; the underlying causes:

  1. 1st line support (in fact, customer service) is under-valued
  2. receives inadequate training and therefore shows limited competency
  3. suffers a very high workload
  4. and the problem is compounded by poor communications skills and/or desire to talk to the consumer.

However is the support provided by those off-shore teams any better or worse after the transition?