I graduated in physics, and management. I love math, philosophy, latin, ancient history. But obviously I’m very passionated in what computer can do. Actually, they only do three main tasks: compute information, store information and transfer information. Nothing more, and nothing less… Once this is understood, then obviously, you start noticing that information in “Information Technologies” is the main part…
It all starts from business level, it all ends at business level
Razor of Occam tells us to avoid unnecessary concepts. Indeed, the only relevant information for a company is only the one that directly relates to its business. This is why all knowledge, all questions we ask, every piece of analysis should start from there.
Formulate and understand the information, not the plumbery
Information and knowledge start with language, right use of words and some abstraction capacities. This is why these skills are very important to me. Most of the time, difficulties in digital transformation start by non being able to formulate correctly the vision, the current situation, the needs. No wonder why many methodologies start from business glossary or ubiquitous language as tools or even frameworks to solve the problem…
Since IT is only made of human, in most companies, there is no such thing as “computer science”, information systems should only focus on the information, in an ideal world, technology choices are transparent on business operations.
Need for decoupling
But then, when I say that technical choices should be transparent, we often face the actual situation: the “legacy” or when emotion are left apart, the pragmatic attitude stating that we never start from scratch.
If people care about current and future plumbery, it’s because it has not negligible impact: positive and negative. Most of the time, the negative impact is simply caused because nothing is simple and need a lot of analysis, and it’s hard or not always possible to scope the changes to the direct stakeholders. This is called coupling, and it should be reduced.
Real SOA
To manage a complex problem, you divide it into smaller parts, but not every split of the problem will lead to actual independent parts that can evolve without any impact to the others. If there’s no mathematical formula, I can give you a trick: that splitting into “services” that are truly independent should be based on a business criteria, not on the actual plumbery.
Integration
But then, if it’s totally of the actual landscape, how to get there? And how to pretend that independent part will never share information? Well, sure they will do, and the path to actual decoupling may be very long, depending on the current situation. This is why integration vision is key: integration as an end to keep pieces decoupled from each other, and integration as a way to get there… And sometimes, there are intermediated levels of maturity to take.
The day in which a company will know and easily play with the business information it manages, and that the IT system (the plumbery) will be implemented in such a way that business will finally be able to evolve faster and by smaller decoupled pieces, focused only on business information, then I’ll be an happy man.