Я тут подумал, что различные информационные системы в процессе своего развития обрастают кучей несвойственного им функционала. Особенно этим “грешат” те, которые развиваются достаточно давно. ну и системы платформенного типа (“большие фреймворки”). Ну действительно, есть в Roadmap у системы что-то … оно делается… система обрастает “фишками”. А потом - приходит очередной пользователь, просит сделать очередную фишку - которая, как оказывается, совсем не фишка. А очень даже фича. И в итоге, на выходе - мешается документооборот и управление, поручения и проекты, бухгалтерия и управление организацией…
Я не скажу, что это хорошо или плохо - это просто объективная реальность. Из которой следует, что
1) выбирая информационную систему (если вы заказчик) стоит посмотреть на то, а что она еще может хорошего? Вдруг “заодно” она закроет боль, которая тихо болела. Сэкономите на поддержке и ресурсах.
2) если вы разработчик ИС - то, по большому счету, следует помнить что “лишняя” смежная функциональность может оказаться совсем не лишней. А очень даже критической при выборе системы. (Не факт, но такие кейсы я встречал).
3) если вы разработчик ИС - то не стоит делать из нее кладбище фич. Делайте несколько направлений, но хорошо. Сделайте расширяемость через открытые протоколы - и к вам потянутся.
4) Спорный тезис, но все-таки. Иногда дешевле заказать доработку у вендора (для отечественных ИС), чем пытаться “допилить” самостоятельно / найти специфическую систему / сделать заказную разработку.
Банально, но об этой банальности часто забывают почему-то.

На Хабре очережная интересная статья: "Что нужно учесть при проектировании системы, чтобы не было мучительно больно?". Статья о том, как много боли можно получить впоследствии, изначально - неверно спроектировав приложение.

Вернее, как "неверно спроектировав". Понятное дело, что когда гипотетическое веб-приложение типа "сайт с некоторыми функциями" делается "для себя" / "для 100 - 1000 пользоваталей", то по большому счету - не очень важно, "синхрон-асинхрон", "прямые права" (не через роли) и т.д. Когда пользователей становится 100 000 - 1 000 000 и выше, эти проблемы начинают "выстреливать", причем - в самый неожиданный момент. Да, кстати, это не только для веба - это в принципе, для многопользовательских приложений. У всех свои "пороги срабатываения проблемы", но то, что проблема "выстрелит" на больших объемах, если её оставить - 100%. Безальтернативно.

Понятное дело, что поначалу никто не планирует "выход на объем", но вот что точно нужно делать в самом начале - как следует проработать архитектуру приложения, с тем, чтобы впоследствии было проще "расшивать" узкие места. Автор статьи, кстати, делает совершенно аналогичные выводы. Не касаясь явно, правда, еще одного момента - а именно объема данных. Косвенно о них говорится в разделе "Масштабирование", но явно - нет. А это, вообще говоря, может быть той еще головной болью. Когда, например, хранилище данных достигает 10000 Тб, и нужно обеспечить быстрый доступ ... или, как вариант, необходимо хранить таблицу в пару-тройку десятков миллионов строк... еще раз скажу, что редко когда на старте думаешь о том, что так будет. Но бывает, и еще как! В одном случае - логирование действий пользователей с ростом их числа съедает всё место, в другом - начинают в систему "заводить" не предназначенный для этого "тяжелый" контент (видео и т.д.). И получается на выходе - тормоза, отказы, 503я ошибка или просто "висим намертво".

Так что мораль: если вы только начали проектировать приложение - думайте о росте. Если приложение уже есть, но в нем еще нет ни пользователей, ни данных - думайте о росте. Потому что если не думать, то "рост" заставит вспомнить о нем сам. И будет существенно больнее.