Published on
story is not published yet
Written by
Jason Smith
Share this post
All the top cloud providers currently have partner programs, but the tier systems can be misleading and are not indicative of the quality of service you may receive from your vendors. In this article I will discuss the cloud provider’s leveling systems and what to take into consideration when choosing your System Integrator (referred to as SI).
There are several issues around the current partner systems.
Numbers are not a clear representation
Certifications are not indicative of skill
Quantity of Opportunities does not indicate quality
The size of any particular SI will determine their ability to walk up the ladder of partner tiers.
If a cloud provider requires 50 certifications spread across 30 engineers for a top level status and your SI only has 25 engineers on staff of course they would struggle to hit that top tier. Intuitively this may not seem problematic but it can be when we look at the large scale SIs that are top level cloud partners.
When your company has 50,000 employees the bar to be a top level partner is pretty low. You have the staffing levels to maintain an army of certified engineers.
Where things start to go awry is when we look as certifications as a ratio of employment. If you have 50,000 engineers and 2,000 of them are certified then you only have 1 certified engineer for every 25 (1:25).
On the other hand when we look at the smaller SIs you may see they have 100% or even 50% certification levels. Your chances of being assigned engineers talented in your cloud provider are much higher. On the other hand in many cases the smaller SIs don’t have the diversity of staffing needed to deploy complex multi-vendor systems in the cloud. Meaning you could get an excellent team for Azure but they may have no talent in SAP. Also many times the smaller shops do not have the bandwidth to help all of their potential customers. Most of the Large SIs have a much larger and more diverse pool of talent.
A great deal of the lower level certifications do not indicate skill in your cloud provider but instead can be used as an indicator of an engineer’s ability learn the platform. Some of the higher level (Pro) certifications have set a higher bar, and can usually indicate an adequate level of experience. As a whole, you can pass certification exams but still not have any practical experience in the cloud provider’s ecosystem.
Many of the larger SIs move engineers through training like cattle. This is either driven by a publicized effort (“look at our commitment to the cloud”) or by their client’s insistence on teams that are certified. Unfortunately a great deal of these efforts are just teaching to the test, which typically results in a cohort of engineers that have little to no experience on the platform.
The current partner systems do not indicate an overall level of quality of service. That will not change anytime soon, due to the relationship between the large SIs and the cloud providers.
There are a large number of SI projects that have floundered and failed, that go completely unreported. Ironically services such as AWS IQ allow you to rate your “experts”, individual freelancers that will ultimately have a small impact on your budget, whereas the large SIs have no such rating system.
The benefit of the smaller SIs is that their portfolio is smaller and easier to request references. The larger SIs plow through so many projects, some of them are bound to have worked out well, but many may have failed.
Interestingly all the cloud providers have the ability to track a lot of the SI implementations and track the good AND the bad, but as stated before those figures would never be released.
So there are several ways to approach management of large Cloud projects. Use one or a combination of these strategies.
If it is possible, you can try to break down your migration into discrete parts and assign them to a variety of separate SIs. This will require a high level of coordination from the client, but in the end it actually helps in encouraging strong decoupling, leading to a more resilient system.
Large SIs love to tout their success stories but it in no way means you will get any of the engineers or architects that worked on those projects. Insist on experienced engineers. Insure you have a minimum number of top level architects and engineers and not just certifications.
Insist in writing a certain number of experienced cloud engineers and insure they are evaluated, by you or an outside agency. Engineers with lower level certifications are also an asset but only when directly working under the direction of experienced engineers or a third party consultant to direct the project.
If you don’t have the internal skill sets you can look at a consulting firm that has skills in managing cloud projects and managing SIs with those migrations. Look for consultants not interested in buffering their utilization numbers.
In the end it is your company’s responsibility to insure your SIs staff you with skilled engineers and don’t rely on the cloud partner programs to evaluate your SI for you.
Look for more articles coming soon where I will discuss the problems of System Integrator utilization percentages, and the problematic cloud provider and system integrator relationship.
Share this post