Архитектура ИТ-решений

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

Под прошлогоднее Рождество я описал в этом блоге довольно призрачную вещь, условно назвав её Цифровая Архитектура Предприятия (Digital Enterprise Architecture). 2016 год принес вполне материальное её воплощение. Правда облачное. Называется этот инструмент Ardoq

Я сначала опубликую короткий видеоролик, с рассказом о том, что это такое, а затем напишу пару абзацев чем новое поколение инструментов архитектуры предприятия отличается от того, с чем нам приходилось сталкиваться раньше. И конечно, я не могу не выразить признательность Ian Stendera (Ardoq) за рассказ о системе и особую признательность Антону Абилову (Ardoq) , который озвучил этот ролик на русском. Спасибо, Антон!

https://vimeo.com/193068396/9dc08d9a13

Вы можете посмотреть другие видео (английский), а так же задать свои вопросы на русском. Для ответов на них мы планируем провести в ближайшее время вебинар (подпишитесь на обновления).

Небольшое отступление. Для меня комфортной формой изучения новых инструментов является просмотр видео на английском с последующей возможностью задать вопросы и обсудить материал на русском. Именно такую схему я хочу предложить

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

ИТ-архитектор с точки зрения ITSM

Пару месяцев назад в блоге компании AXELOS (владелец портфеля ITIL и PRINCE2) появилось сообщение The ‘technical leader’ of the IT realm: the IT Architect. Появилось оно конечно не просто так, а как анонс описания роли ИТ-архитектор в деле создания и управления ИТ-услугами, включающем перечисление видов деятельности, знаний и навыков, а так же полезных для архитектора квалификаций ITIL. Читать далее ИТ-архитектор с точки зрения ITSM

Все пути исчезают, но …

Некоторые моменты, затронутые на серии прошедших вебинаров и в ходе курса «Мастерская проектирования ИТ-решений» представляются мне достаточно важными, чтоб вынести их в отдельную запись в блоге. Напомню, что занимались мы такой дисциплиной как архитектура решений (Solution Architecture) и потому логично будет начать с определения предмета рассуждений. Согласно TOGAF

Solution Architecture A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.

Прежде чем прокомментировать это определение я позволю себе привести одно вспомогательное определение, взятое из руководства по бизнес-анализу IIBA BABOK Guide v.3 (2.1 The Business Analysis Core Concept Model™)

Solution A specific way of satisfying one or more needs in a context.

Проще говоря, Solution или решение – это конкретный путь удовлетворения некоторой потребности в имеющем место быть окружении. В том случае если потребность выявлена и определена как цель, то архитектура решения (описание конкретного пути) – это маршрут достижения этой цели. Пара существенных замечаний: Читать далее Все пути исчезают, но …

Снова про асимметричность информации

ИТ-архитекторам часто приходится выступать в качестве экспертов при выборе новых программных продуктов или платформ. Неявно предполагается что, задав несколько заковыристых вопросов потенциальному поставщику, архитектор выявит реальное качество рассматриваемого решения и поможет заказчику сделать правильный выбор. Иногда эта процедура выглядит еще проще: эксперта просят написать список архитектурных требований к решению, а потенциального поставщика расставить плюсики напротив каждого пункта.

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

Потому предлагаю вашему вниманию, например, вот эту лекцию от ВШЭ

http://www.youtube.com/watch?v=qQeDZ325g9I
Потом обсудим 😉

Мастерская проектирования ИТ-решений

Вот и закончился учебный курс «Мастерская проектирования ИТ-решений». Несколько недель подготовки, пять дней интенсивной работы и огромное чувство удовлетворения. Жаль, что все прошло так быстро и еще раз спасибо всем!

О пользе проектного офиса

В июне 2010 года я разместил в этом блоге сообщение О вреде проектного управления, а чуть позже расширил тему в кратком обзоре гартнеровской статьи Projects Today, «Change Operations» Tomorrow. По законам жанра рано или поздно должна была появиться и сегодняшняя заметка. И дело совсем не в том, что я изменил свое отношение к корпоративным проектам. Пренебрежительное отношение к диаграммам Ганта, регулярному подкручиванию процента выполнения работ, наукообразным рассуждениям о методе критического пути и инструментам, типа MS Project, предназначенным для отображения фиктивной отчетности по проектам у меня сохранилось. Точно так же сохранилось убеждение в полезности средств организации совместной деятельности, общего информационного пространства, трекеров и событийных лент. Но речь совсем не о том. Я хочу рассмотреть проектный офис как некоторый социальный институт внутри компании, форму организации совместной деятельности людей, обладающей признаком самовоспроизводимости. Читать далее О пользе проектного офиса

Фундамент для цифровых сервисов

Хочу чуть подробней рассказать о том, почему я на днях поместил ссылку на короткий ролик Case Lifecycle Management от PEGA Systems. (Кстати, вот ссылка на тот же ролик на YouTube.) Необходимость некоторого промежуточного слоя между так называемыми Systems of Engagement и Systems of Record более-менее очевидна. (Не стану сейчас глубоко погружаться в разговор о том, что этот такое, а тем более затрагивать тему System of Systems. Systems of Engagement нужны для налаживания романтических отношений с клиентом, Systems of Record для осуществления и учета операций. Думаю, что картинки от Forrester будет вполне достаточно.) Такой промежуточный слой нужен даже не столько для того, чтоб улучшить опыт клиентского взаимодействия, а в первую очередь для защиты унаследованных приложений. Разработчики корпоративных систем вряд ли предполагали, что их решения кто-то «обвяжет» программными интерфейсами и вытащит эти интерфейсы в открытый Интернет, на растерзание веб-сайтам, мобильным приложениями, чат-ботам и инфороботам. Читать далее Фундамент для цифровых сервисов

В этом году издательство «Питер» выпустило русскоязычный перевод книжки Майкла Нейгарда “Release it! Проектирование и дизайн ПО для тех, кому не всё равно” Оригинал этой книжки “Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers)” появился в 2007 году. Не знаю какими соображениями руководствовалось издательство выпуская перевод сегодня. Как, впрочем, не помню почему именно эту книжку я взял почитать в отпуск. Тем не менее хочу порекомендовать эту книжку для чтения всем, кто так или иначе связан с архитектурой информационных систем. Читать далее Release it! книжка о трещинах в ПО