I recently worked at a fintech company that has been in business long before “fintech” was invented. So, the company was in effect a granddaddy in Fintech domain.

What I have seen there is something I have never seen before. The company was devoid of “applications”. It was also the most diverse technical infrastructure I have ever seen (and I have worked at global companies like HP, Morgan Stanley, RBC). Needless to say that that was pointless for a small company. It was just a sure way to waste money and complicate things, which is another way of saying “to waste money”.

For this company, the application concept was really meaningless; it was all about components. The best definition of a component there was something with a 3-letter acronym, it might have been an API gateway, an adapter, a connector, a whole enterprise system, a bunch of interfaces, an application server, a Kubernettes server, a layer, a proxy server, a proxy server with an ISO compatibilty layer, a group of UI screens, etc., etc.

There was an indication of this in one of my interviews, when I asked a top-level product owner how many applications he managed, he couldn’t tell, 10 to 15, he said. I thought it odd, maybe he wasn’t that competent, I thought. But when I joined, I realized his problem wasn’t really competency, it was just that they didn’t really have applications, just quasi-business services drafted over technical components. The company wasn’t driven by business; it was driven by technical solutions.

This is a situation that Martin Fowler identified 22 years ago here but it’s coming to fruition only now. Companies are now discovering that, having converted most of their back-end to services or service-like components, it’s hard to keep track of them and align them with discrete business functionality. So maybe this fintech company is at the very forefront of modern design, which is no longer application-centric but service or component-based, in that one doesn’t create unified business functionality under the umbrella of an application but rather pieces together a specific business task functionality based on underlying technical components. This would contradict Fowler’s point that “applications”, though social constructs, are useful and will stay around as they give unified meaning and purpose to various components, which all the participants in the “production” of the application can understand and use to guide their efforts.

I need to mention that this specific fintech company had a good reason to rely on stitching together bits of functionality to achieve the end business result. They provided the back-end payment services, usually one link in the chain of services, where often there was no GUI to their service, and if there was, it wasn’t their own. In this scenario, the back-end becomes a collection of nuts and bolts and wires that need to be configured to fit each other, and application cohesion doesn’t even come into the picture.

One clear advantage of this specific type of infrastructure is that component reuse is assumed and doesn’t need to be mandated by the upper management or the architecture principles. Architects in this environment naturally look for the right component to plug into their design. This is not a small thing.

But there are also cons. It’s not all “blue sky and beautiful beaches”. The main problem is that this approach corrupts the very foundation of its business. A good indication was that the company had a solution architecture team, but they didn’t provide technical solutions to business problems; they provided integration patches based on existing technical solutions, and “business” was fine with that. Business people themselves didn’t think in terms of business anymore; they became the purveyors of technology, sometimes home-grown, sometimes third-party. The difference may be subtle, but it’s unmistakable; it reverses the iron-clad direction between business and technology, which is always one-way, where the business goes, technology follows. In this environment business eventually learns not to lead the technology but to follow it. That’s a cardinal sin which typically leads to the demise of the business itself.

Coincidentally, I worked at a major bank a few years ago and the problem there was the opposite, too many applications at the expense of back-end services. I analyzed the problem in detail here. And I was the one pushing to go easy on the applications and instead concentrate on the back-end services. Not surprisingly, business disagreed. They understood applications, not back-end services, they thought the more applications in their portfolio the better. Eventually, they came to understand that maintaining numerous applications was just too expensive and that services had a place in the portfolio.

Based on my own experience, I would have to say that, as is usually the case, it’s the balance that matters. Having primarily back-end services damages the business as it’s hard for them to sell technical services on business terms, it’s even harder to understand technical services in terms of business. But having too many applications is hard on the IT people in terms of maintenance and support, to say nothing of the development effort itself. It’s great for business as they can have a clean and deep understanding of the application functionality without having to worry about it’s internals and dependencies on services, libraries, versions, patches etc.

Having the right balance between services and applications requires an exquisite balancing act, which cannot be thaught or enumerated; it’s an art more than it is science, and it comes primarily with experience.