The difference between creating a new app and updating an existing one

A team I am working with agreed to 'leverage and extend' an existing application rather than write a new one.  They spec'ed a new one.  (see prior posts).  Now, believe it or not, the question has come up: what's the difference?  They reused the database.   They added a long list of new pages.  It all runs in the same portal.  Is it reuse to use the same auth/auth structure and the same shared database (used by a dozen different apps)?

Easy answer: if you are leveraging and extending an application, then you are investing in it.  Both your team and the existing users of the app should benefit.  Here's the criteria:

1. Your rollout process will remove the existing app from production.  If it does not, you have added a new app.
2. The new features you have added to the system can be used by existing users without additional development costs on their part.  (In other words, they may have to change their process slightly to use a new feature that you have added, but in doing so, they don't have to come back and modify the code.  OK to modify the config.)
3. Any 'shared features' that you added, that are along the lines of features that existing users wanted, will meet the needs of existing users or can be extended to meet their needs without breaking your use of the feature... In other words, the app gives you none of the feature you need, and you develop part of the feature, and someone else needs more of the feature, it is OK to let them develop the rest... but in doing so, your part needs to be part of the overall feature.  This may require the program managers to do some negotiating. 

It really doesn't matter if you access a database at all.  As applications in all industries move closer to SOA, there won't be a database under most of these apps anyway.

Comments

• Anonymous
  July 06, 2006
  >
  It really doesn't matter if you access a database at all.  As applications in all industries move closer to SOA, there won't be a database under most of these apps anyway.
  >
  
  Didn't get it. From my point of view databases are the foundation of most if not all of todays fancy SOA stuff. The initial question (What's the difference between creating a new app and updating an existing one?) from a data centric perspective: There is none. 'Applications' come and go, no matter if you have a new or an updated one - you have to take care of the data: keep quality, keep accessability, migrate them etc. etc.
• Anonymous
  July 08, 2006
  thank you for making my point for me.
  
  Applications come and go.  The data remains.  However, it costs a lot to replace an app on an existing database.  That cost is the problem.  It is a cost of time, money, and lost business opportunities.
  
  We have to detach applications from the database in a manner that allows them to be replaced quickly and without requiring a massive investment in regression testing of every other connected app.
  
  SOA is designed to answer this problem.  A SOBA is an application in the SOA architecture.  It does not attach to a database at all.  It attaches to a business service.  The business service attaches to a database, often through a data service.
  
  The application I am writing about is a SOBA in many respects.  While it doesn't leverage existing business services... because there aren't any existing business services to leverage... it does behave as an independent application on top of a shared database.  The design is a Pre-SOA attempt to solve the same problems that SOA addresses.  
  
  However, the existence of a shared database does not mean that all the apps that share it are one app.  That is simply silly.