|
2 | 2 |
|
3 | 3 | The lab situation starts with the basic, fundamental questions. Why do I want a LDT and to which guardrails and principles should the LDT adhere?
|
4 | 4 |
|
| 5 | +### How do we make sure that the LDT system we envision is a fit for the organisation? |
| 6 | + |
| 7 | +Even though we start in a lab situation, we know already that the envisioned solution should fit into the broader context of the organisation and the ecosystem the organisation is operating in. So before we even start exploring we should get an overview of the prerequisites and requirements from the organisation. |
| 8 | + |
| 9 | +__Best practices__ |
| 10 | + |
| 11 | +A good way to make sure the technical system is fit for purpose is to work from use cases. What is a manageable, concrete challenge the organisation is facing and how could a LDT provide a solution for it? |
| 12 | + |
| 13 | +__Lessons learned__ |
| 14 | + |
| 15 | +While in 'brainstorming mode' it is very likely the envisioned solution is ever growing in scope. This seems great in theory, in practice an increasing scope can also grow a project to such a scope that it becomes unmanageable. Keep trying to find the balance between a valuable solution for the organisation while keeping it small enough to stay concrete and manageable. |
| 16 | + |
| 17 | +### How do we create insights that are interpretable and well balanced? |
| 18 | + |
| 19 | +Make sure ethics and fair data practices are adopted within the systems. All too often an ethics framework is implemented like a 'paper excercise'. Understand challenges from an Ethics and FAIR viewpoint and implement them in technical systems can really add value. For example you could implement a workflow for an Ethics review. |
| 20 | + |
| 21 | +__Best practices__ |
| 22 | + |
| 23 | +- Documentation and clear definitions are key. Design systems in such a way that provenance is available and results are transparant. Be wary of 'black box' solutions where you do not have a clue how results are calculated. |
| 24 | + |
| 25 | +### How can we create results in the short term, while staying relevant towards the future? |
| 26 | + |
| 27 | +Local, as well as regional government organisations have to deal with a lot of interconnected challenges. All too often a solution proposed for a particular challenge keeps increasing in scope until the proposed solution is too big to address, leading to 'apathy'. Be aware of this pattern and make sure to manage expectations. Work towards a bigger goal but do try to keep increments small and relevant. |
| 28 | + |
| 29 | +__Best practices__ |
| 30 | + |
| 31 | +- Work with the best that is available today (affordable, reliable, scalable & resilient). |
| 32 | + A business scope of a project is not the only scope to manage, from a technical point of view it is also tempting to wait for the next new feature or implement promising, but not proven technology too early. Be aware of this challenge and manage this risk explicitly. |
| 33 | + |
| 34 | +__Lessons learned__ |
| 35 | + |
| 36 | +- Pay attention to agile development practices, deliverables should add value. But also take 'technical debt' into account. Be aware that system components need maintenance as well and reserve development time for a solid foundation. |
| 37 | + |
5 | 38 |
|
6 | 39 | ### How do we avoid lock-ins?
|
7 | 40 |
|
@@ -54,25 +87,5 @@ __Lessons Learned__
|
54 | 87 | - Modern architectures operate on a web-scale and can work in a distributed environment, technologies like WebAssembly and memory optimized architectures make scaling systems a lot more feasible.
|
55 | 88 |
|
56 | 89 |
|
57 |
| -### How do we create insights that are interpretable and well balanced? |
58 |
| - |
59 |
| -Make sure ethics and fair data practices are adopted within the systems. All too often an ethics framework is implemented like a 'paper excercise'. Understand challenges from an Ethics and FAIR viewpoint and implement them in technical systems can really add value. For example you could implement a workflow for an Ethics review. |
60 |
| - |
61 |
| -__Best practices__ |
62 |
| - |
63 |
| -- Documentation and clear definitions are key. Design systems in such a way that provenance is available and results are transparant. Be wary of 'black box' solutions where you do not have a clue how results are calculated. |
64 |
| - |
65 |
| -### How can we create results in the short term, while staying relevant towards the future? |
66 |
| - |
67 |
| -Local, as well as regional government organisations have to deal with a lot of interconnected challenges. All too often a solution proposed for a particular challenge keeps increasing in scope until the proposed solution is too big to address, leading to 'apathy'. Be aware of this pattern and make sure to manage expectations. Work towards a bigger goal but do try to keep increments small and relevant. |
68 |
| - |
69 |
| -__Best practices__ |
70 |
| - |
71 |
| -- Work with the best that is available today (affordable, reliable, scalable & resilient). |
72 |
| - A business scope of a project is not the only scope to manage, from a technical point of view it is also tempting to wait for the next new feature or implement promising, but not proven technology too early. Be aware of this challenge and manage this risk explicitly. |
73 |
| - |
74 |
| -__Lessons learned__ |
75 |
| - |
76 |
| -- Pay attention to agile development practices, deliverables should add value. But also take 'technical debt' into account. Be aware that system components need maintenance as well and reserve development time for a solid foundation. |
77 | 90 |
|
78 | 91 | ---
|
0 commit comments