Enterprise Mobility: там где ИТ может стать источником инноваций для бизнеса

Почти “профуфлили”- наверное так можно охарактеризовать скорость реакции корпоративных ИТ на штормовой прорыв их эшелонированной обороны со стороны потребительских (на первый взгляд) мобильных устройств нового поколения – планшетников.

 

Если со смартфонами все еще было ни шатко ни валко, появление iPad в руках руководства компаний и государственных деятелей (и “далее по списку”) навело шороху в ИТ департаментах, в очередной раз сказав им – ребята, а ведь у вас был шанс продемонстрировать свою "инновационность” для бизнеса первыми. При этом не замыкаясь на самостоятельно рассматриваемых сloud computing, unified communication или мобилизации пользователей, а обсуждая их как связанные элементы новой генерации инфо-коммуникационной среды, которую можно и нужно создавать для пользователей.

 

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

 

iPass Mobile Workforce Report q1’2011 
“Strong Adoption of Tablets, Especially iPads, in the Enterprise”

 

Как было раньше? Политики технического обеспечения мобильности сотрудников огранивались чаще всего доступом к почтовому серверу, корпоративной адресной книге, корпоративной WiFi-сети, правилам блокировки экрана, паре сертификатов и выдаче мало- и средне-бюджетных смартфонов (на практике – малопригодных к полноценной работе с мобильными сервисами – маленькие экраны, требующие использования стилуса, не слишком объемная карточка памяти) на Windows Mobile*, т.к. эта платформа выглядела наиболее управляемой с т.з. IT Operations.

*а в Штатах еще RIM Blackberry, изначально заточенная под корпоративных пользователей и только недавно ставшая доступной в России с обрубленным WiFi И другими критически важными сервисами.

 

State of Mobility’2010
“2010 Enterprise Mobility Recap and 2011 Outlook”
by The Enterprise Mobility Foundation

 

Что сегодня? Сегодня ИТ департаменты играют в догонялки с продвинутыми пользователями, приносящими свои – более адекватные для работы с информацией дивайсы (с экранами от 3.7”) на платформах iOS и Android. А некоторые, наиболее мобильные сотрудники, купив iPad по цене, соизмеримой с адекватным для удобной работы смартфоном, приносят на работу и его, перетаскивая на него корпоративные документы через DropBox, ругаясь на физиологическую невозможность работы с интранет-порталом на Sharepoint* (и на Galaxy Tab под Android тоже) и делая всякие другие телодвижения, заставляющие службу поддержки ИТ департамента окриками или измученными улыбками (в зависимости от ранга внутрикорпоративного пользователя) все чаще лихорадочно искать возможные решения этой новой для себя головной боли.

* см. возможные решения в материале “SharePoint Clients for iPad/iPhone, Android and Blackberry”

 

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

 

Enterprise Mobility

 

Хорошо, что многие CIO/CXO понимают этот приоритет. Вопрос в том, насколько он будет отражен в планировании и переосмысление многих аспектов деятельности ИТ.

 

Аналитики “успели” – успели отразить по-сути уже свершившийся факт  ;-)

Источник: Gartner Webinar “Reimaging IT: The 2011 CIO Agenda”

см. также Yankee Group Webinar “7 Trends Of Enterprise Mobility”

 

 

Производители тиражируемых систем тоже вовремя сориентировались, и это стало наиболее заметно в области систем электронного документооборота (см. CNews: СЭД покупают в нагрузку к iPad) и больших вендоров ERP&BI (Business Intelligense), начавших скупать соответствующие активы в прошлом году (например, SAP, поглотивший Sybase, который последние годы серьезно концентрировался на рынке корпоративной “мобилизации”).

 

Консалтеры тоже встали в позицию “готовность номер 1” (см. PWC Technology Forecast “Unleashing enterprise mobility” и Convergence monitor: Enterprise mobility).

 

В общем, реагируя на “землетрясение” с эпицентром в среде пользователей, пошла волна цунами, уже совсем не похожая на родившийся в недрах ИТ рынка очередной hype, а реальных инвестиций, в т.ч. венчурных, которые (наконец-то! :) стали делаться не только в чистые интернет-стартапы (sic!), но и в стартапы, ориентированные на корпоративный рынок - Apperian Gets $9.5M Funding to Tap Enterprise Mobility Boom.

 

Планшеты стали той самой “разрушительной” технологией (disruptive technology), которая сейчас заставляет CIO, руководителей ИТ департаментов предпринимать достаточно важные шаги. Возможность привнесения мобильных возможностей - mobility capabillites (как способностей business capability) в повседневные процессы компаний – это не только ценный мех потенциально по-новому организованные процессы, возможность серьезного сокращения времени прохождения бизнес-сценариев от точки А к точке Б за счет возможности вовлечения сотрудников в работу 24 часа в сутки – мечта любого бизнеса ;)

 

Мое мнение – сейчас крайне актуален вопрос доступности внутрикорпоративных мобильных приложений как средств доставки актуальной бизнес-значимой информации. Эта тема может быть декомпозирована в следующие несколько пунктов, актуальных для Департаментов ИТ (да и самих бизнес-подразделений и пользователей):

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

И это только начало, не проспите его…

SOA = EA

Путь к такому выводу был достаточно длительным (кто-то, наверняка, помнит мои наметки двухгодичной давности о возможной модели сервис-ориентированной EA – SOEA :), но теперь это соображение превратилась в уверенность.  На спавшей волне hype-дискуссий вокруг SOA сейчас уже можно сказать, что сервис-ориентированная архитектура стала однозначно восприниматься в контексте бизнес-сервисов и интегрированных прикладных систем, обеспечивающих предоставление таких бизнес-сервисов. Фактическое вазимное проникновение идей управления сквозными бизнес-процессами и SOA также никого уже не удивляют. Начав свое движение в какой-то степени “снизу-вверх” – от технологий и приложений к бизнес-сервисам, SOA поднялась до уровня не только бизнес-подразделений/LOB (Line of Business), но и до уровня предприятия, став по своей сути той же enterprise achitecture, оперирующей не только привчными для ИТ терминами, но и такими понятиями как business capabilities, business value, риски, governance, напрямую связанными с бизнес-процессами. Так что на сегодняшний день, с моей точки зрения, можно четко сформулировать:

• SOA = EA ,

а IT Governance, в свою очередь, определяет стратегические принципы планирования и управления ИТ на основе EA/SOA.

Приложения-кандидаты для переноса в cloud

В блоге Tech Republic 10 Things опубликована интересная заметка 10 applications you can move to the cloud (pdf-версия). В ней перечислены 10 приложений-кандидатов для переноса в облако:

• Email
• Conferencing software
• CRM
• Web hosting
• Development test labs
• Video hosting
• Email security
• Basic office applications
• Batch processing applications

Участвуя не первый год в обсуждениях на тему “у себя/в аутсоурс” (со времен работы в HP) готов согласиться со всеми пунками. Но вот что вызвало удивление – отсутствие упоминания средств совместной работы (collaboration). будь то средства класса sharepoint для внутреннего потребления, будь то инструменты E2.0 (корпоративный блоггинг, enterprise social network и т.п.) – как мне кажется, вполне естественно его рассматривать в качестве средств того же уровня “утилитарности”, что и e-mail. Так что со свой стороны добавляю collaboration software. Соответственно, и security составляющая предполагает collaboration security. А если совсем по уму, то и email security и collaboration security (например, антивирусная проверка документов, закачиваемых в collaboration-систему) и такие средства как rights management (управление правами), могут рассматриваться в случае облачных сервисов как их расширенная опция (с т.з. прайс-листа), а не как отдельные сервисы.

 

Еще один класс приложений, который мне представляется логичным выносить во вне (конечо, как и в любом другом случае, посчитав деньги ;) – интеграция с внешними системами (чаще всего партнерскими, например, для сетевых, франшизных или дистрибуторских бизнесов), благо появляются такие средства как Windows Azure AppFabric (опять-таки не потому что я в MS, а имхо пример хороший). Так что еще можно добавить к списку external applications integration.

 

* Update 01.12.2010: подумалось. что имеет смысл периодически апдейтить по мере оформления мыслей о пропущенных вариантах приложений-кандидатов для cloud.

 

Собственно, вот несколько дополнений к первоначальному списку, с которыми не просто сталкивался, а на самом-то деле и использую (как минимум часть из них):

• project management
• distance learning
• desktop-mobile device synchronization services
• VOIP call center / help desk / web sales assitant

Enterprise Developer Conference в Москве

26-го марта в Москве состоится Enterprise Developer Conference. Хотя программа еще не финализирована (активно над ней работаем), уже кое-что можно про нее понять и решить :)

И я там буду, на этот раз с докладом

• "Разработчик в корпоративной среде: вопросы, проблемы, практики"

А вот предварительные тезисы:

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

Надеюсь, что некоторые мысли в этом докладе будут не только знакомы, но и полезны ;) Обсуждение и кулуары, конечно, как всегда приветствуются!

Руководство Microsoft по проектированию архитектуры приложений - на русском

Коллеги порадовали - выпущено на русском языке 2-е издание

• Руководства Microsoft по проектированию архитектуры приложений.

Для скачивания достаточно зарегистрироваться по указанной ссылке.

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

SOA: отдача появляется еще до автоматизации как таковой

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

Манифест SOA

22-23 октября в Роттердаме проходил 2-й международный симпозиум по SOA, во время которого был опубликован Манифест SOA (SOA Manifesto), среди авторов которого такие гранды индустрии как Гради Буч, Анне Томас Мейнс, Дэвид Чаппел, Джо МакКендрик и другие визионеры. Сам Манифест сопровождается руководящими принципами СОА - SOA Manifesto Guiding Principles.

Появление Манифеста SOA очень важно для индустрии IT. Пройдя пик первого "hype", сервисно-ориентированные подходы стали реально воплощаться не только на уровне инструментария и платформ, но и в программных экосистемах многих компаний и организаций. Индустрией накоплен определенный опыт, позволивший достичь значимой вехи развития архитектурных подходов и их реализаций.

Конечно, переоценивать роль Манифеста SOA не стоит - мы знаем не менее громкий Manifesto of Agile Software Development, интерпретации которого зачастую превращаются в священные войны, разделение "верующих" на различные "церкви" немотря на одну и ту же "библию" и продолжающиеся дискусии. Манифест SOA безусловно будет также сопровождаться дискуссиями. Сейчас же важно то, что в формулировке ключевых положений было, наконец, достигнуто определенное единство и можно продолжать двигаться дальше, лучше понимая предмет обсуждения и друг для друга, используя один и тот же язык.

Ну а ниже я попытался привести возможный перевод Манифеста SOA на русский язык. Замечания и комментарии - приветствуются (как непосредственно здесь - в блоге, так и на ITBlogs.ru).

---

Манифест СОА

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

В нашей работе мы должны следовать приоритетам:

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

Это означает, что признавая ценность пунктов, стоящих справа, мы больше ценим пункты слева.

Ali Arsanjani Grady Booch Toufic Boubez Paul C. Brown David Chappell John deVadoss

Thomas Erl Nicolai Josuttis Dirk Krafzig Mark Little Brian Loesgen Anne Thomas Manes

Joe McKendrick Steve Ross-Talbot Stefan Tilkov Clemens Utschig-Utschig Herbjörn Wilhelmsen

© 2009, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

---

Update 09.11.09: спасибо за уже оставленные здесь, в почте и на ITBlogs комментарии, некоторые нюансы перевода скорректированы.

Облака и сервисная ориентация

Изучая материалы HPLabs еще раз убедился в том, как сильно связаны различные области ИТ, особенно когда мы пытаемся оперировать в терминах обеспечения бизнес-потребностей. Менее года назад я писал про Service-Oriented Enterprise Architecture (SOEA). А вот теперь натолкнулся на материал HPLabs Outsourcing Business to Cloud Computing Services: Opportunities and Challenges, в котором встретил схожий подход к разделению бизнес-сервисов и бизнес-процессов, но уже в конексте идеи virtual business operating environment, описываемой в статье. Другая мысль, которая логична, но не всегда озвучивается явно - облачные вычисления это еще один сценарий аутсоурсинга отдельных аспектов деятельности ИТ по обеспечению бизнеса, также упакованный в стандартный сервис с фиксированным прайсингом и SLA, целиком реализованный на внешней ИТ-инфраструктуре.

Service-Oriented Enterprise Architecture (SOEA)

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

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

С моей точки зрения, SOA - не о компонентах, шинах и Web-сервисах. Это все - частные инструменты реализации архитектурного подхода к использованию технологий, одним из которых является SOA. Внедрить SOA нельзя. Так же, как нельзя внедрить middleware, сервер приложений, ITIL или PMBOK. Это все инструменты достижения цели. SOA - архитектурный и даже, в определенном плане, методологический инструмент рещения задач, стоящих перед ИТ.

Но каковы бизнес-задачи, стоящие перед ИТ? Что заставляет ИТ-индустрию создавать такие инструменты как SOA? Таких задач перед ИТ, по большому счету, три:

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

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

• Service
  A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.
  
  
• IT Service
  A Service provided to one or more Customers by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer's Business Processes. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement.

• Business Service
  1. An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service which is used internally by the IT Service Provider and is not usually visible to the Business.
  2. The term Business Service is also used to mean a Service that is delivered to Business Customers by Business Units. For example delivery of financial services to Customers of a bank, or goods to the Customers of a retail store. Successful delivery of Business Services often depends on one or more IT Services.

Смотрим на определение бизнес-сервиса. А вот тут как раз “засада”. С одной стороны, это называется Business Service. С другой – определяется как IT Service (точгда чем он отличается от бизнес-сервиса? Еще одной прослойкой архитектурного пирога?). Проблема заключается в том, что корни ITIL лежат в IT Operations - деятельности по эксплуатации информационных систем и, чего уж греха таить - в первую очередь оборудования и инфраструктуры. Давайте абстрагируемся от ИТ и от первого варианта определения бизнес-сервиса, предлагаемого ITIL v3. Возьмем его второй вариант. И те же E-mail или видеоконференц-связь рассматриваем как доступные бизнес-пользователям бизнес-сервисы, предоставляемые ИТ-подразделением, наравное с тем как тем же пользователям предоставляются соответствующие финансовые сервисы (начисление зарплаты, производимое бухгалтерий) и т.п.. Все сразу встает на свои места. Тогда первый вариант определения необходимо либо отбрасывать, либо интерпретировать как бизнес-сервис, предоставляемый IT, наравне с бизнес-сервисами HR, финансового подразделения, отдела продаж и т.п. Т.е. IT Service в ITIL является на самом деле подмножеством бизнес-сервсов. Проблема ITIL заключается в том (и это видно например по обсуждению в его третьей версии и SOA и Enterprise Architecture), что в большинстве случаев при постановке ITSM-процессов в ИТ-департаментах, создании каталога услуг, бизнес-сервисы интепретируются в соответствии с первым вариантом определения, а не со вторым, ограничиваясь только ИТ и, концентрируясь на системах и инфраструктуре, что естественно, так как речь идет об IT Operartions.

Забудем об IT Operations, но вспомним о разработчиках. Они привыкли мыслить в терминах систем и интерфейсов (конечно, а данном случае имеются в виду API, а не user interface). И используя понятие сервиса, разработчики понимают под ним интерфейс, удовлетворяющий определенным правилам единого описания (по-сути контракта) и технологического (программного) обращения к нему. В таком контексте система несет определенный функционал, а интерфейс системы определяет сервис, предоставляемый системой по автоматизации определенных бизнес-процессов, в рамках соответствующего соглашения - контракта. Тут и возникают ESB, EDA, asynchronous messaging, Web-services (как одна из возможных технологий стандартизации доступа к интерфейсам) и т.п. Но является ли такой вариант интерпретации бизнес-сервисом? Нет. Понятен ли он бизнесу? Категорически нет. Обсуждая SOA, под сервисом в большинстве случаев понимается технологический интерфейс доступа к функциональности системы, а не бизнес-сервис, предоставляемый структурным подразделением или организационной единицей бизнес-пользователям. Вот здесь и лежат корни проблемы превращения SOA в buzzword, описанной в самом начале.

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

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

Можно возразить, что SOA как раз о технологиях. Но тогда может не стоит приплетать сюда бизнес и логично опустить бизнес риторику? И честно поставить SOA в один ряд с OOP, AOP, DCE и другими чисто ИТ-шными понятиями.

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

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

SOEA – Service-Oriented Enterprise Architecture

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

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

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

Элементы SOEA
(кликните для загрузки диаграммы)

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

Модель SOEA
(кликните для загрузки диаграммы)

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

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

Реализация бизнес-сервисов и автоматизация выполняемых ими бизнес-процессов обеспечивается функциональными системами.

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

Интеграционная модель в SOEA
(кликните для загрузки диаграммы)

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

Концепция SOA – технология, архитектура или нечто большее?

Моя сравнительно недавняя заметка в Connect (#6'08):

• Концепция SOA – технология, архитектура или нечто большее?

Update (18.01.09): некоторая детализация затронутых в заметке идей - в следующем посте.

SOA и Enterprise Architecture - взгляд в 2010

Все больше специалистов в индустрии осознают, что SOA это далеко не чисто технологический взгляд на организацию прикладных систем. Однако, это не значит, что как по мановению волшебной палочки исчезает недопонимание и ограниченная теми или иными рамками интерпретация SOA. О наиболее частых проблемах, связанных с понятием SOA, очень рекомендую прочитать в ноябрьском номере CrossTalk (The Journal of Defence Software Engineering):

• Common Misconceptions About Service-Oriented Architecture
  

Ну а относительно того, какова роль SOA в качестве стратегии организации прикладных систем как отражения бизнес-сервисов в общей Enterprise Architecture (EA), каковы перспективы и направления развития идей Enterprise Architecture - хочу адресовать вас к материалам октябрьского мероприятия SOA Consortium:

• Enterprise Architecture 2010 Webcast
  

Слайды, стенограмма и подкаст доступны после свободной регистрации.

Оба материала, с моей очки зрения попадают в категорию "must read".

UPDATE: моя модель Service-Oriented Enterprise Architecture.

Интересный технический отчет по SOA от Института программной инженерии (SEI) Карнеги-Меллон (CMU)

В общем, очень рекомендую почитать:

• CMU SEI Technical Report: Evaluating a Service-Oriented Architecture

Отчет подготовлен в рамках т.н. Software Architecture Technology Initiative.

Кстати, не менее интересна и подборка презентаций по архитектурной тематике:

• SEI Software Architecture Presentations, Podcasts, Tutorials, and Movies

Oracle предложил BEA Systems $6.7B

Этого ожидали многие. Теперь это факт. На самом деле, сильно напоминает попытку IBM купить Telelogic:

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

Итак, некоторые ссылки по теме:

• CNet News.com: Buyout could serve both BEA, Oracle
• ComputerWorld: Oracle offer will freeze new BEA business, analysts say
• ComputerWorld: Oracle makes $6.7B offer for BEA Systems
• eWeek: Oracle Aims to Acquire BEA Systems
• InfoWorld: Oracle offers $6.7B for BEA
• The Register: Oracle bids for BEA Systems
• ZDNet Blogs: Oracle-BEA: Will there be ‘fusion’?

Business-driven SOA

SOA по своей сути не зависит от конкретных технологий, используемых при построении прикладной инфраструктуры. Первичными являются бизнес-сервисы. "IT really is a paleontology profession, rather than an architectural profession" - об этом и многом другом, как всегда лаконично и ёмко рассказывает Steve Jones в своем интервью* InfoQ:

• Steve Jones on "Business-driven SOA"

Логично, что анализ бизнес-целей, идентификация и приоритезация бизнес-сервисов, установление связей между ними - все это лежит в основе построения SOA, как следующего шага в согласовании бизнеса и ИТ после определения BSA - Business Service Architecture. В совокупности, BSA и SOA лежат в основе Enterprise Architecture. При этом необходимо понимать, что они не определяют ее полностью, потому как есть архитектура данных и многие другие аспекты, среди которых не только (а может и не столько) аспекты ИТ, но и вопросы, касающиеся функционирования бизнеса как такового.

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

Microsoft заговорил о SOA

Действительно, после тяжелой и продолжительной ... Microsoft начал использовать термин SOA. И не просто, а открыв специальный раздел на MSDN:

• MSDN2: Service-Oriented Architeture

Видимо, все-таки, востребованность SOA копоративными потребителями ощущается Microsoft, хотя интерпретация как всегда своя. Что не умаляет многих идей, например, изложенных в книге “SOA in the Real World” Джона Ивдемона (John Evdemon - сопредседатель технического комитета OASIS WS-BPEL).

SOA: и все-таки about what? о бизнесе или технологиях?

Стив Джонс (Steve Jones, автор Enterprise SOA Adoption Strategies, CTO @ Capgemini) в своем блоге комментирует упомянутую мной в одном из сегодняшних постов статью Эндрю МакКаффи, вступая в дискуссию о первичности фокуса SOA - на бизнесе или технологиях?

• SOA is a change programme, not just technology

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

Кстати, теперь уже в продолжение моего предыдущего поста про исследование IDC по платформам, взгляд Стива Джонса на зрелость наиболее распространенных платформ (не самый новый, но пока еще актуальный - начало 2007):

• SOA Technology Assessment: Main SOA Technology Vendors
  

Исследование IDC по платформам разработки и развертывания mission critial приложений

Собственно, сам отчет (август 2007):

• IDC: 2007 Mission Critical North American Application Platform Study

Несмотря на спонсорство и паблик-доступность с сайта Microsoft, судя по цифрам, представленным в отчете, эти факты на них не повлияли :)

Если для вас Middleware, Enterprise Architecture, EAI и SOA - не пустые слова: ZapThink купил Linthicum Group

Дэвид Линтикум (David Linthicum) является одним из настоящих "визионари" в перечисленных областях, консультант, автор ряда замечательных книг, колонок и блогов - основатель Linthicum Group. В свою очередь, ZapThink - одна из ведущих консалтингово-тренинговых компаний, фокусирующихся на архитектуре, интеграции приложений, SOA. Хотя и так эти источники для меня были must read, то теперь и подавно (что и вам рекомендую :-)

• ZapThink Acquires Linthicum: The Announcement

IDS Scheer, моделирование бизнес-процессов и SOA

Сегодняшний пресс-релиз от IDS Scheer:

• Microsoft и IDS Scheer объединяют возможности платформы ARIS и сервера Microsoft BizTalk

А буквально за 3 недели до этого:

• SAP и IDS Scheer расширяют глобальное соглашение о сотрудничестве в области продаж платформы ARIS

Не секрет, что особенно за последний год компания IDS Scheer стала существенно более заметна благодаря ряду партнерских соглашений - c Oracle, уже продающей под своим брендом целый комплекс продуктов IDS Scheer, с HP, с SAP, ... а теперь и с Microsoft. При том, что Oracle, Microsoft и SAP - "злостные" конкуренты.

И тут закрадывается крамольная мысль - либо мы видим появление еще одного игрока "высшей лиги" IT, либо скоро узнаем о еще одном громком M&A на рынке.

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

Виртуальные конференции по BPM и SOA

Виртуальная онлайн-конференция по Business Process Management - BPM in Action прошла в марте этого года и ее презентации доступны для повторного просмотра и скачивания.

Ну а 30-31 октября этого года состоится новая конференция - SOA in Action, регистрация на которую свободна, как и регистрация на сайте eBizQ, являющемуся организатором этих конференций.

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