Под прошлогоднее Рождество я описал в этом блоге довольно призрачную вещь, условно назвав её Цифровая Архитектура Предприятия (Digital Enterprise Architecture). 2016 год принес вполне материальное её воплощение. Правда облачное. Называется этот инструмент Ardoq
Я сначала опубликую короткий видеоролик, с рассказом о том, что это такое, а затем напишу пару абзацев чем новое поколение инструментов архитектуры предприятия отличается от того, с чем нам приходилось сталкиваться раньше. И конечно, я не могу не выразить признательность Ian Stendera (Ardoq) за рассказ о системе и особую признательность Антону Абилову (Ardoq) , который озвучил этот ролик на русском. Спасибо, Антон!
https://vimeo.com/193068396/9dc08d9a13
Вы можете посмотреть другие видео (английский), а так же задать свои вопросы на русском. Для ответов на них мы планируем провести в ближайшее время вебинар (подпишитесь на обновления).
Небольшое отступление. Для меня комфортной формой изучения новых инструментов является просмотр видео на английском с последующей возможностью задать вопросы и обсудить материал на русском. Именно такую схему я хочу предложить
Теперь несколько слов о том, почему такие инструменты необходимы на современном этапе развития корпоративной архитектуры. Первое поколение EA Tools представляло из себя инструменты для наскальной живописи. Их основная цель заключалась в создании отвечающей графической нотации картинки. Благодаря TOGAF, определившим понятие architecture building blocks и architecture repository, а также Archimate, изменившим концепцию представлений, появилось второе поколение инструментов. Архитектура из набора картинок превратилась в справочник основных объектов организации и отношений между ними, а представления в выборки определенных объектов и отношений из общего справочника (см. ArchiMate – друг архитектора? и Архитектура Предприятия и ArchiMate 2.0). Очень немногие инструменты реализовали эту концепцию сколь-либо внятно. Но те, которым удалось это сделать, обнажили новые проблемы.
Первая заключалась в том, что набор выгруженных из общего репозитория элементов, представлял собой огромную паутину. Архитектору часами приходилось её распутывать для получения хоть немного понятного визуального представления. Вторая – набор понятий, которыми оперирует реальная организация, очень далек от предлагаемого существующими стандартами. Если мы хотим получить пользу от нашей архитектуры, то нам постоянно приходится придумывать собственные сущности, их атрибуты и отношения: продукты, линии бизнеса, сегментацию клиентов, проекты. Автоматизированные системы содержат у нас функциональные подсистемы и программное обеспечение, а оно, в свою очередь, состоит из комплексов задач. И это виртуальная реальность существует параллельно миру реальному, состоящему из серверов и систем хранения, СУБД и JEE серверов приложений. Другие примеры сложной организации данных: функциональная орг.структура организации, каталог продуктов и услуг, справочники мастер-данных. В общем, главное требование к архитектурной модели — её расширяемость. Причем, как за счет добавления новых сущностей, так и типизированных свойств. Желательно опциональных свойств, избавляющих нас от разреженных таблиц с сотней полей. Существует множество атрибутов, которые мы хотели бы «навесить» на объекты нашего репозитория как теги(метки). Например, SOХ-критичность.
Все эти возможности могут показать не очень важными пока мы не вступим в эру digital. По всем информационным каналам нам уже рассказывают про цифровую трансформацию, подрывные(disruptive) инновации и «Индустрию 4.0» (см. Призрак Digital на пороге вашего офиса). Мы все уже что-то слышали о беспилотных автомобилях, вытесняющих сотрудников умных программах и прочих чудесах завтрашнего дня. Мы верим, что все это скоро станет массовым и доступным, но пока остаемся в сегодняшнем дне. На ближайшие несколько лет нам обеспечен разрыв между желанием руководителем и заказчиков вступить в цифровую эру и отсутствием в реальных организациях необходимых для этого средств. IBM Watson оказался не очень прилежным сотрудником, предпочитающим не работу, а развлечения «Своей игрой»(Jeopardy!) и разговорами о погоде.
Основным реальным кейсом дигитализации на сегодня являются системы самообслуживания для клиентов, сотрудников и партнеров. А для того, чтоб сократить количество ручных операций в таких сценариях нужны понятные компьютеру справочники. И вот для этого нам не просто требуется адекватный architecture repository, но и набор программных интерфейсов — APIs для работы с каталогами услуг, перечнями продуктов и актуальными списками ресурсов. Без этих данных цифровые процессы просто не могут быть реализованы. Я постараюсь до конца года провести вебинар про [non-]IT Service Management, Service Integration and Management (SIAM), но пока вернемся к Ardoq. Посмотреть API вы можете здесь, но начать лучше с REST API Tutorial. Различные виды и представления в бесплатной демонстрационной версии
Спасибо за интерес к архитектуре и не стесняйтесь задать вопрос в комментариях к этому сообщению.
Update 28/11: Вопросы можно задавать и на Facebook: https://www.facebook.com/mxsmirnov.arch/posts/980559588714522