AEC Industry Cloud Transition Cost Management: Part 5/7, Value Engineering and Quality vs. Cost

Welcome to part 5/7.  Once you start to flush out your model with products you have or want to use, you will likely start to see a few trends.  After some option analysis, if you end up with costs being the same, you will be left with analysis of quality.  This Cost vs. Quality ratio may not be a new issue for the seasoned buyer but the model we developed will help anyone make more seamless parallels between traditional and cloud offerings. To better illustrate, let’s park Quality for a minute and use 3 scenarios to paint a spectrum of what the cost allocations of your IT solution might look like today.  For organizational purposes I will use the Deployment Models (Public, Private, Hybrid, Community) from the NIST Cloud Definition to line out the options.  Remember the NIST Deployment Models are referring to how many entities the solution is provisioned for (across all 3 layers of Software, Platform, and Infrastructure) vs. where they are located.  So whether your solutions are on or off premise is not relevant at this time.  Hybrid is simply a hybrid and Community is just a limited number of entities somewhere in between so we will leave it out for now.  I have also put a ratio of Human:Non-Human costs.

Scenario 1: Private

Let’s assume all your solutions are managed by your staff and you own/license/manage all the products used.  For example you pay for Software Layer licenses of Microsoft SharePoint, Oracle JD Edwards, Oracle Primavera Unifier, Autodesk Revit and Microsoft Dynamics CRM.  You also pay for/maintain all the Platform Layer licenses of Windows or Java Servers  and perhaps you use VMware products for Infrastructure.  This is fairly traditional, and while not the definition of NIST Private Cloud, it is a private solution.  Your ratio of Human:Non-Human costs may be something like 3:1, 4:1 or higher.

Scenario 2: Hybrid

Let’s assume 50% of your solutions are owned/licensed/managed by your staff and 50% by a 3rd Party.  For example you pay for Software Layer licenses of a financial application like Viewpoint V6 and enterprise content software like Viewpoint Construction Imaging as well as all the Platform and Infrastructure required to run the solution.  This is the Private half. Then for example you pay for some other Software Layer solution like eBuilder for Project Management and Aconex for collaboration.  These are SaaS offerings so they also include the Platform and Infrastructure layers.  This is fairly common and again, while it does not define NIST Hybrid Cloud, it is a hybrid solution.  Your ratio of Human:Non-Human costs may be 1:1.

Scenario 3: Public

Let’s assume 100% of your solutions are managed by a 3rd party and you do not own/license any products.  Basically you are using 100% SaaS only offerings.  For example you pay for Software Layer solutions like Quickbooks Online, Salesforce CRM, and Office 365 all of which include the Platform and Infrastructure costs as well.   This is not very common yet in the AEC Industry, but of the 3 scenarios is more likely to be synonymous with the NIST Public Cloud definition as these solutions are generally not provisioned for your organization’s exclusive use.  Your ratio of Human:Non-Human costs may be the opposite, say 1:5.

With all likelihood Scenario 1 will be least expensive, Scenario 2 in the middle, and Scenario 3 the most expensive.  When this is the case, the Private solutions generally lack some expertise/breadth or meeting NIST Cloud Essential Characteristics but make better use of Resource Pooling across the solution layers.  The Public offerings may be better automated, but they are generally not sharing the Platform and Infrastructure layer costs across the entire solution.  And so the fun begins.

If you are an in house IT team gunning for Scenario 1 you might cross your arms and say I told you so.  If you are a Consultant or Managed Services provider (like my company is) then you may lean toward Scenario 2 and say but let me give you the best of both worlds. If you are are a SaaS provider fitting into Scenario 3 you may say sure, but there’s no IT headaches, we take care of all that.  Perhaps this is all true, but it can be extremely confusing and the reality is until you get the Software, Platform, Infrastructure and related Human Resource costs organized in a way that you can actually make an intelligent comparison between past, current, and future options, decision making is a fairly futile endeavor.

So you may ask, what has this got to do with the Cloud Transition Cost Management again?  Well the model we have developed here makes all the costs transparent, at each layer of the solution.  There is no more guess work unless Vendors will not provide you the information for comparison.  This is rapidly changing with more Software Only licensing models being offered which enable you use a deployment model (Public, Private, Hybrid) of your choice.  With the right information plugged into the model, you can understand exactly why one solution cost differs from the other.  With costs uncovered, you can spend more time on analysis of quality, features, and value engineering the right mix with a very modular model that can be used throughout your organization, not just for IT.

Stay tuned for Part 6: Lab Exercises and Tools where I will provide some visuals that embody what has been discussed in order to get you moving if you have not already taken off down the run way.

AEC Industry Cloud Transition Cost Management: Part 2/7, Definitions

If you missed part 1, I provided an intro and outline about this series on managing the Cost of Cloud Transition for the Architecture, Engineering and Construction Industry.  As a reminder, whether you plan to stay with your current IT solution, go 100% cloud, or somewhere in between, this series will provide you with a modular approach that will be of value either way. To do this, Finance, Operations, and IT professionals may need to learn a bit about each others worlds.   The most common problems I see in  evaluating costs are caused by this lack of cross functional understanding and communication.  With a little time spent exploring each others perspectives; cost, quality and requirements considerations can be more clearly baselined and carried forward into an evaluation.  This series is focused on costs, so to get all stakeholders headed down the same road, here's a few definitions you will need for reference:

On the IT side, the only one you need for this is the NIST Cloud Definition [Link].  This contains a number of definitions in itself, which we will primarily use for categorization vs. talking pros and cons of Cloud.  I use it throughout this site and for daily business.  So far it has passed all the tests in helping communicate cloud transition concepts between IT and non IT professionals.

On the Accounting side, it's a good idea to have a basic understanding and if possible some practical exposure to Generally Accepted Accounting Principles (GAAP) [Link] and key financial statements such as Income Statement/Profit & Loss (P&L) [Link], Balance Sheet [Link], Cash Flow Statement [Link].  I am also throwing in Chart of Accounts [Link] because if nothing else, this will be helpful to make the tie between Operations and Finance disciplines.  Beyond typical accounting, a few acronyms you may here thrown around like magic are Capital Expenditure (CAPEX) [Link] and Operating Expense (OPEX) [Link].

Traditional do it your self advocates will usually lean toward CAPEX.  Proponents of hiring vendors or Cloud providers will usually lean toward OPEX.  From a cost perspective, neither opinion is a magic bullet.  You have to find the bottom line cost to the company to make a good decision.   If your interested in a thorough run down of the CAPEX/OPEX debate related to cloud computing, here's a great article from CIO Magazine [Link] back in 2009.  Don't let the date fool you, not much has changed.

On the Cost Modeling side, Amortization [Link] is a key concept.  Most people know this term from taking out a loan to buy a house or car.  It's important to understand this concept as it applies to business and converting CAPEX to OPEX or Lump Sum to Periodic Payments on an annual, monthly or smaller incremental period.  I like to refer to these as Annualized, Monthilized, etc...  ultimately you will end up with a Total Cost of Ownership (TCO) or Cost of Solution [Link] over a period of time.  The difference between the options will be your Return on Investment (ROI) [Link].

On the Evaluation side, once we have worked out our cost model we can create any number of units for comparison and parity check across the options.  Some of my favorites that focus on the Software Application Layer are Average Cost Per User (ACPU), Average Cost Per License (ACPL), Average Cost Per Application (ACPA), Average Cost Per Application - Desktop (ACPA-D), Average Cost Per Application - Web (ACPA-W).  These averages that tend to be useful in comparison to multi-application solutions like an existing server farm.

I also like using Cost Per Application (CPA), Cost Per Application User (CPAU), Cost Per Application License (CPAL), Cost Per Project (CPP), Cost Per Project Application (CPPA), Cost Per Project User (CPPU), Cost Per Project License (CPPL).  These tend to be more useful in comparison to single application solutions like a SaaS offering.  Feel free to make up your own, as these are not listed in any wikipedia article but you will need some basis for comparison.

While the above points may seem void of AEC Industry specifics, once we get into the other parts of the series I will start to fill in the examples using Construction specific Software Applications from Autodesk, eBuilder, Oracle Primavera, ProCore, Sage, Trimble Buildings, Viewpoint and more.  I will also use some of the more general Software, Platform, and Infrastructure layer products from Citrix, EMC, Microsoft, nVidia, Okta, RSSBus, Salesforce, The Cram Group (My Company), VMWare and more.

That's it for definitions, stay tuned for AEC Industry Cloud Transition Cost Management: Part 3/7, Baselining Traditional IT Costs.


Wesley Smith CEO