Computerworld, США
Цель проекта Project Green— переработать бизнес-приложения, выпускаемые Microsoft, в соответствии с требованиями общей ориентированной на сервисы архитектурой
Сатья Надела, проработавший не один десяток лет в Microsoft, возглавил инициативу Project Green, впервые анонсированную в 2003 году. Цель этого проекта — переработать бизнес-приложения, выпускаемые корпорацией, в соответствии с требованиями общей ориентированной на сервисы архитектурой (Service Oriented Architecture, SOA).
В интервью с Робертом Митчеллом, журналистом еженедельника Computerworld, Надела рассказал о текущем положении дел в проекте Project Green, о планах, которые предстоит реализовать в рамках этой инициативы, причем особо подчеркнул, что компания добивается «последовательного прогресса», а не делает ставку на «кардинальные изменения». Надела также пояснил, что в Microsoft понимают под «слабосвязанными» вычислениями и описал, как в корпорации создают решения, рассчитанные на предприятия среднего бизнеса.
Благодаря Microsoft CRM и приобретениям компании в вашем распоряжении находятся теперь все элементы, необходимые для создания пакета планирования ресурсов предприятия (Enterprise Resource Planning, ERP), ориентированного на нужды предприятия среднего бизнеса. Так и планировалось?
Мы вышли на этот рынок, сделав серию приобретений, но определенная работа велась и в самой компании, в частности был создан Microsoft CRM. У нас есть продукты, относящиеся к категории систем планирования ресурсов предприятия, Microsoft CRM и приложения, предназначенные для небольших компаний, в том числе и те, которые входят в состав Microsoft Office. Что касается средств планирования ресурсов предприятия, то у нас есть Great Plains, Axapta, Solomon, Navision — четыре самых известных торговых марки на рынке систем для предприятий среднего бизнеса.
Как будут развиваться эти продукты? Пользователи хотят, чтобы решения были более простыми и гибкими, а также имели более низкую общую стоимость владения. При этом продукты должны предоставлять максимально широкий спектр возможностей для данной области бизнеса. Имея такие ориентиры, мы прежде всего разработали модель, названную нами моделью потребителя. Она состоит из трех элементов. Первое — это люди. Пользователям необходима связь между их оперативными взаимодействиями и более структурированной, регулярной работой. Второе — уровень сложности бизнес-процессов в том виде, как их отражает организационная схема. Уровень сложности определяется исходя из подразделений, он зависит от числа сотрудников.
Последний элемент связан с тем, что мы называем работой или процессом. Сотрудники подразделений работают в рамках определенного бизнес-процесса.
Каким образом переход к сервис-ориентированной архитектуре влияет на эти программы?
Мы определили пять качеств, которые необходимы пользователям. Во-первых, конечные пользователи хотят иметь более простые, ориентированные на задачи и учитывающие специфику работы конкретных людей пользовательские интерфейсы, способные помочь им в работе с уже имеющимися информационными моделями. Great Plains или Solomon имеют в своей основе достаточно надежные модели данных и объектов. Во-вторых, это учет специфики бизнеса. Да, они хотят получать отчеты, но на самом деле управление предприятием малого и среднего бизнеса — это сплошные исключения из правил. Здесь необходимо то, что мы называем операционным бизнес-анализом.
В-третьих — это наличие связи. Ни одно бизнес-приложение, приложение для планирования корпоративных ресурсов, не существует в изоляции. Для начала нужно предоставить нашим системам возможность использовать Web-сервисы таким образом, чтобы можно было сформировать составные приложения, которые могут быть построены на слабо связанных моделях с помощью новых тенденций в архитектуре, ориентированной на сервисы.
Поэтому мы поддерживаем интеграцию между системой CRM и системой ERP, опираясь на архитектуру, ориентированную на сервисы. Это и есть способ объединения систем, поддерживающий слабо связанные, асинхронные структуры.
В-четвертых — это так называемые адаптивные процессы. Сейчас в коде любого бизнес-приложения жестко прописана бизнес-логика. Проблема заключается в том, что бизнес-процессы не статичны. И со временем любое бизнес-приложение перестает соответствовать реальному процессу в физическом мире, что вызывает множество сложностей.
Реальное спасение — иметь возможность преобразовать то, что сейчас прописано в коде, в более «модельную» форму. Следующая проблема — определить, как мы можем реализовать модельный подход в системах так, чтобы максимально увеличить актуальность и срок эффективной работы этой системы и, что более важно, как мы можем сделать систему более адаптивной к изменениям?
И наконец, в-пятых — в архитектуре наших приложений центральное место занимает процесс. Над этим мы работаем и это определяющий принцип нашего архитектурного подхода.
И какое место в этом отводится Project Green?
Project Green объединяет в себе исследования, касающиеся тех определяющих качеств архитектуры, о которых я говорил. Это также создание при минимальной помощи с нашей стороны реального продукта как результата таких исследований в контексте версий Great Plains, Navision или CRM. Сейчас результаты Project Green находят отражение в наших продуктах. Интеграция базового кода происходит тогда, когда суть бизнес-логики приложений преобразуется в форму единой модели.
Каковы планы выпуска продуктов в рамках Project Green?
Наши планы не предусматривают никаких «резких движений», мол «вот вам новый продукт и давайте все сразу на него переходите». Мы проповедуем последовательный процесс, ориентируясь на пять упомянутых качеств. Вы можете оценить наш прогресс по последней выпущенной версии, и каждые два-три года мы намерены предлагать следующий вариант.
Насколько далеко вы планируете идти по пути модульности и разукрупнения бизнес-приложений Microsoft?
Мы абсолютно уверены в том, что компонентный подход и разукрупнение не ухудшат качество конечного продукта. Если просто взять SOA и, ни о чем не задумываясь, применить этот подход ко всему базовому приложению, то ничего не получится. Перед конечным пользователем есть экран, и он хочет иметь возможность совершить транзакцию. Вы должны очень четко и детально обрисовать границы. В противном случае вы получите лишь компоненты, которые невозможно объединить.
Не приведет ли такой подход к превращению программных компонентов в товары массового потребления?
Самое важное для меня, с точки зрения перспективы компонентного подхода, то, что он позволяет создавать системы, намного более гибко и быстро адаптирующиеся к изменениям. Такова реальность мира бизнес-приложений.
Позволит ли компонентный подход пользователям объединять самые передовые приложения, при условии что затраты на интеграцию будут меньше?
Я верю, что все больше систем будет реализовываться в рамках децентрализованного подхода, и их будет намного проще устанавливать и интегрировать. Возможно, пользователи предпочтут просто купить одну систему. В данном случае все упирается в вопрос стоимости интеграции.