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?

Enterprise Service Bus

I have heard many very smart people talk about the benefits of the enterprise service bus (ESB). I like the idea and am familiar with brokers, subscribers, queues etc.

ESB’s work for developers and for the business systems they build. But the most recent context is to use the ESB as a configuration management subsystem to build complex cloud infrastructure.
It just wont work for the following reasons:

  1. ESB’s are the domain of developers; sys admins don’t understand messages, brokers and queues – you might as well be talking another language
  2. The complexity of the ESB makes orchestrating a solution very difficult
  3. ESB’s are not real-time, declaritive.

I wait with baited breath to see whether VCE has yet delivered its’ solution uisng SonicMQ.

Now, DevOps – that is an approach that might just work but it needs a more educated IT management specialist.

What to monitor and why it matters

In a previous post I made it clear that I am no believer in enterprise systems management.

In most cases ESM is nothing more than IT monitoring which has little relevance.

ESM adds no value yet it remains central to most modern IT strategies – the industry must do better.

Applications must be developed to address both functional and non-functional requirements; this means the use of instrumentation in the code. Developers are increasingly inserting instrumentation that helps search engines, data scientists / marketing so why are they not routinely coding for operations.

Few people in Operations challenge the norm and fewer still have developed the concept of a service or have direct exposure to customers. My approach is that I should only monitor services that have an SLA and an SLA should be about the performance of a service and not a single IT object.

We hve been through a cycle of in-sourced, out-sourced, off-shore and right-shored IT operations and they all have their merits.

Surely we are at a period where our operations approach should mature; the industrial revolution for IT where automation, computer-learning and autonomics drove ALL routine IT functions. The motor industry managed this transition so what is stopping IT?

My guidance :-

  1. Monitor the service [end-user experience that abstracts all IT]
    1. the experience of the user is key
    2. deviation from business norms is a good metric
    3. be careful of the calendar and of statistical outliers
  2. Present service health using language and with pictures that make sense to the business
  3. Ensure your services are properly described [with meta-data]
    1. enforce this rigour when developing|enhancing new services
    2. use a discovery methodology or maybe tool to determine what makes a service
    • this might make it sound like I am an advocate of the enterprise service bus; I am yet I have yet to see one implemented [not implemented properly, simply implemented]  so have some skepticism
  4. Alarm at the service-tier only
  5. Remove opportunities for prima donna
    1. develop operating procedures for common fixes
    2. automate [guided|fully] these procedures
  6. Integrate the change/release/testing cycles
    1. no change without a ticket, no exceptions
    2. forensically assess the impact of a release and an incident
    3. a change to the service demands that the service map is updated [automatically]
    4. expose fools and frauds

I must|might share my thoughts on enterprise service buses

The Value of Technology

Customers buy technology for three reasons:

  1. to reduce cost
  2. to reduce risk
  3. to enable them to do something that they cannot do without the investment

If someone tells you otherwise you are entitled to raise an eyebrow and it’s your decision whether to show them the door.

Vendors and especially cool new tech’ loves to pronounce that they are visionaries or have unique intellectual property and disruptive technology [so what?]. It is all about value.

I work for a software house and even I glaze over when I hear these terms. At the end of the day if I cannot show how the technology is relevant, reliable and can answer , 2 or all 3 of the points above I would not expect you to show more than a passing interest.

Tranditional licensed software vendors talk about buiness value but their modus operandi is to understand a clients pain in order to establish the optimum price for their software. Their commitment to your business and demonstrating both the value in the product and benefit you will achieve from working with their team is often spoken of but I think clients want something more tangible.

An emerging band of open-source advocates will tell you that they do not make their money by license but from service, support and throught the innovations they deliver to make the open-source software easier to manage [which is still packaged as a product].

How do you prove that the software will support your business needs, determine that the vendor is a good partner who will provide the required level of service and also determine that they will be in business in 2-3 years?


  • measure and track every interaction with the vendor from sales call through support
  • make support calls during any evaluation and test the response and also whether they can operate in your timezone and language
  • don’t let your technicians run an evaluation in isolation; they must test the solution and understand its’ architecture and how it will support your business
  • engage with service managers, line of business and end-users: develop use cases around how you plan to run this aspect of the business and even determine whether your supplier has enough vision to help improve the processes and even the capability to advise you as you deploy and mature

In parallel with the technical evaluation:

  1. work on the implementation and adoption plan
  2. establish the operating costs of the solution
  3. determine how you will partner and jointly deliver the value
  4. Create a realistic and defensible business case


  • if it sounds to good to be true……….
  • decide whether you can work with the supplier at all levels and especially whether you can solve problems in the bad times
  • meet the leaders within the organisation and ask yourself ‘do I / can I trust them’


  • develop a business case that you feel comfortable with; encourage the supplier to contribute but do not lose ownership and make sure you retain ownership
  • prove that the software works; works in your organisation and is applicable to the  way that your business operates [or will operate]
  • expand the evaluation to the point that you can understand and share a vision on the overall solution, how it complients your goals and where you expect to have problems
  • do not accept mediocrity. A supplier must show that they will go the extra mile – stretch every aspect of the suppliers service
  • establish your delivery team and ensure everyone is aligned, competent and personally responsible for success
  • do not delay but do not rush; if you do not know what the investment model or architecture is you are not ready to proceed
  • if you cannot specify how you will address the use case or do not know how to transform the organisation do not proceeed in the blind faith that it will come together in a miracle
  • hold your supplier accountable

Confused Cloud & clear thinking

"Clarity of Thought"

Space to think










Public, Private, Hybrid, Legacy – seems like mission impossible?

Cloud computing, whether delivered on-premise or by exploiting platforms such as Salesforce, EC2, Rackspace etc. is well within the grasp of anyone; just be clear what you want to achieve.

Remember Cloud is two things:

  1. Ubiquitos access – secure but available over the Internet
  2. IT delivered as a service; on-demand and with the implementation invisible to the consumer

Based on this definition you can probably see why I do not see exploting Cloud computing as a significant leap.

Caution must be advised when you engage with suppliers or you might be persuaded by your suppliers that Cloud is far more:

  1. An entirely new architecture such as Vblock [or FlexPOD for that matter]
  2. A 100% technology refresh running in isolation from legacy services
  3. VMware / HyperV or another flavour of virtualisation
  4. complete automation [even autonomics]
  5. Springsource
  6. A new, dedicated management stack

While it might be desirable to incorporate some of these aspects into your cloud strategy it is not mandatory.

Economies of scale might demand that you can support multiple tenants on a single infrastructure; but again this is not a technical requirement more of a commercial consideration.

If you build your own Cloud from the ground up you might find that you have missed the boat. Of course large enterprises still have a window of opportuntiy; but emerging service providers need something exceptional to get a foothold.

More to follow.


Joining it up

Lots of buzz about DevOps and a number of notable proponents.

I am a believer myself but will it make it to the enterprise and at what cost?

I certainly hope that some of the most admirable aspects do make it to the enterprise. I am particularly interested in:

  1. the speed with which devops can deliver by embracing automation and the eability to remove operational noise
  2. the take-up of pattern-based computing
  3. self-documented systems

And by the same token there does need to be an amount of control an compliance as new services are introduced. A free-for-all where any technology can be delivered into the enterprise is clearly a non-starter.

I will pick on 10gen / mongoDB since I have studied it a little and it has been massively [over]-hyped recently.

How can platforms like MongoDB make it into the enterprise successfully in the next 12-18 months?

  • first; what is the real business need
  • is there any tooling to help manage the environment
  • are there already tools that can do the same but don’t have the same appeal

Again, more pondering to do.

Converged Infrastructure = So What!

Dell, HP and EMC/Cisco have all jumped on the band wagon and been joined by some interesting startups too ( step forward Nutanix)

What is it all about?

A single pre-engineered system that incorporates storage, processing and networks.

Is this new?

No. Isn’t that what you got when you bought from IBM or DEC in the 90’s? And wasn’t this sort of system considered a risk due to vendor tie-in and replaced in favour of open, and more recently, commodity systems?

Nothing is black and white.

It is clear that many big IT shops spend too much time tweaking the hardware ad nauseum which does not add to the bottom-line for the business.

It can be argued that they have felt the need to do this because the right balance between cost, availability and performance come at the expense of good engineering.

The thing is however that hardware has become faster, cheaper and pretty much everything is a commodity CPU these days. Too much time is spent playing with tin while not delivering anything so the infrastructure guys only have themselves to blame for the re-emergence of the pre-built system.

While I want a guarantee of performance and availability the hardware really on matters a little. I want my hardware on the floor quickly and ready for me to run my applications nearly instantaneously; and I want to be able to deploy may applications at the touch of a button. So, sure, Converged might be good but I want self-service and I want it now.

Only you can determine if converged is right for your business. The primary sales propositions are:

  1. we do the engineering to deliver a secure, scalable, high-performance platform
  2. we certify it for specific workloads

The moot point is that you are delivering a ‘service’ and your service is hopefully distinct from that of every other service provider…….

  • so this certification……… is it actually worth anything; does the profile of your lync|UCS|SAP|PaaS mirror what got certified?

I reiterate: converged might be good but I want self-service and I want it now and that is a proposition about software and process automation!

Disclaimer: I  worked for VCE and Digital Equipment.


Great businesses always have great leaders.

I am priviliged to have worked for some of the greats in the industry but I have also worked for some who have a lot to learn (and some who unfortunately lack the capacity to become great).

I count Ben Horowitz and Ross Perot amongst the best. They hired well, empowered and gave people stretch goals. They supported and allowed people to acheive (deliver) in the manner that worked for themselves. Criticism was done in private and at the right time and support was always available to help reduce the risk of failure.

Leaders establish the strategy, direction and culture of the company.

Leaders show high levels of  integrity; they do not hide from an inconvenient truth and learn from previous experience.


Conversely poor leaders exist in an environment of fear and half-truths;.

Doing the same thing again and again and expecting to get different results is a sign of madness; It is important to learn to identify and move on from a failure; accepting something or someone has failed and learning the lessons of that failure and to move on in a positive manner is a positive management trait. Identify and address the reason for the failure; act in a positive manner and at the right time.

Consider the manager who cannot (will not) hire someone who is clearly exceptional and often better than they; such people are never too far away. Remember people and companies only grow and succeed by virtue of their people; accept help willingly, look to learn from everyone around you, stretch those who work for and with you and be prepared to forgive those who give their all but find that the task is ultimately beyond them (for the time being).

Don’t be afraid of someone elses strengths; embrace those strengths and learn to let them take flight.

If you believe that you, and only you, are qualified to fix every problem in your organisation then you are doomed to failure and more, you are likely the cause of many failures. Identify your strengths, identify those who will help you to become successful and your organisation to thrive and lead.

Belatedly my sixth sense is becoming finely tuned; belatedly!