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...
Shifting To Code Ownership
In my recent CodeOwnership post, I described the way in which I think about code ownership issues. Many of my software development friends are extreme programmers, and tend to favor collective code ownership. However these kind of practices aren't absolute and should always be tempered by local considerations. One of my colleagues sent me a note with the following story which I thought was a good indication of when you have to vary your practices, even if you are a strong fan of XP. (As he's talking about his team, he prefers to be anonymous.)
I shifted our team from the "collective" to "weak" model, in order to counter some undisciplined programming by a couple of developers. Combined with some rather candid feedback, the result was a gain in velocity since the programmers who now "own" our key code areas are not constantly reworking sub-par code, while those that were doing sub-par work in those critcal areas are instead doing things like bug hunting and low-risk code changes -- which further frees up the others.
We also had a net gain in morale, since everyone but the sub-par producers were getting frustrated by having to watch their every check-in for issues, and fixing the problems that they didn't catch in time. This change rewarded those who took quality, TDD, non-speculation, etc. seriously.
However, we also needed some additional practices and policies to counterbalance:
- More frequent pair switching (our actual policy is that you can still work on any part of the code, but if its in an area other than one where you have "free play", you need to pair with someone who does, or heavily vet your ideas through them first)
- The way back in is through the owners. If they feel comfortable that your code will be up to snuff, you can take tasks freely there again.
- If things don't improve, then we'll have to take further steps.
It's been very educational for me, because I never had to go this far before, and I was really reluctant to "play the heavy." It was really tough for me to introduce a directing instead of an enabling practice, but things have been much improved since.
This kind of local adaptation is an essential part of extreme programming, or any agile method. All things being equal my colleague still prefers collective code ownership, but all things are seldom equal.
Yorumlar
Yorum Gönder