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...
Large Agile Projects
A common question is whether large projects can be done with agile techniques. After all many agile approaches are designed for smaller projects and the heavyweight ideas that they resist are more needed on bigger projects.
One of the main reasons that this is a question is because we don't know yet. New techniques tend to be tried on smaller projects first. Only when they work on a smaller scale do people try them on a larger scale, and even then it takes time to ramp up. With any technique or technology I wouldn't recommend using it on anything larger than twice the size of something you've used it successfully already.
Despite this much of what goes with agility has a background in larger systems, depending on what you call large. For software projects I think the primary measure of large is number of people. The people there are, the more the communication issues rise. XP's sweet spot is up to twenty team members. FDD looks to be more, more in the mid tens. Talking to Phillipe Kruchten, the lead designer of RUP, RUP at its essence is very much an agile approach and Phillipe has primarily worked with projects of over 200 people.
Scaling Agile methods is the last thing you should do
I used this phrase recently at the Canadian Agile Network. I meant it literally. I'm not saying that you shouldn't do large projects, I'm saying that trying to scale agile techniques up to big projects, while often necessary, shouldn't be your first choice.
A better approach is to try to scale down your project. At that workshop an unscientific straw poll revealed that most projects could lose about half the people of the project without making things go slower. Time and time again I hear of success occurring when a team is cut significantly in size. Large teams carry a big overhead in communication and management. Using smaller teams staffed with more able people is usually faster and cheaper, even if the everyone is more individually expensive.
Yorumlar
Yorum Gönder