Share
On my first day as Xebia employee I immediately got involved in a very interesting project for a customer in the financial sector. In hindsight it had almost all ingredients to be a spot-on case for our New IT paradigm. Our audit of the IT department quickly brought to light a perfect storm of ‘impediments’ this organization faced: a depricated technology stack, a silo-based waterfall culture dominated by manual hand-offs, bureaucratic process steps and ivory tower behavior, an average release cycle of multiple months, customers walking away, investors being reluctant to keep investing in the company, and on top of it, an anxious workforce with low morale and only a few experts remaining who are willing and able to reverse a downward trend.
To complicate things, this customer also acquired the help of a strategy consulting firm that was busy revising the business strategy, operating model, and product/market combinations. On the day we started with our audit, the strategy consultants were finalizing the slidedeck that was going to be presented to the board of directors. In it, an inevitable recommendation was being made: “start investing in an agile transformation” asap. By forming a number of full-blown agile teams doing Scrum, in a number of effective iterations (sprints), a renovation roadmap could be implemented and this company could be made successful again: customers would buy licences for the revised product, existing customers would stay, and significant cost reductions would be possible after the house has been cleaned.
“I hate to break it to you, but that’s not how it works” was more or less my message to the CIO.
The weeks that followed were spent mostly on backing this claim with as much evidence as we could find, and by working out alternative scenarios. It took us quite some effort to explain why going agile was not only a too simplistic solution to the status quo, but also a dangerous step to take now. After all, we had found out after a few days of interviewing people and looking at source code and documentation that the technology stack basically was one cluttered monolith that would make Foote and Yoder’s big ball of mud look like a toy example. Creating agile teams and expecting them to refactor parts of this spagetthi ball independently from one another is simply wrong. At least two additional investments were warranted:
- A new functional and technical architecture needed to be created, in order to define services/features that represent or can generate some business value
- A continuous delivery capability needed to be implemented to allow teams to test, deploy and release new versions of their software independently and much more frequently (daily instead of monthly)
The architecture of this organization's IT landscape was, unfortunately, a big elephant in the room of the CIO and the rest of the management team. The renovation roadmap presented to the board of directors did include a significant budget for coaching agile teams for approximately half a year to create the envisioned agile firm, but little to no budget was allocated to overhauling the complex technical landscape that was going to be the showstopper of this whole project. As Xebia, we, of course, refused to just send a few of our agile coaches and offered a scenario in which coaching with test automation, designing a microservices architecture, and the creation of a continuous delivery pipeline were core ingredients. The jury is still out on our alternative proposal. Time will tell what possibilities exist for this organization to battle the enormous heaps of technical debt that have been accrued over the past years.
For me, this story also symbolizes the importance “Architecture” still plays in many of our customers’ key battles to turn into leaner and meaner companies. And this is interesting, because our clients seem to have either forgotten a bit about this discipline, or have become a bit fed up by the promises architects did not deliver over the past years. Architecture is not as sexy as DevOps or continuous delivery is, and CIOs are much more eager to invest in agile transformations than in something that reminds them of SOA. But the truth is that in many companies we haven’t learned all that much over the past ten years when it comes to creating sound IT architecture landscapes. And this is going to cost these organizations dearly in times where IT is supposed to become faster, more flexible, and more reliable than ever. So please let’s stop turning big balls of mud into elephants in the room and start cutting away some of the complexity and legacy jungles we encounter.