Недавно я был на мероприятии Oracle Communication и заразился там одной простой но, на мой взгляд, достаточно важной идеей. Один из докладчиков сказал примерно следующее
В вашей организации, наверняка, есть множество программ, направленных на лучшее понимание потребностей клиента (customer experience), оптимизацию затрат и инновации. Ваша задача состоит в том, чтоб втолковать вашему заказчику, что не следует рассматривать эти инициативы отдельно друг от друга. Потому что проблема, встающая на пути всех этих инициатив, одна и та же и называется она complexity. Неоптимальная организация данных, запутанность бизнес-процессов, множество разрозненных плохо синтегрированных приложений не позволят продвинуться в решении ни одной из сформулированных выше задач.
Безусловно, это утверждение является верным не только для телекоммуникаций. Большинство организаций идут по пути разделения операционной деятельности и развития. Ну а взаимодействие с клиентом это вообще отдельная автономная область в корпоративном ландшафте. Идея очень простая и потому доступная для понимания даже самому высшему руководству. Если информация о клиентах и услугах и связанные с нею бизнес-процессы размазаны по нескольким приложениями, то мы не сумеем реализовать на них простую, понятную клиенту услугу. Каждый элемент системы внесет в реализацию те или иные особенности. Кстати, делать мы это будем долго, т.к. реализация новой услуги потребует согласованного изменения в большом количестве информационных систем, длительных циклов интеграционного тестирования и продолжительного периода опытной эксплуатации пока не исправим все баги. И стоить разработка и поддержка такого продукта будет дорого.
Задачей перехода от complexity к simplicity, по большому счету, кроме архитекторов никто не занимается. Да и те не могут внятно сформулировать, как они это делают или собираются делать. Простые решения, такие как консолидация приложений и хранилищ данных не дают ожидаемого результата. В лучшем случае поверх существующих приложений появляется еще одно, призванное спрятать complexity, а в худшем – система просто перестает работать. Сложные решения вызывают большое недоверие: все и так слишком запутано. Порой кажется, что реально для преодоления complexity в основном используется детский подход решения пространственной головоломки, типа кубика Рубика: крутите её и почаще разглядывайте с разных сторон.
Update: В детстве я однажды научился собирать кубик Рубика и почему-то очень сильно этим гордился. Но один раз моё самолюбие серьезно пострадало. Однажды в какой-то поездке житель одной из южных республик попросил меня собрать его кубик Рубика и это у меня не получилось. И так его крутил и сяк, но не получается и все тут. Кубики в то время делали из пластика и наклеивали на них цветные квадратики. Часть цветных наклеек была просто переклеена. Так например, один из угловых кубиков имел две желтые грани
Для строительной отрасли это еще более актуально, так как на эта отрасли настолько сильно отстает по внедрению интеграционных ИТ решений. Особенно сильно это проявлется в России, так как строители считают, что работать можно только с «колес».
На мой взгляд, здесь напрашивается решение, аналогичное с задачей формирования управленческой отчетности в распределенном и диверсифицированном холдинге, когда есть множество разнородных бухгалтерских и финансовых систем, имеющих различные режимы закрытия.
В идеале нужно вводить единые стандарты учета, но это радикальная перестройка процессов, поэтому почему бы как первый шаг не внедрить аналитическую базу консолидированной отчетности?
И это достаточно безболезненное и вполне работоспособное решение.
Правда, если есть закрытые системы, связанные интерфейсами машина-человек-машина, это, конечно, критическое препятствие. Следовательно, первой целью технической стратегии должно быть полное исключение закрытых систем из корпоративного ландшафта…
И еще одна страшилка на тему сложности The Last Remaining Method Of Simplification
«Простые решения, такие как консолидация приложений и хранилищ данных не дают ожидаемого результата.» — почему-то пропустил этот тезис при чтении поста, расписав похвалу консолидаци в своем предыдущем комментарии 🙂
Но, размышляя на эту тему, пришел к тому же выводу: действительно, путем консолидации можно получить базу для анализа свершившихся фактов, а если стоит задача использования полных данных онлайн, в оперативной деятельности, то этот путь тупиковый.
Действительно, как страшно жить… Пару лет назад я пришел к выводу, что типичный жизненный цикл больших систем заканчивается состоянием, которое можно назвать термином «облако функций». Вопрос, как не допустить такой деградации пока для меня остается открытым…
Консолидация данных дело хорошее. Особенно, если источники данных не подвержены частым изменениям. Но это не упрощает ИТ-ландшафт, не увеличивает скорость внесения изменений и не сокращает затраты на унаследованные приложения.