I work on a huge project for a client and the data model contains 1200+ subjects. Every branch we make works on other subjects, for example a Project branch works on Project related subjects and the CRM branch works on the CRM subjects. These branches currently both have the same subjects (1200+) and this makes the branch (data model) pretty big.
What would be great to have is that we could define a Module; or a part of the data model specific for that branch. Probably the CRM module doesn't need all 1200+ subjects but only needs around 300 or so. If that Module would only have in it those 300 subjects needed to develop the CRM, then it would save a lot of space, time and most importantly synchronization time (syncing to IAM).
What do you think about this Community? Would love to hear more about this.
In R&D at Thinkwise we have another solution for this 'issue’. Since the introduction of temporal tables in SQL Server, it is possible to time travel in data. This means you can see the state of your data at a certain point in time.
We can use this feature to get rid of project versions and only store changes in your project. Every project version contains a complete model, which is very resource consuming, especially with 1200+ tables.
In the solution we think of creating some kind of version table with the next fields:
- Version
- Point in time
So when your product is to be released you can add a record in this table. When you want to access an older project version, you will have a task to select one of these versions. The software factory will access the history tables to present the data as it was on the point of time of this version.
When you create a branch, the model is still copied entirely. But versions also work as explained above.
Is the idea clear and will it contribute to the solution of your issue?
The idea is only an idea and not (yet) part of the road map.
Hey Frank,
This can certainly benefit my cause immensely. I spoke to you yesterday about it and we came to the conclusion that this idea indeed could be exchanged with your solution and using temporal tables. Only the initial synchronization phase will be a long one and then every synchronization after will be very light since it only needs to sync the changes; that's perfect.
I hope to see the change from project versions to project changes!
Kind regards,
Mark Jongeling
Hi Mark,
I have not worked with a huge Thinkwise project yet, but am already thinking about modularization. Having a module would be great, but am wandering whether this would be the same as having multiple projects that communicate with each other through Indicium.
How would you see a difference between splitting the huge project into smaller sub-projects and the introduction of modules?
Kind regards,
Roy van Uffelen
Hi Roy,
Personally I don't know how it's possible to combine (sub-)projects through Indicium but I would like to see the result. For making modules, I do think it would be a nice addition but also a bit risky. But I think because we have the model, we can separate chunks and deem them separate from other chunks.
For splitting a big project into smaller pieces, yes it's possible but we do need to make sure that the different pieces do not share any references unless it's meant to be like that.
I do think if we can let multiple projects communicate through Indicium that it would kind of be the same as having modules like I proposed. The main difference is that I intent to use Modules for development and not for Production. In production the full software model should be available, but for development, I only intent to work on a part of it, hence I would like a module/sub-project.
Hopes this answers your question Roy!,
Kind regards,
Mark Jongeling
In the 2023.1 version of the Software Factory the way projects/project versions are managed has significantly changed, which makes this wish obsolete.