Monday, 29 September 2014

What's Really Needed for Solution Selling - DevOps for Vendors?


Solution selling has been held at the pinnacle of achievement by IT vendors for a long time. The goal is to become the trusted advisor to the customer and, ideally, so integrated into their strategy & decision making process that sales simply happen as a side effect.

This isn't as easy as to achieve as the corporate bods who run sale training programs would like to think:  a couple of years ago the Harvard Business Review published an article describing how conventional solution selling has reached the end of its usefulness, especially when the "solutions" being applied to customer problems are really just pre-packaged configurations of what products are available "on the truck".
The hardest thing about B2B selling today is that customers don’t need you the way they used to.
 – Brent Adamson, Matthew Dixon and Nicholas Toman in Harvard Business Review (July 2012)  
The thing is, given the Internet and other ready sources of information, many customers no longer need to approach vendors simply to acquire data about products and capabilities. Customers are also naturally suspicious of the "sales" approach, not wanting to be either baffled by (or simply subjected to)  techno-babble or waste valuable time when they perceive that a vendor simply has a quota to meet.

What they do need, whether they know it or not, is someone to help take them on the journey past simple product selection and into design and deployment stages with deeper insight than they can manage themselves. This is clearly evident by the large number of "vendor neutral" consultants that are often found floating around major projects. Of course, the the challenge that these consultants often have is they lack the detailed design & implementation knowledge required to take full advantage of the technologies purchased by the customer, and also don't have access to the back-line support to engineering & product teams for detailed assistance.

This is where vendors can really help the customer by integrating the sales, design and delivery portions of their organisation. With simple feature & product comparisons already done by the customer's online research, the sales team can become more valuable by being really involved with the design process, and helping see this through to implementation (& even beyond).

Sadly, all to often corporate structures aren't set up to cope with this idea: too often there's a strong demarkation between sales and delivery, with only a few very large customers having access to a team of solution designer[1] and professional services delivery people as part of a vendor relationship. The difficulty is further compounded, even in these cases, by the separation of profit & loss for sales, professional services and education. Of course it's important to measure performance, but in complex sales situations the complete solution is almost always going to be a combination of product, services and training.

What IT vendors need is to have someone (let's call them a solution architect[2]) to take the customer on the journey from idea to deployment. What I mean by that is to have someone who will listen to (and help document) the customer's requirements, be involved in pitching a solution concept, work on a developed design, and then guide the customer (and perhaps a larger team) through the implementation phase to successful operation.

The Architect - by BoonieT
This may be easier said than done, as it requires a skill set and temperament to see things through from inception to deployment, and may include the need for project management skills if the architect is to lead a team of others, especially if they are from other organisations. The biggest hurdle, though, may be entrenched corporate structures or simply industry culture in the vendor organisation. This is clearly a significant role, yet the prevailing wisdom is that "sales" jobs are more senior/appealing/lucrative than "implementation" roles. Even if senior, technically-competent people exist in an organisation, it is often the case that such folk are seen as being "too valuable" to tie up on on account or one project for a long time: either they need to get on to the next sale, or fight some fire at another customer.

This is where the traditional concept of separating sales and implementation needs to be changed, to be thought of as simply different phases along the same continuum. Perhaps this idea is really a vendor version of devops.

Of course, operations is where the real rubber hits the road, more on that in a later post.


1 - I studied "real" architecture - buildings and suchlike - so the application of the word "architect" to stuff we do in IT often seems wrong to me

2 - This is more like what a "real" architect does, so I'll consent to use the term here

Saturday, 20 September 2014

Can Open Source Help Solve Unemployment?



The other day on the way from yet another airport to yet another hotel, I was chatting with the taxi driver who was interested in what I did. Inevitably, the taxi driver was not really a taxi driver, but just doing it as casual work while he looked for a real job.  He had a degree in electrical engineering, but like a lot of young people was finding it hard to get that first job since he lacked experience.

His story isn't unusual – according to The Smith Family's Dr Lisa O'Brien, Australia (like other countries) is facing record youth unemployment, with many candidates lacking job-ready skills.  Now having that university degree is probably going to help, but even this is no longer a guarantee of employment without experience.

So what has this got to do with Open Source?

Put simply, getting involved in an open source project is a great way for anyone to show that they can contribute in a meaningful way, work well with others, and develop skills and experience that can be directly transferred to a work environment.

The barrier to entry for open source projects is very low – you just need to show an interest in getting involved. In fact, it's not even necessary to be a proficient coder: open source projects often have more need of usability testers and documentation writers than programmers.  Although higher education can help with developing programming and project management skills, many open source projects have contributors who have not yet graduated or may not yet even be of university age.

The results can be quite dramatic: open source companies like SUSE frequently recruit new developers from the ranks of active contributors, and often look for open source experience & reputation rather than demanding formal qualifications.

What this means is that even without a particular degree or even paid work experience, involvement in open source can open doorways into an IT career, in a way that is relatively easy to access.

Just another reason why open source is increasingly important.



Wednesday, 3 September 2014

Bits and Bytes: SUSE® Cloud 4 OpenStack Admin Appliance – An Easier way to Start Your Cloud

Bits and Bytes: SUSE® Cloud 4 OpenStack Admin Appliance – An Easier way to Start Your Cloud: If you used the SUSE Cloud 3 OpenStack Admin Appliance, you know it was a downloadable, OpenStack Havana-based appliance, which even a non-technical user could get off the ground to deploy an OpenStack cloud.