My company is considering consolidating all their tier-1 (i.e. top end production) applications and sites into one all-encompassing code base.

The theory is that their permissions, design and overall functionality can be homogenised and centrally managed.

I have no end of concerns about this approach since the data structures underpinning each application are very different, the business rules are complex and unique to each application and the overall code bases for the existing applications are extremely disparate and very neglected.


The current environment consists of three ASP.Net 1.1 sites that have barely seen any real love since first being written (due chiefly to an absence of experienced developers in the company) and one MVC2 application that was also an ASP.Net 1.1 site before being upgraded last year. We write exclusively in C#.

The company is a fairly small one, with about 50 staff; three of whom are actual developers. Management (even IT management) do not have any IT background or experience other than project management of IT projects (and therefore some passing knowledge of terminology and business impacts).

The applications are chiefly online services to support the products sold by the company. The company doesn't sell any software directly.

So to phrase this whole situation in a reasonably specific and answerable question: What are some compelling reasons for and against trying to pull all your systems together into one over-arching solution given the current conditions (i.e. old code base, complex business systems and rules)?

  • 4
    The question as presented here is extremely open-ended and overly broad. If you can narrow it down then it might make a better question.
    – ChrisF
    May 9, 2011 at 11:10
  • @ChrisF - I'll try. Could you suggest what sort of specifics you'd prefer to see? May 9, 2011 at 11:24
  • @Phil You're the OP, what are you looking for? May 9, 2011 at 12:09
  • @Phil You way want to give some specifics on the language as well because there are many tools that externalise the management of applications (e.g. security, logging, configuration, db connection etc)
    – Gary Rowe
    May 9, 2011 at 12:21
  • 1
    that way they can neglect one big ball of mud instead of 3 - 4 smaller balls of mud, much more efficient that way!
    – user7519
    May 10, 2011 at 1:07

8 Answers 8


Bad idea

This reaction is based on the following assumptions:

  1. There are a lot of fairly disparate applications being homogenised
  2. There are many teams working on the different applications
  3. There is no well-respected and authoritative software architect actively managing the applications

What will happen if you go ahead

Most likely there will be an inital consolidated effort to bring everything together under a single design approach. This will show up the huge effort required to make everything work the same and may get canned as being unworkable.

If it presses on then some kind of centralised repository containing configuration data (e.g. security access, logging levels etc) will be required at which point someone will point out the obvious and say

"Hey, why don't we just retrofit this externalised configuration approach to the old applications, it'll be much quicker?"

and a moment later someone else will pipe up with

"And, since we're refactoring anyway, why don't we just apply a design standard for each of the application domains - web processing looks like this, business rule processing like this and database access like, er this."

until finally

"Oh, and there's a lot of common code here why not put together some easily shared libraries. We'll probably need some kind of integration build run at regular intervals, say, every night."

At which point everyone breathes a sigh of relief that an enormous monolith was not constructed.

  • (+1) just for (1), the rest of the description is also valid...
    – umlcat
    May 9, 2011 at 20:43

We have been working on this at my company. I think it is possible and there are obvious benefits (you mentioned them), however, this will probably be a 5 to 7 year project at an absolute minimum, and requires basically everything to be rewritten. If you can get sign off on something like that, then I would say go for it. If not, then get ready for a nightmarish death march.


Google does it, so it certainly is possible.

That link BTW is an interesting presentation from a Googler about how they manage their code base, continuous integration, testing etc.

Without a similarly strong commitment to tooling, however, like Google has done, you are likely in for a world of hurt.

The key question here is why? Why does senior management want to do this? What savings, leverage or other advantage do they hope to gain?

If you can address enough of those issues such that you accomplish their goals, you may well avoid the single code base that concerns you, while still giving them the same effective result.

  • Thanks for that link. The video surprised me by being very interesting. (Although, that site needs to make it more obvious the video is sync'ed with the slideshow below. I almost left frustrated about not seeing the slideshow.)
    – Amy B
    May 9, 2011 at 16:24
  • InfoQ does get some pretty good presentations up there; they are a top site in my RSS list.
    – sdg
    May 9, 2011 at 17:17

We've been going through a similar process. We had a product that's been around a while. Last year we introduced another product that is 95% the same as the first one, with 5% of sometimes subtle but significant differences, with those differences to be developed and maintained by a separate team.

When we first started work on the new product, the old team kept making changes that adversely impacted us in that 5%, because they didn't understand the new product. So we completely forked that 5% of code, which enabled us to finish the first release on time.

Then more maintenance work kicked in, and we found we were frequently making nearly identical changes in nearly identical code. The old team also has a much better understanding of the new product now, so we are gradually reintegrating what we forked, and finding more efficient architectural ways to express the differences.

So when you say data structures are different and overall code bases are disparate, the question that I would ask is if they have to be that way or that's just how they evolved due to the expediency of the moment. Obviously you have to account for differing business rules and requirements, but the key is to isolate those differences into as small a module as possible. If you often find yourself implementing the exact same feature for multiple customers in slightly different ways for different code bases, then consolidation can really help, and I suspect that's the case or management probably wouldn't be proposing this.

  • Some good points. The code is the way it is due largely to evolution and not necessarily through necessity or best practice. However, management's understanding of the actual technical environment is next to nil: they honestly do not know how programnming and software works. They have no visibility into the differences in code so their decisions are not based on what is architecturally best for the company. May 9, 2011 at 23:58

You will most likely not be able to consolidate numerous applications into the same code base because that will take quite some effort and for old, neglected programs this might be much more work than initially expected.

That said, there is nothing wrong in having all your applications in the same code repository, where each application has it separate area. This allow you to e.g. have any online documentation generated for the whole code base in a single, consistent view which is generally a good thing as you want as much visibility as you can get.

Those who decide this, should strongly consider WHY they want to do it, and consider how much work they want to spend getting there.


If there is one single thing that makes enterprise development so inefficient and expensive it is the illusion that it is possible to make a single system that does everything. If you had a single product owner who understands all details of the system and can make all decisions without needing a week of meetings it might work, but I've never seen that happen.

In general you will be better off if you treat it more like developing for the internet - just build your own app, admitting that in practice you have zero control of anything outside your own code. You can get pretty much all the consistency you are likely to want with OAuth and a simple API for user settings and a bit of shared CSS.

This is quite similar to the original intent of SOA, but if you call it that you'll just end up with a different type of large, barely working system that tries to do everything.


My first thinking is that this would be a total PITA for releases.

Splitting into manageable chunks of functionality is much more sensible, if only to avoid all the layers of management and approval.

Breaking out common stuff into components/services and standardizing that way would be much easier IMHO.


You can approach this differently, using an integration technology such as Deliverance to theme all of your web applications similarly. Basically, each application is still separate; Deliverance uses XSLT rules to shoehorn their output into a static HTML template that you design. This allows a relatively simple static HTML/CSS theme to be applied to an entire suite of applications with a minimum of woe.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.