Background: My bosses want to merge two application that have two separate purposes.

  • One being for monitoring of equipment and bandwidth for our internal network operations.

  • The other is an application to view similar data just less granular and with less detail. This second application has to also perform tasks such as generating tokens or creating a splash page that is meant for the client to use but is generally used by the customer representatives in the company. It also is used by external clients of properties.

Does it make sense to merge the two applications? Why or why not. I can understand there is an inherent security flaw with introducing this type of architecture. But is it worth the time to merge these two even if I have to re-code some of it in order to merge the code bases? Also many of the queries and back-end calls are different. They are currently completely separate and stand alone applications. I did explain this to my boss and explained that we will be using the same database, he still wants to merge the code bases. I am also asked to create the whole design.

  • 2
    I am a fan of the Unix philosophy of Do One Thing and Do It Well – user22815 Oct 19 '15 at 20:30
  • 2
    Please define "merge" - does that mean merging two frontends into one, making functions of one application also available for the users of the other application? Or is the task just to reduce the amount of duplicate code, without making changes to the two frontends? For the latter, a shared library would be obviously the better choice. – Doc Brown Oct 20 '15 at 6:21

I see two distinct questions here:

  1. Does the combined functionality make sense?
  2. Does the work of converting the two applications to one pass a cost/benefit analysis?

The first question should be purely user-driven. Does it make sense for users to have these two sets of functions together? Is it likely that some of them want to see a less granular view, and then switch to the more detailed view? And so on.

The second question has to do with the actual development work involved. It could be a huge amount of work with little benefit. Or it could even save work overall, if the combined application is simpler and more maintainable in the future. Development work to address security concerns should also be considered as part of this (it is unlikely that there are any insurmountable security issues, but it could be a lot of work to make the combined application secure).

We don't have the information to answer these two questions, but it would be helpful for you to consider them separately in deciding how to respond to your boss.

If you don't think the combined software meets #1, your response would be something like I am worried that this won't meet the needs of our users/customers, for these reasons:... It is not an objection about the amount of work, but that the end product is not a desirable goal.

If you see the benefit of combining the applications in the abstract, but think it is too much work, in my opinion the best response is not to say "we shouldn't do this" but try to present an estimate of how much effort the project will take. It is up to your boss to decide cost/benefit, ultimately, but you can provide information to help with this (and highlight the size of the task).

Also important is why your boss wants you to do this. If you don't know, you should try to find out more about the reasons. Maybe there is a good rationale that you aren't aware of. Or, maybe the reasons aren't very good, but it will help you have a more informed response.

  • I think this is correct. The reasoning was because it would be easier to maintain later. My issue with this is that it seems pointless to merge these two applications, they do have an intersect but are geared to different audiences. It is like merging a bathroom and a bedroom, because it makes things convenient and easier to maintain. But does it serve the same purpose? But they are the ones that are paying so I guess I will end up having to do it. – Kevin Oct 21 '15 at 12:50

My view is that this comes down to your definition of 'Application'

Lets say you have the following n-tier structure

  • Database A
  • Database B
  • Web Service A
  • Web Service B
  • Application C

Where A is your client facing stuff and B is the low level monitoring.

So we are separate at all the layers until we get to application C which merges services A and B to create a combined tool. I think this is fine and 'correct' design. We still have complete separation of concerns in terms of business logic but we present both to a user through a single Website or Application or whatever.

I notice you have tagged your question 'database design' this leads me to think that your structure might be more like

  • Database C
    • Tables A
    • Tables B
  • Application C

I think this does lead to a problem, as you will have no clear separation of the objects and business logic for the two sets of operations. The danger being these get muddled together and changes in one break, or expose security concerns in the other.

However, would a non-developer using the Application C, know the difference? or is it just an 'implementation detail'?

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.