In comparison to many of its strategic competitors, IBM has been behind the curve in the small to medium enterprise (SME) space for many years now. Whether it’s hardware, email servers, platform software or development tools, IBM’s presence as a supplier tails off rapidly as we look below 5,000 employee mark in terms of company size.
So is it that IBM offerings are less suitable for smaller businesses than alternatives from Microsoft and others? Well not if you consider it on capability. IBM has invested a great deal in packaging and even designing solutions for SMEs under the Express umbrella, and doing a good job of making enterprise class technology accessible to those with more modest IT budgets and limited IT resources. So why the lack of market penetration?
There are a couple of contributors to this, the first being that other suppliers better managed the transition to commodity kit and software that swept the market during the 90s, while IBM was still focusing its efforts on higher margin proprietary platforms. The end result was a loss of position in the traditional reseller and integrator channel that serves the needs of the majority of smaller businesses when it comes to IT infrastructure. The likes of Microsoft and HP therefore largely took control of some important routes to market, and while IBM has been trying to catch up since, and nowadays has very much embraced commodity solutions as well as open standards within its portfolio of offerings, the gap that exists is still pretty big.
The other big contributing factor to IBM’s challenges in the SME space is the way in which technology is bought. Unlike large enterprises that make explicit investments in IT infrastructure improvement and evolution, the type of platform technology that IBM delivers tends to be pulled through more on the coat-tails of business application purchases in smaller organisations. This brings the companies who build and deliver those business applications, commonly referred to as ‘Independent Software Vendors’ (ISVs), into sharp focus. And when we look closely at these, the majority of them focused on SMEs are using non-IBM technology, e.g. from Microsoft and Oracle, to underpin their solutions at the moment.
In practical terms, the two factors we have been discussing are linked. If we think of it from a business perspective, ISVs generally need to focus on selling their own capability in the sales cycle. They really don’t want to waste time explaining to customers who are already familiar and comfortable with the Microsoft stack, for example, why the application they are offering is based on something else. To put it another way, if you are an ISV targeting the SME market, then building your application on Microsoft or Oracle technology has traditionally represented the path of least resistance and therefore the lowest cost of sale. This is a generalisation, of course, but it does lie at the root of why relatively few SME focused ISVs have bet their business on an IBM platform in recent years.
The exceptions are very interesting, though, and when you talk to IBM business partners you hear a couple of strong reasons as to why they ended up in the Big Blue camp. The first is technology and the feeling that IBM platform solutions are more open, standard, capable and scalable than the alternatives. The breadth of the portfolio is also a perceived strength for some, with solutions ranging from data warehousing at one end to systems management at the other. While Microsoft and Oracle could legitimately argue with most of these claims nowadays, it is clear that some ISVs believe the IBM foundation and backing provides them with a useful competitive differentiator.
The word ‘backing’ provides a clue as to the other big reason given for embracing IBM platforms as an ISV. While some we have spoken with allude to historical challenges interfacing with the complex machine that is Big Blue, they also highlight the rewards that are available if you can crack it from a partnering perspective. The general consensus also seems to be that while things are not perfect, the IBM partnership programmes are becoming progressively clearer and easier to access.
Against this background, it was interesting talking recently with three of the IBM executives responsible for overseeing ISV related activity in Northeast Europe – Robert Curran, VP General Business Channels, Melinda Matthews, Director of ISV and Developer Relations, and Aidan Troy, Director of Channel Sales. What struck me most about the conversation with these guys was that as they talked about their programmes and activities, the rationale for working with ISVs was consistently explained in terms of what was in it for the partner. This is in stark contrast to my discussions with people in similar positions within other IT vendors who are more inclined to talk in terms of partners being a route to market for product – a subtle but very important difference, implying a genuinely partner centric mindset.
Having said this, the IBM team were very clear about their objectives in business terms, and spoke in a realistic way about the need to ‘convert’ key ISVs in target industry sectors that are currently aligned with the competition, or at least get them to embrace elements of the IBM technology portfolio in a complementary manner.
The point was made that many of the acquisitions IBM has made over recent years is helping a great deal here. On the one hand, the broadening of the portfolio, often with products that already coexist and interoperate with other vendors’ technologies, provides more potential entry points into the partnership discussion. Then, of course, each acquired product has brought with it a partner base of its own, which provides potential win/win opportunities for some ISVs to extend their involvement with IBM through cross training and evolution of existing commercial arrangements.
We also spoke about the resources, facilities and education/coaching available to ISVs to help them from initial porting/development of solutions, through go-to-market planning, and ultimately sales and marketing execution. This is something I will pick up on in more detail in the future, along with some of the internal mechanisms in place to coordinate between product, industry and partner groups across IBM on both a local and international basis. Suffice it to say in the meantime that when you speak to senior management and tour one of the facilities geared up to supporting business partners (‘Innovation Centres’) as I have a couple of times now, the level of commitment IBM is making to driving and enabling its ISV community leaves little to the imagination.
So, I will be watching with interest, and indeed tracking through market research, the impact IBM’s efforts through the ISV and other programmes on its SME market share over time. It appears to be doing all the right things to make itself more relevant, and with ISVs having to deal with ever more complex requirements, I can see many of them tempted into the IBM fold by the breadth and depth of both the products and support on offer.
It’s not going to be easy though, and I don’t imagine for a moment that Microsoft, Oracle, HP, and other competitors are going to allow IBM into their partner bases without a fight, but from what I have seen, it is definitely a case of ‘game on’, so any ISV looking to re-evaluate the foundation for their solution would do well to check out what’s on offer from IBM. After all, when someone is coming from behind, they are often willing to put in a lot more effort to catch up.
Thursday, February 12, 2009
Tuesday, February 03, 2009
Don’t let Microsoft timescales dictate your Windows migration schedule
There is a lot of talk at the moment about desktop migration schedules. With the majority of enterprises still managing XP estates, the big question is whether to make a short term move to Vista, hang on and wait for Windows 7, or dig in and not think about it until you really have to.
A minority - typically represented by small tech-savvy professional services firms in the IT, engineering and media sectors, in particular - will take the uncertainty as a cue to investigate alternatives such as Linux and Mac OS X. This is a perfectly legitimate thing to do, but outside the scope of this article.
For most, the key question remains about when and how to move forward in terms of Windows releases. Having looked at the options, there isn’t a single ‘right’ answer to this that applies to every organisation. So what’s the best way to think about the issue and come up an appropriate plan?
A couple of things are worth bearing in mind as a foundation for the discussion.
First: the physical deployment of the operating system itself, i.e. getting the new version of Windows onto target machines, can involve significant operational effort, but the real cost and pain of most previous Windows migrations has been associated with testing and remediating applications, utilities, drivers and so on. We know from those who have already made the move from XP to Vista that this is not a trivial task in that particular case. Real compatibility issues are typically encountered with both commercial and in-house developed software that need to be identified, understood and fixed methodically. Tools exist that can help with the process, but there is no getting away from the need to treat the exercise as a properly planned, resourced and funded project if you have anything more than a handful of PCs.
Second: from what we have seen and heard so far with the beta version, Windows 7 is largely an optimisation of Vista rather than a generational leap forward. I am sure that Microsoft and others might debate this throwaway comment from various different angles, but the pertinent point is that software designed to run on Vista will very likely run on Windows 7 with no compatibility issues.
Microsoft’s claims here seem to be corroborated by feedback from beta testers. Indeed, it seems every man and his dog has now given it a whirl and is reporting positive experiences in developer communities and social media circles.
The upshot is that the bulk of the effort put into the ‘hard bit’ of an XP to Vista migration i.e. the remedial compatibility work, will not need to be repeated during a subsequent move from Vista to Windows 7. Of course it’s unrealistic to expect perfection, and you would be mad to assume compatibility without going through a full re-test of everything. But the chances are that most things will pass and need no further action, making the whole thing much less costly, time-consuming and risky.
So how does this help when considering migration strategy and timing? Let’s not pretend the situation is ideal, but at least it puts control of the decision back in your hands. With early experiences and Microsoft promises indicating a relatively small difference in effort between a two step (via Vista) and one step (skipping it) migration, the consequences of choosing one route or the other are not that great.
So it’s up to you, really. If it suits you to move sooner rather than later, then there is no need to hold back from implementing Vista for fear of having to duplicate a huge amount of effort. Yes, there will be additional work involved in the two-step journey you will ultimately be taking, but the second refresh will be much less daunting.
If you plan to wait for Windows 7 before rolling out your next major upgrade, you can begin testing and remedial work in advance using Vista. Having said this, the stability of the current beta bodes well for the future, so working Windows 7 directly into your test and preparation activities may be possible sooner than we might expect, based on past experiences with new Windows releases.
The last question that remains is how to decide if and when to move forward. Critics maintain that there is simply not a business case to migrate from Windows XP, so why bother at all?
I would not dispute the difficulty in justifying a Vista rollout from an end user value perspective, although larger organisations that have taken Vista fully on board report significant payback from operational improvements. I personally haven’t formed a strong view on whether Windows 7 will change the cost/value equation very much, though my own experimentation with the beta (admittedly just a single data point) has revealed a noticeably better user experience that could arguably make a difference to productivity - it’s too early to make a call on this, though.
But the cost/benefit calculation associated with the operating system per se is not the main issue. After all, the only reason Windows is there is to run applications. And with the relentless upgrade spiral among software vendors, practicality says you can’t fall too far behind without running into support and compatibility problems at the other end of the conveyor belt.
There’ll come a time when the latest releases of solutions that are important for your business will no longer run on XP, in the same way that vendors have gradually dropped support for pre-XP versions of Windows. So unless you are one of those looking to defect to Linux or OS X, the move from XP is inevitable at some point down the line. And it’s always better to act proactively than reactively.
So, whether you are an enthusiastic pioneer or a grudging pragmatist, the good thing is that you can largely set your own pace in terms of migration timing, which is exactly as it should be.
Republished on the The Register here.
A minority - typically represented by small tech-savvy professional services firms in the IT, engineering and media sectors, in particular - will take the uncertainty as a cue to investigate alternatives such as Linux and Mac OS X. This is a perfectly legitimate thing to do, but outside the scope of this article.
For most, the key question remains about when and how to move forward in terms of Windows releases. Having looked at the options, there isn’t a single ‘right’ answer to this that applies to every organisation. So what’s the best way to think about the issue and come up an appropriate plan?
A couple of things are worth bearing in mind as a foundation for the discussion.
First: the physical deployment of the operating system itself, i.e. getting the new version of Windows onto target machines, can involve significant operational effort, but the real cost and pain of most previous Windows migrations has been associated with testing and remediating applications, utilities, drivers and so on. We know from those who have already made the move from XP to Vista that this is not a trivial task in that particular case. Real compatibility issues are typically encountered with both commercial and in-house developed software that need to be identified, understood and fixed methodically. Tools exist that can help with the process, but there is no getting away from the need to treat the exercise as a properly planned, resourced and funded project if you have anything more than a handful of PCs.
Second: from what we have seen and heard so far with the beta version, Windows 7 is largely an optimisation of Vista rather than a generational leap forward. I am sure that Microsoft and others might debate this throwaway comment from various different angles, but the pertinent point is that software designed to run on Vista will very likely run on Windows 7 with no compatibility issues.
Microsoft’s claims here seem to be corroborated by feedback from beta testers. Indeed, it seems every man and his dog has now given it a whirl and is reporting positive experiences in developer communities and social media circles.
The upshot is that the bulk of the effort put into the ‘hard bit’ of an XP to Vista migration i.e. the remedial compatibility work, will not need to be repeated during a subsequent move from Vista to Windows 7. Of course it’s unrealistic to expect perfection, and you would be mad to assume compatibility without going through a full re-test of everything. But the chances are that most things will pass and need no further action, making the whole thing much less costly, time-consuming and risky.
So how does this help when considering migration strategy and timing? Let’s not pretend the situation is ideal, but at least it puts control of the decision back in your hands. With early experiences and Microsoft promises indicating a relatively small difference in effort between a two step (via Vista) and one step (skipping it) migration, the consequences of choosing one route or the other are not that great.
So it’s up to you, really. If it suits you to move sooner rather than later, then there is no need to hold back from implementing Vista for fear of having to duplicate a huge amount of effort. Yes, there will be additional work involved in the two-step journey you will ultimately be taking, but the second refresh will be much less daunting.
If you plan to wait for Windows 7 before rolling out your next major upgrade, you can begin testing and remedial work in advance using Vista. Having said this, the stability of the current beta bodes well for the future, so working Windows 7 directly into your test and preparation activities may be possible sooner than we might expect, based on past experiences with new Windows releases.
The last question that remains is how to decide if and when to move forward. Critics maintain that there is simply not a business case to migrate from Windows XP, so why bother at all?
I would not dispute the difficulty in justifying a Vista rollout from an end user value perspective, although larger organisations that have taken Vista fully on board report significant payback from operational improvements. I personally haven’t formed a strong view on whether Windows 7 will change the cost/value equation very much, though my own experimentation with the beta (admittedly just a single data point) has revealed a noticeably better user experience that could arguably make a difference to productivity - it’s too early to make a call on this, though.
But the cost/benefit calculation associated with the operating system per se is not the main issue. After all, the only reason Windows is there is to run applications. And with the relentless upgrade spiral among software vendors, practicality says you can’t fall too far behind without running into support and compatibility problems at the other end of the conveyor belt.
There’ll come a time when the latest releases of solutions that are important for your business will no longer run on XP, in the same way that vendors have gradually dropped support for pre-XP versions of Windows. So unless you are one of those looking to defect to Linux or OS X, the move from XP is inevitable at some point down the line. And it’s always better to act proactively than reactively.
So, whether you are an enthusiastic pioneer or a grudging pragmatist, the good thing is that you can largely set your own pace in terms of migration timing, which is exactly as it should be.
Republished on the The Register here.
Subscribe to:
Posts (Atom)