A Bottom-Up approach to Maintenance and Support doesn't make any sense

First of all, please note that my view on IT is that it services the user and when used in an enterprise, it services the enterprise. Typically we refer to the enterprise part that IT is servicing as 'The Business'. There is no other raison d'etre for IT other than to service.
With that being said, it should come as no surprise when I say that I consiser IT to be a tool. It's a tool that is supposed to be utilized.

With that out of the way, let's move on to the topic of Maintenance and Support and why it makes no sense to address this bottom up.

First of all, what is bottom-up in this context. For that we define the stack that an IT system typically consist of. At the very bottom of the stack we have the communications infrastructure. This is the Network. It is somewhat an odd-ball in this discussion, as the Network is not limited to a few systems. But for argument's sake, we start with the Network, the communications layer.
Next we have the hardware layer, this can be physical or virtual. But in case we're talking virtual, it does make sense to separate this layer into two sub-layers. For the purpose of this post, the division is not relevant.
On top of the hardware we have an operating system, and with that the rest of the system infrastructure. Think about anti-virus, system firewalls, etc.
Next we have the middleware, or rather we have software engines. Think in this regard about application servers, database servers, webservers, messaging servers etc. These are not all considered middleware, but they are engines. Generic pieces of software that provide specific services to application specific software.
Which brings me to the next layer, the application software. This is in fact the software that provides the services that the business benefits from.
Finally, there're the business processes in which the applications play a part. As with the communications layer, this is sort of an odd-ball. But within this post it is in fact relevant.

Now looking back at the start of this post, IT services the business. And the business is in fact defined by its processes. Without processes there is no business. Mind that the processes do not necessarily need to be formalized or even repeatable. I'm just saying that the business is defined by how the various actors interact, these interactions are processes, the business processes.
Consequently, when the business can't execute its processes, it doesn't function. Nothing gets doen. When it is impossible to execute the business critical processes, the business seizes to exist.
Thus, from an architect's perspective it becomes critical to understand these processes, or at least their criticality, and the demands regarding the processes to be executable. Hence, and now we're getting close to where I want to be, the architect needs to understand which steps, which actions in the various processes are automated. This is where IT kicks in!

Now you understand that an architect should worry about the availability of the capability to execute a business process and an IT architect, should worry about the automated parts. These are the business services, or in fact the applications. (Yes, I know that I'm simplifying this a bit, but within the context of this post, that is fine.)
So, (parts of) applications need to be available and the data used in these applications need to be secured. I'm saying parts of applications because more and more we see applications to be composed of reasonably disparate parts. What is 'available'? It means that a business service, an application's functionality, is accessible and once is started it is concluded within an acceptable timeframe. This is important, because when the system does execute but not fast enough, it should be considered unavailable.
What does it mean to secure data? Well it means that the data has to be available, can't be tampered with and can only be accessed by those that are supposed to have access.
We typically define these by using KPI's, typically RTO (Recovery Time Objective, i.e. how long till a service is available again), RPO (Recovery Point Objective, how much committed data can be missed) and an up-time defined in an amount of time the service can be unavailable over a period of time.
These are all business requirements, all to be defined by those that can understand what it means when a process can't be executed.

We're getting close to where we need to be, or rather where I want to be with this post. The topic of Maintenance and Support. Once a process is being used, it needs to be supported and maintained. For IT systems, it means the same. These systems need to be supported and maintained as well.
The roles that need to maintain and support are dividable in three areas: Functional, Application and Technical. Basically it's about the people that understand what the system should do, which services it should provide. Functional. The people that understand how the application works and how it can be kept working. Application. The people that understand how it all actually runs on the systems. Technical.

Let's bring in the animal kingdom, shall we; There are different ways to skin a cat. By this I mean that there are different ways to keep a process executing. And that's the whole point! The process needs to be kept executing. This is what maintenance and support is about. Full Stop.
By realizing this, it becomes clear that from a functional perspective it must be defined in what circumstances what needs to be done to keep the process executing. And in the cases IT is needed, it must be defined what needs to be done.
But that's not the point, the point is that those KPI's that are defined, the RTO, RPO, etc are regarding the business service. Explicitly not, and I emphasize this, the application or the infrastructure or the network. This is what needs to be managed. So in order to provide in the requirements regarding this, it must be implemented at the top of the stack. And then you go down the stack realizing these requirements. Just like any other business requirement.

Talking contractual issues, the SLA and OLA, is the exact same issue. The SLA is defined on a business process layer, the SLA defines to what extend the process can execute and then trickles down. Down the stack, to ensure that it can be done. And the OLA's are there to ensure that everybody is on the same page and commits to help meeting the SLA with everything at their disposal.
It should be clear that it is rather pointless to define and agree an SLA on a lower level in the stack when that doesn't support the requirements higher up in the stack. It would be a waste of money as the enterprise will still falter when poop hits the fan.
Again, it's the same as with all other requirements, you don't build something that doesn't help doing business.

Agreed, my post title should've been "A Top-Down approach to Maintenance and Support is the right way" as this is what I'm discussing here. But I choose to be a bit controversial here. Why? Because too often I see that the bottom-up approach is taken. Enterprises consistently fix availability at the infrastructure level. And genuinly believe that this is cutting it. Not realizing that it doesn't. Furthermore, they invest extensively in expensive IT solutions that are typically complex to maintain and support. And because of this, there's rigid standardization enforced to keep costs down.
Consistently, enterprises are solving business problems that are not conceived as business requirements, we actually call them non-functionals most of the time, using technology. Preferably hardware, virtualized.
This is counter-intuitive because any other business requirement is actually addressed top-down.

One of the reasons for this behavior is that 'the business' doesn't think of how important a business process is, how important the automated activities are, how valuable the data is. When asked for the RPO and RTO it is typically conceived to be a technical issue. Typically the answers to RPO and RTO are that they need to be '0', i.e. no downtime and no data loss. Of course this is incorrect in all circumstances, because the RPO and RTO are to be defined on a business service level and in pretty much all cases it needs a significant amount of analysis to come up with the real numbers.

So, yes, the title is correct. Why? Because we keep on doing it the wrong way. We keep on messing up. We keep on spending money where it doesn't need to be spend. And we keep on not delivering what is actually required. Why? Because thinking about it and get to the real answer is actually hard and just throwing more kit at the solution will seem that it will fix the problem.

IT is irrelevant when it comes to business criticality!

I hope I got your attention, because that is the sole reason for the title of this post. Of course IT is not irrelevant, it is very relevant. But it is not that important as many architects would like you to believe. Well IT architects that is. I would like to believe that your Enterprise Architect and your Business Architect would actually subscribe to this notion.

So what was I thinking when I decided that IT has no relevance when it comes to business criticality? You may actually ask yourself what I was smoking or sniffing when I started this post. Well the sheer fact that businesses where there long before the arrival of IT and most of our business processes today are still very well possible to be executed without IT. Probably not as efficient, after all that is why we have IT, but they can be done nevertheless.

Communication on the other hand is very crucial and having a means of communication is critical for business continuity. The more efficient we communicate, the more efficient we can do our work. This is why you always see that the most effort in IT has always been in the area of getting the right information at the right time at its destination.

And this is where my post starts to make sense, well it's the start. When we talk about information getting at the right time at the right place, we are talking about defining the business process, after all this is what a business process is all about; Moving information from one person to another, from one system to another. With every person, every system doing its magic with that information. Transforming it, enriching it, creating new information from it.

Back in the days we didn't have computers, we did have processes. And we had technologies to move information from one person to another. By couriers, Pony-Express, tube-systems, etc. Than with the advent of machines and later computers we started to make some steps in the process more efficient by automating them. Most of the processes stayed, in essence, the same, but we made them faster so we could produce more of the same. Make more profit and keep shareholders happier. But since the processes are still the same, we can replace the automated steps with the original manual steps again. Without compromising our business other than not being able to produce as much. So IT is irrelevant for the operation of the business unless you want to make money that is.

But here's the deal, when it comes to the operation of a business, the continuation of the business, the success of the business. IT is only a tool. It is the constellation of processes that defines the business, that ensures business operation, allows for continuity and determines the success of the business. Probably IT has a strong impact on the success of the business, but unless the process is clearly defined, the costs of performing each step in the process is known (to a degree) and we know what the cost of an automated variant of that step would cost, there's no reason to automated. In development countries, the emerging markets, manual labour is relatively cheap. This is why you'll see 10 men digging a canal instead of one man using a bulldozer. Because its cheaper, more cost efficient. Even in the western world, where manual labour is relatively expensive, automated solutions are often more expensive. Work is being automated or machine aided because time is a constraint, scalability is an issue or the labour is too hard and machines more reliable. But automation is and should always be a conscious decision.

With today's state of technology, we can automated pretty much everything and more importantly we can automate the governance of our business processes. This means that we can control that very essence of our enterprise, the process and keep tabs of what is happening when where by who and why, all in real time. Allowing us to make split second decisions when they are needed but more importantly ensuring that the the right information will arrive at the right time with the right person or system. Alerting us when this is not the case, telling us why it is not the case, keeping track of how often this is not the case. We call this Business Process Orchestration and in my humble opinion it is the going to be the area in IT that will garner the biggest cloud.

An important aspect op Business Process Orchestration (BPO) is that it allows us to unambiguously define business processes in a way that is almost technology agnostic, meaning that we can define he process without too much information as to how steps in the process are implemented. Of course to make the process track and traceable, we need to know the implementation and in a true BPO governed environment we have to go to that level of detail, but think about this; when we define our process at a high level such that it is almost irrelevant how the steps in the process are executed we can use this definition in various contexts.

Which is important why?

Remember I stated that the essence of an enterprise are it's processes, this means that in order to make the enterprise more profitable it is required to make the processes more efficient. And in that same train of thought, when the health of the enterprise is in jeopardy, it is important to make the failing processes more healthy. This can only be done when you control the processes and are able to manage them. This is exactly what BPO intends to do for us.

Now think of a scenario in which the health of the enterprise is pretty awesome but all of a sudden the enterprise finds itself close to dying. A serious disaster has struck the enterprise, for example an earth quake hitting the data center, a tsunami has taken its toll or a revolution has overthrown the stability of the country. In this case you're faced with a situation in which the business continuity of the enterprise is at risk. You're required to ensure that those parts of the business that are crucial for its continuity are taken care of and running as always. Which from an IT perspective means those systems that are crucial need to be up and running, most likely at an alternative site. And here's the multi-million dollar question, literally, what are the crucial systems?

In the old days this was simple, the was only one system, the mainframe, you needed 2 of them to be ready for whatever disaster. Nowadays this is not that simple. Systems depend on each other, have different designations and different technologies. More uses and a variety of uses as well. So how do you determine what's crucial and what's not? Business processes to the rescue.

Look at the processes that are crucial, the systems used in those are crucial. Look at the costs of making these redundant and see if the 'manual' option is viable as well. For those systems where there can not be a manual alternative you spend the dollars to make them disaster recoverable. While doing so, don't forget to keep in mind the RTO ( Recovery Time Objective) and RPO (Recovery Point Objective) of these systems and obviously also the Confidentiality, Integrity and Availability (CIA) rating of the required information.

As you should understand by now, the business process is key in all of this. And there is no point in spending time and money on IT without knowing what processes are being served and how crucial these are.

As always, I'm more than happy to read your comments and learn from them. Happy to feedback as well on any of your questions and maybe other may answer them as well.

Iwan