A few times every year, I sit down with the topical experts at Cegeka. Today: Toon Martens, Director of Application Modernisation, and a remarkably enthusiastic evangelist for Composable Business. We talk about:
- Composability: old wine in new bottles? Or is there something more to it?
- Composable business in a nutshell.
- What does composability mean in the sphere of architecture?
- What are fusion teams, and how do they work?
- Composability as a corporate culture: what should you look out for?
- ... and how can Cegeka give organizations more help?
There’s a lot to debunk. Let’s roll!
Toon, since Gartner came up with them in 2020, composability and composable business have become buzzwords in IT jargon. But what do they actually mean?
Toon Martens: Well, to start with it isn’t a new concept or a new term. If you Google it, you’ll see that IBM was already talking about composable business in 2014. And those who studied information science in the ‘nineties will be familiar with the idea, even if other terms were used at the time. To be honest, it’s a question of old wine in new, somewhat more attractive, bottles. Or as Stijn Bijnens, our CEO, puts it: at heart, it is nothing more or less than software engineering done right.” (he laughs)
Integration platforms today are much more mature than about ten years ago.
“What has changed, in comparison with back then, is how the term can be interpreted today from an architectural and technological point of view. For example, integration platforms today are much more mature than about ten years ago. Today, with such a platform, you can have your legacy systems communicate via APIs with the rest of your application landscape much faster and more cost-efficiently. It was previously much more difficult to set up such integrations.”
Taking a step back, can you sum up the concept of composability clearly and concisely?
Toon Martens: “It’s quite a complex matter, but in the end it comes down to extreme modularity. Composable apps are made up of building blocks - such as microservices, for example - each of which represents a neatly delineated business capability. These building blocks are autonomous to the extent that they can be replaced or modified without any impact on the rest of the application landscape, and without operational hitches. As a user, you simply don’t notice them.”
“The opposite? Monolithic ERP systems or legacy custom work with a spaghetti-like architecture. Such systems can go down completely if a new, big release is rolled out backstage. A composable application built according to the rules of the art doesn’t have that problem; small, frequent updates are rolled out without any problem for the end user. It’s a bit like the apps you find on your smartphone.”
You say “according to the rules of the art”. What does that involve?
Toon Martens: “Well, at Cegeka we firmly believe you should ideally have four things properly under control in order to work with composability, and to maximise the benefits from it. The first has to do with architecture. You need an integration platform or iPaaS, so that you can allow all the applications in your landscape – from SaaS apps relating to legacy systems to custom applications – to communicate with each other and the outside world in a flexible and secure way.”
Composable apps are made up of building blocks - such as microservices, for example - each of which represents a neatly delineated business capability.
“It’s also best to invest in a data or IoT platform, so that you can combine the data from your various applications and allow Artificial Intelligence to make use of it. And a Cloud-native Application Platform, in which all the non-functionals are provided as standard, so that developers can focus on application functionality and don’t have to re-invent the wheel.”
“This shift from non-functionals to an automated platform not only gives you a huge increase in efficiency but also helps to keep everything secure and stable. You can do this by maximising your use of the PaaS services of hyperscalers such as Microsoft. But you can also call on cloud-agnostic platforms that can support all cloud scenarios.
And the other three things that you absolutely have to have under control?
Toon Martens: “On the process side, you have to think as flexibly as possible in accordance with the principles of agile/SAFe, DevSecOps and ‘everything as code’, but in some cases ITIL or waterfall/PRINCE2 are also the right approach. Thirdly, you have to choose the right tools, and the code word here is maximum automation. Finally - and it will come as no surprise - the organization and, above all, the culture and mindset have to be right.
Can you give an example of that composable organization?
Toon Martens: “Yes. For composable working to be a success, people have to unite and collaborate in what are termed ‘fusion teams’. These are small, multi-disciplinary groups in which people from the business and IT divisions work together continuously on a certain business capability. A team of this type forces IT people to think and develop in a more business-oriented way, and forces business people to get a feeling for the technical side of affairs.”
For composable working to be a success, people have to unite and collaborate in what are termed ‘fusion teams’.
“I spoke just now about building blocks from which composable apps are constructed. Actually, each building block is a kind of business-oriented microservice that communicates via APIs with the other blocks. A building block like this stands out from the more technical spaghetti of microservices that many applications consist of. In a fusion team, there is a much smaller chance of technical confusion being created.”
Legacy software is one of the top 3 headaches for CIOs. Can you make legacy software composable?
Toon Martens: “The question is, how composable? Look, you can forget about turning legacy software developed before 2010 into a composable application. Legacy software from after 2010, with sound architecture: that already has more chance of success. But actually there’s sometimes simply no need for that, and it’s sufficient to have the legacy software communicate well via APIs with the other applications in the landscape.
Look, you can forget about turning legacy software developed before 2010 into a composable application. Legacy software from after 2010, with sound architecture: that already has more chance of success.
“If you superimpose an integration platform - the iPaaS I was talking about - on your legacy system, then you can not only get your legacy software talking with the other apps, but also gradually phase out segments of it and replace them with composable apps, if that’s worth it. But sometimes monoliths are quite alright, and do their work excellently. And then API’s are enough.”
Is there any myth about composable that you want to refute?
Toon Martens: “Hmm... perhaps the idea that you’re on the right track if you have one or two of the things I mentioned under control, but not all four. I often see that happening. Organizations have the tooling and the platforms, but not the mindset. Or they are working in an agile fashion, and with DevSecOps teams, but remain in their silo or business unit, so that the data they generate can’t be shared with the rest of the organization. That happens more often than you think.”
Finally, what is Cegeka doing in the field of composability?
Toon Martens: “Of course, clients don’t ask for ‘composability’ (he laughs). Clients want to have their application landscape in good order, to reduce costs, and to be cyber-resilient. They want stability, but also the possibility to rapidly switch and to scale, and all that in the context of a worldwide war for talent. Our point of departure is always the proposal request, the client’s specific problem, with the composable philosophy at the back of our mind and looking at things from a holistic perspective.”
Clients want to have their application landscape in good order, to reduce costs, and to be cyber-resilient. They want stability, but also the possibility to rapidly switch and to scale, and all that in the context of a worldwide war for talent.
“Something we have a lot of experience in is analysing, managing and/or modernising applications. In this, we apply our own version of the 6R method in order see whether (and if so, how) we can successfully migrate applications to the cloud. This part of the business is running at full speed, because there is still an enormous amount of legacy software. Legacy systems usually have a very high business value, but they shouldn’t put a brake on our clients’ ambitions.”
“If we are to build applications, then we work in accordance with the principles of software engineering ‘done right’, such as containerisation, the right mix of high, low, and no-code, separation of concern and so on. We are experts in setting up platforms; for example, for integration (iPaaS), data and IoT, or the cloud-native application platform that I mentioned earlier. And in the field of standard ERP, we work with systems that are constructed to be composable.”