Data Mesh Principles and Logical Architecture The great divide of data What do we really mean by data? The answer depends on whom you ask. Today’s landscape is divided into operational data and analytical data . Operational data sits in databases behind business capabilities served with microservices, has a transactional nature, keeps the current state and serves the needs of the applications running the business. Analytical data is a temporal and aggregated view of the facts of the business over time, often modeled to provide retrospective or future-perspective insights; it trains the ML models or feeds the analytical reports. The current state of technology, architecture and organization design is reflective of the divergence of these two data planes - two levels of existence, integrated yet separate. This divergence has led to a fragile architecture. Continuously failing ETL (Extract, Transform, Load) jobs and ever growing complexity of labyrinth of data pipel...
Bimodal IT
Bimodal IT is the flawed notion that software systems should be divided into these two distinct categories for management and control.
- Front Office systems (systems of engagement) should be optimized for rapid feature development. These systems of engagement need to react rapidly to changing customer needs and business opportunities. Defects should be tolerated as the necessary cost for this rapid development cycle.
- Back Office systems (systems of record) should be optimized for reliability. As systems of record, it's important that you don't get defects that damage the enterprise. Consequently you slow down the rate of change.
The term Bimodal IT is used by Gartner [1]. McKinsey and Co talk about the same basic idea under the name "Two Speed IT". (I find it hard to resist calling it "Bipolar IT".)
When I first heard about this approach, I was pleased - thinking that these august organizations had come to same conclusion that I had with my UtilityVsStrategicDichotomy, but as I read further I realized that Bimodal IT was a different animal. And worse I think that Bimodal IT is really a path down the wrong direction.
My first problem is that the separation is based on software systems rather than business activity. If you want to rapidly cycle new ideas, you are going to need to modify the back office systems of record just as frequently as the front office systems of engagement. You can't come up with clever pricing plans without modifying the systems of record that support them.
My second issue is that the bimodal idea is founded on the TradableQualityHypothesis, the idea that quality is something you trade-off for speed. It's a common notion, but a false one. One of the striking things that we learned at ThoughtWorks when we started using agile approaches for rapid feature delivery is that we also saw a dramatic decline in production defects. It's not uncommon to see us go live with an order of magnitude fewer defects than is usual for our clients, even in their systems of record. The key point is that high quality (and low defects) are a crucial enabler for rapid cycle-time. By not paying attention to quality, people following a bimodal approach will actually end up slowing down their pace of innovation in their "systems of engagement".
So my advice here that it is wise to use different management approaches to different kinds of software projects, but don't make this distinction based on the bimodal approach. Instead take a BusinessCapabilityCentric approach, and look at whether your business capabilities are utility or strategic.
Further Reading
Sriram Narayan's book - Agile IT Organization Design
Jez Humble provides a worthwhile critique of Bimodal IT
Simon Wardley prefers a three-level model of Pioneers, Settlers, and Town Planners.
Notes
1: Sadly all their substantial material is available to subscribers only.
Yorumlar
Yorum Gönder