What's in a Reference Architecture?

Over in the Twitter-verse there was a question asked by @aneel:

It got me thinking, especially since Cisco (@aneeI’s employer) tends to leverage them to a significant degree and VCE (partially owned by Cisco) has traditionally been the opposite side of that coin.  Personally, I think both are valid ways to go to market, I think it’s more a matter of how do you leverage your delivery options to provide your customers with the most value?  Is one better than the other?  Is there a place for both?  Is there a NEED for both?  While this typically ends up being a religious discussion, does it have to be?

 

It’s actually an interesting time to have this discussion because while it’s been a hot topic for some time, the release of the VCE VDI product and the EMC reference architecture have focused attention on the situation.  EMC’s Chad Sakac did separate blog posts on both the EMC reference architecture and the VCE product during VMworld, and has some great points about the difference between the value for the customer.  Pulling in part from his comments and from my experience, let’s make a list:

Reference architecture:

• Value
  • Help reduce risk…a little.
  • Infinitely flexible, nothing to “break”
  • The more you diverge the less value it has
  • Moderate/limited acceleration of deployment time
  • Protection of existing investment
  • Allows leveraging of existing skillsets and staffing strengths
  • Did I mention infinitely flexible?
• Costs
  • Cost of developing business requirements
  • Cost of technology “discovery” (the “beauty pageant”)
  • Cost of matrix compatibility/testing
  • Cost of ancillary equipment (racks, cables, PDUs, etc…)
  • Cost of implementation (rack & stack, cable, configure, certify)
  • Cost of go-live testing/acceptance
  • Staffing/Professional Services Costs as needed
  • Cost to business of increased “time-to-market”
  • Cost of support overhead (paying for multi-vendor support management or having to do it internally)
  • Cost of third-party tools acquisition, integration and maintenance to manage
  • Subset of all above costs when purchasing capacity to grow/scale
  • Overall, includes a significant amount of “Non-Recurring Engineering Time”
• Risks
  • Slow time-to-market
  • Very dependent on internal employees and their availability/competencies for success
  • QA both for initial deployment and as capacity is expanded is very complex
  • Documentation of as-built configuration is additional project/cost
  • As core elements get upgraded, some subset of the initial tasks have to be redone to allow for upgrades to be incorporated into design

In the end, I feel like a reference architecture is all about the people involved.  The better they are, the more organized and informed they are about the needs of the organization and the less biased they are towards where they’ve been while evaluating where they are going, the more likely the project is to succeed.  This kind of focus CAN (but doesn’t always) detract from the business side of things, because it’s asking a lot of siloed infrastructure engineers to keep the big picture in mind.  This process succeeds or fails based on the management of the project and on how the balance between speed and thoroughness is maintained.  Partners and systems integrators play a very key role here, since maintaining that balance is what they are good at, and they can make sure that the right mix of staffing is available.  There’s an additional cost, of course, but it’s cheaper than the cost of letting the project fail!

Productized solution:

• Value
  • Help reduce risk…A LOT
  • Quantifiable level of business value (ROI/TCO)
  • Extreme acceleration of deployment time/time-to-market
  • Testing and validation of components is included
  • Component upgrades are included in pre-testing and validation
  • Best practices and logical limits are in place from day one in order to avoid performance issues and component misalignment
  • Ordering process, both initially and when additional capacity is needed is streamlined and focused
  • Logical build and local delivery included
  • One-call support to handle all components included
  • Integrated management/orchestration stack
• Costs
  • Costs of developing business requirements
  • Costs of go-live testing/acceptance
  • May force realignment of internal infrastructure silos
  • Coupling/convergence of components may limit the reusability of existing gear
  • New management tools can introduce training costs
• Risks
  • Since the value derived increases with scale, these purchases are seen as commitments that need to be followed through on over time, not just one-time purchases
  • Choosing your partners/vendors is critically important: this is who you will do business with for years
  • Promise of “converged” doesn’t reduce inherent complexity.  Setting internal expectations properly can be challenging when the core premise is “it just shows up and works”
  • Design is more rigid in places where standardization and supportability are affected

For a product, I feel like everything revolves around the technology included, and in how much effort the provider has put into integration, delivery and orchestration of the core components.  The basic requirements from a strategic standpoint still rest on the customer, as does the responsibility for managing the requirements and application stacks, but much of the burden of the design, regression and interop testing, manufacturing, implementation and delivery are taken off the customer from a tactical standpoint and are rolled into the value proposition of the product.  The more committed and prepared the platform provider is to providing a complete offering, the more value the customer will realize.

As someone who has worked in the industry for a long time with a number of companies and industries, I can certainly see the value of both offerings.  For customers who have an existing investment, using a reference architecture can keep you from having to strand invested capital.  For some service providers who haven’t been able to sync their technology refresh cycles, a reference architecture can be valuable, so long as the cost of deployment/testing and the delay in generating revenue doesn’t outweigh the capital being saved.  For customers who are ready to move NOW, and who want to accelerate their deployment without needing to staff up internally or contract for a large amount of professional services on the hardware side, having a product ready to order is the way to go.

I recognize that my stance here goes against the expected response from VCE.  I’m expected to say things like “No one needs just a PDF and a sticker” and other nonsense.  Want to know the truth?  The Vblock not only started out as a reference architecture, but it’s still delivered as one in certain circumstances today!  The open house event for EMC’s New Center Of Excellence And Cloud Data Center was a good example, where the Vblock architecture is being used to host  350 applications and 6 PB of storage.  They definitely don’t live inside Vblock cabinets, and the staff on the data center tours shared publically that in order to fit into the cooling strategy of the facility they used the base Vblock reference architecture (pssst: the original 0/1/1U/2, 700MX and 300-series reference architectures are available publically from the vce.com and vcepartnerportal.com sites) to build the platform in a way that fit their infrastructure requirements.  There are even countries where, for many reasons, it’s required to deliver the components separately rather than ship a completed Vblock from manufacturing.  Does this mean we don’t have customers using Vblocks there?  Heck no, it means we use the reference architecture and our incredible partner and parent company ecosystems to deliver what the customer wants.

Does VCE offer a pure reference architecture design where partners are responsible for 100% of the delivery and support of the infrastructure?  Nope.  Will we ever, in a Vblock of any/every size?  I don’t know.  But here’s an important question to think over:  If, as has been stated by myself here, Chad and others elsewhere, there is a legitimate need in the market for both a product and a reference architecture, which will be easier to accomplish: VCE augmenting their existing world-class product with a less formal reference design, or any other company trying to build a formal product with a true, integrated single support model across all of the relevant component vendors?  To go one step further, which would be more easily accepted by existing customers?  If the only option you had in order to use the components you wanted was to build it from scratch (or pay a partner to do it for you), and you were told that a “product” was too inflexible for what you needed, and then your vendor released a product with enhanced support, how would you feel?  AT THE LEAST I’d want my deployment re-certified to get the same benefits as people who were buying the new productized version. Trust me, I know how expensive that certification/remediation process can be on both the customer and the vendor.

On the flip side, all of the EMC customers for whom the Vblock product wasn’t a perfect fit, they have been getting V+C+E solutions that can track to the Vblock reference architecture all along.  Formalizing that, and handing out stickers to go with the PDF wouldn’t be painful at all.  In fact, it would allow VCE to level the competitive landscape somewhat and start to recognize all of the hundreds and hundreds of millions of dollars of V+C+E deployments as Vblocks.  Even counting the way we are now it’s pretty clear that VCE is more than holding it’s own on the revenue generation side of things, so I wonder what will happen if the playing field gets leveled on that front.  Oh boy.

Will a VCE reference architecture ever happen?  I have no idea.  I’m part of the field-facing team at VCE, so strategic decisions like this happen well over my head, but I think it would be good for our customers and the market in general.  Since it’s already used in places today, and since it would be a way to help EMC by giving them a standard to design V+C+E implementations to, I don’t see any reason why it couldn’t happen.  There would definitely be differences in the value proposition; for example I can’t see our traditional single-call support working in a pure reference architecture model, although we could still leverage the joint ticketing and escalation process for customers who build to the reference architecture.  The value there would still be higher than it would be if you’d purchased the components separately or through a reseller partner, but not as much as if you’d purchased a single product.  Of course I think customers would understand that as part of choosing their acquisition model.

The big picture is that customers want to consume in a way that is most beneficial to their business.  With VMware View, EMC and VCE are offering both a productized and reference model version, with VCE being the only company on the market offering View as an integrated part of a converged, multi-vendor infrastructure. Why not take it one step further and have VCE continue to lead the market by becoming the only company to provide both a productized and reference-based infrastructure?  Time will tell.

Comments

[Robert Miletich]

>>: In the end, I feel like a reference architecture is all about the people involved.

Let me respectfully disagree. The people involved are crucial since you're depending on integrators or internal staff to assume responsibility for success but the reference architecture (a Cisco one anyway) goes a long way to assure some form of success. An additional value to reference architectures is that they bring ownership of the solution closer to the client - i.e. the client is less prone to look at the solution as someone else's child and by extension, their responsibility.

>>: For a product, I feel like everything revolves around the technology included, and in how much effort the provider has put into integration, delivery and orchestration of the core components.

"How much effort" can be viewed subjectively - it can be anything from not enough effort, to just right to too much effort depending on the product manager. Is it just right? It was for the product manager :-). Is it just right for the client? Maybe. Probably. And if not there'll be another product around the pike to fix today's issues.

My view of the value of a "product" is time-to-implement, and its close cousin, time-to-monetize. That takes for granted that it actually is - like many "products" are advertised - a pull-the-string to successfully implement proposition.

[Jeramiah Dooley]

Thanks Robert. Even the best reference architecture is left in the hands of the staff and partners of a company to implement, much the same way even a good recipe still needs a good cook. In the case of a converged infrastructure it's not just following the RA that's important, it's making sure the end goal matches up with the business requirements. That's a lot to ask of people, and it's why I feel that the people end up being the critical path item.

Leaving my choice of phrase aside, I agree with your second comment as well. The reduction of risk is assumed (although, like you point out that can be a big assumption sometimes. :-) and the goal is to minimize TTI.

Thanks again for the comment!