Рубрика: Digital

The Digital Practitioner Body of Knowledge

Я давно обещал написать немного об этой книжке, имеющей необычный подзаголовок: The Open Group Snapshot. Пора это сделать, тем более, что согласно уверениям авторов 15 января 2019 года это руководство может превратиться в тыкву. Так что успейте скачать и посмотреть http://pubs.opengroup.org/dpbok/snapshot/ Но главная причина моего интереса к DPBoK, конечно, не в этом. The Open Group выпускает много всяких текстов туманно-абстрактного содержания, читать которые могут заставить себя только настоящие ИТ-архитекторы. Свод знаний цифрового практика не похож на такие работы. Перед нами цельная, неплохо структурированная и довольно конкретная книжка, вобравшая в себя основные темы предыдущего десятилетия так или иначе связанные с развитием цифровых продуктов. Какие-то вещи банальны, другие спорны, но в общем и целом текст (кстати, с картинками) в полной мере претендует на то, чтоб называться Body of Knowledge. Его можно использовать как справочник, можно как учебник, при условии некой толики критичного отношения или, как минимум, как набор полезных ссылок. Продолжить чтение «The Digital Practitioner Body of Knowledge»

Микросервисная архитектура для менеджеров

Сделал для FutureBanking короткий материал в формате «микросервисная архитектура для менеджеров»:

Сейчас новые функции принято создавать, переписывая существующие приложения, что несет определенные риски и накладывает ряд ограничений. Нам нужны разработчики, обладающие определенными компетенциями и знакомые с кодом существующего приложения. Доработанное приложение нуждается в тестировании, желательно полном регрессионном, а также нагрузочном и интеграционном. При изменении структуры данных потребуется разработка процедур их миграции, а часто и тестирования такой миграции. Всё это влечет за собой затраты ресурсов и времени и несет нам соответствующие риски, главный из которых поломать что-либо при развертывании новой версии приложения в «боевой» среде.
В случае микросервисной архитектуры мы стремимся наращивать функциональность посредством создания новых модулей, не переписывая существующие приложения. Подробнее, читайте на FutureBanking.ru

Гибкий процесс развития продуктов

Одно время стали довольно популярными обсуждения на тему: а как-бы нам использовать agile за границами ИТ. Несколько таких дискуссий вы, безусловно, найдете в группе FB GosAgile или в блоге Atlassian

Честно говоря, я не помню, чтоб в них было сказано что-то уж очень полезное. Возможно, я просто читал их недостаточно внимательно, а быть может авторы ограничивались слишком простой калькой с процессов разработки ПО. Ниже я опишу некую гипотезу о том, как мог бы выглядеть процесс new product development, адаптированный к современным реалиям посредством agile Lean и Kanban. В какой-то мере это будет продолжением статьи Чему ИТ может научить бизнес. Продолжить чтение «Гибкий процесс развития продуктов»

Цифровой дарвинизм

Digital Transformation DriversВ продолжении темы, затронутой в сообщениях:

хочу обратить внимание читателей на отчет The 2016 State of Digital Transformation. Предыдущий подобный отчет делался в 2014 году, поэтому есть возможность проследить некоторую динамику. Ну и еще, кроме красивых графиков в исследования Brian Solis есть довольно интересные наблюдения. Но сначала небольшое замечание к вводному абзацу отчета

Digital Darwinism continues to impact businesses as technology and societies evolve. As a result, organizations are moving away from “business as usual” as they pursue digital transformation to compete.

Продолжить чтение «Цифровой дарвинизм»

Паттерны постановки задачи

4015279Иногда культурологам удается озвучить то, что не могут или не хотят выразить инженеры и менеджеры: инструмент значимо влияет на наше поведение, [пред]определяет принимаемые нами решения или, как минимум, задает диапазон возможных выборов. Принцип: Если у вас в руках молоток, то большинство вещей в этом мире представляется вам гвоздями – не только работает, но и преобладает при принятии решений.

Традиционный подход к анализу требований и проектированию информационных систем изначально игнорирует наличие концепций. Причем не важно, о каких именно процессных подходах идет речь: водопаде, итеративном процессе или гибких методологиях. Согласно любому из них в момент старта проекта в нашей пустой голове нет ни малейшего представления об образе будущего решения. Мы постоянно пытаемся убедить себя в существовании процесса проектирования сверху-вниз. Хотя весь практический опыт свидетельствует о успехе противоположного подхода, проектировании снизу-вверх, подборе решений методом поиска среди имеющихся шаблонов (см. Роберт Гласс «Программирование и конфликты 2.0»). Продолжить чтение «Паттерны постановки задачи»