The dogma of acronyms

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

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

The Relevance of Data Governance; Why the 'I' is more Important than the 'T'

It is always interesting to see that in most enterprises the T in IT is considered most important or at least it gets the better part of the IT department’s budget. This is probably due to the fact that the T is always changing. In fact in order to keep the competitive edge, enterprises need to adopt new technologies, they need to embrace new technologies. Competitive edge becomes cutting edge becomes bleeding edge.
In addition, enterprise need to keep investing in the T because their T vendors have clearly defined end-of-life dates and when the T is not supported, the enterprise is risking its continuity.
The T is a moving target and requires a constant stream of budget in order for the enterprise to keep up with the competition. In order to control the constant stream of budget and being able to manage the changes in the enterprise due to new and improved T’s we define projects to migrate from one T to another, to stay up to date with our T and to assess our maturity with respect to the T.



I think most people understand the T more than the I as well.

In many enterprises the T is treated as an asset, it is considered a business’ capital, where it is only a tool. But we forget about this. Because it is so dynamic, so hard to capture, to restrain and harness it keeps us preoccupied and we forget about the I in IT. Whereas the I is the asset. Without the I there would be no IT.
More interestingly, the I should typically not change at all, there is no end-of-life for the I. Where the T will have to change constantly, the I cannot be allowed to change. Once it is fixed and considered correct, we need to keep it fixed in order to keep it being correct. And where we do whatever we can to change the T, where we spend as much as possible to change the T to keep up with the competition, we spend close to nothing to maintain the I, to keep the I stable, fixed and correct. All the new T we introduce in our enterprise, is directly or indirectly harming the integrity of the I, yet we fail to prevent the T from impacting the I. The T is no longer there to improve the I, to enrich the I, to make the I the added value of the enterprise. In many enterprises the T transcended from the means to the end.
We have become so dependent on the T that every change in the T is controlled, the T is governed by processes, forms, people and standards in varying orders of importance depending on the maturity of the enterprise.

It is ironic that the T was once introduced for the I to benefit from. Enterprises were all about the I in those days, but the T took over, it’s dynamic nature made it more interesting, less boring than the I. Its dynamic nature made us govern its changes. It became our object of expenditure. The I was forgotten, a second class citizen in the enterprise. But it is the dynamic nature of the T that makes it less of an asset in the enterprise, every investment in the T is by its very nature not a long term investment. All of a sudden a short ROI is important for every change in the T, because it is not an asset. The T is an opportunity, one that depreciates more and more rapidly as we are more and more dependent on the T to keep the competitive edge.
The I is hardly changing at all. It is growing in size and forms, but once it’s here, it’s here to stay. The I never changes, it’s location may change but the I itself doesn’t change, the I therefore is an asset must be considered an asset. The I is long term planning and as with all long term planning in order to make sense, in order to be fruitful it requires to be well thought through, to be looked at from any angle and it needs to be handled with great care. It needs to be governed.

Back to reality.

I've been most of my professional life contracted or employed by financial institutions and I think that over the last 2000 years the way banks operate hasn’t drastically changed. The advancements in technologies has made banking more efficient and has provided us with more and more ways to get in touch with customers but the essence of banking hasn’t changed. People trust banks with their money and they trust others with this money. Banks have invented interest and interest rates in order to implement a viable business.
When one looks closely at the different banks all over the globe they mainly differentiate by the level of service offered to their customers and where it is relevant the reputation of the bank in the market it operates in, be it a geographical market or a business market.
The advancements in technology in the last decade have turned financial systems into commodities, where software companies can develop generic solutions for financial markets in a far more cost effective way than these financial institutions can. Due to this commoditization of technology in the financial sector, it becomes more and more difficult for enterprises in this market to differentiate by the level of service without exclusivity. Nowadays every bank has an online presence and the maturity of the bank defines the diversity of its online presence (internet, phone, mobile, smart-phone apps, etc). Because of this, the technology they have at their disposal does no longer provide a means to differentiate them from their competition. It no longer can provide them with a competitive edge, it can merely streamline their processes and polish their image.
These days they have to differentiate from competitors by the amount of information they have about their customers in the context of the customer’s world. The customer wants to know his complete financial situation. He wants to know his exact position, but also the bandwidth of his credit. And he also wants to know this in the context of his current situation. For example, he is abroad and needs to pay a hotel bill, he will not be interested in the amount of money in his savings account, but he will be interested in the limits of his credit cards. But when this same customer is back from vacation he will be less interested in his credit limits, but will be more interested in his expenses for each of his methods of payments. He will be interested in what is paid by which credit card, what is paid for by debit card, when and where does he use an ATM and how much did he take from the ATM. He will want to know what bills are being paid and how much each bill was. What are recurring payments and is there in trend in the amounts of these payments.
It is not technology that he wants from his bank, but information. As a bank, people traditionally trust them with their money and in an ever more digitized world, they trust banks with their data about their financial situation. It is up to banks to turn this data into relevant information for their customers. In order to do this efficiently and to provide the services to their customers efficiently they need technology. The competitive edge is in the fact that a bank can turn this data into information for their customers that is relevant in different situations.
Meanwhile, the same data is used to streamline the internal processes and allow for better analysis of the financial markets and the general business a bank is in. Customer data is the micro level information that is important in understanding macro level economies as long as it is in abundance. After all the financial business is more than anything else a business of people and their trust. And accurate information is the cornerstone of this trust.