Одна из ключевых проблем корпоративных/ведомственных бизнес-приложений состоит в том, что их функционал сложно детально прописать даже в среднесрочной перспективе. Ведь такое приложение автоматизирует некоторые процессы, которые склонны меняться под воздействием внешних и внутренних причин. Архитекторы приложения могут планировать функционал сколько угодно, однако в их планы постоянно будут вмешиваться неподвластные им причины.
В кризисный период многие компании изменяют одни процессы, отказываются от других и запускают третьи. Причем, изменения могут носить как стратегический, так и тактический характер. Например, банки стратегически отказываются от обслуживания клиентов в офисах, закрывают часть из них и переносят такое обслуживание в Интернет. Или розничные магазины электроники меняют формат магазинов, сокращая представленный в них ассортимент и превращая их в шоу-румы с возможностью заказать понравившиеся модели через Интернет. Даже большая часть госуслуг теперь оказывается через Интернет. Такое сокращение расходов требует радикальной перестройки существующих процессов в рамках существующих приложений и запуск новых.
Тактические изменения могут потребоваться ввиду изменения регулирования – обычно требования регуляторов меняются с довольно небольшим временем на приведение информационных систем в соответствие. Наверняка вам случалось откладывать все планы, чтобы броситься реализовывать требования, изложенные в очередном письме Федерального казначейства «О порядке исчисления…»?
Да и сам бизнес любит периодически диверсифицироваться или, наоборот, фокусироваться, покупая или продавая какие-то активы, процессы, которые обеспечиваются бизнес-приложениями. Государственные ведомства также подвержены постоянной реорганизации и передаче функций в зависимости от инициатив правительства.
Поэтому разработчики, обеспечивающие автоматизацию постоянно меняющихся процессов, не могут работать в классической парадигме разработки: версии, сервис-паки, функциональные патчи. Часто приходится делать несколько билдов в неделю, чтобы успевать за требованиями заказчика. Единственная выигрышная стратегия в таких условиях – разработать или взять готовое ядро, обеспечивающие базовые функции, а конкретный функционал дописывается на основе этого базового функционала с помощью встроенных скриптов или в виде дополнительных модулей. Выбор бизнес-платформ довольно разнообразен – зарубежные IBM Lotus Notes, MS Exchange, Oracle EBS, SAP R/3 и другие ERP- или DocFlow-платформы, а также российские 1C, БОСС, Диасофт и другие. Выбор стандартных модулей к этим платформам достаточно велик, но тем не менее компании продолжают нанимать разработчиков для того, чтобы писать заказные приложения – обходить конкурентов можно и с помощью правильно выстроенных процессов.
Применительно к безопасности такая ситуация означает, что классический подход «фиксация кода и следующее за этим исследование безопасности готового приложения», принятое в исследовательских лабораториях, «не сходится», как говорят математики: срок исследования безопасности конкретного билда больше, чем срок выхода следующего. То есть вы всегда будете иметь заключение о безопасности неактуальной уже позапрошлой версии.
Поэтому для «непрерывной» разработки необходим другой подход – безопасность, встроенная в разработку на основе предварительно построенной модели угроз.
