Design Meeting
Overview
The goal of design meeting is to figure out design details about particular functionality of a software, particular solution, or even a methodology or process. It is usually applied to midPoint design. But it may be also useful for non-technical and organizational aspects.
Design meeting is a creative, free-form discussion. It may be following an agenda, but it is usually closer to a free-form brainstorming.
Schedule
Design meetings are schedules as needed, the schedule is not fixed. For midPoint, the design meeting usually happens at the beginning of a development cycle or milestone cycle.
What To Discuss
Motivation and Requirements
What is the motivation to discuss this topic at all? Do customers need it? What are the use cases? Will it help make deployments better/faster? How exactly?
What are the problems that we are trying to solve?
What will happen if we just do nothing? Do we really need this? It is worth the effort?
Should we do this now? Maybe we can postpone it, there may be better opportunity in the future.
What are the assumptions? What we expect that customers will do? Maybe we are not certain about some requirements and we just assume something?
Do we have some performance or scalability targets? Do we know how big a system do we want to support? How many users, how many requests per second, special usage patterns (bursts), anything else?
Ideas and Concepts
When thinking about the use cases, do not limit your thoughts to just that one specific use case. Think about generic mechanisms, broader principles. Focus on concepts and ideas, rather than algorithms. Design mechanism that can handle your use case, and thousands of similar use cases as well. Design generic re-usable mechanisms.
Make sure the new mechanisms work well with existing mechanisms. We are looking for synergies. We want to combine mechanisms together into more flexible and more powerful solutions.
Implementation
Discuss how to implement the functionality. Keep the discussion on relatively high level. Delve deep into details only when necessary, usually for critical or risky parts of the problem.
The goal of the implementation discussions is to assess feasibility. We want to know whether we can implement what was designed. We would also want to get some idea how difficult is to implement it. How long will it take? Do we need special skills or knowledge? Are there any hidden risks?
Performance and Scalability Considerations
Discuss how may the functionality affect performance and scalability.
How will the functionality affect performance? Will midPoint be faster or slower? Are there any expensive operations that we need to do for every request? Will we need more database operations to complete the task? Are there any complex computations?
How will the functionality affect scalability? Will if work even with huge amount of data? Will it work if we have many users, roles, resources, tasks? Is each request demanding on memory, are we at risk to run out of memory?
Testability Considerations
Make sure the functionality can be tested. Think about the testing process.
Can this be tested by the usual mechanisms that we have? Will we need some special environment or setup? Will you need special performance or load testing? Do you expect some special security tests?
Can the testing be automated? Do you need to create any special interfaces to allow efficient testing? Will the testing need to create any non-trivial mocks?
Security Considerations
Does the design have any impact on security? Can the functionality be secured by using the usual authentication/authorization mechanisms that we already have? Will we need to extend those mechanisms? Is there any need to record or audit the operations due to security reasons? Are we working with sensitive data that need special protection? Are we handling personal data properly? Do we maintain appropriate privacy?
Are there any obvious security vulnerabilities? Do you need to expose unsecured services? How could users abuse the functionality?
Rolling Wave Design
We design our systems as a rolling wave:
-
We create detailed designs for the things that we are about to implement. Discuss the details of functionality that you are going to implement in current iteration, next weeks or months. You can go as deep into the details as needed. Create schema, design algorithms, do whatever you need to do.
-
We create rough designs for things that we expect in near future. Discuss the rough ideas of functionality that is likely to follow in next few development iterations, next 1-2 years. Do not go too deep here. Think just about the important aspect of the problem. Do not concern yourself with implementation details. Do not create schemas, maybe just put in some comments how the schema may evolve in the future. Do not dive deep into algorithms. Maybe just update the architectural documentation, write design notes, update plans. Do not implement anything.
-
Create a vision for the things that may come in the far future. Discuss how the functionality can be evolved, how it can be extended or improved in the long run. Think about years that may come, even decades. Feel free to speculate, to play with ideas, to foresee how users will react, what will they need. Do not go into any details here. Work with the ideas.
The closer the thing is, the more detailed it should be. Things that are Further ahead could be rough and incomplete. The things that are far in the future may be very fuzzy and abstract. However, make sure you dedicate some time to think about the future.
Revisit the topic next time when there is a suitable opportunity, ideally at the start of next development iteration. Take important things from rough design and work out the details. Take probable parts from the vision, and work on rough design. Think about new possibilities that may come in the future, add them to the vision. Gradually add details to your design, expand it, shape it.
Write It Down
Notes from design meeting at the appropriate place. For midPoint, the appropriate place is usually Design Notes at docs.
Do not forget to document:
-
Requirements and assumptions. Interesting use cases.
-
Outline of the approach, important aspects of algorithms, schemas and so on.
-
Decisions that were made, also the explanation or motivation why the decision was made.
-
Outline of a plan. What do we implement now? What parts will remain to be implemented later?
-
Risks and challenges. What parts are likely to be problematic? Where can the design fail?
-
Open questions. What we cannot answer now? What problems remain to be solved later?
-
Long-term vision. What do we expect in the future? How can the functionality evolve? What are probable development paths?