Современное предприятие нуждается в цифровой архитектуре

Под прошлогоднее Рождество я описал в этом блоге довольно призрачную вещь, условно назвав её Цифровая Архитектура Предприятия (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. Различные виды и представления в бесплатной демонстрационной версии

itdeptexample

Спасибо за интерес к архитектуре и не стесняйтесь задать вопрос в комментариях к этому сообщению.

Update 28/11: Вопросы можно задавать и на Facebook: https://www.facebook.com/mxsmirnov.arch/posts/980559588714522

Современное предприятие нуждается в цифровой архитектуре: 7 комментариев

  1. Подход интересный!

    Но хочется проход в глубину по мощности функционала для реального применения:
    1. Какие поддерживаются нотации и стандарты из коробки?
    2. Есть ли какие-то механизмы выгрузки документации в отчуждаемые форматы (картинки, документы, pptx)?
    3. Что с коллективной работой?
    4. Версионирование, блокировки?
    5. Интеграцию с какими средствами моделирования поддерживает? Можно ли, например, модели из ARIS, Enterprise Architect, Archi и других “оффлайн” моделеров импортировать в Ardoq?

    Вопросы не праздные: я использую Enterpise Architect (+автоматический экспорт в wiki) и всем, кроме юзабилити, я доволен. Единственная фича, которая зацепила в презентации – это визуализация связей. EA к сожалению показывает карту связей только в виде таблицы.

    В итоге вижу, что зайду поиграться, а в работе все равно буду использовать связку EA + wiki.

    1. Павел, спасибо за вопросы!

      Я бы хотел уточнить вопрос про интеграцию. Для разных сценариев нужны различные подходы. Одно дело единожды выкачать все данные из исходной системы и залить в целевую. Совершенно другой подходы, если мы хотим периодически получать набор изменений или, например, подписаться на изменения конкретного объекта и получать об этом уведомления. Я не сумел до конца разобраться со Sparx EA и никто мне, к сожалению, не объяснил какие у него есть APIs, выгрузки и т.п. Многие относятся к этой штуке как к “черной дыре”, в которую можно забить структурированную информацию, а обратно получить только картинки или файлы для печати отчетов.
      Какой сценарий нужен? Как добавляется информация в Sparx EA? Её вбивают туда специально обученные сотрудники с бумаги, или из головы или она берется из каких-то других систем, типа auto-discovery сетевых элементов и приложений, как это нынче модно

      1. Максим, добрый день!

        Да, про интеграцию я как-то расплывчато написал. Я имел ввиду первоначальную загрузку с целью смены инструмента.

        У Sparx EA есть разные варианты предоставления API. Напрмиер, можно подключить к своему проекту на .NET сборку EA.Interop.dll и использовать объектную модель из нее.

        А можно написать свое расширение (Add-In), которое будет запускаться в среде EA и выполнять разные полезные штуки. Например, мы так автоматизировали выгрузку диаграмм в wiki. Пока только в виде png, но недавно пришла в голову мысль выгрузить в svg. А это уже не просто картинки.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *