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.
Typical IT development organization in traditional Financial Institutions
In a Spotify-style organization, and following the principles of micro-services architectures, teams are structured around business capabilities and not technical capabilities, each team including all required business and technical skills for this purpose. This minimizes dependencies between teams, so that developing, maintaining, and evolving applications is more efficient, and allows for Agile and Dev Ops practices that are unsuccessful with traditional application structures and organizations. Changing the organization and processes without changing an application architecture that mirrors said organization is very complex.
Spotify Organization (source: Spotify)
The transformation of legacy systems to an application architecture based on a BIAN-style domain model can be the mechanism that allows moving to Spotify-style organizations. BIAN is an organization that groups together Financial Institutions with software and services providers, for the creation of a banking industry standard. One of the components of the BIAN standard, the Service Landscape structures business capabilities into elementary, but collectively comprehensive components, called service domains. Each domain of services are the building-blocks of the application architecture and each of them is implemented as independent components that communicate only through APIs and Events. Service Domains are grouped into Business Domain and these into Business Areas.
Structure of BIAN Service Landscape (bian.org)
A Service Domain provides business capabilities and serves a single business purpose. The organization that matches an application architecture based on Service domains will have teams responsible for each service domain and said team will have all the necessary technical skills.
This fits enormously well with the typical organization we are looking for: there will be squads responsible for each of the service domains, tribes responsible for all the service domains in a business domains and charters to generate the necessary competencies and skills in the squads. As tribes are responsible for a Business Domains, every squad in the tribe will share a business language, SMEs, business owners and IT managers
Perfect fit of BIAN based Application architecture and Spotify-style organization
Given that many of the Institutions that want to adopt this Spotify-style organizational model are, in addition, planning or executing transformation programs to modernize and take their core systems to cloud platforms, they have a great opportunity to achieve the objectives as long as they design their target architectures based on BIAN domain models.
