Applications Architecture - fewer big systems vs more smaller systems

Question

re: Applications Architecture, that is, "the science and art of ensuring the suite of applications being used by an organization to create the composite application is scalable, reliable, available and manageable."

When looking at a range of applications in an organisation, I can see various reasons for merging apps together, but sometimes also good reasons for keeping them separate.

In general, what are the pros and cons of having fewer big systems versus more smaller systems (bearing in mind that many of the systems will exchange information).

I'm thinking things like: fewer, bigger apps means less plumbing between apps, but more smaller apps means more flexibility for individual departments.

Is there any literature on this, or has anyone got a list of pros and cons that they've discovered?

edit: In my scenario, a lot of the apps might be customisable off-the-shelf ones rather than in-house developed, but feel free to consider more general scenarios.

Answer 1

Just off the top of my head

Smaller Systems

• Pro - Scale up on commodity hardware, or cheaper virtualized environments.
• Pro - Can implement on demand scaling in a Cloud.
• Pro - Fewer intra-system dependencies, ie. 1 service per server.
• Pro - HA/DR (High Availability/Disaster Recovery) is typically easier to implement
• Con - Has to be horizontally scalable
• Con - The more systems, the more interconnects the more complicated management is

Larger Systems

• Pro - Fewer interconnects which usually mean it's less complicated
• Pro - Responds faster to high peak usage if it's within the tolerance.
• Pro - Fewer resources to manage
• Pro - More efficient resource usage (assuming relatively constant usage)
• Con - More complicated intra-system dependencies, ie. N services per server
• Con - HA/DR is typically harder/more complicated

Answer 2

In a larger system, it is much easier to:

• Share features and code. You will reinvent the wheel a little less. For example, if you have ten applications which must have an access to the database, you have to specify the connection string in all of them, i.e. ten times. Or you have to create a separate library and reference it ten times again.

• Consolidate workflows, including the deployment process.

• Manage the system: less applications to manage is generally easier.

• Unify the user experience. When an employee has to deal with ten different applications, he may easily be lost: what application to run to do A? In what application is available the option B? But don't overunify. No one will appreciate Word, PowerPoint, Outlook, Publisher, Visio, Project and Groove as a single monolithic application.

In a bunch of small systems, on the other hand, you'll find that:

• You can abandon a whole system if you don't need it any longer. Or start from scratch if the codebase becomes unusable over time. This is of course only true if other systems do not rely on this one, or if the interface is light enough to be easily rewritten in a new version.

• You can form a team of fresh developers and expect from them to understand the existent codebase in less time. If it's a part of a large project, chances are they will require more time, unless the overall large codebase is done extremely professionally and refactored very well (I haven't seen such codebases in my life).

• The system administrators will be able to relocate the applications easier. The larger system, on the other hand, either scale well on multiple servers, or not.

• The developers can migrate the codebase to new standards easier. Migrating a large codebase is always scaring. Instead, when you have to deal with a small codebase, then another, then another, and so on, it becomes less scary.

This being said, such comparisons work only in general cases, but your decision must be taken not from pools, but from your company assets. How is it organized? Are there many small developer teams or a few large ones? Are there strict guidelines about coding style and similar things?

It also depends on the application itself. For example, it would be absurd to ship all Microsoft Office applications as a single app. But it would also hurt productivity to, for example, separate Adobe Photoshop in an application for drawing and another one for photos retouching. IMO, the decision to unify or separate a product must be a business decision, not a purely technical one.

Finally, I also want to answer to the second comment of the original question:

I'm kindof assuming that linking data within an app is less effort than linking data between apps

It is not always true. If you're dealing for example with .NET, it is not unusual to ship a single application where different components are exchanging through WCF. In this case, this is comparable to a set of separate applications communicating through WCF.

Of course, when you have to deal with multiple applications, you have to establish some way for them to communicate, whereas having a single monolithic application does not force you to do that. But would you really be able to write a large monolithic application?

Answer 3

Read this. It's the "many small programs" philosophy of Unix. Linux uses it, also. The immense endurance of this philosophy (from the late 1960's to today) suggests that it's the right thing to do.

http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond

http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy

http://159.93.17.14/usoft/WWW/LJ/Articles/unixtenets.html

http://www.linuxjournal.com/article/2877