Commercial Considerations and Enterprise Architecture

This post is dedicated to my colleagues in the Government ICT Supply Management Office within the New Zealand Government.  I’ve learnt a lot from working with them over the last few months.

When working in the ICT architecture of an organisation – whether enterprise architecture or solution architecture – your architecture will always be better for a well-informed engagement with the commercial side of ICT. In this post I will describe why it is important to understand the commercial aspects of ICT in order to deliver more successful ICT solutions, and how working with your commercial team can assist in this success.

In my experience, most architects couldn’t care less about the procurement of ICT or the commercial aspects of the solutions they architect, design and deliver.It has only been recently that I have had my eyes opened to how important these aspects of enterprise ICT are. If we view one of the key measures of success of an ICT project as being return on investment (ROI) then the cost of the solution is one half of determining the ROI (the other half being the financial benefit accrued). If, as part of the solution, we are procuring software, hardware or services the costs of obtaining them are likely to form a significant part of the overall costs of the solution. It follows from this that the process of negotiating these costs (procurement) is obviously very important. To give an example: if we are implementing a solution to deliver a new product to market it doesn’t matter if the solution is brilliant from a technical point of view if it is so expensive that it costs more than the revenue that  the new product brings in.

Beyond the initial purchase costs, if we are to really understand the ROI we need to consider the ongoing costs of the solution. A significant portion of this can be the ongoing support and maintenance fees associated with enterprise software (and hardware). Typically the annual support and maintenance fees run at about 20% of the cost of initial licenses. Many vendors, however, will heavily discount initial purchases and instead rely on annual fees to form the bulk of the revenue. When looking at your solution components you need to understand the scale of annual fees you will be incurring and what you get for them, otherwise you will not be able to understand the likely operating costs of the solution.

Besides the purchase cost of the hardware or software itself, another aspect that we need to consider is the cost of the procurement exercise itself. Heavy-weight procurement exercises such as RFPs can cost a large amount of money to run and take a long time. While this is more of an issue within the public-sector where fairness and open-ness are mandatory, it is still important in the private sector too. It may make sense to implement a less technically preferred solution using already purchased components than it would be to run an expensive procurement process. Or, conversely, we could tailor the procurement process (where possible) to meet the constraints (financial, timeframe or other) that the solution is developed under.

Beyond mere price, you should be asking the question: “Does the commercial construct of this ICT procurement align with the goals and purposes of the architecture?” For instance: does it make sense to buy hardware and software outright when what is required is a temporary solution with a short life-time? In this case a leasing/renting model or Software as a Service would probably be in better alignment with your architecture. If you are making a significant investment in a solution that locks you in to a particular technology then a short-term commercial arrangement where the vendor can raise annual fees whenever they feel like is inappropriate. In that case you are better off locking in support fees for a number of years. For a high transaction volume system is a per transaction licensing model best? (Unlikely.) Per user licensing works best for systems with a lower number of users, rather than for an enterprise system that everyone must use but mostly infrequently. If your ratio of devices to users is high, then licensing on a per user basis is better. However if your enterprise composition is the other way around (with a large number of shared devices) then licensing on a per device basis is better. From these examples you can see that the kind of commercial model can make a big difference to the financial viability of a particular solution. The more options you can give your procurement people, the more information they have to base their negotiations on, the more likely you are to get a licensing and commercial model that maximises the benefits to your organisation.

To summarise the following commercial considerations should always consider the following factors in the architecture of your enterprise and your solutions:

  • The initial cost of the ICT components (and the leverage you need to get the best price);
  • The cost and time of a procurement exercise (and what is the most appropriate procurement approach);
  • The ongoing support and maintenance costs of your solutions (and what that gets you);
  • The commercial constructs negotiated with vendors.

For large projects or expensive software, work closely with your commercial and procurement teams to ensure that the right technology and vendor are chosen for your architecture, the right contract is negotiated at the right price and that your architecture best utilises the commercial construct that has been arrived at. Doing this will lead to greater overall success of your architecture whether it is project or enterprise in scope.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: