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
Big data is definitely a hot topic with opinion, discussion and polarisation amongst across the community. For me the most fundamental question I am considering is who can benefit most.
I am not sure if I am being unduly pessimistic or whether I have limited exposure but the only use I see being championed is in advertising, search engine optimisation and understanding the demographics of your customer. Important? Well, yes, but surely the advances in technology, creation of new platforms and emergence of ‘data science’ takes us beyond this!
Perhaps the limiting factor has simply been the economy and limited cash within the business and government. Maybe all of the companies IT resources have been focused on eke’ing out new customers or maximising the profit from existing one; I am not sure but I believe that the time is right for companies to look at increasing their use of big data at all levels; improving skills, exploring the new technologies and looking to invest in other areas where analytics and exploration can add competitive advantage.
There are clearly valid uses in government and security that might be considered unwelcome by some. Others could have a massive reach and bring benefits to a huge audience; the options for healthcare research, materials analysis, R & D, demographics, manufacturing are huge but largely unexploited?
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.
I often hear that selling should not be confused with implementing.
As with many such statements I hold two opposing views.
It is important to make the pre-sales process simple and ensure that the client understands the value of the solution that they are considering BUT equally important that the client understands the technical merits of the product and how they will implement and use it.
Don’t over-complicate the process but don’t treat me like an idiot.
Too many pre-sales people have only ever been in pre-sales; they lack operational knowledge and have no benchmark for the way that an organisation will work. I would not buy from someone who lacks the depth of knowledge and expertise necessary to deliver my project.
Pre-sales must prove they have the competency to implement my solution and guide me to use it: I need my pre-sales team to:
- develop the architecture for my solution
- advise me on the project plan; the whole plan including my activities – afterall they have done this before?
- articulate the assumption and likely risks they are making
- tell me what I must do to make the project successful
- lay out the milestones and measure of my project so I can judge success and risk
- work with me and my technical team to solve the inevitable problems that will arise during my project
How many of your suppliers are able to deliver this and how many of the pre-sales people are capable?
…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:
- 1st line support (in fact, customer service) is under-valued
- receives inadequate training and therefore shows limited competency
- suffers a very high workload
- 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?
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:
- ESB’s are the domain of developers; sys admins don’t understand messages, brokers and queues – you might as well be talking another language
- The complexity of the ESB makes orchestrating a solution very difficult
- 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.
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 :-
- Monitor the service [end-user experience that abstracts all IT]
- the experience of the user is key
- deviation from business norms is a good metric
- be careful of the calendar and of statistical outliers
- Present service health using language and with pictures that make sense to the business
- Ensure your services are properly described [with meta-data]
- enforce this rigour when developing|enhancing new services
- 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
- Alarm at the service-tier only
- Remove opportunities for prima donna
- develop operating procedures for common fixes
- automate [guided|fully] these procedures
- Integrate the change/release/testing cycles
- no change without a ticket, no exceptions
- forensically assess the impact of a release and an incident
- a change to the service demands that the service map is updated [automatically]
- expose fools and frauds
I must|might share my thoughts on enterprise service buses
Customers buy technology for three reasons:
- to reduce cost
- to reduce risk
- 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
- IT REALLY IS ALL ABOUT HOW YOU PLAN TO USE IT – THE NUMBER OF TECHIES I SEE IN THE BUSINESSES I SUPPORT WHO ARE LOST IN FEATURES AND FUNCTIONS AND IGNORANT OF USE CASES IS REALLY WORRYING
- 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:
- work on the implementation and adoption plan
- establish the operating costs of the solution
- determine how you will partner and jointly deliver the value
- 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
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:
- Ubiquitos access – secure but available over the Internet
- 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:
- An entirely new architecture such as Vblock [or FlexPOD for that matter]
- A 100% technology refresh running in isolation from legacy services
- VMware / HyperV or another flavour of virtualisation
- complete automation [even autonomics]
- 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:
- the speed with which devops can deliver by embracing automation and the eability to remove operational noise
- the take-up of pattern-based computing
- 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.