Стратегия корпоративной архитектуры SOA

Хатай Туна (Hatay Tuna),
корпорация Microsoft

Сентябрь 2009 г.

Краткое содержание.

В данной статье описываются основные понятия и методы, которые ИТ-директора, директора по технологиям, архитекторы и руководители ИТ-отделов могут использовать на практике. Эти понятия и методы помогут организациям развивать ИТ-архитектуру и решения в соответствии с постоянно меняющимися потребностями бизнеса путем внедрения сервис-ориентированной архитектуры (service-oriented architecture, SOA). Созданная на основе зарекомендовавших себя успешных методик и практических приемов, SOA – это надежная основа ИТ-архитектуры предприятия, которая позволяет развертывать важные службы системным и тиражируемым образом в соответствии с приоритетами бизнеса. Она гарантирует, что компания получит предсказуемые и измеримые выгоды, а также максимально повысит отдачу от ИТ-инвестиций.

Введение

• С чего начать внедрение архитектуры SOA.
• Как соотнести службы с потребностями и приоритетами бизнеса.
• Как определить необходимые службы и их объем.
• Как обеспечивать гибкость и внедрять инновации с помощью служб.
• Как внедрять архитектуру SOA.

Эти фундаментальные изменения необходимы организациям, которые стремятся сегодня с помощью архитектуры SOA повысить ценность бизнеса за счет инноваций, роста бизнеса, доходов или снижения операционных затрат.

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

В этой статье рассматриваются ключевые концепции, принципы и методы, которые архитекторы могут сразу же использовать на практике, и которые помогут компаниям разрешать эти проблемы и успешно внедрить SOA.

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

Концепции

SOA – это не конец пути; это ни в коей мере не рабочая среда, которую организация может приобрести или развернуть, после чего некие суперсовременные технологии волшебным образом изменят бизнес и принесут немыслимые выгоды.

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

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

С другой стороны, из-за вертикально-ориентированного технологичного подхода, которого придерживаются многие поставщики программного обеспечения, организации, стремящиеся внедрить SOA, остаются плохо осведомленными о способах – методах и практических приемах, которые помогут им во внедрении SOA.              

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

1. Абстрагирование стабильныхэлементов от изменчивых.
2. Инкапсулирование изменчивыхэлементов в службы.
3. Управление изменениями через службы — путь.

Абстрагирование стабильных элементов от изменчивых

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

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

Давайте рассмотрим следующий сценарий из области подбора персонала:

Консультант по подбору персонала направляет электронное письмо с уведомлением успешному кандидату.

Основная проблема состоит в том, что клиенты не делают различий между тем, что требуется сделать и как это нужно делать. Другими словами, они тесно связывают проблему и решение.

Сколько раз архитекторам ставили задачу в подобной форме и ожидали от них быстрой и рентабельной разработки решений по изменениям?

Здесь может помочь суждение, основанное на функциях.

Функции абстрактны

Функция – это абстрактное представление того, чем именно занимается отдельное подразделение. Она определяет, «что» делает это подразделение, и не имеет отношения к тому, «как» это делается. Понятие «функция» скрывает такие неясные понятия, как:

• Сотрудники, которые осуществляют функции.
• Информационные технологии, которые поддерживают эти функции.
• Процессы, которые описывают, как осуществляется та или иная функция.

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

Рисунок 1 иллюстрирует суждение о проблемах, ориентированное на функции.

Рисунок 1. Перспективное представление функций

Функции стабильны

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

Давайте вернемся к нашему сценарию.

Консультант по подбору персонала направляет электронное письмо с уведомлением успешному кандидату.

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

Например, как показано на рисунке 2, консультант может оставить голосовое сообщение на автоответчике кандидата или отправить ему SMS-сообщение.

Рисунок 2. Происходят изменения: эволюция неизбежна (щелкните рисунок, чтобы увеличить изображение)

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

В этом и состоит суть архитектуры SOA.

Функции имеют четкие границы

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

Архитектура функций, известная также как архитектура бизнес-функций или архитектура бизнеса, – это разбивка и демонстрация бизнес-модели, представленной в виде карты функций, которая состоит из тех или иных функций. Карты функций имеют различную детализацию, известную как уровни.

Давайте рассмотрим карту функций на примере агентства по подбору персонала:

• Создание продуктов и услуг.
• Генерирование спроса.
• • Продажи.
  • • Создание новых рабочих мест.
    • ...
  • Маркетинг.
  • ...
• Поставка продуктов и услуг.
• • Подбор персонала.
  • • Поиск новых кандидатов.
    • Управление заявлениями о приеме на работу.
    • • Отправка заявлений о приеме на работу.
      • Обработка заявлений о приеме на работу.
      • • Анализ CV [curriculum vitae, или резюме].
      • Уведомление кандидатов.
      • • Уведомление кандидатов о приеме заявления.
        • Уведомление кандидатов об отклонении заявления.
        • Доступ к кандидатам.
    • Управление списками избранных кандидатов.
    • ...
• Планирование и управление предприятием.
• • Управление финансами.
  • • Выставление счетов.
    • ...
• Управление совместной работой.

Архитектура функций имеет три свойства, которые могут очень заинтересовать архитекторов. Архитектура функций:

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

Создание карты функций

Главная обязанность архитектора – придерживаться этой точки зрения, возглавить и вести диалог с представителями бизнес-подразделений на семинарах, в ходе собеседований и т. п., и разработать для компании карту, которая представляет ответы на вопрос «что», а не «как».

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

Назначение приоритетов и согласование контекста

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

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

• Найти кандидата на должность:
  Ценность для бизнеса: высокая.
  Конкурентная дифференциация: да.
  Выполнение: плохое.
  
  Или
• Зарплата сотрудникам:
  Ценность для бизнеса: низкая.
  Конкурентная дифференциация: нет.
  Выполнение: плохое.

Скорее всего, ответ: «Найти кандидата на вакантную должность». На самом деле ценность этой функции для бизнеса высока, поскольку она, а не «зарплата сотрудникам», дифференцирует компанию от конкурентов.

Именно так организация может понять, с чего начать и как согласовать инициативы в области SOA с потребностями и приоритетами бизнеса.

Аналитическая оценка функций по их свойствам мгновенно дает выгоды:

• Она обеспечивает более четкое, рациональное и обоснованное принятие решений по назначению приоритетов проблемам.
• Она дает архитекторам информацию в контексте для лучшего понимания проблемы (что особенно важно для бизнеса, где кроются проблемы, почему они возникли и т. п.).

Запомните основные принципы: «что» – очень стабильно, а «как» – изменчиво. Что же дальше? Почему бы не решить вопрос касательно «как» с помощью служб?

Инкапсулирование изменчивых элементов в службы

Сервис-ориентированное моделирование – это метод, который связывает функции с их реализацией через службы. Функции – это абстрактное представление того, что делает компания или ее подразделение, либо что они намереваются делать. Люди, ИТ-системы и процессы в своей совокупности участвуют в реализации функции. Подобные реализации логически группируются как службы.

Сервис-ориентированное моделирование помогает архитекторам продуктивно:

1. Оценивать (или сопоставлять) функции и соответствующие службы.
2. Моделировать службы, включая компоненты, из которых они состоят.

На рисунке 3 указаны ключевые понятия сервис-ориентированного моделирования.

Рисунок. 3. Связь бизнеса и ИТ (щелкните рисунок, чтобы увеличить изображение)

Службы состоят из компонентов служб, которые реализуют функции. Другими словами, служба – это логическая группа компонентов, которые обеспечивают реализацию функции. Служба – это логическая связь между функциями и компонентами служб. Таким образом, реализуется некоторая связь между тем, что представляет собой функция, и как ее необходимо реализовать.

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

После того как соотнесены опыт кандидата и требования по данной вакансии, цикл подбора сотрудника продолжается (интервью, предложения и т. п.):

• Управление заявлениями о приеме на работу.
• Отправка заявлений о приеме на работу.
• Обработка заявлений о приеме на работу.
• Анализ резюме.
• Уведомление кандидатов.
• Уведомление кандидатов о приеме заявления.
• Уведомление кандидатов об отклонении заявления.

На рисунке 4 показана не только детализация этих функций, но и взаимодействие между ними.

Рисунок 4. Функция «Управление заявлениями»

Изучив этот пример, давайте посмотрим, какие из этих функций можно соотнести со службами.

Оценка функций для соответствующих служб

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

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

На рисунке 5 указано возможное сопоставление функций, относящихся к управлению заявлениями (изображены в виде кружочков), со службами, которые инкапсулируют их реализацию.

Рисунок 5. Сопоставление функций и соответствующих им служб

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

Таким образом выполнение функций можно отслеживать и оценивать в соответствии с целями бизнеса.

Хороший пример в этом смысле – сценарий «Анализ резюме» в случае с нашим агентством по подбору персонала:

• 90-процентная точность (в плане извлечения качественной информации из резюме кандидатов).
• Одна тысяча резюме в час.

Такие свойства и требования дают архитекторам важнейшую информацию и контекст для выбора правильных продуктов и технологий, а также для разработки успешных архитектур. В данном случае, например, архитекторы должны выбирать технологии, которые обеспечивают точность 90 % и производительность (анализ 1 тыс. резюме в час), а также соответствующую масштабируемость.

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

Моделирование служб

Моделирование – это процесс выявления и иллюстрирования взаимоотношений и взаимосвязей между службами. Сервис-ориентированные модели включают в себя структурные и поведенческие модели, которые отражают и детализируют различные аспекты служб.

Например, «Служба уведомления кандидатов» зависит от «Службы уведомления по электронной почте», которая рассылает уведомления, как указано на рисунке 6.

Рисунок 6. Структурная модель

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

Поведенческие модели, в свою очередь, демонстрируют взаимодействие между службами в контексте бизнес-процессов, сценариев, вариантов использования и т. п.

На рисунке 7 показан сценарий, в ходе которого кандидат подает заявление о приеме на работу. Резюме успешно проанализировано и сопоставлено с требованиями вакансии. Кандидату отправлено уведомление по электронной почте.

Рисунок 7. Поведенческая модель

Модели разрабатываются на уровне служб (в отличие от подробных технических моделей) и служат простой для понимания иллюстрацией, которая помогает архитектору выявлять бизнес-требования с четкими границами. При этом сложности реализации не указываются.

На рисунке 8 показан логический состав этих служб в плане компонентов, реализующих функцию «Управление заявлениями».

Рисунок 8. Службы, составленные из компонентов служб

В таблице 1 представлены взаимосвязи функций, служб и компонентов служб.

Таблица 1. Состав служб и функции, которые они реализуют

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

Часто начинать проект с нуля и игнорировать существующие инвестиции – не самый лучший выход. Архитектор обязан провести оценку активов и их сопоставление с функциями через службы так, чтобы этими активами можно было управлять и повторно их использовать – в нашем случае это служба «Уведомления по электронной почте» для отправки сообщений.

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

• Повышение точности анализа резюме с 90 до 95 % путем внедрения специализированного готового приложения.
• Использование SMS вместо электронной почты.
• Расширение охвата благодаря тому, что кандидаты смогут отправлять заявления через мобильное приложение со смартфона.

На рисунке 9 показаны эти изменения.

Рисунок 9. Границы неизменны

Обратите внимание на границы служб; хотя внедрение изменилось в соответствии с последними требованиями бизнеса, объем и границы функций остались стабильными. Это помогает организации свести к минимуму отрицательное влияние изменений, а также расширить возможности для эволюции и инноваций.

Не забудьте о разрыве между ИТ и бизнесом!

Сервис-ориентированное моделирование играет важнейшую роль в сокращении разрыва между бизнесом и ИТ – между бизнес-архитектурой (представленной как функции бизнеса) и ИТ-архитектурой (представленной как компоненты служб). Оно объединяет абстрактное представление с конкретными действиями и способами их выполнения (см. рисунок 10).

Рисунок 10. Недостающее звено корпоративной архитектуры – согласованность с SOA

Кроме того, сервис-ориентированное моделирование обеспечивает свободные связи между бизнес-моделями и технологическими моделями, что позволяет реализовывать изменения и в итоге обеспечивает гибкость.

У сервис-ориентированного моделирования есть три качества, которые могут очень заинтересовать архитекторов:

• Оно соединяет гибкими связями через службы бизнес-модели с технологическими моделями.
• Оно скрывает сложности и преобразования для ИТ за границами служб.
• Оно ускоряет внедрение служб благодаря их точному моделированию.

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

Управление изменениями с помощью служб

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

Рисунок 11. Путь от концепции до повышения ценности бизнеса

Обратите внимание, что лучше увязать этапы внедрения SOA (путь) с существующими ИТ-функциями, такими как стандарты Microsoft Operations Framework (MOF), Information Technology Infrastructure Library (ITIL), Control Objectives for Information and related Technology (COBIT) иInternational Organization for Standardization (ISO). Это очень облегчает структурированное и системное управление жизненным циклом служб, поскольку большинство ИТ-подразделений уже хорошо знакомы с этими методами. Кроме того, это позволяет организации использовать существующие кадровые ресурсы и процессы, углубить понимание сервис-ориентированной архитектуры и избежать ненужных организационных и политических барьеров.

Давайте коротко рассмотрим эти этапы.

Этап 1. Назначение приоритетов функциям и определение служб

Планирование служб – это основной этап, в ходе которого архитектор выполняет моделирование архитектуры функций и сервис-ориентированное моделирование, чтобы назначить приоритеты функциям и смоделировать службы. Цель этого этапа:

1. Выявить и назначить приоритеты функциям, которые требуют внимания в зависимости от бизнес-контекста.
2. Оценить приоритетные функции для служб, то есть выполнить ориентацию на службы.
3. Смоделировать определенные службы и их ключевые компоненты.

На этом этапе решаются фундаментальные проблемы: где и когда начинать внедрение SOA, как определить объем служб и т. п.

Первостепенными являются утвержденные проекты по реализации служб, которые представляют собой необходимые изменения.

Этап 2. Преобразование функций с помощью служб

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

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

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

Этап 3. Прослеживание функций через эксплуатацию служб

Эксплуатация службориентирована на работу со службами и отслеживание их компонентов, введенных в эксплуатацию. При этом отслеживается работоспособность и производительность служб (состав компонентов служб), которые реализуют те или иные функции.

Организации должны обеспечивать постоянный мониторинг ключевых характеристик служб, таких как SLA, требования к качеству обслуживания, КПЭ и т. д.

Основной результат эксплуатации служб – работоспособность и производительность служб – служит подтверждением успеха внедрения службы в любой ее форме. Эти результаты являются основой и одновременно требованием к правильному планированию служб.

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

Заключение

Решение ключевых проблем в развертывании SOA не скрыто внутри продуктов или технологий. На самом деле успех в разрешении этих проблем зависит от применения структуры методов и практических приемов (все они представлены на рисунке 12), которые помогают организации внедрять SOA.

Рисунок 12. Общая картина: успешная стратегия корпоративной архитектуры SOA

Давайте вспомним основные концепции:

1. Абстрагирование стабильныхэлементов от изменчивых.
   Архитектура функций помогает организации сформировать абстрактное и стабильное представление бизнеса и выявить области, требующие внимания. Она помогает архитекторам абстрагироваться и разбить проблему на элементы с четкими границами.
2. Инкапсулирование изменчивыхэлементов в службы.
   С помощью сервис-ориентированного моделирования организации могут согласовать требования ИТ и бизнеса. Оно помогает архитекторам соотносить функции, службы и внедрение ИТ, а затем моделировать эти службы, не раскрывая сложность технологий.
3. Управление изменениями через службы. SOA – это путь, а не пункт назначения.
   Организации должны поэтапно и итеративно внедрять SOA в соответствии с потребностями и приоритетами бизнеса.

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

Люди, процессы и ИТ, которые используются для внедрения функций, постоянно меняются. Так было, и так будет всегда. Свободные связи между тем, что именно делается (функция), и как это делается (компоненты служб) через логические ассоциации (службы) являются основой для согласованности, инноваций, производительности и гибкости.

Создание свободных связей между бизнесом и ИТ, а затем – свободных связей между системами гарантирует инновации и производительность, столь необходимые бизнесу, которых нельзя добиться путем формирования только лишь свободных связей между системами.

Ресурсы

• Корпорация Microsoft. “Michael Page International MPI.” Целевые исследования Microsoft, июль 2009 г.
• Корпорация Microsoft. “Service-Oriented Modeling.” Конференция Architect Insight 2009, май 2009 г.
• Решения Microsoft Services Business Architecture (MSBA) и Microsoft Services Service-Oriented Modeling (MS SOM), предлагаемые подразделением Microsoft Services.

Благодарности

Я очень благодарен своему брату Кутаю Туна (Kutay Tuna) (Microsoft Services) за то, что он постоянно анализировал все, что я пишу, и помогал мне в работе.

Об авторе

Хатай Туна (hatayt@microsoft.com) – удостоенный наград главный архитектор корпорации Microsoft в Великобритании. Он специализируется на программных продуктах и службах, сервис-ориентированных архитектурах, бизнес-архитектурах, моделировании и архитектурах на основе моделей, концепции «ПО как услуга», архитектурах шин обслуживания, автоматизации и оптимизации процессов, архитектурах на основе событий и разработке ПО. Хатай – приверженец инноваций, современных технологий и зарождающихся отраслевых тенденций. Он создал несколько решений для госсектора, финансовой отрасли, здравоохранения и розничной торговли, которые успешно используются. Кроме того, он постоянно участвует в таких конференциях, как TechReady, SOA & Business Process и Architecture Insight. Свободное время Хатай любит проводить с семьей; также он играет в игры на консоли Xbox 360, смотрит фильмы и читает техническую литературу.