The basics of the business perspective (AKA the logic many aspiring VCDX candidates forget during mocks).
When people start up a company, they believe that they have a product or service that will outperform the competition and they want to start selling this product or service to potential customers. Although the business owners and the business management might really believe in the excellence of their product or service, ultimately they need to earn money to sustain their business. In a sense you could say that the business mantra has four words: “More Money, More Profit.” So there you have it, the monster is out. The ugly truth about business is that without money, there is no business.
If you would take a look at the total lifespan of a company, from when it is founded until the moment it stops existing, you would notice that a company changes over time. You would see that the vision on how to achieve the goal will change because what customers want and need changes over time as well. But the goal will never change. Companies will always want to make money (of courseI am ignoring company bankruptcy where companies need to reduce loss).
Yes, I know this really is oversimplified but it makes it easier for me to get my point across. 🙂
Let’s analyze this and put it into perspective for the VCAP-DCD exam:
- A company has a VISION: Selling their product/service
- A company has a GOAL: Earning money
And basically, that is all there is to it.
What does this have to do with IT? (in progress)
You always have to keep in mind that to spend budget (money) you will need a justification for the costs. In all cases the driver for spending money is/should be a business reason.
In a way you can say there are 2 major reasons to spend money on IT:
– The business wants to expand to a new market and needs new IT tools / or a new architecture to explore the new market.
– The current tools have to be upgraded (licensing, EOA, EOS, etc ) because the business might be/will be negatively impacted when the current tools fail or do not have the newer features.
So the adoption of newer tools/architecture should ALWAYS be business driven. The new architecture/tools have to benefit the business, although this can be a direct benefit as well as an indirect benefit. Whatever changes you make in IT, whether that is an organizational change, an infrastructure change, a technical change, a security change, an availability change, a recoverability change and so on, you make those changes so the business can continue chasing their goals.
Of course there are other things to consider: Risks, Opportunities, compliance, rules and regulations, etc..
Let’s look at a small example. If you have a small company and run only a handful of servers, spending money on vSphere Enterprise Plus licensing might be more than you need. Although the features are technological improvements over the features presented by lower licensing types of vSphere, do you really need the Enterprise Plus features? Does not having those additional services have a negative impact on the business or not? Give this thought a few minutes if you have to.
Take note that ‘IT as a service to the business’, whether that is internal IT or IT provided by an external provider, in itself does NOT make money for a company. Instead it has a cost. That is right, from a business perspective, IT is a cost centre. IT costs money, not just in hardware or software, but also in operations. To run IT means: paying for staff, paying for location, paying for electricity, paying for software and support, paying for hardware and support and so on.
This is NOT the same as ‘IT services being sold’. I am strictly talking here about the IT services you run to keep a company running and make more profitable.
But although IT is a Cost Centre and requires investment, when applied correctly (let’s not get into what correctly means or can mean) it also enables the business to grow. It is in this field where IT has to sell solutions; making businesses invest in reduction of loss, increase in growth, enablement of compliance, rules and regulations. IT when in line with the business can help achieving all that.
Imagine you run a big electronics shop, it is black Friday and the area around and inside your shop is filled with potential customers. At the same time hundreds of customers are walking through your shop and about a hundred are queueing up at the tills waiting to pay for all the products they want to purchase in your shop. To lure more customers to your shop you have advertised that free WiFi (you also get to gather customer details when they sign up for the service, bonus! -GV) will be available inside and outside of your shop. Most of these (potential) customers, while waiting, are flicking through Facebook pages, using WhatsApp, going through Snapchat on their smartphones and watching YouTube videos. Unfortunately your access points only support 300 users and you estimate there are at least 700 potential customers around. After an hour or two you notice that potential customers outside the shop and even inside the shop start to leave. After asking around you discover that most people are leaving because of the free WiFi which is hardly accessible because too many people are trying to access the same Access Points.
It is pretty obvious why (potential) customers start leaving: You have promised them a free service and have not been able to deliver. There are few things as bad for your business as promising a free service and then not being able to deliver.
Now there are two ways to look at this:
- The IT perspective; we need more Access Points because not all users were able to access the WiFi and clearly they started leaving because we promised them something and did not deliver.
- The Business perspective; we need Free WiFi available to all of our customers otherwise potential customers might start leaving and we will sell less. The costs of implementing additional Access Points will be high, but losing customers will have a bigger negative effect in the longer run. Loss over time can outweigh the impact of initial costs.
So try to think of IT as a business enabler. It should allow the business to take care of business by giving them the tools to reach more potential customers, to keep customers more happy, to enable everyone to perform with excellence. In our time, not having the right IT for the business will kill the business equally well.
Let me give you a more crude example, something more in-line with architecture. Why the Business doesn’t care about your three 9’s, five 9’s or whatever.
The business doesn’t count in 9’s. Instead they count in seconds, hours or days in or out of business. It might refer to the same, but you might as well speak a foreign language when you mention the 9’s to some business people. However the business does understand what the impact is of not having their business tools online for x amount of time. Time after all equals money.
Why IT has a hard time seeing the business perspective
Actually the title is not completely correct because depending on your function/role within the organization you work for, you will have a worse or better insight in the business perspective in the company you work for. Hopefully the drawing below will show you how much information you need about the overall business perspective to be able to do your job. I am not talking here about that little thing which might be customer facing, but the business vision of the company itself). The more to the right in the drawing, the more you need to be aware of the business vision and goals.
So what about IT Architecture and Design, who much do you need to know in your current role or function? (in progress)
The further away from the IT architect, the less you have to know about the technical specifics of the IT architecture. Support engineers have to support the end-users, engineers have to support the infrastructure and C-level just wants to know if the IT infrastructure will support the business and will support business growth.
There are far better resources to explain business than this blog. But I would like to help you understand what the fundamentally drives a business and what ultimately also drives IT design and architecture. I want to help you understand how to translate business needs to technical solutions and to help you understand why a lot of times management says NO to a technical improvement where you clearly see the benefit by implementing it but the business doesn’t see it.
There is logic in this non-technical madness. I promise!
Bilal VCDX #251
Now Kim has written up a very good concise post about the business perspective. The main thing I would like to emphasise on is that talking about 5x9s, SPOFs etc is all great, but at the end of the day as Kim rightly mentioned the business does not care.
I mean lets think about it some more, you can have a SPOF somewhere but why would they care? I mean it works right??!! Why spend more money when it will work the way it is?! But if you explain that if it goes down you could suffer a major outage and they have told you that they can’t afford to be down for more than 8 hours in the year (4x9s), and that outage could bring their whole business crashing down….that is something they will fully understand and get behind.
Another example is the business doesn’t really care if they have the newest fanciest architecture unless it is helping them. But can it be done in a simpler way, if they have a lot of staff….who is going to train them on a major infrastructure change….there is a cost and risk with that…do you really need to re-invent the wheel for them.
It’s your job to meet their requirements, constraints, risks etc and ensure the solution meets what they want. You are the guy who extracts this information and gets into the weeds to help them get what they want to help the business run and grow.
This topic can get very complex, BUT there is no reason for it to be overly complex! I am a firm believer there is no need for anything to be harder than it has to be!
Graeme (current MBA student!)
At the end of the day if you’re trying to help a company, even if you’re not talking to the senior leadership team, you should always try to understand a few key things:
- What product / service do they sell?
- How does selling that product / service equal revenue?
- How does technology underpin the process of money moving from the customer to their bank account?
Business acumen is a valuable skill to grow because it’ll enable you to highlight where you can deliver business value. This is the only thing that senior management really care about, they care very little about the low-level technical details that make up the technology solution that they end up choosing. They care more for the following:
- Does it meet the overall business goals?
- Return on investment?
- Is it strategically right for this company?
As an example, refreshing a load of their physical infrastructure. As Bilal said, they don’t care for SPOFs. They care about the business impact that a failure would have, which is why it’d be highlighted to them.
Or maybe they will identify that strategically, the public cloud is a better fit. Therefore they have decided to start their cloud journey and digital transformation – a 1-3 year journey at least. They have decided that they would rather move to a consumption-based model which all of a sudden means that the underlying infrastructure is taken care of. You might find as an architect, worrying about using two network cards in a server and two switches is a thing of the past. Instead, you’re worrying about making sure your cloud solution is geo-replicated across two different cloud providers for redundancy.
The higher you go up the hierarchy, the less you need to know technically as you can start to rely on other SMEs and experts in the overall solution you’re putting together. This is why it’s so important to understand how the business is tied to the technology and the problems you’re solving, because often the SMEs will be focussed on their area alone. Think Manhattan project, the pieces come together to form the whole!
There’s very little that makes me happier than helping a company transform itself, with returns on all sides.