Hi, I think that when you know me, you know I don't like acronyms, especially those acronyms I encounter at work. I really don't like the ESB, SOA, ITIL, TOGAF, TRM, BPMN, BPO, etc in this world. I get really nervous around people that use them. What even makes me more nervous are those acronyms that refer to 'Best Practices', 'Adaptable', 'Frameworks' and 'Models'. The reason for my dislike of acronyms is that they tend to be very dogmatic. And I really dislike dogma. The worst of them are those that are brand new. Acronyms I mean. The new acronyms are the worst because they're typically an existing acronym's reincarnation or they're so new that nobody has experience in them. Even worse acronyms are those that provide certifications, multiple levels of certification with accredited training. Well, actually I don't really dislike acronyms, but I do get nervous around people that use them. Most of the time anyway. Because these people are usually very dogmatic about what the acronym stands for. They've lost every sense of pragmatism and reality for that matter. When they reason that an acronym is great because it represents the best practices, they tend to forget that you really need to be very pragmatic when applying the acronym. Tailor it for your specific situation. Explicitly not being dogmatic at all. My experience is that architects that use frameworks and methodologies that are summarized by an acronym, knowingly use them. That purposefully use them, have no to little clue what they mean, what benefit you can get from them or why to use them in the first place. When this is a result of inexperience, it is not so bad. But an experienced architect that falls into this category is probably not that talented. Those esteemed architects I've come across that were actively applying an acronym told me later that they found out by accident that they were doing the acronym. And now were leveraging the work of others to document their way of working. As a starting architect the acronym is there to give you guidance, a head start, as an experienced architect you have the acronym to help you guide the starting architects in your team. Iwan
An iconoclast's take on IT. While staying away from conventional wisdom, publishing personal views, insights and ideas. All stemming from day to day experiences in a world where mainstream is pulling the brake on innovation.
Translate
June 19, 2012
The dogma of acronyms
Labels:
Architecture,
BPMN,
BPO,
Enterprise Architect,
ESB,
in,
IT,
IT Architect,
ITIL,
SOA,
TOGAF,
TRM
June 5, 2012
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
Subscribe to:
Posts (Atom)