- -
- 100%
- +
Очевидно, что актуальность тенденции развития архитектуры, заключающейся в применении программного обеспечения с открытым исходным кодом при создании ИТ-решений, а также необходимость применения платформенного подхода для повышения эффективности создания продуктов неумолимо приводят к тому, что и в рамках продуктового подхода открытый код становится ключевой архитектурной тенденцией. Если открытый код позволяет повышать эффективность цифровизации, если современные платформы позволяют эффективно создавать продукты, то было бы непростительно отказываться от открытых решений – это привело бы к падению эффективности, застою и деградации. В конечном итоге организация, принявшая столь недальновидное решение, утратила бы собственную конкурентоспособность. Мы же говорим о необходимости не просто учитывать P&L, мы говорим о том, что P&L является основой продуктового подхода. А поэтому мы должны принимать во внимание необходимость использования открытых решений для поддержки позитивных тенденций в P&L.
Нельзя не отметить также тот факт, что активное использование решений с открытым исходным кодом меняет психологию организации, формирует совершенно иной mindset. В конечном итоге это приводит и к опережающему достижению истинно продуктового мышления, на нехватку которого мы уже сетовали по ходу настоящего изложения.
Современные организации делают ставку на развитие дистанционных каналов обслуживания: данный подход позволяет кратно снизить издержки, обеспечить массовость привлечения клиентов, быстро отрабатывать ключевые рыночные тенденции и сигналы рынка, учитывать конкурирующие предложения и многое другое. Исходя из этого, продукты изначально планируются, проектируются и создаются с учетом их доступности в дистанционных каналах, число которых может варьироваться, а нагрузка оказывается непредсказуемой. В этой ситуации современные ИТ-решения, предоставляемые клиентам в формате продуктов, должны поддерживать концепцию распределенного исполнения, в противном случае такие продукты не будут востребованы рынком: продукт, не следующий рыночным тенденциям, не выдерживающий колебаний нагрузки, не представленный в актуальных дистанционных каналах, не может считаться конкурентоспособным. Можем ли мы представить себе, чтобы на рынке были популярны продукты финансовой организации, если они не представлены, например, в мобильном банке? Таким образом, современные ИТ-решения должны поддерживать режим распределенного исполнения, соответственно, и современный цифровой продукт априори является распределенным.
В предыдущих книгах распределенность рассматривалась нами в двух смысловых плоскостях: технологической и организационной. Выше была представлена необходимость для современного продукта поддерживать технологическую распределенность. Но распределенность организационная является не менее важной в продуктовом подходе, нежели технологическая. Современные продукты являются исключительно сложными как с точки зрения реализуемых ими бизнес-требований, так и в технологическом плане. Создание и развитие такие продуктов классическими командами гибких практик (не более 8—10 человек, работающих в одной комнате в итеративном и инкрементном режиме), конечно, возможно. Но подобное развитие оказывается исключительно долговременным и совершенно неадекватным рыночным тенденциям, ориентированным на максимальную скорость. Поэтому применение гибких методологий в крупных организациях, а таковыми зачастую стали и многие современные стартапы, требует адаптации. Над продуктами работают десятки, а иногда и сотни команд. Члены одной и той же команды могут находиться в самых разных точках земного шара, тем более могут быть распределены по поверхности нашей планеты различные команды. И современный продукт уже на уровне концепции, тем более на этапе архитектурного проектирования, должен учитывать еще и эту распределенность, которую мы именуем организационной. Необходимо иметь возможность создавать и развивать продукты распределенными командами. Поэтому распределенность и в контексте продуктов остается ключевой тенденцией развития архитектуры.
Уже неоднократно по ходу настоящего изложения мы отмечали высокую сложность создаваемых на сегодня цифровых продуктов. Эта сложность проявляется в том числе и в их жизненном цикле. Действительно, если бы жизненный цикл продукта был прост, не понадобилось бы для его перевода в цифру распределенных команд. А сложный жизненный цикл продукта, зачастую имеющий пересечение и с другими продуктами организации либо продуктами партнеров, описывается набором бизнес-процессов. Таким образом, мы логично приходим к тому, что обязательным архитектурным элементом продукта является логика бизнес-процессов, непосредственно описывающая продуктовый жизненный цикл. Мы уже отмечали ранее по ходу настоящей книги, что продуктовая логика является ключевым архитектурным уровнем в структуре продукта. И продуктовая логика описывается бизнес-процессами. Таким образом, бизнес-процессы как ключевая тенденция развития архитектуры являются исключительно значимыми при создании и развитии продуктов. Также мы уже отмечали важность применения платформенного подхода при разработке продуктов, а современная платформа, кроме того, должна поддерживать бизнес-процессы, в том числе их исполнение в распределенном режиме. Поэтому продуктовое ИТ-решение использует платформенные механизмы (в формате платформенных сервисов, как показано в книге «Архитектура цифровых платформ. От настоящего к будущему») для описания, реализации, исполнения и отслеживания связанных с жизненным циклом продукта бизнес-процессов.
Необходимо подчеркнуть, что многие бизнес-процессы организации являются комплексными, их нельзя локализовать рамками только одного продукта. Поэтому архитектура продуктового решения должна предусматривать возможность того, что при автоматизации жизненного цикла продукта будут задействованы подобные комплексные сквозные процессы. Например, продуктовые процессы по депозитам задействуют данные кредитных продуктов при их наличии у клиента, что также может потребовать исполнения бизнес-процессов, связанных с кредитами. Возможна и обратная ситуация. Поэтому продуктовая автоматизация должна предельно корректно относиться к работе с бизнес-процессами, чему будет посвящен отдельный раздел настоящей главы.
Сложно переоценить значимость данных при создании и развитии продуктов. С данными работают клиенты, партнеры и сотрудники организаций, данные обрабатываются в ходе исполнения бизнес-процессов, описывающих жизненный цикл продуктов, на основании данных формируются аналитические показатели и принимаются управленческие решения, касающиеся как конкретных продуктов, так и всей организационной деятельности. При этом массивы данных, обрабатываемые организациями, постоянно растут. Увеличиваются потребности в эффективном хранении и обработке данных. При этом меняется сама концепция хранения, которую можно в современных реалиях именовать эффективной. Например, понятие оперативного хранения информации претерпевает значимые изменения едва ли не каждый год.
Необходимо отметить, что продукты зачастую используют не просто данные, а большие данные (Big Data). Под последними понимаются данные, которые характеризуются не только значительными объемами, но наличием как структурированной, так и неструктурированной информации, а также высокой скоростью поступления новых объемов информации, которые в свою очередь также могут быть весьма значительными. Использование больших данных предъявляет специфические требования как к хранению информации в продуктовом ИТ-решении, так и к проведению операций над ними, что в свою очередь формирует и требования к архитектуре продукта. Поэтому данные являются одним из ключевых трендов развития не только архитектуры в целом, но и продуктовой архитектуры в частности. Им будет посвящен специальный раздел в настоящей главе.
В контексте работы с данными подчеркнем еще два важных аспекта. Первый. Поскольку каждый продукт использует и продуцирует огромные массивы данных, то как на уровне концепции, так и на уровне архитектурного проектирования продукты должны обеспечивать поддержку концепции управления данными, принятой в организации. Последняя носит в значительной степени методологический характер, а потому может изменяться вне зависимости от жизненного цикла конкретного продукта. Таким образом, архитектура современного продукта должна быть адаптивной: позволять использовать продуктовое ИТ-решение в различных концепциях управления данными и накладывать минимальные ограничения (а в идеале не накладывать их вовсе) на организацию при развитии концепции управления данными последней. Второй. Поскольку современные архитектурные концепции предполагают выделение продукта данных, входящего в состав продукта организации, но обладающего собственным жизненным циклом, архитектура продуктового ИТ-решения должна позволять гармонизировать жизненные циклы продукта организации и связанного с ним продукта данных. В противном случае могут пострадать самые разные характеристики продукта: время вывода на рынок (time-to-market), производительность и надежность продуктового решения, сложность сопровождения и т. д.
Развитие искусственного интеллекта переживает на сегодня взрывной рост – способствование ускорению работ в данном направлении становится государственной задачей в самых разных странах, мощнейших экономиках современности. И данный факт не оставляет нам выбора – искусственный интеллект является одной из ключевых тенденций развития архитектуры, что должна учитывать в своем продуктовом развитии каждая организация, желающая сохранить собственную конкурентоспособность. В настоящее время невозможно представить себе продукт, не использующий технологии искусственного интеллекта. Даже эффективный анализ тенденций рынка и их влияния на P&L предполагает наличие соответствующих интеллектуальных помощников. Применение искусственного интеллекта позволяет обеспечить дополнительную прозрачность жизненного цикла продукта и принятие необходимых управленческих решений по развитию последнего с немыслимыми ранее точностью и скоростью. При этом нельзя не учитывать высокую ресурсоемкость технологий искусственного интеллекта, что может привести к негативному влиянию на P&L продукта, при создании и развитии которого используются данные технологии. Обеспечение сочетания интеллектуализации продуктов и невысокого ресурсного потребления – один из важнейших вызовов современности.
В настоящей главе каждой из вышеперечисленных ключевых тенденций развития архитектуры и ее месту в концепции и архитектуре цифровых продуктов будет посвящен соответствующий раздел. Пока же отметим, что продукт, пренебрегающий какой-либо из тенденций, не может считаться полноценным в современном цифровом мире. Схематично круговорот тенденций вокруг продукта представлен на Рисунке 12.
Рисунок 12. Продукт и ключевые тенденции развития
архитектуры
В книге «Архитектура цифровых платформ. От настоящего к будущему» мы рассматривали вопросы применения и адаптации платформенных подходов в соответствии с частными тенденциями развития архитектуры, не носящими столь масштабного характера, как вышеперечисленные. Мы называли данные частные тенденции связанными, поскольку они связаны как с ключевыми трендами развития архитектуры, так и с вопросами интенсивного развития цифровых решений. В контексте продуктов связанные тенденции развития архитектуры также являются чрезвычайно значимыми, поэтому их месту в продуктовом подходе будет посвящен отдельный раздел в настоящей главе.
Отдельно добавим, что поскольку мы рассматриваем создание и развитие продуктов в контексте современного платформенного подхода, при следовании ключевым тенденциям развития архитектуры необходимо учитывать и платформенные механизмы их поддержки.
Цифровые продукты и открытый код
В наших предыдущих книгах («Архитектура цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему») мы указывали две исключительно важные даты для всего цифрового мира: 17 сентября 1991 года и 28 октября 2018 года. Обе приведенные даты имеют непосредственное отношение к открытому коду. В 1991 году Линус Торвальдс опубликовал исходный код ядра операционной системы Linux. И мы вновь и вновь повторяем, что это событие стало эпохальным, а дата 17.09.1991 – отсчетом новой эры программных продуктов. Не только программных продуктов с открытым исходным кодом, но вообще любых, поскольку незамедлительно возникла синергия открытых и «закрытых» (vendor-lock) программных продуктов, которая в дальнейшем лишь набирала силу. Фактически сегодня мы с уверенностью можем сказать, что любой программный продукт так или иначе использует открытый код.
Но это было лишь началом большого пути. Вторая из вышеприведенных дат знаменательна тем, что именно в этот день свершилась одна из наиболее значимых сделок в истории открытого кода. Корпорация, ставшая, казалось бы, синонимом масштабных, тяжеловесных, исключительно дорогостоящих решений, вложила огромные денежные средства в приобретение экспертизы в открытом коде. Да, формально сделка по покупке компанией IBM ведущего разработчика решений с открытым исходным кодом RedHat была просто очередным корпоративным мероприятием, каковых было множество на тернистом пути «голубого гиганта». Но подобные формальности можно считать сугубо вторичными. Главным же стало другое – рассматриваемая сделка ознаменовала собой ключевое изменение философии в цифровом мире в целом. Да, в программные решения вкладывается огромные труд, интеллектуальные ресурсы специалистов и исследователей со всего мира, но безусловным приоритетом на сегодня стала эффективность, эффективность создания новых решений, скорейшее предоставление ценности клиентам и партнерам. И открытый код стал тем решением, которое безусловно позволяет повысить указанную эффективность. По факту 28.10.2018 навсегда изменилось мировоззрение цифрового мира. На смену дорогостоящим тяжеловесным решениям (например, тем же масштабным серверам приложений) пришли легковесные программные компоненты, использовать которые могут команды по всему миру. Но не только использовать, но и развивать, расширять и улучшать.
В качестве примера дрейфа даже, казалось бы, апологетов vendor-lock решений в сторону открытости можно привести такой популярнейший фреймворк разработки и исполнения приложений, как. NET. Выпущенный из недр корпорации Microsoft, всегда считавшейся в ИТ среде едва ли не главным сторонником закрытости, популярный фреймворк также стал открытым. Сперва в 2014 году появилась открытая сборка. NET Core, впоследствии и весь. NET ушел от «темной стороны силы», если цитировать знаменитую киносагу. И не просто ушел в сторону открытого кода, но и полностью поддержал исполнение в Linux среде, теперь фреймворк развивается и такими компаниями, как упомянутая выше RedHat. То есть на наших глазах происходит синергия решений, которые самыми разными путями неумолимо движутся в сторону открытости. Кто-то исходно придерживался данной философии, кто-то переходил к ней в тяжелые корпоративные моменты, кто-то же, наоборот, на волне успеха. Но главное случилось – шаг в сторону приоритета открытого кода сделан. И это, если использовать метафору из еще одной исключительно популярной серии фильмов, та «красная таблетка», после которой невозможно смотреть на мир, как прежде.
Но в чем же заключается упомянутое повышение эффективности, которое дает открытый код? Что побуждает таких в прошлом апологетов закрытости, как IBM и Microsoft, выбирать этот путь? В книге «Архитектура цифрового мира» мы уже подробно разбирали ответы на эти вопросы. Вкратце напомним их читателю.
Современная экономическая теория, восходящая еще к итальянским натурфилософам, таким как Антонио Серра, выводит повышение эффективности из увеличения разделения труда – длинные экономические цепочки, предполагающие задействование большего числа участников, позволяют резко повышать общую эффективность. Серьезнейший вклад в развитие данной теории и ее систематизацию внес Адам Смит и его последователи. Есть представители и отечественной школы, внесшие свою лепту в развитие указанного научного направления, такие как М. Л. Хазин. Целью настоящей книги не является повторение всех их логических умопостроений, мы принимаем их выводы: увеличение разделения труда ведет к повышению производительности. И для области информационных технологий данный факт исключительно важен. Открытые решения позволяют вовлечь в их развитие такое количество специалистов со всего мира, которое невозможно ни для одного закрытого программного обеспечения, сколь бы крупная корпорация его ни развивала. И это принципиальный момент – открытые решения обеспечивают уровень производительности труда, недоступный для закрытых решений. Именно подобный уровень производительности труда и привел крупнейших игроков ИТ-рынка в стан сторонников открытого кода.
Что же все вышесказанное означает для цифровых продуктов? Мы и по ходу предыдущих книг, и в течение настоящего изложения неоднократно говорили о ценности, которую несет продукт клиентам и партнерам организации, создающей и развивающей продукт. Отмечали мы и P&L продукта в качестве его обязательной характеристики. То есть мы подчеркиваем тот факт, что ценность необходимо создавать как можно быстрее и эффективнее. Рассуждая же о преимуществах открытого кода, мы во главу угла ставим производительность труда, характеризующую развитие и использование открытых решений. Таким образом, применение открытых технологий становится ценностным мультипликатором, позволяющим существенно повысить производительность труда при создании и развитии современных продуктов. Это означает, что если ставится цель создавать конкурентоспособные продукты (а это в свою очередь означает, что должны выискиваться все варианты повышения производительности их разработки), то организация, имеющая указанную цель, обязана использовать открытое программное обеспечение.
Как и в случае с цифровыми платформами, продукт для своего эффективного развития должен использовать лучшие практики открытого кода. Платформа же, как мы неоднократно отмечали в книге «Архитектура цифровых платформ. От настоящего к будущему», предоставляет опосредованную ценность, позволяя разгрузить продуктовые команды от рутинной деятельности, что также приводит к росту производительности продуктовой разработки. То есть платформа также является ценностным мультипликатором. Мы приходим к логичному выводу: платформа должна использовать практики открытого кода, продукты же должны использовать практики открытого кода и разрабатываться на платформе. Сочетание указанных ценностных мультипликаторов позволяет многократно повысить производительность труда – мы уже ссылались в нашем предыдущем труде на исследование, показавшее, что технологические гиганты оказываются в состоянии вносить изменения, дополнения и в конечном счете улучшения в свои решения, находящиеся в постоянной эксплуатации, практически каждые десять секунд. Это и есть движение к достижению эффективности XXI века. Но только начало этого движения. Необходимо не просто не останавливаться на достигнутом, но и постоянно искать новые пути повышения производительности труда.
Неоднократно по ходу своей профессиональной деятельности автор этих строк сталкивается с вопросом: «Можно ли построить продукт вообще без какого-либо использования открытого кода?» Иногда этот вопрос ставится несколько по-другому: «Объектом уточнения становятся платформы, возможно ли создание последних без применения открытого кода?» И краткий ответ на подобные вопросы всегда один: «Можно». Читатель может удивиться: «Как же так, мне пришлось прочитать столько хвалебных од в адрес открытого кода, а теперь автор так просто признается, что сложнейшие программные комплексы можно создать и без него! Меня вводят в заблуждение!» На самом деле ввод читателя в заблуждение – это последнее, чего бы хотел добиться автор. Поэтому вслед за кратким ответом о принципиальной возможности создания продуктов без применения практик открытого кода необходимо дать более развернутое объяснение.
И поскольку настоящая книга, как и две предыдущие, посвящена архитектуре, то и объяснение, даваемое автором, также будет базироваться именно на архитектуре.
Для начала вернемся к детализации концептуальной архитектуры продукта, приведенной на Рисунках 9 и 10 и описанной в предыдущей главе. В соответствии с описанием в архитектуре задействованы такие программные компоненты и фреймворки, как:
• Языки программирования высокого уровня (в том числе позволяющие разрабатывать легковесные фронтальные решения).
• Реляционные СУБД.
• Нереляционные СУБД.
• Потоковое программное обеспечение.
• Кэширующие компоненты.
• BPM движки.
• Программное обеспечение для управления открытыми API.
• Распределенная файловая система.
• И т. д.
Для всех указанных пунктов существует свободно распространяемое программное обеспечение с открытым исходным кодом, позволяющее решать задачи по автоматизации продуктов. Пример такого сочетания технологий приведен на Рисунке 13. В очередной раз оговоримся, что мы приводим иллюстративный пример, а не разбираем конкретные случаи продуктовой разработки. Взаимодействие, показанное для технологий реализации, также является иллюстративным и может отличаться при конкретной продуктовой автоматизации. По сравнению с ранее приведенным примером мы на Рисунке 13 заменили BPM Camunda на BPM Kogito, чтобы следовать принципу выбора максимально открытой лицензии, тем более в главе, посвященной открытому коду.
Рисунок 13. Пример перечня технологий с открытым исходным
кодом для продуктовой автоматизации
Возможно ли заменить каждую из представленных технологий ее проприетарным аналогом? Безусловно, да, именно поэтому мы и дали положительный ответ на принципиальный вопрос о возможности реализации продуктов без применения открытого кода. Но дальше начинаются архитектурные нюансы.
Любое современное программное обеспечение, решающее задачи повышенной сложности, например в части управления базами данных, является огромным программным комплексом, содержащим множество компонентов. И даже в случае предоставления подобной СУБД в формате vendor-lock оно будет использовать значительное число внешних библиотек, требовать для своего исполнения определенного программного окружения. Это касается и программных библиотек в реализации, и компиляторов, и интерпретаторов, и многих других аспектов. И во всех этих компонентах содержится свободное программное обеспечение. В противном случае компания, предоставляющая соответствующее ИТ-решение, должна разработать его полностью самостоятельно, вплоть до компилятора. Подобная реализация, конечно, достижима, но оценить ее стоимость и сроки не представляется возможным. Мировые технологические гиганты идут другим путем и включают в предоставляемые ими решения компоненты с открытым исходным кодом, а зачастую и базируются на них. Ведь именно таким образом оказывается возможным выстроить максимально длинную цепочку разделения труда и снизить стоимость итогового ИТ-решения. Тем самым улучшается и P&L конечного продукта.
Резюмируя вышесказанное, подчеркнем, что технически создать современный цифровой продукт без использования открытого кода возможно, но таковой продукт будет создаваться долгое время, а себестоимость создания и последующего развития окажется исключительно высокой. Поэтому подобный подход автор считает бесперспективным и нецелесообразным.
В ходе своей профессиональной деятельности (и особенно после выхода предыдущих книг) автору приходилось сталкиваться и с обратным вопросом: «Возможно ли построить современный цифровой продукт только с использованием открытых решений?» Зачастую собеседники автора высказывали сомнения в реализуемости подобной парадигмы.
Мы понимаем, что каждая компания действует в собственных финансовых, экономических, технологических и иных условиях. И поэтому однозначного рецепта по созданию продуктов дать не можем. Начнем свой ответ с совмещения Рисунков 9, 10, на которых представлена детализация концептуальной архитектуры продукта, и Рисунка 13, демонстрирующего пример сочетания ряда технологий с открытым исходным кодом, используемых в ходе продуктовой разработки. Проиллюстрируем указанное совмещение на Рисунках 14 и 15 (мы продолжаем разбивать детализацию архитектуры на два рисунка для удобочитаемости).
Рисунок 14. Детализация архитектуры продукта с использованием открытого программного обеспечения (часть 1)
Рисунок 15. Детализация архитектуры продукта с использованием открытого программного обеспечения (часть 2)