Overview

In large enterprises in the BFSI space, there are some common issues we see surfacing both on the business and tech side. We often see issues with ways of working resulting in bloated timeframes, lack of alignment, lack of communication and collaboration, poor prioritization etc. Projects never seem to finish on time and within budget. On the tech side, there are issues with reliability, quality, fragile dependencies, frequent breakages, slow release cycles etc.

A lot of these have to do with the ways of working and how work is managed and run. However, a significant contributor is also how the digital services and technology stack is architected and organised. We all know Conway’s Law:

Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.

Over the course of a multitude of engagements at Greyamp, we’ve observed that this does play out. Organizations’ digital services and platforms tend to reflect organizational ways and structures, and the two can form a feedback loop that exacerbates the problems observed. This is the introductory post in a blog series that dives into the inherent problems and how to design a model that could alleviate a lot of these issues. We will look at integrating the principles from Team Topologies, Domain Driven Design, Composable Architectures and other techniques and practices into a cohesive approach that could work for large organizations.

‍

Project and Product Mindset

A fundamental disconnect that sometimes drives large BFSI enterprises is from their understanding of the role of Digital or Tech or IT in their organization. It is an engine of growth and success for the organization, and not merely a cost-centre. The domain offerings like “Digital Banking” or “Digital Insurance” are the products of the organization, and their tech platforms should be aligned to the domain capabilities and built like products. The customer journeys and workflows should consume capabilities from this domain aligned digital product layer.

However companies tend to structure their work around projects with narrow focus, and cutting across vertical subdomains. There are certain patterns and problems we have observed with companies adopting this approach:

• Focus on Output over Outcome
• Success when within time, scope and budget
• Scope fixed to meet Project plan
• Isolated team for Project lifecycle, unrelated to lifecycle of what is built

Organizations could, instead, consider a product model, where the focus is on delivering continuous value to customers and iterating on a product over its lifecycle. Success is measured by the product's adoption, user satisfaction, and long-term viability in the market. On the tech platform front, the focus should be on the product’s extensibility, reusability, reliability, and quality when building products. These patterns would emerge:

• Focus on Outcome
• Success measured against value delivered
• Scope flexible to meet Product/Platform needs
• Dedicated team for Product/Platform lifecycle

‍

Domain, team structures, and projects

If we consider a simplified domain based services model of an enterprise BFSI organization, it would normally be along these lines:

Customer Facing Products

These are the digital products the end customer consumes from the organization. For example, in a bank or NBF, this would be products like personal loans, savings accounts etc. Each of these would have a set of user journeys and workflows within them.

Primary Domain Services

These are the main services offered by the various subdomains in the organization. The subdomains for a bank could be something like Account Management, Customer Management, Payments and Transfers etc. All of these subdomains serve a set of capabilities.

Capabilities across domains are consumed by the customer facing journeys.

Secondary Services

These are services and capabilities that in turn serve the primary domain services, enabling them to serve the customer workflows.

However, we often see that work is often planned and managed along these lines:

‍

So we end up with team structures along these lines:

‍

This leads to a host of problems and inefficiencies.

• Work and teams organized only on the basis of Initiatives based on user journeys, with no domain aligned teams
• No domain ownership as a product or platform
• Development teams have less domain understanding and do not build services thinking of the domain from first principles
• There is potential for duplication and divergence of implementations because of the lack of a domain and capabilities based backlog

‍

Future Posts: Moving to a Product and Domain oriented model

In future blog posts, we will explore these facets in detail, and talk through how we can move to a model where teams and work being done aligns well with the domain, and we unlock speed, reliability and relevance for the organization.

We will explore facets of Domain Driven Design, Domain Aligned Architecture, Team Topologies, Platform Architecture, Platform-as-a-Product and other topics as we bring together an organizational structure and tech architecture that would give organizations a way out of a lot of the problems they currently encounter. Stay tuned for part 2 in this series.

‍