How do you manage references (having 100+ applications)?


I'd really like to hear from people working on big projects how do you manage references, if anyone doesn't mind to share?

Under "big" I mean at least 100 applications / 200-300 modules in release package, even though I'm not sure if this is considered big.

In our project we have 130 applications and more the 300 modules, not counting tests, development tools and various temporary stuff. Refreshing references is a huge problem which gets worse with time. Solution publish takes 3 to 5 hours (depending on which part of the stack is included) and fails time to time due to various internal errors. I recall few years ago it took just about an hour, so I would push it during launch. We can't afford this any more, it can only be run in the night, and someone needs to push it manually, because automatic start is no longer available (which was very disappointing step from outsystems!). I have raised my concerns several times, but in response I am usually getting "it's your architecture is bad". I don't even want to discuss architecture here, because I am sure that dev ops and environment health should not depend on or be limited by architecture in any way. But the irony is in that we have been working on architecture improvements according to best practices (as we've been told, it will let us deploy much easier) during the last 2+ years and in the end it only became worse. Yes we are trying to minimize dependencies, but still there are some low level elements which are used in too many places, and changing something there needs full republish. And even if there are few consumers - refreshing them manually takes time and is not something people like to do. I was dreaming to have background refresher running constantly, but again there is no API for it to use. 

I'd like to highlight that I do think that OutSystems is great platform which really improves the ways how you can deliver, and after working with it for 7 years I don't want to change to anything else... But references is a HUGE problem which kills a lot of impression from it. And the saddest thing is that they don't want to improve it anyhow, instead they removed publish API which was there in the past. So basically I'd like to find out how others are dealing with it, and maybe this will give me some insights on what we can do.

Thanks in advance!


Imho it's not the dependencies that causes the issues, but more important apparently the structural changes in the "common/core components".

If these component are changing a lot, then those are not really core/common. They should be stable and very slow changing. There you must look and find a way to actually stabilize them in such a way, you do NOT have to change them for the upcoming months :)

Furthermore, it's always a balancing issue between the amount of Work In Progress, The Business Demands and the logical split-up of modules. There is absolutely NOTHING wrong with a monolith application, the same there is nothing wrong with splitting it up into tiny modular components.

It's really up to you, as an architect, what's the best way to build an app.

If you are always having userstories that will impact every module, perhaps the split is incorrectly done by splitting it up by entity instead of business domain.

For example, thinking out of the blue here.. but it might be feasible, to have a core-module which contains the data.

then for each application you will create a cache of the data via webservices.

this will you will break the monolith. of course, this only works if the data in the core-module is pretty "static" or changed every week etc.

Thanks J., but I'd like to highlight again that it's not the question of architecture. Yes we do have bad architecture (I suppose) and we already did the change in core module which is not supposed to be changed, imagine all those bad things already happened. Now how do we update our stack to get the changes applied, and not getting "invalid key" or "method not found" errors, and to let LifeTime agree to deploy all that... What is the best way?

I'm wondering what do people in other projects do in this situation. I don't believe that everybody are living in the perfect world, having perfect architecture and business never asking for any change which needs a low level change, and developers never doing wrong decisions which need low level change again. Or is it really only my project which has all this happening for some reason?

And also, having low code fast development platform, do everybody actually spend years on improving architecture just for the sake of not needing to do full stack republish?


it's a never win situation ;)

To put it simply, use the boy-scout rule

“Always leave the campground cleaner than you found it.” If you find a mess on the ground, you clean it up regardless of who might have made it. You intentionally improve the environment for the next group of campers. (Actually, the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was “Try and leave this world a little better than you found it.”)

What if we followed a similar rule in our code: “Always publish a module cleaner than when you opened it”? Regardless of who the original author was, what if we always made some effort, no matter how small, to improve the module? What would be the result?

I think if we all followed that simple rule, we would see the end of the relentless deterioration of our software systems. Instead, our systems would gradually get better and better as they evolved. We would also see teams caring for the system as a whole, rather than just individuals caring for their own small part.

I don’t think this rule is too much to ask. You don’t have to make every module perfect before you publish it. You simply have to make it a little bit better than when you opened it. Of course, this means that any code you add to a module must be clean. It also means that you clean up at least one other thing before you publish the module."

gonna poke a fellow-MVP, I know he manages a 1500+ factory I believe.

Yes, I like this rule and I am following it.


Hello Igor.
I know your pain. The publication of one small app causes a refresh of 60 modules at once. When we touch in a low-level module in quality, we need the full night to republish the environment. And going to production, Phase 1 starts at least 4 hours before Phase 2 so that we can be sure it ends on time.

Still, it is better than the opposite. I also worked at a factory that had only 3 modules (no typos here) and I spent months splitting it into 20 modules with fewer circular references so that we could deploy in less than one hour.

The only way out is to stop, sit, rethink and redesign. It is an Architecture issue, no matter how you see it.

Until then, as I see suggested above, use the "boy scout rule". Every time you touch anything, try to make it a little better.

Oh, great, at least now I know our project is not the only one. :D I was often wondering, cause it seems like we are the only one concerned about that.

One question to you if you don't mind - what was the problem with having 3 modules exactly? Because after having spent 2 years in multiplying modules and getting nothing but more problems in the end - I'm starting to think that monolithic is not that bad. At least in this environment, where managing dependencies is the major problem.


It was basically 1 for integration and core, 1 for screens, 1 for a new business that was launched. Anything I wanted to change, I had to republish the entire factory.

As soon as I broke it (in a good way) I could publish modules in 5 minutes instead of one hour.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.