среда, января 28, 2009

MIT WORLD - updated

Года полтора назад я уже писал про этот интереснейший ресурс MIT WORLD (см. Бизнесы-лидеры и другие персоны @ MIT World). Теперь сайт серьезно обновился - стал очень современным и по технологиям и по пользовательскому интерфейсу. Кстати, теперь содержит более 500 видео, в т.ч. с MIT Open Courseware (см. мою заметку Открытые материалы курсов MIT Sloan School of Management).

P.S. ну а раз уж упомянул MIT Sloan, значит грех не упомянуть и Harvard - изменился стартовый адрес Harvard Business Review на http://hbr.harvardbusiness.org/. Значит скоро обновлю ссылку в ITMediaList, а может и добавлю некоторые новые :)

Ярлыки: , , , , ,

суббота, января 24, 2009

Must see

Часто тут даю ссылки из серии must read (иначе бы не упоминал их ;). А вот то, что с моей т.з. must see. Классные диалоги и тексты с отличной музыкой, искренне и красиво снято, не без пары параллелей с The Wall Алана Паркера.

Ярлыки:

среда, января 21, 2009

Результаты работы над Enterprise Architecture в HP

Кто-то наверняка уже видел сегодня в CNews заметку "HP сэкономит $1 млрд на ИТ-инфраструктуре".

На самом деле оригинальный материал был опубликован еще 1-го декабря '08 HP Embarks on Next Phase of Global Technology Plans to Support Future Growth. В англоязычном пресс-релизе немного больше цифр (например, "Reduce spending on internal IT from approximately 4 percent of revenue in 2005 to less than 2 percent in 2009").

К чему это я? Просто указанные цифры стали результатом систематического подхода к Enterprise Architecture. В HP (как и в EDS до присоединения к HP) есть целая команда Enterprise Architecture Steering Team (EAST), рапортующая непосредственно CIO и отвечающая за работу над корпоративной архитектурой и в части ИТ и в части бизнес-архитектуры. Собственно, еще к моменту приобретения Compaq, HP подошел с определенным видением и результатами систематизации внутреннего ИТ (в т.ч. и в терминах EA), а к 2005 году, о котором упоминается в указанных материалах, деятельность в области развития корпоративной архитектуры как целостного взгляда на операционную деятельность HP (т.е. включая бизнес-процессы, управление активами в т.ч. с финансовой т.з. и т.п.) стала инициативой действительно корпоративного уровня.


P.S. Конечно, работая в HP (сейчас уже в EDS, являющемся частью HP) я вижу тот объем информации по Enterprise Architecture, который вряд ли смогу рассказать тем, кто не является сотрудником компании, но некоторыми деталями все же стараюсь делиться ;) Btw, HP активно использует внутри себя Sharepoint (уже 2007-ой), в т.ч. и в работе над корпоративной архитектурой. При этом не просто как замену FTP или "next generation" файловой свалке ;), но и в достаточно функциональном и полноценном collaboration-режиме. Но sharepoint это уже другая история...

Ярлыки: , , ,

воскресенье, января 18, 2009

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.

Ярлыки: , , ,