Tenders or Tenderisers?

As you may have noticed by the infrequent nature of updates on here, yes I've been doing lots of new work.

However in my past I've had the pleasure of performing many number of global IT infrastructure tenders, and really the impact on my professional & personal life these have.

Unlike Duncan Fitzsimons not all of us like reinventing the wheel, but for some things in order to make something tender you have to hit it repeatedly...

And finally Philip Clark got it perfectly here where he replied with :-

"Do you find the Tender process to be misnamed? <= No, it's named for how your lower extremities feel afterwards!"

It really shouldn't be this hard or painful for all parties!!!

Now, despite having been involved in global tenders for 10+ years I still get surprised each time, sometimes for better sometimes for worse but always raising an eyebrow - so here's some previous examples - I've personally experienced every on listed - with smatterings of free (and that's rare from me being both Scottish and now a Consultant) advice for suppliers :-

No matter what the customer provides for response formats & template, it appears the vendors will always ignore this and use whatever random & complicated format they feel like. The supplier then complains or is surprised when the customer can't easily locate the information and they get scored low.

Embedding 100+ PDFs into an MS-Excel sheet just isn't fun to read - honest! Nor is providing your submission as 98 individual zip files with 2 files in each... Similarly please ensure that any PDF submission that has further embedded documents includes the full print of the sub-embedded documents not just a picture of an icon.

How many vendors simply somehow miss entire sections of a tender and don't respond to them at all? If this is the level of attention and detail during the romance phase, just what will it be like once we're committed together??

The irony of a vendor signing a full mutual NDA, and marking 'fully comply' to a requirement of providing a documented "18-36 month roadmap", but then refusing to discuss products to be launched in 2 weeks time or leave copies of the roadmap. But the irony isn't lost on the customer - only thing they're never sure of is, is the stupidity, ignorance, bravado or naivety by the suppliers...

Oh and the use of imperial units rather than metric & SI - that gets tends you to the very bottom of the 18th century Luddite pile, either as a customer or as a supplier... We're in the 21st century, please keep up...

How little appreciation from suppliers that providing opaque / oblique / random / monosyllabic answers to requirements really doesn't help them or the customer in any way at all

One word answers to questions are rarely valid - it often feels that a tender response has been written by a begrudging 17yr old teenager at 8am on a Sunday morning, rather than a Fortune500 global corporate. As a hint, if you answer a question 'partially' or 'no' some kind of details explanation as to what & why would be of use. Equally answering simply 'yes' or 'compliant' to every question without giving any further information to provide confidence doesn't help either. I certainly haven't got the time or inclination to get a crystal ball out to establish your thinking behind your cryptic clue of an answer!

If the customer provides a Q&A period of time for the supplier to raise clarification points or questions, then the supplier should - if not then there's no ability to say "oh we weren't sure" or "we didn't understand" later.... You'd be staggered how many suppliers appear to lose the ability to raise clarification questions until after the deadline...

Similarly, during the presentations it also helps if the supplier has a list of questions for the customer, so when the customer asks you "Mr Supplier, is there anything you want to know?" they're not left looking either like a clueless goldfish or overtly smug / distant...

Pay attention to your own staff & presentation - if the vendor looks bored and ignores the presentation then the customer is likely to as well...

Whilst stating to the customer "we're not giving your our best offer now, we're saving that for later rounds & negotiations" may be very candid & truthful, it also shows a certain gaming strategy technique that is less relevant in the world of eAuctions...

Oh and vendor staff arguing between yourselves during the customer presentation - whilst it makes for amusing customer bar stories, but that's not good either!

Nor is having 4 different presenters for different sections but no single 'neck on the block' accountable owner - it should always be clear to the customer who the lead is and that they are fully invested in the response and process.

Requesting an extension for the tender the day before it's submission date? Yup that's the equivalent of "my dog ate my homework" and will just be looked on as amateurs...

Lobbying & making proposals to try and subvert, change or prevent a tender? Have a guess?? You'll certainly not be at the top podium for customer happiness...

The supplier also needs to remember the customer will regard that this is you at your best, and it'll only go downhill from here - so if you're not at 150% of your game and totally switched on expect the customer to look depressed...

How poor some responses are, with many supplier mngt teams resembling a goldfish when asked questions about parts of their response. Frankly I'd swear half of the teams haven't written or read their own responses, in fact sometimes I'd swear they've never met the other members of their response team before.

And just what is the point of the customer providing strategy guidance, requirements documents & templates, specific materials or meeting & presentation agendas if nobody on the supplier's team appears to read them?

How poorly people prepare for presentations - arriving late, arriving without materials, appearing that the presentation team have never met before - all not great sales methods...

How poorly people manage their presentation time and/or content - clearly having not rehearsed their presentation timings, or presentation roles. Spending lots of time on non-valuable content. Having written it on a Mac but never tested it on a Windows PC - that's a disturbingly common one...

How tangential some people try and stretch the scope of their responses into areas utterly unrelated, remember you're there to address the customer's issues & opportunities, not you're monthly sales quota. Waste the customer's time and they won't give you a second chance...

That a supplier actually being honest about their strengths and capabilities and declining an invite to tender can build a stronger and more trusting relationship with the customer, that ultimately will lead to greater revenue for the supplier. Thankfully - that there are still some suppliers that are very candid & honest and decline to respond if they believe their technology & services would not be a productive and positive relationship for all. Every time I've seen this the supplier has within 12 months won more business that the original tender was worth.

When - despite being clearly told by the customer 1.5hrs into a 2.5hr time-slot that 'your presentation has no relevance to our requirements' - it astounds that suppliers plough on regardless, as if somehow a war of attrition through powerpoint will convince the customer that up is now down...

How some suppliers simply fail to follow basic process logistics and expect / demand the right to be 'special', the very purpose of a tender is to normalise the engagement and actions of both suppliers and customers. But still some suppliers prefer to play the management escalation & relationship game rather than deliver on value and quality.

That with the customer having created and given 100+ pages of specific guidance and response templates, just how varied the responses are and in just how complex fashion, I'll not even mention those suppliers that edit or customise the templates...

Each supplier whines & moans about their work for a tender, but they appear to forget how complex & difficult the task is on the customer side and that the customer invests many times more effort in the tender process. From managing many different supplier responses, to creating the structure & process, to evaluating the responses in a clear objective fashion.

The basic quality control & integrity checks on responses - suppliers leaving working notes within documents, leaving markup versions in documents (showing both the response and the document's history), leaving previous customer details / logos etc within materials...

Some very honest and candid responses - "this is too complicated" & "we don't know" being classic responses to specific but common customer questions.

That how few suppliers don't appear to know "why does this product / variant / solution / service exist?", "what is the 3 minute elevator pitch used to justify this product / variant / solution / service development?", "how does this relate & differentiate from your other products / services / solutions?". If the supplier doesn't proactively address these basic questions then customers get nervous. If they can't, or won't, answer them when directly raised then it raises serious material concerns with the customer.

It's also dismaying just how many Forture500 suppliers appear to have account staff that have been ex car / double glazing salesmen in their past, adopting the "I need to phone my boss about that" to simple questions. If the supplier's staff are not able to make accountable account decisions then the wrong staff are in the room and on the account...

I do find it assuming that suppliers seam to be able to count to 14 decimal places when margins are concerned, but can't count to 7 when the maximum number of meeting attendees is concerned - 11 being the record attempted in the few years (naturally the surplus 4 got told to 'go away')

How many 'polite' excuses / explanations suppliers use to avoid being honest in sessions - sometime just saying "we ballsed up" is worth much more than "the dog ate it" kind of excuses

That the podium space for the #1/2/3 spot in any technology domain must be incredibly crowded given just how many companies claim to be 'the best', 'the leading', 'unique' or 'the number 1' - I've certainly never seen any such rankings independently managed,,,

How few suppliers are fully honest, and don't seem to think or believe that the customer will both cross reference the various elements of their multi-part responses but also validate responses via independent means.

Naturally Pinocchio could never be involved in a vendor's tender proposal - as the avalanche of unjustified / unsubstantiated subjective claims would cause his nose growth to drain the blood from his entire body.

So if from the above, you've reached the impression that managing tenders with multiple suppliers is very much like being a school teacher setting homework, then welcome to my world...

But do the basics, do them well and honestly and spend some time thinking about sitting in the customer's seat and good things will happen.

All of the above said, thankfully some companies come very prepared, with clear documents listing all contact details of the attendees and involved parties, even to the point of bringing their own name badges / name plates for desks - all of which makes it much better for the customer who's going through dozens of such sessions and meeting 100+ people within 5 days.

NDA Briefings - the content lap-dance?

So those who follow my twitter profile, or know me in person, will understand that one of my major annoyances in life is the topic of NDAs.

Now I fully understand what an NDA entails (I've spent enough time with lawyers in my life to know this area very well), and understand why anything more than 2 way NDAs are a genuinely terrifying concept. I also personally know what it means for all involved to 'tear-down' and NDA in 'an aggressive fashion'.

Naturally in my line of work, probably 70% of the external discussions I have are of a confidential content nature, with a high % being purportedly related to NDAs.

So why do they annoy me?

http://twitter.com/ianhf/status/9569522994
Why the hell don't vendors trust customers when under NDA with a copy of the slides? either respect an NDA or don't bother at all..#Annoyed

Well as far as I can see they are increasingly used as a way to restrict the content, or method of delivery of the content, provided to customers. With phrases such as "can't give you to document or presentation as it's NDA" being uttered on a weekly basis - the concepts of trust and respect being lost forever.

A common use of the NDA is to cover future roadmap discussions - naturally enough as for any supplier this is a very sensitive are. But my position is that roadmaps should change, and that's fine. The key is to ensure that there is regular communication & dialogue about the changes. The customer of course needs to have some reference artefacts for a point in time to use for their own decisions, after-all we have to create our own 6/12/18/36mth internal strategies.

Clearly if we can't have a secure & trusted copy of information from a point in time, then we can't reference the information - as my memory is such that I could very easily get information very wrong. In short - if a copy of the information isn't provided that we have little choice but to 'strike it from the record' and ignore it - making the whole 'NDA' exercise worthless all round... As far as I'm concerned this just shows that many vendors simply don't trust or respect their staff or their customers - these are not the vendors I'm interested in working with.

How often are NDA pitches one-way presentations? Sadly all too often :( There are still some good people out there that do genuinely have the sessions as NDA discussions and will influence their roadmaps and/or decisions based on dialogue & requirements - but these are most certainly in the minority.

Whilst I accept some customers may leak NDA information, either consciously or unconsciously, my thoughts are that people should have the courage to penalise those that breach NDA clauses, make an example of them don't penalise those who understand & respect them. But, surely we also need to address the information moving between competitors in the increasingly incestuous IT sales & engineering industry job shuffle (or are lobotomies standard practice in changing jobs between IT suppliers? well now I mention it that would explain many things...,)

A major irony of this is that at least 3 suppliers (eg EeeMSee, SumNotech & SnOracle) all sell commercial IRM/DRM products, but yet they refuse to use these with their own customers for protection of NDA content. Now if this doesn't fit a perfect target use case for IMR/DRM tools then I don't know what would! If partners won't use these products to protect their own content then I sure as heck won't be buying their tools to protect mine! You'd think their own sales teams would be pushing use of the IRM/DRM tools to 'spread the word' so to speak... Either way they should use & trust their DRM tools or kill them...

All of this sadly leaves me to the conclusion that 'NDA briefings' are often now little more than than marketing meetings wrapped in a 'special legal secret sauce' to puff, fluff & massage the ego of the invitees - the "I've been somewhere special" & "I know something you don't" playground taunt factor...

There are words for those who are paid to say & do nice things purely to boost a customers ego - and candidly, I think we'd all rather be with partners than whores!

Rounding the wagons?

So the tin providers can see the differentiation end coming, they can see the need to drop their high margins are vast & costly sales structures and move into other areas.

A few of these talk a story, but very very few of them appear to be able to do something meaningful or lasting.

Consolidation in the infrastructure stack market - lots of blogs talking about this, lots of disruption and issues, lots of risk & downside for the customer.

Oracle made the first move with an application provider acquiring Sun in order to control their own destiny re infrastructure and have better control of their own margins, but despite this they have a dead h/ware business that they are desperate to force onto customers (although I think few Oracle people understand the word customer, most seem to  interpret it as fund payer for their Porsche & holiday homes). Increasingly we now see that Snoracle's applications are 'only provided' or 'only supported' if bolted to the tin albatrosses bodged together by themselves.

EMC and their pet VMWare are nibbling around the edges purchasing software development tool companies, acquirin some serious individual tallent and now into the DW/BI and eventually database area.

If I look at HP, they have lots - but several areas they are lacking in (excusing the clear lack of sales, marketing & product proposition talent) are :-

• Database
• Middleware
• x86 Server Operating Systems

If I look at IBM, they have everything except direction, sales, marketing, focus and conviction...

SAP buying Sybase was interesting for a number of reasons :-

• Removes the last major (meaning deployments in existing data-centres) RDBMS from the table for those infrastructure companies desperate to have a plat in the database world (eg EMC, HP etc)
• Will further muddy the water with SAP's database usage relationship with Oracle
• Might knock some sense into Sybase's management team
• Doesn't seem to add much obvious additional value, synergies or savings for SAP
• Will likely start a bidding war for other 'platform tool' players in the mobility market - although all of these will be competing with the networks & the device providers themselves...

But when do we see the first IT infrastructure company buy a business application software provider? Would you put money on EMC or HP acquiring Teradata, SAP, SAS, Amdocs, Comverse, Sage, Tibco

Is anybody interested in acquiring Citrix? BMC? Symantec? RedHat? Novell?

Of course all of the infrastructure companies are courting Microsoft for partnership scraps off the table in the SMB application areas.

So whilst the masters of FUD fight their whispering battles against each other, the account teams become increasingly desperate and high-maintenance and the manufacturers fight each other (eg Snoralce Vs Intel/HP) as far as I can see it's only the customer that loses - quality, clarity, options, stability all reducing...

Feature stacks and the abuse of language

So the new financial year heralds the season of vendor conferences, and - as night follows day - over the horizon, like the four riders of the apocalypse, approaches the associated marketeering storm that always comes with such conferences.

Sadly one trend I'm seeing more of from the (increasingly desperate?) IT infrastructure industry is aspirational future feature stacking. Where endless features are announced haphazardly into the mix in an attempt to justify new revenue streams; naturally the delivery of these features is in a different year/decade to when they are announced, let alone when any actual benefit might be realised.

Of course the first challenge to this is trying to convince customers re the vital importance of features they haven't heard of before, often for problems they never knew they had. So some use fictional stories in order to try and paint a picture of utopia as a result of paying for their magic liquor, some just plaster the industry with noise, others use new abuses of marketing terms, some use all.

A common area glossed over is the 'initial ingress disruption' required to achieve such utopia features - especially given the likely useful life of 'nirvana function'© versus the duration of benefits case and lifetime of said feature.

The benefit's case is an interesting point in it's own right - remember these are the vendors that often still haven't a clue about the TCO or ROI for their products several years after they were announced. Naturally there is little or no mention of the financial costs involved, ingress & egress disruption, organisation & technology process changes, operating model changes, and increasingly, the business process changes needed to use this fictional future widget function.

Now you wouldn't expect otherwise, but of course there is little mention of either the existing abilities to solve this problem other ways, or that the effort & resources might be better invested elsewhere (ie higher up) in the technology solution stack? Or that the symptom cold be avoided entirely if the cause were addressed with better application design. My view has always firmly been that infrastructure can provide at best single digit % improvements, where as changes in the application layer can provide double digit % improvements.

Always just snow-ploughing the data problem symptom around rather than addressing the cause - of course you can't fault the bottom feeding tin vendors from offering this solution, there is always some legacy application that can benefit from any improvement; but frankly the infrastructure companies don't have many other options and there is always somebody that'll buy anything.

So there's plenty of noise, lots of definition and understanding confusion & plenty of widget functions, indeed it's nothing new for companies to start abusing words and terms in a desperate hope to generate excitement and differentiation - yet normally this just further confuses the market (remember when a word typically had one clear, obvious and innocent meaning???).

Some recent history of definition & language abuse could be :-

• 'Cloud' NIST has worked to a certain extent but IT companies have abused the hell out of it.
• 'Virtualisation' has some common understanding in the server world, but as usual the storage world is chaos.
• Now along wanders 'Federation' as the latest word to be put through the hype & definition mangler.

I'd really encourage the use of the relevant standards body to help create common industry definitions for the terms used, always provide clear & transparent context and always detail the assumptions & pre-requisites with any form of benefits discussion. Rather than using hypothetical stories and definition abuse, I'd really much rather prefer it if companies explicitly list the: -

• The specific customer requirements & problems this addresses & justify how
• The use cases this feature / function applies to, and those that it doesn't
• Why & how this feature is different to that own vendor's previous method for solving this problem
• Provide clarity over the non-functional impacts of the feature before, during & after it's use - ie impact on resilience, impact on performance, concurrency of usage etc (including provide up-front details of constraints)
• Provide the before & after context of the benefit position, clearly explain the price of the benefit change and any assumptions or prerequisites needed to use the feature
• 
  
  Provide some form of baseline & target change objective for entire process steps impacted
• Confirm the technology costs and cost metric model for this feature
• Naturally you'll also expect me to require TCO & ROI of the feature, and any changes to the models as a result of this feature

To take an example, one key element being touted by 'federation' is 'non-disruptive migration' - something I'm very much in favour of. However a) for many this can already be done through the use of the de-facto volume manager & file-systems, but b) the real issue associated with migration are 'remediation' and CABs. With most CABs nowadays been based on risk, and commonly used as process validation gates - it's hard to understand how 'federation' helps change approval boards (especially when you consider that lots of CABs still require engagement for moving hypervisor guest images). For the 'remediation tech refresh' use case of federation there will need to be a lot of changes in the vendor support & interop processes, culture, responsibilities and agreements for this to be of use. If the host still requires any material remediation (eg HBA change, firmware changes, OS patches, server model change, VM/FS changes etc) then moving the bytes stored on the rust, whilst good, does little to address the majority of the problem. Let's not forget all the other associated OSS processes that have to be engaged - eg ICMS/CMDB updates, asset & license management registers, alert & monitoring tools, networking planning & bandwidth management etc. Yes in the world of the automated dynamic data-centre these related issues will be improved, but that's a future state after a lot more of investment & disruption.

If this sounds overtly negative that isn't the intent. The issue for me is that any 'nirvana function'© is normally only of use if it makes a net positive change to the cost of BAU service or change. In order to prove that we need to understand how it impacts the steps, effort & duration for each item in the transition from 'desire to delivery' (eg when somebody thinks they may need some capacity to when they are able to actually use this). From my experience this sequence involves a mix of commercial, technical, political, emotional & financial steps - similarly very few companies seem to be able to show the steps in this sequence and how their function changes them.

Now I'm very much one for focusing on capabilities and architectures rather than point widget features, but the current trend of announcing aspirations as architectures and then products is a very dangerous and steep curve downhill. Like an iced wedding cake made from cards built on a sandy beach - this obsession with feature stacking promises everything but benefit delivery regularly lasts for only a few minutes before collapsing in an ugly mess.

Are suppliers hoping that by increasingly frequently hyping the shiny shiny baubles of the progressively distant future they will distract us from the factual reality of today? Remember today was the future of yesterday, and how many of the past's 'nirvana functions'© promised by these same charlatans vendors actually came half way true?

If only these vendors spent time & resources making the existing features usable, simplifying the stack, resolving the interop issue, given clear context and being able to actually justify their claims, rather than building their own independent leaning towers of Pisa from which they can throw mud at each other...

Large slices of pie do choke you!

So a new blogger called "Storage Gorilla" makes a few interesting and well reasoned points here about IBM's XIV (my views re XIV will be in a different blog post) - but a couple that jump out to me are the 'entry size' & 'upgrade size' points about half-way down the text.

Now anybody who's spent time working with me on my companies' global storage BOMs will understand that this is a major issue for me, and not something that is getting any easier. The issue is a complex one :-

• The €/Per GB ratio becomes more attractive the larger the capacity within an array (as the chassis, interfaces, controllers & software overheads get amortised over a larger capacity) - however of course the actual capex & opex costs continue to be very sizeable and tricky to explain (ie "why are we buying 32TB of disk for this 2TB database??")
• As the GB/drive ratio increases, the IOPS per individual drive stays relatively consistent - thus the IOPS/GB ratio is on a slow decline, and thus performance management is an ever more complex & visible topic
• IT mngt have been (incorrectly) conditioned by various consultants & manufacturers that 'capacity utilisation' is the key KPI (as opposed the the correct measure of "TCO per GB utilised")
• DC efficiency & floor-space density are driving greater spindles per disk shelf = more GB per shelf
• Arrays are designed to be changed physically in certain unit sizes, often 2 or 4 shelves at a time
• As spindle sizes wend their merry way up in capacity the minimum quantity of spindles doesn't get any less, thus the capacity steps gets bigger
• Software licences are often either managed / controlled by the physical capacity installed in the array, or in some random unit of capacity licences key combination - these do not change re spindle sizes
• Naturally this additional capacity isn't 'equally usable' within the array - thus a classic approach has been to either 'short stroke' the spindles or to use the surplus for low IO activity. However in order to achieve this you either have to have good archiving and ILM, or need to invest in other( relatively sub-optimal to application ILM) technology licences such as FAST v2.
• Of course these sizes & capacities differ by vendor so trying to normalise BOM sizes between vendors becomes an art rather than science

So what does this all mean?

• Inevitably it means that the entry level capacity of arrays is going up, and that the sensible upgrade steps are similarly going up in capacity.
• We are going to have to spend more time re-educating management that "TCO per GB utilised" is the correct measure
• Vendors are going to have to get much better at the technical size of software & functionality licensing that much more closely matches the unit of granularity required by the customer
• All elements of array deployment, configuration, management, performance and usage must be moved from physical (ie spindle size related) to logical constructs (ie independent of disk size)
• Of course SNIA could also do something actually useful for the customer (for a change), and set a standard for measuring and discussing storage capacities - not as hard as it might appear as most enterprises will already have some form of waterfall chart or layer model to navigate between 'marketing GB' through at least 5 layers to 'application data GB'
• Naturally the strong drive to shared infrastructure and enterprise procurement models (as opposed to 'per project based accounting') combined with internal service opex recharging within the enterprise estate will also help to make the costs appear linear to the business internal customer (but not the company as a whole)
• The real part though will be a vendor that combines a technical s/ware & h/ware architecture with a commercial licence & cost model that actually scales from small to large - and no I don't mean leasing or other financial jiggery pokery 

So I wonder which vendor will be the first one to actually sit their licensing, commercial & technical teams all together at the start of a product's development, then talk with & listen to customers, and actually deliver a solution that works in the real enterprise to enable scaling from small to large in sensible units? I'm waiting...

Vendor Partner Programmes - use or useless?

Most of you will know that many topics can make me a tad irritated, however a reoccurring one that never fails to wind me up is the topic of "parter accreditation" programmes.

You know, the ones where ISV XYZ says they are a 'gold partner' of technology supplier ABC and all the world is going to be hunky dory. Of course this applies equally to SIs, ISVs & OEMs.

This irritates me for a number of reasons :-

1) Mainly because it's never 'hunky dory' and given the devil is in the details, all these partner schemes do is set certain expectation levels in top management's minds that can never be achieved. Indeed if it was all so 'hunky dory' why the heck do so many SI managers drive around in expensive cars paid for through 'change control additions'???

2) Often the one 'partner' insists on the use of another partner, either in the form of a direct statement, or simply through the use of limited partners on the support & interop list. Of course it most certainly would be interesting to better understand any financial relationships or transactions between these partners ('finders fees' anyone?)

3) However the main issue I have with these schemes is that 90% of the time they are little more than joint marketing and sales programmes, which whilst sounding nice in reality they do nothing to actually help the customer. Once in, their accreditation schemes are often so light & flexible its daft, and this leads to lazy practices - which may in fact be negative for the customer.

But the real point of this note was to call out one specific area that vendors really could use these programmes for some positive value, namely tacking the issue of "supported versions". What I mean by this is that far too often, companies that have these schemes ignore a key issue - which is that they allow 'accredited partners' to either require the use of older technology versions or that they allow partners to support subsets of the products.

A couple of examples of this are :-

a) Cisco SAN switch interop programme for SAN-OS/NX-OS - where Cisco allow their partners to certify & support against a specific minor version of the code that is effectively unique to the partner. Thus making it more than tricky to get a solution between server, HBA, OS, disc array, tape library etc that actually matches all of the partner's specific certification requirements.

b) Oracle partners & out date/support software - where Oracle allow their certified partners to 'only support' aged versions of the database products. In the last month alone I've had one major billing partner & one major ISV both say that they currently only support Oracle DB 10.2.x and it will be mid-next year before they have anything that supports 11.x! Remember that 10.2 ends premier support July 2010, and 11.1 was released in Aug 2007!!!  (see here for details on Oracle support versions & dates)

So what do I want done about this? Frankly a simple starting point would be for these three items to added into the conditions of a partner scheme :-

1) If you offer a partner accreditation programme then mandate that members of the programme support the current version of technology within 90 days if it's GA release (after all they will have had plenty of notice & beta access as part of the programme) - this must also include providing upgrade routes

2) Partners are only permitted to do new deployment installs using non-current versions for up to 1yr of GA of the current version (and even then only n-1 release version)- thus allowing 'in-flight' projects to complete but preventing partners from proliferating aged technology deployments

3) If you allow partners to initially certeify against specific minor release sub-set versions, then require them to support the full major release version within 6 months of initial release (eg a 'terminal release' variant) - thus ensuring that the eco-system will converge on a common supported version within a period of time

Naturally companies that are not part of these partner programmes could carry on causing issues, but what this would mean is that those genuinely in such partner schemes would actually be helping their customer and have real differentiating benefits to offer.

Of course this would actually require companies to actively manage their partner programmes, and of course to remove those partners that don't adhere to the rules - something I doubt will ever actually happen. But you've gotta have a dream haven't you? :)

Show Me The Money! (information)

Just a short entry today re a some points to take into account if you're ever (un)lucky enough to be trying to sell anything to me, yes that includes technology, products, services, change or ideas :-

1) I expect you to have done your homework on my company - understand my current suppliers, current products, scale, locations, press releases re plans, priorities & focus. If you don't do this, arrive unprepared, arrive late, arrive at the wrong location or spell the company name wrong then don't expect me to pay full attention.

2) Product positioning, definition, differentiator to other products and overall reason for existence - if you can't explain these points to me in 6 slides and 15 minutes expect to go no further. In effect I expect to be presented with at least the internal pitch made to justify the product's creation. Assuming you manage to do this, I also need to get a clear understanding of when / where this product should & shouldn't be used, and compared to other products from the same supplier. Lastly I expect a clear comparison to other vendors products with a strengths & weaknesses competitive assessment.

3) TCO / ROI / CBA - Total Cost Ownership, Return On Investment, Cost Benefit Analysis are the bywords for technology evaluations and procurement. You are expected to provide customer editable models for your products and suggested architectures, including the assumptions and process/org context these models have been built for. Where you don't know input values relevant to my business then use & identify industry averages for me to edit & refine.

4) I'm not interested in free-of-charge trials, loan equipment or evaluations as sales devices - if you can't sell & prove the value case without this then please hold your breath for an hour and we'll carry on after then... Should you manage to prove value, then I may, at some point in the future, wish to want to validate certain things with either customer reference visits or witness tests in your labs - at your cost.

5) Please understand that any form of change costs money - this will always be factored in to any decision made.

6) A feature does not make a product or a company - look around the IT graveyard and you'll find lots of companies that tried to break this rule. I am VERY unlikely to change product or supplier as a result of a single feature - useful & valuable features will become free-of-charge hygiene factors common across the industry soon enough.

7) I try and measure value & cost over 7 years (to include ingress, usage & egress), not this month's discounted deal - accepting this will be longer than your likely sales role with supplier, please understand you will be impacted by your predecessors sins of the past.

8) I'm more interested in partnership and quality people & relationships than transient discounted deals - trust and credibility is earned through honesty, actions, delivery, quality & consistency.

9) Understand that your sales forecasts, quotas, commission, priorities, timelines, financial period ends etc are of absolutley no interest at all to me

10) Understand that I'll contact you when / if I'm interested or able to - I'm often very busy and if you continually chase, harass me or phone me out of work hours then you'll drop down the list faster than a lead balloon.

11) I make our standards process very clear. If you attempt to avoid or subvert the standards process in any way (including with mngt manipulation, FoC offers,avoiding the truth or clandestine work) then expect your company to be removed from my engagement lists in totality and permanently.

12) If you use FUD or hype expect me to publicly challenge you - also expect me to validate anything you say using me own methods & sources. If you continue expect our relationship to get difficult.

13) I need electronic copies of any & all materials discussed or presented - no exceptions, without this I can't use it as reference material in my internal strategy planning. If you hide behind "it's beyond NDA", or "NDA prohibits" then I'll interpret that as "you don't trust me personally or respect me professionally" and the relationship will be difficult from then on.

14) If I give you questions & actions (and I will, likely lots of lists of questions) then please ensure you deliver upon them or things won't progress well

15) My company is global, I need you to be and to able to map to our account structure requirements globally - service, support, products need to be globally available directly and we need empowered global SPOCs with partners

16) Good enough is good enough - the world is about fit for purpose rather than best of breed or ultimate performance nowadays, let us make the decisions re performance or resiliency by providing all the information

17) I expect industry open performance benchmarks for each product / technology - even if you don't like or believe in them allow me to interpret their use, value, accuracy or relevance.

But most importantly, if you do take the above into account, we will have a good relationship, I will be a loyal customer and together we can do lots of business... And I'll even buy the beer :)