Большинство методологий разработки программного обеспечения предполагают создание программного продукта с нуля. Они сформировались в те времена, когда требовалось автоматизировать операции заказчика, осуществляемые до этого вручную. Пользователи работали с бумажными документами, информацию хранили в локальных файлах и обменивались ими по электронной почте. Разработчик документировал требования, описывал бизнес-процессы, реализовывал и внедрял решение.
Сегодня ситуация изменилась принципиально. За истекшие 10-15 лет организации закупили, разработали и внедрили множество информационных систем, сформировали огромные хранилища данных, выстроили бизнес-процессы. Речь о внедрении новой информационной системы теперь заходит не в тот момент, когда требуется что-либо автоматизировать, а в тех случаях, когда существующие бизнес-приложения уже не способны удовлетворить заказчика. Уместна аналогия с градостроительством. Свободного места для постройки новых микрорайонов практически не осталось. Возможна только точечная застройка, т.е. возведение новых домов в сложившейся городской инфраструктуре, на месте сносимых пятиэтажек.
Перед разработчиками таких ИТ-решений неминуемо встают вопросы:
- Что мы будем делать с существующими данными и функционалом, реализованным в унаследованных приложениях?
- Как интегрировать новый продукт с источниками основных данных, содержащими информацию о клиентах, партнерах, продуктах и сотрудниках организации?
- Как вписать процессы сопровождения и развития нашей системы в простроенные у заказчика процессы управления информационными системами, процессы внесения изменений, поддержки пользователей?
- Что может повысить ценность нашего приложения для заказчика и что превратит один проект в первый шаг долгосрочного сотрудничества с этим клиентом?
- Как сделать наше приложение ключевым элементом ИТ-инфраструктуры заказчика?
С другой стороны, не смотря на финансовые потрясения последних лет, темп развития технологий не снижается. Рядом с реляционными базами данных занимают важное место базы данных NoSQL. Распространение социальных сетей приводит к появлению требований по созданию принципиально новых способов взаимодействия сотрудников внутри организаций. Бизнес-приложения становятся похожими на социальную сеть, позволяющую пользователям коллегиально обсуждать требования и «на лету» перестраивать свои бизнес-процессы. Разработчики вынуждены выносить клиентские приложения на завоевывающие популярность мобильные устройства. Часть корпоративных данных собирается переехать в «облако».
Как сделать программный продукт, отвечающий всем этим требованиям?
На одной из предстоящих конференций я планирую сделать доклад о том, как адаптировать методологии разработки ПО к современным задачам. Стоит ли осветить еще какие-либо вопросы?
Как преодолеть сопротивление пользоветелей и инженеров старых систем… 🙂
Забыл написать, что менять системы нужно только тогда, когда исчерпаны все возможности их починить. И даже в этом случае, ряд проблем можно решить посредством интеграции унаследованных приложений с новыми легковесными решениями.
Если же идея внедрения новой системы принадлежит какому-либо вице-президенту, то пусть он и мучается с персоналом
С инженерами — хуже. Я думаю, что изобретя proprietary software, ИТ-шники не только заработали кучу денег некоторым отдельным личностям, но и испортили себе карму. По сути, эти инженеры старых систем ведут себя как поставщики закрытого ПО и ничего с ними не сделаешь. А всем остальным теперь приходится чистить карму такими упражнениями, как парное программирование, непрерывная интеграция, совместное владение кодом и т.п. =)
Не соглашусь с вами в части негативного отношения к proprietary software. По сути карту: не делайте своих разработок, а покупайте тиражируемое ПО, разыгрывается вендорами этого самого тиражируемого ПО. Но на деле они умалчивают о том, что кастомизация этого самого ПО выполняется такой разработкой кода, что в дальнейшем нет никакой разницы между ПО собственной разработки и кастомизированным ПО. Его одинаково сложно поддерживать и зависимость от разработчика высока.
А как вы относитесь к идее «лоскутной» автоматизации. Т.е. когда автоматизируются отдельные процессы или даже активности в рамках процессов, а не вся деятельность компании.
По идее, в современном сообществе культивируется негативное отношение к такому подходу. дескать нечего зоопарк разводить, надо взять одну огромную систему и как всё автоматизировать интегрированно.
Но я вот часто размышляю на тему экономической эффективности ИТ (это надо признать моя любимая тема), и получается, что экономический эффект от лоскутной автоматизации очевидней (тут можно говорить о конкретных изменениях свойств информации, а не о каких-то абстракных выгодах). А тут ещё мне в руки попался Голдратт со своими идеями об узком звене. И по его идеологии получается, что автоматизировать надо там, где эта автоматизация закроет узкое звено в процессе, а вся остальная автоматизация, если она не связана с устранением узкого звена, пустая трата ресурсов.
Какие-то соображения я писал в заметке про «точечную застройку» http://wp.me/pRljZ-8b Ну, а вообще, при принятии таких решений, мало ведь кто обращается к здравому смыслу. Продажа больших систем — это такой бизнес, кстати, довольно прибыльный 🙂
Можем же мы, хоть в личном блоге отдать приоритет здравому смыслу над большим бизнеслм? 🙂
Да! Обязательно напишу и об этом. Я думаю, что у отрасли нет другого направления развития кроме движения в сторону здравого смысла