Хочу чуть подробней рассказать о том, почему я на днях поместил ссылку на короткий ролик Case Lifecycle Management от PEGA Systems. (Кстати, вот ссылка на тот же ролик на YouTube.) Необходимость некоторого промежуточного слоя между так называемыми Systems of Engagement и Systems of Record более-менее очевидна. (Не стану сейчас глубоко погружаться в разговор о том, что этот такое, а тем более затрагивать тему System of Systems. Systems of Engagement нужны для налаживания романтических отношений с клиентом, Systems of Record для осуществления и учета операций. Думаю, что картинки от Forrester будет вполне достаточно.) Такой промежуточный слой нужен даже не столько для того, чтоб улучшить опыт клиентского взаимодействия, а в первую очередь для защиты унаследованных приложений. Разработчики корпоративных систем вряд ли предполагали, что их решения кто-то «обвяжет» программными интерфейсами и вытащит эти интерфейсы в открытый Интернет, на растерзание веб-сайтам, мобильным приложениями, чат-ботам и инфороботам. Читать далее Фундамент для цифровых сервисов
Метка: Архитектура Предприятия
Digital Enterprise Architecture
Новогодние праздники – пора прогнозов, фантазий и предсказаний. И потому я могу позволить себе порассуждать о понятии, существующем на сегодняшний день только в виде идей, концепций и ранних прототипов. Цифровая архитектура предприятия (Digital Enterprise Architecture) это пока еще даже не buzzword, а всего лишь эксперименты, такие, как приложение для iPad Enterprise Evolver, изображенное на картинке выше. Вы можете его скачать, показать в качестве прототипа, но не использовать в повседневной работе. Но я думаю, что для Enterprise Architecture (впрочем, как и для многих других вещей) выбор сегодня выглядит так: архитектура предприятия должна существенно видоизмениться, воплотившись в цифровой форме, или она окончательно перейдет в разряд ненужных инициатив по устранению времени и части бюджета организаций. Читать далее Digital Enterprise Architecture
Функциональная карта — не территория
Так получилось, что за несколько месяцев я написал целую серию заметок об использовании функциональных карт. Вы можете применять этот инструмент как для анализа требований и визуализации вариантов ИТ-решений в рамках обычных проектов, так и для отображения архитектуры деятельности целой организации. Список ссылок на эти статьи:
- Заметка Так ли уж близки корпоративная архитектура и бизнес-процессы? — рассказывает о том, что такое Business Capabilities Map
- Функциональные карты и диаграммы вариантов использования – вымышленная история об использовании механизма функциональных карт в простом проекте
- Сообщение Эскизы архитектурных решений обобщает технику рисования карт, дает её в качестве некоторого общего способа визуализации фактов и отношений
Пришло время разбавить ложку меда маленькой бочкой дегтя. Дело в том, что функциональная карта это инструмент архитектуры, средство визуализации данных, суждений и предложений. И как любой инструмент он, помогая отобразить мысли, не может компенсировать их отсутствие. Читать далее Функциональная карта — не территория
Структура операционной модели ИТ
Публикация на Facebook ссылки на IT4IT Reference Architecture вызвало большую, но неоднозначную реакцию. Кто-то проявил живой интерес, а кто-то отметился репликами в стиле: «Да кому это нужно! И что это за кружочки с квадратиками?». Выскажу свое мнение. Эталонная архитектура операционной модели деятельности ИТ-подразделения, изложенная в документе, получилась очень неплохой. Визуализация этой архитектуры (см. рисунок ниже) сделана существенно хуже. Чтоб закрыть вопрос с картинками сразу скажу, что синии прямоугольники на картинках обозначают основные функции, а черные круги — объекты данных. Серые и фиолетовые круги — это частные случаи объектов данных (подклассы), обозначающие вспомогательные объекты и воспринимаемые пользователями ИТ-услуг сервисы. Теперь о содержании. Читать далее Структура операционной модели ИТ
Функциональные карты и диаграммы вариантов использования
Сегодня несколько слов о техниках работы бизнес-аналитика. Уже пару десятков лет основной техникой моделирования функционала информационных систем является разработка вариантов использования (use cases). Техника, действительно, неплохая. Особенно если бизнес-аналитик прочитал книжку Алистера Коберна «Современные методы моделирования функциональных требований» или посетил учебный курс по разработке юзкейсов. Однако визуализация вариантов использования в виде соответствующей UML диаграммы до сих пор вызывает сдержанную ухмылку у разработчиков и легкое недоумение у функциональных заказчиков. Пару месяцев назад в заметке Так ли уж близки корпоративная архитектура и бизнес-процессы? я писал о том, что на уровне бизнес-архитектуры никто никаких юзкейсов не рисует. Для отображения деятельности организации используется Business Capability Map – техника, позволяющая отобразить все виды деятельности предприятия на одной картинке. Довольно часто звучит и другой термин: функциональная карта. Что это такое и как использовать эту карту в проектах я позволю себе изложить в виде небольшой истории о вымышленном проекте разработки системы управления инцидентами, рассказанной от лица ведущего бизнес-аналитика этого проекта. Читать далее Функциональные карты и диаграммы вариантов использования