Boston Consulting Group о перспективах cloud computing для бизнеса и некоторых других не менее интересных темах

BCG (Boston Consulting Group) явно не из тех, для кого очередная технологическая next big thing является основой их собственного бизнеса. Наверное, просто потому что они не являются IT-игроками, их взгляд на cloud показался достаточно свежим, особенно когда внимание сосредоточено на сценариях получения отдачи для потребителя-бизнеса. Таких сценариев или уровней бизнес-применения облачных вычислений аналитики BCG выделяют три:

• Utility - Оптимизация использования ресурсов (в первую очередь с финансовой т.з. – т.е. CAPEX vs. OPEX, точность spending forecast и т.п.)
• Process Transformation - Трансформация процессов
• Business-model-innovation - Модификация бизнес-модели 

Эти и другие достаточно интересные идеи лаконично (что не мешает логичности изложения) опубликованы в материале BCG, на который я рекомендую обратить внимание тем, кого интересует не только технологическая сторона cloud computing:

• Capturing the Value of Cloud Computing.
  How Enterprises Can Chart Their Course to the Next Level.

---

Хотел еще обратить внимание на то, что этот материал является частью нового выпуска IT Advantage (издание об ИТ с т.з. бизнеса, выпускаемое BCG) под общей темой IT as a Differentiator:

• IT Advantage - Spring 2010: IT as a Differentiator

В этом публично доступном выпуске есть и другие крайне интересные матераилы, среди которых, например, расширеное представление результатов декабрьского (2009) исследования MIT CISR (Center for Information Systems Research), посвященного характеристикам ИТ департаментов, которые не просто обеспечивают, но и в определенной степени “драйвят” изменения в core-бизнесе.  Не могу не “процитировать” интереснейшую иллюстрацию, показывающую 11 ключевых ролей в ИТ, выделенных в результате проведенного анализа:

Кстати, Enterprise Architect выделена как одна из наиболее значимых ролей, что по моему мнению демонстрирует важность самой деятельности в области корпоративной архитектуры – Enterprise Architecture.

Основы облачной экономики от экспертов из Беркли

Наверное именно так стоило назвать авторам свое исследование:

• Above the Clouds: A Berkeley View of Cloud Computing (white paper, ppt)
• Above the Clouds Presentation (pdf)
• Above the Clouds Video (YouTube) 

Будучи опубликованным экспертами Berkley RAD Lab (Reliable Adaptive Distributed Systems Laboratory) еще в феврале 2009, это исследование до сих пор остается наверное самым важным в части экономического анализа облачных вычислений с точки зрения сопоставления затрат и получаемого эффекта, будь то эластичность, SLA и т.п.

 

Example: Elasticity. Assume our service has a predictable daily demand where the peak requires 500 servers at noon but the trough requires only 100 servers at midnight, as shown in Figure 2(a). As long as the average utilization over a whole day is 300 servers, the actual utilization over the whole day (shaded area under the curve) is 300 x 24 = 7200 server-hours; but since we must provision to the peak of 500 servers, we pay for 500 x 24 = 12000 server-hours, a factor of 1.7 more than what is needed. Therefore, as long as the pay-as-you-go cost per server-hour over 3 years(4) is less than 1.7 times the cost of buying the server, we can save money using utility computing.

 

Можно много говорить о переносе капитальных затрат (CAPEX) в операционные (OPEX), но ведь не только этим ограничивается экономика облачных моделей (!), а то это превращается в мантру, а как доходит до “посчитать”, какие подходы применить к экономическому расчету… на эти вопросы, по крайней мере на уровне задания возможных направлений движения и фокусируется предлагаемый материал, который я честно считаю must read, особенно для тех, кто так или иначе связан с бюджетированием ИТ (причем желательно read до того, как придется сменить работу из-за игнорирования того явления, которое из hype как-то незаметно превратилось в реальную тенденцию ;-).

2 июня - очередная встреча Клуба Архитекторов

2-го июня состоится очередная встреча Клуба Архитекторов в Москве.

Тема: "Облачные вычисления сегодня и завтра. Архитектуры, технологии, практики и перспективы". Будем обсуждать почти всё ;) - от динамических ЦОДов до SQL Azure.

• Детали - в моем блоге на MSDN.

Enterprise Architecture сегодня (по результатам опроса Forrester)

Анализ результатов опроса Forrester "State of EA", проводившийся менее года назад и охвативший более 400 IT-руководителей, отметил некоторые важные аспекты деятельности в области корпоративной архитектуры, необходимые для повышения её значимости для бизнеса и успеха самой инициативы как инструмента стратегического планировая:

• не только желание, но и серьезная потребность в перепозиционировании ИТ-лидеров из технарей, решающих тактические задачи обеспечения деятельности бизнеса в активных участников разработки бизнес-стратегии организации, где они отвечают за ИТ
• представителям ИТ необходимо больше внимания уделять бизнес-архитектуре, начинаем ли мы с документирования её состояния as is или говорим о проработке и анализе возможных сценариев to be именно на уровне бизнеса, его организационной структуры и бизнес-функций
• деятельность по формализации и оптимизации бизнес-процессов должна быть тесно связана со всей деятельностью ИТ, в т.ч. в рамках проработки Information Architecture как особо значимой для бизнеса части EA
• выбор стратегических (на уровне принимаемых корпоративных стандартов ИТ, а следовательно и тактических - для архитектуры конкретных прикладных систем) архитектурных решений должен учитывать не только технологическую и финансовую составляющую, но и то. что можно назвать Business View, подразумевая перспективы и планы развития соответствующих "способностей" бизнеса - business capabilities (отдельная и очень важная тема и тренд, которую я надеюсь осветить в этом блоге в ближайшее время).
• совместная работа корпоративных архитекторов и архитекторов ИТ-решений вместе с бизнес-консультантами, которые часто и вовсе не встречаются даже в рамках длительных бизнес-проектов, проводимых бизнес-консалтерами

Как видим, большинство из этих вопросов связано с организацией взаимодействия ИТ департаментов и бизнес-подразделений, что наводит на мысль о стирании граней между IT Governance и процессной частью разработки и отслеживания реализации планов по Enterprise Architecture как неотъемлемого элемента долгосрочного планирования и бюджетного мониторинга.

Хотя сам отчёт целиком и не доступен в свободном режиме, хочу привести два источника, позволяющие как минимум получить представление о сегодняшнем состоянии деятельности по разработке enterprise architecture в "корпоративной Америке":

• статья "Enterprise Architecture Today and Tomorrow" в Architecture & Governance Magazine, содержащая основные количественные результаты опроса, в частности:

• вэбинар "The State of EA: Is 2010 the Transitional Year?",
  проведенный в январе 2010 Architecture & Governance Magazine, на котором Forrester представлял ключевые результаты этого исследования.

Real-world EA - Британский Совет (British Council)

Детально проработанная корпоративная архитектура Британского Совета (British Council):

• ***Enterprise Architecture Roadmap
• **Enterprise Architecture Benefits Matrix
  
• Enterprise Architecture Overview
  
• Enterprise Architecture Actions Summary
• Enterprise Architecture project update
  

Описания доменов EA (roadmap-документы):

• Application Domain
• Colaboration Domain
  
• Data Domain
  
• Network Domain
  
• Systems Management Domain
  
• Security Domain
• Platform Domain

Корпоративная архитектура в Британском Совете, как это и принято в зрелых организациях, рассматривается в качестве ключевого инструмента планирования IT, детализирующего ИТ-стратегию и используемого в сочетании с практикой управления портфелем проектов (т.е. по-сути инвестиционным портфелем) - Project Portfolio Management.

Эти и другие материалы доступны на страницах политик и процедур в разделе, относящемся к Information systems and technology.

Real-world EA - университет Charles Sturt

Ещё один пример EA, особенно интересный тем, что он в большой степени фокусируется на IT Governance и бизнес-процессах (по-сути Information Architecture):

Enterprise Architecture (EA) is a strategic framework to provide guidance, consultation and approval of investments in people, process and technology that aligns to and supports Institutional Strategy and Vision.

Начать знакомство можно с буклета yourCSU (то бишь "ваш Charles Sturt University"), который сами авторы позиционируют как "has been developed as a means of describing the complexity of the University and its structure. In short, this is the Who, What, Where, When, Why and How of CSU".

Основные ссылки с материалами CSU:

• домашняя страница всей инициативы/программы
  CSU Productivity and Reform
• Методология
  
• Процессная модель (Higher Education Process Reference Model)
• The Enterprise Model / Process Knowledgebase
• Change Management Framework (обратите внимание - речь идет об организационных изменениях в т.ч. !)
• Enterprise Architecture - интересны и полезны обе презентации (кстати, очень подробные !):
  - CSU'S Journey to Enterprise Architecture
  - EA Workshop – Educause 2008

Ну а раз уже не первый раз обращаемся к материалам реальных EA в крупнейших университетах (public и education - две сектора, где такого рода информация является часто общедоступной в отлие от нефтянки, производства и т.п.), не могу не дать ссылки на материалы австралийско-новозеландских конференций Enterprise Architecture in Higher Education Symposiums:

• 2008
• 2007
• 2006
  

Свод знаний по бизнес-анализу BABOK - версия 2.0

В 2006 году IIBA - International Institute of Business Analysis впервые выпустила Свод знаний по бизнес-анализу - Business Analysis Body of Knowledge (BABOK). В марте 2009 было выпущено обновление BABOK® Guide 2.0, кратко о котором вы можете прочитать в обзоре.

Если вы член IIBA, то BABOK 2.0 и другие материалы (например, Business Analysis Competency Model, доступ к онлайн-библиотеке) для вас целиком открыт (для России, кстати, всего за $65). Если же вы еще не являетесь членом IIBA, то можете купить печатную версию BABOK или, если перед встпулением в IIBA хотите предварительно ознакомиться с BABOK 2.0 в электронном виде - можете посмотреть BABOK 2.0 Guide на Google Books :)

Что должен знать и уметь архитектор

Такой вопрос мне задают часто, и кулуары Software People 2010 не были исключением. Проблема в том, что часто те, кто задают такой вопрос, ограничиваюся первой его частью "что должен знать" или формулируют его даже несколько иначе - " какие технологии надо знать архитектору?". Вопрос, имхо, в корне неверный. Знание технологий "не освобождает...", в сочетании с опытом построения и, что принципиально важно, развёртывания систем - необходимое, но инедостаточное условие to be recognized в качестве архитектора. Кроме того, есть еще один важный момент - а о каком именно архитекторе идет речь? том, кто пишет конкретный софт (system или solution architect)? отвечает за решение по автоматизации целого подразделения или области деятельности (domain или LoB architect - от "line of business"), или определяет технологическую политику организации в целом в роли enterprise architect? пресловутый scope, область ответсвенности, уровень архитектуры (application, infrastructure, information/data, ...) - имеет значение, и требования к знаниям и навыкам серьезно зависят от этого.

 

Чтобы легче было сориентироваться начинающим специалистам, которые ставят себе цель, да и почерпнуть что-то полезное тем, кто давно уже выступает в роли архитектора, хочу обратить внимание на интересную с моей точки зрения часть TOGAF - The Open Group Achitecture Framework (см. TOGAF online)

• TOGAF Architecture Skills Framework

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

 

Generic Skills

 

 

IT General Knowledge Skills

 

 

- и это лишь малая часть того анализа требуемых архитекторам умений, которая представлена в TOGAF, так что не ленитесь заглянуть в первоисточник ;)

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

 

 

 

Конечно, ни один фреймворк не является истиной в последней инстанции. Есть и второй, причём неплохо согласованный с TOGAF :-) Это - IASA - International Association of Software Architects (базовый уровень членства в которой, кстати, бесплатен) предлагает свой взгляд на "уровни зрелости" навыков, необходимых архитекторам:

• IASA Architect Proficiency Matrix

Хотя IASA и ограничивается именно программными системами, с другой стороны - предлагает и соответствующий инструмент оценки, включающий описания соответствующих навыков:

• IASA Capability Level Assessment

Конечно, любая оценка в стиле assessment или тем более self-assessment не является абсолютно объективной. Тем не менее - это полезный инструмент, особенно в сочетании пусть и не полным "сводом знаний", позиционируемым как библиотека к своду знаний IASA IT Architect Body of Knowledge - ITABOK Library (таким же сводом, кстати, в определенной степени можно считать и тот же TOGAF, являющийся может быть и даже более систематизированным).

 

И, наконец, завершая такую небольшую вводную часть о навыках архитекторов, я рекомендую интересный материал, опубликованный членами шведского отделения IASA в недавнем номере Microsoft The Architecture Journal:

A Study of Architect Roles by IASA Sweden

В нём, как мне кажется, достаточно хорошо описываются архитектурные роли Enterprise Architect, Business Architect, Solution Architect, Software Architect.

Real-world EA - штат Мичиган

Я уже не раз давал ссылки на US Federal Enterprise Architecture (FEA) - не только проверенного временем методологического подхода к построению и использованию концепции архитектуры предприятия (enterprise architecture), но и обязательного (их "счетная палата" проводит ассессменты госсруктур на предмет соответствия требованиям FEA) к использованию инструмента планирования инвестиций в ИТ в госсекторе США.

Хороший пример того, как EA на практике рассматривается в качестве неотъемлемой части стратегического плана ИТ - в данном случае в масштабах штата Мичиган, США:

• Michigan IT Strategic Plan (interactive online overview)
  
• IT Strategic Plan (site)
• Enterprise Architecture как часть IT Strategic Plan
• Enterprise Architecture - Strategic Approach
  

Обратите внимание, что за стратегический план разивтия ИТ и позиционирование в нём EA отвечает не просто департамент ИТ, а Department of Technology, Management and Budget. А вот за методологию построения и реализацию EA отвечает уже Department of Information Technology.

Real-world EA - US National Institutes of Health (NIH)

Корпоративная архитектура американского Национального Института Здоровья - National Institutes of Health (NIH).

• NIH Enterprise Architecture
  

Real-world EA - Massachusetts Institute of Technology (MIT)

Что бы мы не обсуждали на уровне методологий, всегда интересен пример из реальной жизни. Особенно, когда это касается столь комплексной и стратегически значимой темы как архитектура предприятия - Enterprise Architecture.

Этим сообщением я хочу начать категорию постов, которую можно будет в дальнейшем найти по тегу Real-world EA.

В этот раз, хочу дать ссылку на корпоративную архитектуру Массачусетского Технологического Института - MIT:

• MIT Enterprise Architecture

Архитектурные уровни в Enterprise Architecture

Всегда, когда обсуждается общий подход построения архитектуры предприятия (Enterprise Architecture - EA), приходится для себя выбирать как её строить, с чего начинать. И, обычно, обсуждаются два сценария:

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

Однако, вне зависимости от выбранного сценария, у нас всегда существует еще один уровень архитектуры - архитектура направления или области деятельности (Line of Business - LoB) или как это предлагает Federal Enterprise Architecture (см. FEA Practice Guidance) - архитектура сегмента Segment Architecture. Часто, с сегментом сопоставляют соответствующую организационную единицу, подразделение, отдел.

И вот тут появляется третий сценарий:

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

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

P.S. Подробную информацию о возможных подходах к построению архитектуры сегмента рекомендую почитать на сайте Federal Segment Architecture Methodology - FSAM.

Корпоративные ИТ 2015

Исследование, опубликованное ИТ-направлением The Corporate Executive Board Company (CEB) небольшое, но с моей т.з. достаточно полезное, потому что систематизирует (по результатам опроса 127 ИТ-лидеров крупнейших компаний и организаций) общие тренды - куда смещается фокус корпоративных ИТ:

• Shift 1: Information over process: в противоположность тому, о чём говорит Ник Карр (ИТ как электричество - используется всеми и не дифференциирует потребителей). Конкурентное преимущество всё больше определяется средствами бизнес-аналитики (BI), совместной работы (collaboration) и пользовательским интерфейсом (в широком понимании - от customer interface до usability в отношении логики использования конечными потребителями ИТ-систем, в целом).
  
  
• Shift 2: IT embedded in business services: департамент IT всё менее будет заметен как достаточно обособленное подразделение в организации. "Технологии будут рассматривается как неотъямлемая составная часть бизнес-сервисов и традиционные функции ИТ сливаются с общими группами бизнес-сервисов в составе общих корпоративных функций - финансов, HR, и т.п.
  
  
• Shift 3: Externalized service delivery: в течение пяти лет до 80% затрат на прикладную составляющую ИТ будут направляться на приобретение внешних сервисов. Внутрення роль ИТ сменяется с "technology providers" на "technology brokers".
  
  
• Shift 4: Greater business partner responsibility: Потребность в дифференциации от конкурентов (от себя добавлю - скорее, в обеспечении более высокой управляемости и повышении гибкости организации) связана с управлением информацией, что часто выходит за рамки способностей и функций локального департамента ИТ (IT departments' capabilities). Как результат - всё большее вовлечение представителей бизнеса в вопросы, традиционно адресовавшиеся ИТ.
  
  
• Shift 5: Diminished standalone IT role: по мере смещения роли ИТ в сторону бизнес-сервисов, наблюдается эволюционирование ИТ в полноценную бизнес-роль (с моей т.з. только в компаниях, для которых работа с информацией есть составляющая основной деятельности - финансовые институты, страховые компании, государственные структуры и т.п.), при этом предполагается качественное сокращение собственного персонала (на 75% и более). Стратегия, архитектура, управление рисками, управление программами, поддержка пользователей и взаимодействие с бизнес-потребителями (relationship management) выходит на уровень бизнес-сервисов, связанных с функциями чистого ИТ.
  

Исследование:

• The Future of Corporate IT. Executive Summary.
  How to Prepare for Five Radical Shifts in IT Value, Ownership, and Role
  

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