Интеграция новых приложений в корпоративный ИТ-ландшафт

Большинство методологий разработки  программного обеспечения предполагают создание программного продукта с нуля. Они сформировались в те времена, когда требовалось автоматизировать операции заказчика, осуществляемые до этого вручную. Пользователи работали с бумажными документами, информацию хранили в локальных файлах и обменивались ими по электронной почте. Разработчик документировал требования, описывал бизнес-процессы, реализовывал и внедрял решение.

Сегодня ситуация изменилась принципиально. За истекшие 10-15 лет организации закупили, разработали и внедрили множество информационных систем, сформировали огромные хранилища данных, выстроили бизнес-процессы. Речь о внедрении новой информационной системы теперь заходит не в тот момент, когда требуется что-либо автоматизировать, а в тех случаях, когда существующие бизнес-приложения уже не способны удовлетворить заказчика. Уместна аналогия с градостроительством. Свободного места для постройки новых микрорайонов практически не осталось. Возможна только точечная застройка, т.е. возведение новых домов в сложившейся городской инфраструктуре, на месте сносимых пятиэтажек.

Перед разработчиками таких ИТ-решений неминуемо встают вопросы:

  • Что мы будем делать с существующими данными и функционалом, реализованным в унаследованных приложениях?
  • Как интегрировать новый продукт с источниками основных данных, содержащими информацию о клиентах, партнерах, продуктах и сотрудниках организации?
  • Как вписать процессы сопровождения и развития нашей системы в простроенные у заказчика процессы управления информационными системами, процессы внесения изменений, поддержки пользователей?
  • Что может повысить ценность нашего приложения для заказчика и что превратит один проект в первый шаг долгосрочного сотрудничества с этим клиентом?
  • Как сделать наше приложение ключевым элементом ИТ-инфраструктуры заказчика?

С другой стороны, не смотря на финансовые потрясения последних лет, темп развития технологий не снижается. Рядом с реляционными базами данных занимают важное место базы данных NoSQL. Распространение социальных сетей приводит к появлению требований по созданию принципиально новых способов взаимодействия сотрудников внутри организаций.  Бизнес-приложения становятся похожими на социальную сеть, позволяющую пользователям коллегиально обсуждать требования и «на лету» перестраивать свои бизнес-процессы. Разработчики вынуждены выносить клиентские приложения на завоевывающие популярность мобильные устройства. Часть корпоративных данных собирается переехать в «облако».

Как сделать программный продукт, отвечающий всем этим требованиям?

На одной из предстоящих конференций я планирую сделать доклад  о том, как адаптировать методологии разработки ПО к современным задачам. Стоит ли осветить еще какие-либо вопросы?

Реклама

7 Comments

    1. Забыл написать, что менять системы нужно только тогда, когда исчерпаны все возможности их починить. И даже в этом случае, ряд проблем можно решить посредством интеграции унаследованных приложений с новыми легковесными решениями.

      Если же идея внедрения новой системы принадлежит какому-либо вице-президенту, то пусть он и мучается с персоналом

      С инженерами — хуже. Я думаю, что изобретя proprietary software, ИТ-шники не только заработали кучу денег некоторым отдельным личностям, но и испортили себе карму. По сути, эти инженеры старых систем ведут себя как поставщики закрытого ПО и ничего с ними не сделаешь. А всем остальным теперь приходится чистить карму такими упражнениями, как парное программирование, непрерывная интеграция, совместное владение кодом и т.п. =)

      Ответить

      1. Не соглашусь с вами в части негативного отношения к proprietary software. По сути карту: не делайте своих разработок, а покупайте тиражируемое ПО, разыгрывается вендорами этого самого тиражируемого ПО. Но на деле они умалчивают о том, что кастомизация этого самого ПО выполняется такой разработкой кода, что в дальнейшем нет никакой разницы между ПО собственной разработки и кастомизированным ПО. Его одинаково сложно поддерживать и зависимость от разработчика высока.

        Ответить

  1. А как вы относитесь к идее «лоскутной» автоматизации. Т.е. когда автоматизируются отдельные процессы или даже активности в рамках процессов, а не вся деятельность компании.
    По идее, в современном сообществе культивируется негативное отношение к такому подходу. дескать нечего зоопарк разводить, надо взять одну огромную систему и как всё автоматизировать интегрированно.
    Но я вот часто размышляю на тему экономической эффективности ИТ (это надо признать моя любимая тема), и получается, что экономический эффект от лоскутной автоматизации очевидней (тут можно говорить о конкретных изменениях свойств информации, а не о каких-то абстракных выгодах). А тут ещё мне в руки попался Голдратт со своими идеями об узком звене. И по его идеологии получается, что автоматизировать надо там, где эта автоматизация закроет узкое звено в процессе, а вся остальная автоматизация, если она не связана с устранением узкого звена, пустая трата ресурсов.

    Ответить

    1. Какие-то соображения я писал в заметке про «точечную застройку» http://wp.me/pRljZ-8b Ну, а вообще, при принятии таких решений, мало ведь кто обращается к здравому смыслу. Продажа больших систем — это такой бизнес, кстати, довольно прибыльный 🙂

      Ответить

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s