Correct way to develop a large application

Question

We are developing a very large web application in .Net 3.5. Two separate vendors are involved having expertise in different areas. Both the vendors are located remotely and working on separate functional area of the same web application. I was wondering what is the best way to handle the development of UI.

The UI have a master structure where left side and top side have navigation links. Clicking on a link opens a page in the main area. The individual pages will be developed by each vendor. The whole master can be developed by one vendor. In the master layout I use iframes to show the individual page in main area.

I deploy the master app on a pool of IIS-Master, vendor A app on a pool of IIS-A and vendor B app on a pool of IIS-B. The pool of IIS to do the load balancing as the number of users are high.

Also this web application is access based, i.e., user need to login to access the pages. I understand I need to implement single sign-on as well here as different sites are involved.

Is this a good idea? Is there any alternative?

---

EDIT AFTER REPLIES

I also have the same apprehension as mentioned in your replies. But the solution I have in mind is not only because two vendors are involved. The two vendors are involved because two separate functional areas are there and both areas have its own user load so it helps in load balancing properly as well. I was thinking of completely creating two sites with single sign-on implemented. But the issue is maintenance of the common part of UI. Common library is easy as can be developed by one vendor and distribute the DLL to other vendor. How can we do this for UI layer?

Answer 1

Working with distributed teams can be difficult -- especially on larger applications. In fact, sometimes we unnecessarily change our architecture simply because we think it will make the development life cycle easier.

I personally believe that software fundamentals like version control, continuous integration, code reviews and open communication scales very well. I suggest thinking of this project as a SINGLE application which happens to be coded by multiple development teams. Make someone(s) responsible for code integration, ensure that all teams are on the same page and don't change your architecture to suit your team dynamics.

The question you have to ask is: are you really better off unnecessarily maintaining multiple sites and a single signon system OR are you merely suggesting this approach because you think isolating the vendors and keeping them focused on their core area(s) of the application is the right approach?

Answer 2

My first impression on what you wrote is that it might be worth re-considering the architecture.

With iframes you are going to run into lots of issues, the first is the behavior of browser back button.

A possible alternative might be to use remoting or web services between the master application and A and B and handle the entire user interface in one place. It might be very difficult to coordinate development of a consistent UI with two different vendors.

Answer 3

Why can't both development party's work on the same UI project, as long as they are sharing the same instance of a source control branch. When the masterpages are developed, they can both build client pages against the master template without bugging the other party?