How many apps should an internal development group be building/maintaining?

Question

I've always been of the opinion an internal development group should really only be building/maintaining three applications.

1. An internal composite/pluggable/extendable application.
2. The company website.
3. (Optional) A mobile version of #1 for field employees.

I'm a consultant, and everywhere I go, my clients have dozens of one-off applications in the web and on the desktop for every need no matter how related to the others. Someone comes to IT and says "I need this", and IT developers turn around and write another one-off ASP.NET application, or another WinForms app.

What's your opionion? Should I embrace the "as many apps as we want/need" movement? I assume it's common; but is it sensible?

EDIT: A colleague pointed out that it depends on the focus of the development - are you making apps or are you making a system? I guess to me, internal development is about making a system; development of shippable software products, like MS Word, iTunes, and Photoshop, is about making apps.

Answer 1

This question depends on so many things and is subjective besides. I've worked at companies that have needed several different apps because we do business in discreet silos. In that case, an internal group may not build and maintain apps, but may build several, with another group that is responsible for maintenance.

Also, what do you mean by "app"? If you broaden the term enough, then you could say "it's all just one big app".

In short, I think the main consideration is the capacity of the group and what business needs are.

Answer 2

All of them?

Answer 3

Wow do I ever agree with you. The problem is that many one-off applications will (at some point) each have many one-off maintenance requests. Anything from business rule updates to requests for new reports. At some point the ratio of apps that need to be maintained to available development staff is going to be stretched/taxed.

From my perhaps (limited?) vantage point, I'm starting to think #1 and #3 could be boiled down to Sharepoint. Most one-off applications where I work (a large 500+ attorney law firm) consist of one or more of the following:

1. A wiki
2. A blog
3. Some sort of list (or lists joined together in some type of relationship), which can be sorted and arranged in different ways.
4. A report (either a Sharepoint data view or a SQL Server Report work just fine)
5. Or, the user just wants to "make a web page" and add content to it. But only they should be able to edit it. Except when they're out of the office, and then, etc...

Try to build any one of the above using [name your technology], and you've got lots of maintenance cycles to look forward to (versus a relatively minor Sharepoint change).

If I could restate what I think is your point: why not put most of your dev cycles to work improving and maintaining a single application that can support most of your business' one-off needs, rather than cranking out an unending stream of smallish speciality apps?

Answer 4

I think there should be internal development teams that each has a system which may contain multiple applications within it. To take a few examples of what I mean by systems:

1. ERP - If you are a manufacturer of products, you may need a system to keep track of inventory, accounting of books and money, and other planning elements. There are a wide range of scales of such systems but I suspect in most cases there is some customization done and that is where a team is used and may end up just doing that over and over if the company is successful and a new system is needed to replace the previous one as these can take years to get fully up and running. The application for the shop floor is likely not the same one as what the CFO needs in order to write the quarterly earnings numbers to give two examples here.

2. CRM - How about tracking all customer interactions within an organization that can be useful for sales and marketing departments? Again, there are many different solutions and generally there is customizations done which is another team. The sales team may have one view of the data but if there is a support arm to the company they may want different data about a customer to help them.

3. CMS - Now, here I can see your three applications making sense, but note what else there is beyond simple content.

I don't think I'd want to work where everything is a home grown solution and there is no outside code used at all. Lots of code out there can be used in rather good ways such as tools but also components like DB servers or development IDEs.

Answer 5

So what's the alternative to several one-off applications? One super-huge application that runs everything and everything? That seems even worse to me...