Platform-first has become such a common business-tech phrase that HBR (Harvard Business Review) has coined a term for this phenomena; “‘platformania’...a land grab, where companies feel they have to be the first mover to secure a new territory, exploit network effects, and raise barriers to entry.” But, the excitement is not without reason. Seven of the world’s 10 largest global companies are underpinned by some of the most evolved technology platforms we’ve seen.
Infact, the Indian government has been treading this path with the trinity of JAM (Jan Dhan accounts), the Aadhaar ID system and mobile technology. India’s digital backbone, another moniker for this trinity, is fueling rapid digital transformation across the country and fostering a competitive innovation agenda that both the public and private sector can partake in.
We’ve put together the five anti-patterns that organisations should avoid when they go down the inevitable platform journey.
However, one side effect is each team tends to also create their own build and deploy pipelines along with monitoring infrastructure. Also, multiple teams end up solving similar problems in multiple different ways using several tools.
Our recommendation is to develop a technology platform that provides build, deploy and monitoring capabilities for the feature development teams. This requires standardization of the technology stack but relieves multiple teams from building the same deployment pipelines and monitoring stack.
Building a self service platform also reduces friction between the feature development team and the platform development team. This approach requires moving beyond the project-as-the-primary-mechanism for funding, staffing and delivery of technology. Additionally, self-service infrastructure lowers costs, removes silos, and increases productivity. It enables the effective use of technology investments, shortens release cycles and hikes employee satisfaction.
Our counsel is to design and manage enterprise platforms by architecting them to be modular and evolutionary, at the same time. This allows continual changes to both business capabilities and the technologies that power them.
Also, utility components, that are not strategic to the business, need not be custom-built but can be bought. For such components, ‘buy and integrate’ is a credible strategy to retain control over future evolution. It helps to align with the long term tech roadmap and evolving future-perfect capabilities when needed.
Our guidance is to, “be open to the possibility of moving beyond the monolithic and centralized data lakes to an intentionally distributed data mesh architecture; Embrace the reality of ever present, ubiquitous and distributed nature of data.” The shift, “requires a new set of governing principles accompanied with a new language:
We’ve witnessed enterprises not applying Domain-Driven Design (DDD) principles leading to the lack of well-defined bounded contexts and service boundaries. This causes any change to spread across multiple services, increasing coordination and alignment efforts amongst multiple teams.
Identifying bounded contexts leads to cohesive services, designed around business boundaries. Teams aligned to bounded contexts speak a ubiquitous language, ensuring complete alignment between business and tech teams. Understanding business context helps effectively drive the long term roadmap for the domain.
For instance, India’s Aadhaar platform allows three forms of biometric authentication; thumbs, fingers and iris scan. The biometric device’s captures come from third parties who follow the Unique Identification Authority of India’s (UIDAI) prescribed method for device integration. Here, UIDAI’s core team is not building the biometric system themselves, as it’s not their core capability. It’s being built by partners within the ecosystem. When the platform is modular, like in this instance, such integration and collaboration is uninterrupted.
These applications can extend to other sectors like retail where the shopping experience is augmented via text, voice or video based channels like WhatsApp, Twitter, SMS etc. in addition to conventional web based channels.
This article was first published on TechCircle.
Infact, the Indian government has been treading this path with the trinity of JAM (Jan Dhan accounts), the Aadhaar ID system and mobile technology. India’s digital backbone, another moniker for this trinity, is fueling rapid digital transformation across the country and fostering a competitive innovation agenda that both the public and private sector can partake in.
We’ve put together the five anti-patterns that organisations should avoid when they go down the inevitable platform journey.
Anti-pattern 1: Reinventing the wheel prevents scaling i.e. local optimization
We’re firm advocates of autonomous teams, where each cross-functional team has the freedom and flexibility to build software suited to their specific needs. This encourages both a deep understanding of business problems and a high level of ownership to see them through.However, one side effect is each team tends to also create their own build and deploy pipelines along with monitoring infrastructure. Also, multiple teams end up solving similar problems in multiple different ways using several tools.
Our recommendation is to develop a technology platform that provides build, deploy and monitoring capabilities for the feature development teams. This requires standardization of the technology stack but relieves multiple teams from building the same deployment pipelines and monitoring stack.
Building a self service platform also reduces friction between the feature development team and the platform development team. This approach requires moving beyond the project-as-the-primary-mechanism for funding, staffing and delivery of technology. Additionally, self-service infrastructure lowers costs, removes silos, and increases productivity. It enables the effective use of technology investments, shortens release cycles and hikes employee satisfaction.
Anti-pattern 2: Near-sighted platform capabilities are not future ready
A significant hurdle when building platforms is the traditional enterprise’s mindset to evaluate a platform on it’s current requirements, and not on how it will evolve to meet the business’ needs in the near and far future.Our counsel is to design and manage enterprise platforms by architecting them to be modular and evolutionary, at the same time. This allows continual changes to both business capabilities and the technologies that power them.
Also, utility components, that are not strategic to the business, need not be custom-built but can be bought. For such components, ‘buy and integrate’ is a credible strategy to retain control over future evolution. It helps to align with the long term tech roadmap and evolving future-perfect capabilities when needed.
Anti-pattern 3: Monolithic data architectures don’t meet innovation and scale requirements
An article by Zhamak Dhegani, principal technology consultant at Thoughtworks says it best with these words, “Data platforms based on the data lake architecture have common failure modes that lead to unfulfilled promises at scale. To address these failure modes we need to shift from the paradigm of a centralized data lake or its predecessor data warehouse. We need to shift to a paradigm that draws from modern distributed architecture: considering domains as the first-class concern, applying platform thinking to create self-serve data infrastructure, and treating data as a product.”Our guidance is to, “be open to the possibility of moving beyond the monolithic and centralized data lakes to an intentionally distributed data mesh architecture; Embrace the reality of ever present, ubiquitous and distributed nature of data.” The shift, “requires a new set of governing principles accompanied with a new language:
- Serving over ingesting
- Discovering and using over extracting and loading
- Publishing events as streams over flowing data around via centralized pipelines
- Ecosystem of data products over centralized data platform
Anti-pattern 4: Fuzzy service boundaries increased coupling and misaligned teams
An organisation cannot build a distributed platform armed with the mindset of building monoliths. When designed well, a distributed system ushers in the benefits to incrementally release and scale independent parts.We’ve witnessed enterprises not applying Domain-Driven Design (DDD) principles leading to the lack of well-defined bounded contexts and service boundaries. This causes any change to spread across multiple services, increasing coordination and alignment efforts amongst multiple teams.
Identifying bounded contexts leads to cohesive services, designed around business boundaries. Teams aligned to bounded contexts speak a ubiquitous language, ensuring complete alignment between business and tech teams. Understanding business context helps effectively drive the long term roadmap for the domain.
Anti-pattern 5: Being closed to the ecosystem inhibits speed and quality of innovation
A traditional approach followed by enterprises is to own (build or buy) any capability offered to their clients. It’s important to nurture an ecosystem view of business, where we leverage others’ capabilities as well as expose our own capability to others. This helps the enterprise sustain innovation. The platform should orchestrate ecosystem-wide capability integrations that will result in accelerated time to market, with market leading solutions.For instance, India’s Aadhaar platform allows three forms of biometric authentication; thumbs, fingers and iris scan. The biometric device’s captures come from third parties who follow the Unique Identification Authority of India’s (UIDAI) prescribed method for device integration. Here, UIDAI’s core team is not building the biometric system themselves, as it’s not their core capability. It’s being built by partners within the ecosystem. When the platform is modular, like in this instance, such integration and collaboration is uninterrupted.
These applications can extend to other sectors like retail where the shopping experience is augmented via text, voice or video based channels like WhatsApp, Twitter, SMS etc. in addition to conventional web based channels.
This article was first published on TechCircle.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
