by Alfredo Muñoz
IT Architect, IBM Global Center of Competency for Banking and Financial Markets
In his latest article here on Medium, Kyle Gene Brown explained how he has the principle to put in writing the answers to questions he got asked three times, because it the topic is of interest to three people he met, it would probably be of interest to the industry. This is one of these cases and, well, I am following his advice.
After a very interesting project in one of my clients, where I have designed the target domains model for a transformation from traditional core systems to hybrid multi-cloud, and where the reference model used was BIAN, “Banking Industry Architectural Network” (bian.org) I received several questions from my colleagues in relation to how the domain model was used to re-design the IT organization that would support such a model, and how such a model could resemble Spotify’s famous tribes and squads model.
There are many traditional Financial Institutions that have plans and aspirations to change the organization of IT teams, together with their design and development practices, in order to establish Agile and Dev Ops-style practices, and gain in efficiency and the always desired improved Time-To-Market. Generally the model in which they are looked at is that of Spotify, with its tribes, squads, guilds, etc.
However, the results to date are not very promising despite the heavy investments made. One of the main reasons, in my opinion, is that the structure of software applications follows the same structure as the organizational model and therefore, in order to change this model, it is necessary to align the way in which the software is structured.
Almost any application development and maintenance department in Financial Institutions is historically structured by technological platforms. We can find teams responsible for channel applications, teams for applications on Mainframe, for applications on distributed platforms (generally java application servers), for informational systems, which include DWH, Data-Lakes, reporting systems, etc. Other teams have been added in recent years, such as process teams (development of processes on BPM platforms), integration teams (development of APIs on API gateways or previously services on the ESB) or Big Data teams. If we consider any business domain, we will find applications with data and business logic of the domain distributed into the different technical platforms, applications that are maintained by different teams, reporting to different managers. This makes the maintenance and evolution of the systems inefficient, costly and time consuming because it requires the involvement of several teams, generating dependencies and conflicting priorities.