UX Design. Проектирование опыта взаимодействия

Удивительным образом популярность понятия опыт взаимодействия (User eXperince) совпала с появлением touch screen-ов. Пока люди обозревали веб-сайты с при помощи стационарного персонального компьютера все использовали понятие usability.  С появлением мобильных устройств, планшетных компьютеров, в общем после того как пользователи стали активно тыкать в экран пальцами, на смену термину юзабилити пришло понятие User eXperince. Теперь  пользователь должен не только разглядеть кнопку «Купить!», но и суметь её нажать. Не все сайты предыдущего поколения предоставляют такую возможность.

В надежде обнаружить что-нибудь полезное для описания архитектуры информационных систем прочитал пару книг по опыту взаимодействия. Мне всегда не нравилась архитектура в виде квадратов и стрелок, напечатанная черно-белым принтером на листе формата А4. Ну что можно сделать с такой архитектурой? Разве что взять карандаш и почиркать. Добавить пару стрелок, написать от руки комментарии, нарисовать жирные знаки вопроса и рожицы. Есть вероятность того, что после совещания вашу архитектуру скомкают и отправят в мусорную корзину. Формат листа писчей бумаги к этому располагает, вне зависимости от содержания отображенной на нем архитектуры. Вот такой вот опыт взаимодействия.

Люди, которые занимаются проектированием опыта взаимодействия более прагматичны, чем системные архитекторы. Оказалось, что в книжках у них написано не о том, как следует делать сайты, а скорее о том, как убедить заказчика, что UX Design – отдельная обязательная работа. Работа, которую следует поручить команде высокооплачиваемых профессионалов. Ну, и кроме того, эти книжки помогают научить новоиспеченную команду профессионалов тому, как собрать рукописные наброски, скриншоты, заметки на полях в нечто цельное, завершенный продукт, такой чтоб не стыдно было его представить заказчику.

Архитекторам информационных систем явно есть чему поучиться у проектировщиков опыта взаимодействия в части организации работ.

Как документировать базы данных

Казалось бы, если архитекторы информационных систем что-то и умеют делать, то это что-то – документирование структуры базы данных. Питер Чен еще в 1976 году предложил модель «сущность-связь», в которой сущности отображаются в виде прямоугольника, их атрибуты – в виде овала, а отношения между сущностями в виде ромба. В дальнейшем, отношения выродились в стрелки или птичьи следы (crow’s foot) атрибуты вписались в квадратики сущностей и все это преобразовалось в знакомую нам нотацию IDEF1x. Затем появились case-средства, типа ErWin и задача документирования реляционных баз данных, вроде бы, была решена. Но есть, как минимум, две проблемы.

BigData 2012. Время выполнять обещания?

Удивительное единодушие проявили вендоры на конференции BigData 2012. IBM, Oracle, Microsoft, Informatica, в общем все, говорили одно и тоже слово. И это слово – Hadoop. Одни говорили о том, как развернуть hadoop на своем оборудовании, другие намекали, что портируют hadoop в свою операционку, третьи рассказывали как «прислонить» их продукты к hadoop сбоку, сверху, снизу, в общем со всех сторон.

Другое, в чем были единодушны практически все ораторы, так это в том, что hadoop нужен для анализа социальных сетей. Робкие упоминания о том, что BigData это не только facebook и twitter вряд ли кто-то расслышал. Мое мнение на этот счет заключается в том, что анализ социальных сетей это, конечно, хорошо. Еще лучше будет, если маркетологи, заинтересованные в анализе социальных сетей, заплатят за очередную технологическую революцию, вызванную появлением понятие bigdata и соответствующими технологиями. Уверен, если это случится, то наши корпоративные ИТ-архитектуры ожидают серьезные изменения. Потому что линейно масштабируемые приложения для хранения и обработки данных нужны не только для анализа социальных сетей.

Open Graph: Третье поколение глобальной сети

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

Идея этого сообщения родилась у меня пару дней назад, 14 февраля, на встрече клуба архитекторов. Обсуждали мы вторую версию языка моделирования архитектуры предприятия ArchiMate. Вероятно, несколько главных ИТ архитекторов, собравшихся в одно время и в одной комнате, создают некоторый магнетизм,  что позволят обратить внимание на вещи, которые почему-то с первого взгляда от внимания ускользают. Дело в том, что у элементов, определенных в ArchiMate нет свойств(и методов), как например у классов языка UML. Свойства элементов определяются теми отношениями, в которых они участвуют. Кроме того, в ArchiMate нет аналога понятия стереотип, используемого в UML. Т.е. если мы хотим показать, что какой-то класс является частным случаем другого класса, то мы должны делать это явно. Но вернемся к теме.

Архитектура Предприятия и ArchiMate 2.0

31 января 2012 года на конференции в Сан-Франциско Open Group представила вторую версию языка моделирования архитектуры предприятия ArchiMate. По словам разработчиков, основной задачей данной версии явилось расширение языка для более полного покрытия методологии TOGAF Architecture Development Method (ADM). И действительно в ArchiMate появилось два расширения Motivation extension и Implementation and Migration extension с новыми симпатичными обозначениями заинтересованных лиц, целей, требований и так далее. Вы можете скачать (после регистрации) описание ArchiMate 2.0 с сайта The Open Group Так же на сайте есть некоторые сопроводительные материалы: шаблоны для MS Visio, пример архитектурных моделей вымышленной организации ArchiSurance, постеры с нотацией языка, онлайновое описание и т.п.

Отвечая на вопрос: «зачем все это нужно?» руководитель проекта разработки ArchiMate Marc Lankhorst сказал примерно следующее:

Сначала мы разработали язык, призванный помочь архитекторам создавать модели архитектуры предприятия, так же как UML помогает разработчикам моделировать программное обеспечение. Вы наверняка знакомы с ”PowerPoint архитектурой” состоящий из квадратиков и стрелок. И каждый раз, при взгляде на такую картинку, у вас возникает вопрос, что означает эта фигурка и эта линия. Целю ArchiMate было определить условные обозначения, чтобы быть уверенным, что у вас есть единое понимание отображенной архитектуры… Теперь(в версии 2.0) у нас есть язык, который дополнен средствами для моделирования концепций, проектов, результатов; позволяющий описывать мотивацию – заинтересованные стороны, драйверы, цели и требования.

Интеграция новых приложений в корпоративный ИТ-ландшафт

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

О том как вендоры и аналитики победили ITIL

Наверное, я один из немногих читателей книжки Роба Ингланда «Овладевая ITIL», которым эта книжка не нравится. Не нравится не потому, что я не согласен с приводимыми автором фактами и выводами. Наоборот, с большинством суждений о роли, месте и истинных мотивах популяризаторов ITSM я согласен. Мне не нравится подход IT sceptic-а. На протяжении всей книжки автор пишет о том, что построение ИТ-сервисов в соответствии с ITIL это очень дорого не всегда нужно, и потому предлагает действовать более прагматично. В одном направлении немножко поработать с процессами, в другом – немножко, вот всем и станет немного лучше.

Учебный курс: ИТ архитектура предприятия

В преддверии Нового года принято строить планы и загадывать желания. Я собираюсь в начале 2012 года собрать имеющиеся у меня материалы в учебный курс по архитектуре информационных систем организации. Краткая презентация курса выглядит примерно так:

Я не собираюсь пересказывать учебник по UML или учить вас рисовать диаграммы в нотации Archimate. Мы не будем моделировать корпоративные java приложения и разбираться в тонкостях отображения объектно-ориентированных моделей в реляционной базе данных. Цель этого курса выделить базовые техники ИТ архитектуры, востребованные в современной организации. Разобраться что, когда и главное зачем должен делать сотрудник, занимающий должность ИТ архитектора. Как применить теоретические наработки архитектуры предприятия (Enterprise architecture), подходы к моделированию информационных систем, руководства по процессам управления ИТ к задачам и операционным процессам современной компании.

В программе курса:
1. Ретроспектива программных архитектур. Возрастание сложности корпоративных информационных систем: непрерывные инновации; разрозненность унаследованных приложений; устаревание технологий. Изменения в бизнесе: слияния и поглощения; процессный подход к управлению организацией; интеграция информационных систем предприятия с системами поставщиков и заказчиков.

2. Роль архитектуры в процессах управления ИТ. Моделирование и инвентаризация ИТ-услуг и ИТ-ресурсов. Задачи архитектора в процессах управления изменения, управления релизами информационных систем, инцидентами, дефектами и проблемами.

3. Предпосылки возникновения сервис-ориентированного подхода в архитектуре:

- объектно-ориентированный анализ и проектирование информационных систем;
- открытые интернет-стандарты взаимодействия бизнес-приложений, SOAP и RESTful веб-сервисы;
- архитектура предприятия, средства управления бизнес-процессами, интеграция приложений.

4. Проектирование архитектуры сложных ИТ решений, включающих согласованные изменения нескольких информационных систем и построение композитных приложений. Создание высокоуровневого дизайна решения. Декомпозиция бизнес-процессов по системам. Разработка программных интерфейсов. Планирование инфраструктуры, развертывания и сопровождения. Задачи архитектора на разных фазах традиционного ИТ проекта. Кросс-проектная деятельность. Оптимизация портфеля проектов.

5. Основные информационные системы организации. Финансовые и учетные системы. Системы управления персоналом, документооборота и коллективной работы. Приложения для поддержки взаимоотношений с клиентами, поставщиками и заказчиками. Интернет-сайт и корпоративный портал. Мобильные приложения. Технологии интеграции приложений. Сервисная шина предприятия, системы управления бизнес-процессами и бизнес-правилами, управление основными данными.

 

Надеюсь, основное учел. Буду признателен за добавления, советы, акценты и замечания!

В тумане облачных вычислений

Я подвергся очередному опросу относительно ожиданий от cloud computing или же, говоря русским языком, облачных вычислений. Думаю, эта тема изрядно надоела не только мне, но и большинству экспертов, занимающихся информационными технологиями.
Возможно, она уже актуальна для людей, занимающихся перепродажей серверного оборудования, но для отрасли программного обеспечения «облака» остаются пока в разделе размышлений о будущем. Сейчас про «облака» достоверно можно сказать лишь следующие:

ICAS-2011: Интеграция корпоративных прикладных систем

Недавно я выступал на конференции Интеграция корпоративных прикладных систем (ICAS-2011). Судя по высоким оценкам в анкетах участников конференции, готовился я не зря. Мой доклад об использовании Open ESB для построения композитных приложений был хорошо принят (выкладываю несколько слайдов)

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