A recent trip to Istanbul got me thinking about enterprise IT architecture. Seriously! If you’ve ever been to Istanbul, you’ll know that it’s a fast-growing, vibrant, and dynamic city. Unfortunately, the roads can also be very congested at times, taking hours to get from one side of the megacity to the other.
The worst is when you’re stuck in a taxi without a safety belt, no AC, it’s the summer, and you’re trying to cross the Bosphorus (millions of people cross the grand total of two bridges across the two sides of the river every day). But it often seems like even when the traffic isn’t bad, journeys still seem quite long. Recently, when driving between meetings in a taxi, it took far longer than expected to travel only a couple of kilometres. I asked the driver why this was taking so long as it seemed like we were almost going round in circles.
He showed me that the roads were like “makarna” or, in English, spaghetti. I asked why the roads were such a mess in Istanbul, and he said that buildings were built quickly on aggressive timelines as Turkey grew over the last 20 years, without thinking about how people would travel between them. The roads grew up to connect the buildings, and therefore they don’t make much sense for driving. A10 minute walk can sometimes take over 20 minutes by car simply because of the way the roads are designed. Two words came to mind: design-first – putting the needs of the end user first, whether it’s developers, customers or in the case of roads, drivers.
When I have meetings with customers, their IT teams are under pressure to complete priority tasks quickly, buy new applications or technologies, and implement all these projects fast. Usually, IT focuses its resources on priority projects when deadlines are approaching and then they’ll focus on the next priority project when that deadline approaches.
The result is that IT teams use short-term solutions confined within the context of the project, looking no more than 6-12 months past the deployment or go-live times. Then, a lot of those assets they create and buy for the individual projects end up being duplicated multiple times, and the project-based methodology builds up complexity over time creating issues with their integrations, creating a brittle network prone to fail.
The CIO of a retail company gave me a good example recently. He had been at the same company for nearly 25 years and built his career in the company. He admitted they have a high error rate at their point of sale systems and as a consequence, the price of their products sometimes shows up incorrectly when a customer tried to pay. This means the cashier has to make changes manually, which can cause delays for customers and a bad shopping experience. It might cause customers not to return again. Even worse, the customer can pay the wrong amount.
They asked if MuleSoft could help them solve this problem. I asked if they had any ideas as to why this might be happening, to which they all looked at each other, sighed while shrugging their shoulders before looking at me and responding “we don’t know.” By the way, the room had all the IT leaders and architects responsible for the retail group’s IT systems and architecture.
This example shows how complexity accumulates to an extent where managing and monitoring their IT systems is virtually impossible because they took at project-based and myopic, technology view to solving their problems. Our suggestion was to adopt an API-led connectivity approach that packages underlying connectivity and orchestration services as easily discoverable and reusable building blocks, exposed by APIs.
The “makarna” problem continues as IT teams acquire new technologies such ESBs, SaaS applications, or an API management solution. Again, they’re using the same project-based approach to solving something that is a broader and a systemic issue. Errors, downtime, and network fragility can all result from this method.
Putting yourself in Istanbul’s urban development’s head for a minute, next time you’re expanding your infrastructure, to improve connectivity you could start by blaming the roads themselves and thinking about new bigger and better roads, bridges, roundabouts and junctions that everyone else is building. Or you could first start by taking a step back and recognising that there was something wrong with the old approach and changing it, so you don’t repeat the same mistake. Then you can start building a new approach which incorporates technology that takes into consideration the state of your existing road structure and the new infrastructure being built.
Which one would you go for?
If you liked this article remember to sign up for our blog newsletter on the top right corner of the page! Thanks for reading!
