Инструменты планирования ИТ в California’ Office of CIO

Хотя, в отличие от других примеров, которые я публиковал под тегом Real-world EA, этот пост не содержит ссылок на саму enterprise architecture (ну не нашел её ;), думаю некоторые из упоминаемых ниже инструментов будут небезынтересны не только новичкам, но и ИТ руководителям, которые драйвят внутрикорпоративные ИТ уже не первый год.

 

• California Office of the State CIO (OCIO)
• Office of Technology Services (OTech) – подразделение OCIO

 

California IT Strategic Plan - на то и стратегический план, чтобы определять приоритеты и принципы реализации (2010 Update to the California IT Strategic Plan - pdf) , включая фреймворк One IT (см. стр. 24-25 pdf’а), определяющий три базовых средства средства планирования и контроля развития ИТ:

• Enterprise Architecture как инструмент Strategic planning
• инвестиционный анализ в рамках Capital planning
• Project management and oversight

И вот тут начинается самое интересное ;)

Замечательный (вдвойне, т.к. публично доступен) ресурс

Statewide Information Management Manual (SIMM) содержит целый набор крайне полезных, на мой взгляд, руководств, часть из которых не могу не указать напрямую:

 

1. Statewide Enterprise Architecture

• A Enterprise Architecture Developers Guide and Executive Transmittals
• Enterprise Architecture Developers Guide (pdf)
• Agency Executive Transmittal (doc)
• Department Executive Transmittal (doc)
• B The Enterprise Architecture Governance Process (pdf)
• C Enterprise Architecture Glossary (pdf)

 

2. Economic Analysis Workbook (EAW) Package (pdf)

• EAW Worksheets (xls)
• EAW Worksheets - Extended (xls)
• Sample Worksheets (xls)
• Sample Worksheets - Extended (xls)

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

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

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

• 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 как-то незаметно превратилось в реальную тенденцию ;-).

Структура нового семейства продуктов ISACA COBIT 5 (драфт)

В 2005 году ISACA выпустила COBIT 4 - de facto стандарт и блестящий инструмент построения практики стратегического управления ИТ - IT Governance. В 2007 году последовало удачное уточнение/обновление вопросов управления в корпоративном масштабе - COBIT 4.1, принятый и как стадарт ISO 38500:2008 "Corporate Governance of Information Technology".

Это стало естественно не только на фоне роста популярности COBIT (я сам после ухода из Borland занимался парой проектов адаптации COBIT в конкретных корпоративных ИТ ). Набирала темп серьезнейших публикаций и, соответственно, вес сама ISACA, выпустившая один за одним такие важные фреймворки как ValIT (Value of IT), RiskIT (понятное дело - о рисках в ИТ), ITAF-A Professional Practices Framework for IT Assurance и, наконец, уже совместно с CSA (Cloud Security Allinace) - ряд материалов по оценке рисков применения "готовых взлететь" облачных технологий Cloud Computing.

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

• ISACA опубликовала предварительную структуру нового семейства продуктов COBIT 5.

кликните для увеличения

P.S. Интересно, что в чём-то по аналогии с моделью Филиппа Кратчена 4+1 (Philippe Kruchten, "The 4+1 View Model of Architecture," IEEE Software, 1995), а если быть более точным - в соответствии с архитектурным стандартом IEEE 1451 "Recommended Practice for Architectural Description of Software-Intensive Systems", COBIT 5 использует концепцию перспектив или представлений - view (я пока ещё предпочитаю использовать тот или иной перевод в зависимости от обсуждаемого контекста ;), отражающих различные точки зрения, роли, контекст обсуждения вопросов управления ИТ. Думаю, что немного сориентироваться в самой идее использования представлений/перспектив помогут мои слайды с недавней конференции Software People 2010 (особенно, слайд 17).

P.P.S. Посмотрев на теги этого сообщения, у кого-то (м.б. более "архитектурного", чем "процессного" ;) может возникнуть вопрос - а какое отношение COBIT имеет к корпоративной архитектуре? тема несчерпаема как и само обсуждение где заканчивается IT Governance и начинается Enterprise Architecture. В качестве же краткого ответа на этот вопрос я адресую к текущей версии COBIT 4.1, где можно найти и определения EA от ISACA

• Enterprise architecture - Description of the fundamental underlying design of the components of the business system, or of one element of the business system (e.g., technology), the relationships amongst them and the manner in which they support the organisation's objectives
  
  
  
• Enterprise architecture for IT - Description of the fundamental underlying design of the IT components of the business, the relationships amongst them and the manner in which they support the organisation's objectives

и такую вот показательную, как мне кажется, диаграмму даже на страницах "выжимки" ключевых идей COBIT - Executive Summary:

Основные угрозы безопасности в облаке - 2

Не так давно в своем посте Основные угрозы безопасности в облаке я уже публиковал ссылки на анализ рисков безопасности в облаке от CSA (Сloud Security Alliance).

"Приложившая руку" к этому анализу ассоциация ISACA (автор фреймворков COBIT, ValIT, RiskIT и ITAF-A Professional Practices Framework for IT Assurance), провела в Штатах опрос, чтобы выяснить, какие риски в области ИТ-безопасности видят потребители в использовании облачных сервисов:

• Пресс-релиз "More than 45% Say Risks of Cloud Computing Outweigh Benefits, Survey Finds"
• 2010 ISACA IT Risk/Reward Barometer

В этом контексте, так сказать для полноты картины, интересно также посмотреть свежим взглядом на их же (ISACA) материал "Cloud Computing: Business Benefits With Security, Governance and Assurance Perspectives".

Enterprise Developer Conference в Москве

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

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

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

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

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

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

Риски и иллюзии в принятии решений

Таким заголовком можно объединить две очень важные, по моему мнению, статьи в The McKinsey Quarterly:

• The halo effect*, and other managerial delusions
• Distortions and deceptions in strategic decisions
  

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

• Running with risk

Кстати, все три статьи являются отличными примерами того самого класса материалов "must read" (в данном случае - для менеджеров), которые упомянуты в подзаголовке блога.

* хотя к WikiPedia по многим вопросам приходиться относиться с осторожность, все же позволю привести ссылку, дающую если не ключ, но важные замечания к содержанию статьи первой статьи - Halo effect.

UPDATE: на сайте The McKinsey Quarterly изменились ссылки. Ссылки на приведенные выше статьи поправлены. Не забудьте бесплатно зарегистрироваться на сайте МакКинзи для доступа к полным текстам этих статей.

Ловушки согласования бизнеса и ИТ

Читая один из материалов MIT Sloan Management Review (ссылку на конкретную статью я дам ниже), невольно вспомнил как 14 лет назад, прийдя на работу в РОСНО и начиная заниматься в тандеме с Федором Кожевниковым* автоматизацией бурно развивавшегося добровольного медицинского страхованием (ДМС), столкнулся с достаточно сложной ситуацией:

Задача, поставленная отделом оформления страховой документации звучала как крайне , почти катастрофически срочная - сотрудники этого отдела уже практически не успевали справляться с подготовкой полисов страхования и необходимо было в кратчайшие сроки создать программу печати полисов. Я начал заниматься этой задачей. Благо, руководитель группы оформления страховой документации был человек очень разумный (и как менеджер, и как человек) и начальник ИТ-отдела, ставший в дальнейшем известным российским CIO и входившим в совет директоров РОСНО не только умел делегировать полномочия, но и доверял сотрудникам. Так вот - конечно, можно было "просто" взять и написать программу, которая при вводе соответствующих данных выводила бы на бланки полисов и дополнительных документов всю информацию в необходимом формате. Дело, вроде бы несложное (ну да - DOS, прерывания там всяческие, да еще PCL 5 для лазерника ;)

Однако, анализировав вместе с руководителем группы оформления необходимую для печати информацию (а она сильно зависела от типа договора страхования и т.п. - вы чувствуете, да? ;), мы пришли к выводу - по сути для печати надо было вбивать большую часть информации по договорам. Ок. Но договора корректируются, бывают ошибки в наборе данных.... - в общем, врубившись в бизнес-процесс, я рискнул упереться. Как говориться - "по полной". Моя позиция, в которой я убедил и руководителя группы оформления и руководителя ИТ-отдела, - надо делать программу управления договорами и уже как ее составную часть - печать полисов и доп.документов к ним. Первоначально, ни о какой системе управления договорами никто не хотел слышать - зачем она - у нас и так шаблоны Лексикона (был такой популярный русский редактор) тут? "Не надо самим себя занимать работой над непонятно какой системой, когда нужна печать полисов." Я оценил объем работы, прослезился - получалось +2.5-3 месяца от требуемой даты задания на печать полисов. Но, пошел убеждать с цифрами в руках - система управления договорами нужна бизнесу, информация - та же, дублировать ввод в разные системы в дальнейшем - глупо. Динамика изменений в модели добровольного мед. страхования - очень высокая. Но при автоматическом формировании номера и серии полиса, всегда все зависит от договора, это обсуловлено природой бизнеса ДМС. и т.п. И таких примеров зависимостей очень много.

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

Первая версия подсистемы управления договорами (в дальнейшем - ключевая часть "Системы ДМС" РОСНО) была готова через 3.5 месяца, включая разработку и дизайн нового формата полисов и алгоритм автоматического формирования их номеров и серий. Второе поколение подсистемы договоров (с новым ядром, работавшим уже в защищенном режиме DOS) была введена в эксплуатацию где-то через 8 месяцев, а окончательно выведена из повседневной работы... в начале следующего века.

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

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

А это и есть настоящее согласование ИТ с целями бизнеса - Business-IT Alignment. Заметьте - целями бизнеса, а не текущими бизнес-задачами. Пойди я тогда на поводу классического запроса "надо срочно", могу с уверенностью (вполне) сказать , компания понесла бы дополнительные затраты (поверьте - считали: намного большие, чем дополнительные три месяца ручной работы по оформлению полисов) уже через несколько месяцев после ввода в эксплуатацию автономной программы печати полисов. Конечно, любой кейз, и этот, в частности, - достаточно схематичны. Но, надеюсь, некоторые важные аспекты согласования бизнеса и ИТ мне удалось проиллюстрировать на этом примере не только на уровне явно озвученных выводов.

В какой-то степени, в продолжение своего же недавнего поста, одной фразой о согласовании бизнеса и ИТ это можно переформулировать так: It's about business. But about IT too. Но надо четко понимать, что "it's about business" <> "it's not about technology", хотя последнее - "это ведь не о технологиях!"- часто можно услышать на конференциях, где выступают представители многих маститых вендоров. Кстати, на эту тему вот неплохая статья Эндрю МакКаффи из Harvard Business School:

• The Impact of Information Technology (IT) on Businesses and their Leaders
  

А вот, наконец, и материал, который заставил меня вспомнить всю эту историю:

• MIT Sloan: "Avoiding the Alignment Trap in IT"

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


* "старое поколение" дельфистов знает Федора как ключевого автора RXLib, кстати, название которой расшифровывается как "Rosno vcl eXtension Library", а мы с Федором были одними из первых филд-тестеров продукта Borland под кодовым названием AppBuilder, известного теперь всем под именем Delphi ;)

HERMES – проектный менеджмент со швейцарским вкусом

Изучая детально некоторые свежие материалы и кейзы ISACA и ITGI по имплементации IT Governance на основе COBIT, нашел интересную ссылку на метод управления проектами HERMES, используемый гос-структурами Швейцарии. Плотно поизучав материалы HERMES, могу сказать точно - если вы занимаетесь вопросами управления проектами и рисками в приложении к ИТ, концепция и шаблоны HERMES вам наверняка понравятся. Особенно, если нужен общий, высокоуровневый взгляд на организацию отбора и управления проектами, прозрачно сочетающийся с COBIT и IT Balanced ScoreCard (IT BSC).

• HERMES Foundations (Handbook)
• Шаблоны и дополнительные материалы HERMES
  
• Обзорные презентации HERMES
  
• Recommendations on IT projects
  (by IT auditors working group of Swiss public administration)
  

Два отчета по управлению рисками

Два совсем разных и вроде бы не связанных отчета, дающих, по моему мнению, общую картину по зрелости управления рисками, вниманию к этой проблематике и соответствующим приоритетам:

• Protiviti U.S. Risk Barometer: Survey of C-Level Executives with the Nation’s Largest Companies - не самый новый отчет, однако, учитывая, что опрашивались крупнейшие компании США, не думаю что кардинально что-то изменилось за пару лет, как в силу инерции многих корпораций, так и по причине чисто статистической стороны :) Безусловно, в отчете присутствуют и информационно-технологические риски на фоне других, чем, собственно, отчет интересен.
  
  
• Coming to grips with IT risk (Economist Intelligence Unit) - как ясно из названия, посвящен ИТ-рискам.

Снова о рисках - в контексте Basel II

Для российских банков все ближе 2009 год, когда требования Basel II, вероятно, станут одним из повседневных факторов, влияющих на их деятельность по управлению рисками. Времени осталось всего-ничего. Ну и пока соответствующие документы находятся в общедоступном драфте - не грех на них и посмотреть. Я говорю о дополнении к COBIT, аналогичном IT Control Objectivies for Sarbanes-Oxley:

• ISACA IT Control Objectives for Basel II. The Importance of Governance and Risk Management for Compliance. - Exposure Draft от 16 мая 2007 года, скорее всего будет лежать в открытом доступе лишь до 18 июня 2007.
  

А, заодно, и сопоставить то, что вычитали, с сегодняшними реалиями и трендами:

• Совместное исследование компании InfoWatch и проекта Банкир.Ру - "Стандарт Центрального Банка по ИТ-безопасности 2006. Регулятор воспитывает банки."

А то придет аудит, зафиксирует все, что нашел... а потом по ИТ-департаменту начнут шашкой махать, а так - в контексте ;-)

Читаем о рисках

Государство это огромная корпорация, предприятие, the enterprise. Я не говорю здесь на тему устройства государства. Я имею в виду комплексность решаемых государством задач. В том числе экономических. В том числе финансовых. В том числе инвестиционных. Иначе не было бы такого понятия как, например, бюджет или суверенный дефолт. Иначе мы не говорили бы об управлении рисками. Тем интереснее смотреть на различные работы в области eGovernment и eServices for Citizens - информатизации и информационных сервисов для граждан. Без соответствующего глубокого анализа такие работы были бы невозможны. Я уже приводил примеры такого рода reference-моделей "сервисов для граждан". Надеюсь, что вы их если не глубоко читали, то как минимум обратили внимание. Масштабность задача требует анализа. Знаю, я это уже говорил. Но подчеркиваю это снова и снова потому что убежден - "с высоты птичьего полета" легче начать локализовывать вопрос или проблему. Решив комплексную задачу концептуально, легче подойти к менее масштабной и частной задаче на более глубоком уровне детализации. Можно возразить - а если концепция "большого" не верна? А если как в физике, когда вроде бы законы макромира не очень-то хорошо работают в микромире, именно на уровне микромира проявляется неопределенность? Да, вопрос спорный и мы все еще на подступах к единой теории поля :) Работая в ИТ мы все равно пытаемся положить реальный мир в прокрустово ложе моделей. Что именно гарантирует успешность или неуспешность моделей - вопрос на самом деле очень многогранный. Подтверждает ли ложность модели ее хреновая реализация на коленке? Конечно, нет. Повышает ли вероятность точности и применимости модели объем инвестиций вложенных в нее? А вот в этом я убежден - да, повышает. Поэтому и обращаю часто и свое и ваше внимание на те, вроде бы общие работы, фреймворки, подходы, которые, как мне кажется, могут дать не только пищу для размышлений, но и дают отдельные, часто очень неплохо отградуированные инструменты. Говорим ли мы о сервис-ориентированном подходе, анализе рисков или управлении инвестициями. Вот несколько таких источников:

• Advancing Return on Investment Analysis for Government IT. A Public Value Framework.
  
• Making Smart IT Choices: Understanding Value and Risk in Government IT Investments.

Если эти документы показались интересным - можно найти некоторые аналогичные здесь - на сайте Center for Technology in Government.

Далее, уже от NIST Computer Security Division:

• Risk Management Guide for Information Technology Systems
• Information Security Handbook: A Guide for Managers - здесь, кстати, дается целостный взгляд на проблемы управления рисками и, в том числе, о самой концепции Security Governance (по аналогии с IT Governance и, конечно, Corporate Governance - корпоративным управлением). Это, с моей точки зрения, один из ключевых современных материалов по концептуальному взгляду на информационную безопасность. И уже после этого только стоит приступать к таким стандартам ISO как 17799 и 27001. Кстати, невольно получается тот же подход от концепции к детализации отдельных аспектов.
  

Неплохой материал из подборки Business Link, ориентированной намалый и средний бизнес (SMB или как еще называют в Европе - SME, т.е. Small and Medium Enterprises):

• Identifying and managing IT risks to your business

И, наконец, обновленная версия COBIT 4.1, вышедшая в мае этого года, которую можно свободно скачать с сайта ISACA, всего лишь зарегистрировавшись на нем.

Управление "виртуальной личностью"

Как часто внутрикорпоративные разработчики задумываются о вопросах безопасности? А если задумываются, насколько легко интегрировать создаваемые custom-решения с соответствующей инфраструктурой организации? Вроде бы те же Java EE-разработчики используют соответствующие механизмы управления ролями пользователей, входа в систему .... однако, если в организации используется Directory Server, Active Directory, регламенты безопасности, аудит доступа к системам? А ведь политики безопасности диктуются самой природой деятельности организаций, говорим ли мы о банке, GSM-операторе, страховой компании, заводе, управляющей компании или органе власти.

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

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

Речь об Identity Management (Id Management или просто IdM). Буквально на днях наступил на классический грабли, написав по русски "управление идентификацией". А ведь identity это нечто уникальное - "признак личности", если так можно выразиться. И когда мы говорим "управление идентификацией" мы лишь касаемся вопроса установления личности, но никак ни всего что связано с ее поддержанием в заданном контексте (читай ИТ-инфраструктуре предприятия).

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

Эта задача, конечно, возникла не сегодня, и не вчера. Сколько лет уже используются службы каталогов? Именно. А как часто они интегрированы с системой отдела кадров / HR-модулем ERP? ... А если вот так не побояться и спросить про учетную систему или нечто развернутое на сервере приложений при всей своей кластеризации и отказоустойчивости, живущее абсолютно своей жизнью с точки зрения безопасности? ... вы сами знаете...

А ведь "правила игры" начинают определяться в тот момент когда информацию о сотруднике заносят в базу отдела кадров. И когда мы говорим жизненном цикле identity, то это значит, что в том же банке, в зависимости от должности, на которую человек оформляется, служба безопасности должна поставить виртуальный штампик - к каким системам человек должен иметь доступ, а какие ему как минимум не нужны для работы, а иногда и просто вредны ;) Если же серьезно смотреть на эту проблему, то в том же банке существуют операционные и репутационные риски, а на них оказывает серьезное влияния ИТ, даже если мы не берем в расчет ИТ-аудиторов с COBIT, и "нам не страшен" SOX и Basel II, существуют стандарты безопасности (17799, отображаемый со стороны COBIT и более практический - 27001:2005, по которому уже проводится аудит и аттестация на соответствие) и руководящие документы ЦБ РФ, его рекомендации и письма играющие роль реальных стандартов для финансовой сферы. И, конечно, вопросы identity management касаются не только банков. Достаточно посмотреть на последние исследования по информационной безопасности:

• 2006 E-Crime Watch Survey: инсайдеры все опаснее и опаснее
• InfoWatch: Глобальное исследование инцидентов внутренней информационной безопасности
• Внутренние ИТ-угрозы в России 2006
  

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

Ну а для начала разговора уже о решениях Identity Management, хочу обратить внимание на еще один свободно-доступный Web-курс:

• WMT-IDM-1400 Sun Java Identity Management - Overview
  он расчитан на 2 часа и включает два модуля:
  - Business Case for Identity Management о проблематике задач IdM
  - Sun's Identity Management Portfolio уже о конкретной IdM-платформе Sun

В отличие от других Web-курсов, о которых я писал в предыдущем посте, этот курс на закладке "Notes" включает полный текст курса, который читается преподавателем. Объем этого курса при закачке для работы в офлайн - 42 Мб. Они стоят того,чтобы ориентироваться и в проблеме и в ее решении, от того же банка до сервис-провайдера, так как в курсе дается представления о всех компонентах, входящих в Sun Java Identity Management Suite:

• Java System Identity Manager
• Java System Directory Server Enerprise Edition
• Java System Access Manager
• Java System Identity Auditor
• Java System Federation Manager
• Java System Identity Manager Service Provider Edition (SPE)

Конечно, Sun Java System Identity Manager включает не только встроенные средства прописывания соответствующих workflow (говорим ли мы о визуальном редакторе workflow или встроенном языке xpress) - есть и соответствующие API SDK, о которых (и не только о них, но и о сответствующих open source-решениях Sun) можно, например, прочитать в специальном разделе Sun Developer Network (SDN). Более того, уже практически готов специальный интеграционный модуль NetBeans (в составе Enterprise Pack), позволяющий Java-разработчикам легко расширять функциональность своих систем в соответствии с требованиями безопасности доступа и, конечно, следуя стандартам, в том числе - OASIS SAML.

Презентация моего доклада на SECR 2006 по ITLM

Как и обещал на конференции , выложил презентацию своего доклада
"Ключевые стандарты IT Lifecycle Management (ITLM), их роль, место и значимость как источников стратегических ИТ-практик".

Наверняка, кое-кто помнит мой треугольник "Business-AppDev-IT Ops" - это его актуальная версия с логикой построения и первоисточниками соответствующих стандартов, изложенными в презентации.

Несколько полезных материалов об управлении рисками

В продолжение недавнего, но уже на уровне практически "беллетристики" :)

• IT Manager's Journal: Reducing IT risk aversion
• CIO.com: Running The Risk
• CIO.com: Playing with FIRE
• InfoWorld: Calculating IT risk, navigating compliance
• InformationWeek: Accepting The Risk
• Quality Risk Analysis
• (Karl Wiegers) Know Your Enemy: Software Risk Management
• Dr.Dobb (SDMagazine): Agile Risks, Agile Rewards
• и небольшой списочек в дополнение (не только по рискам)

Приятного чтения! :)

IT-Business Alignment: а теперь о рисках

Одним из важных элементов согласования бизнеса и ИТ (IT-Business Alignment - по этой теме я уже писал не раз, например, в марте) является адекватная работа с рисками. На сайте ITSMportal.ru обнаружил интересную заметку по этой теме:

• Нормы и принципы ИТ (дополнения к известным стандартам)

Практикум "Аспекты рисков в управлении требованиями"

Коллеги!

Рад пригласить вас на практикум "Аспекты рисков в управлении требованиями" ("Addressing Risks in Requirement Engineering"), который состоится 26-го октября в Москве в рамках конференции Software Engineering Conference (Russia) - SEC(R) 2005. Факультативная часть практикума будет посвящена иллюстрации аспектов управления требованиями и проектными ожиданиями с использованием Borland CaliberRM и Borland Estimate.

Практикум будет проводить ведущий консультант и авторизованный SCAMPI CMMI Lead Appraiser европейской штаб-квартиры Borland Роберт Фишер (Robert Fisher). Факультативную часть буду делать я и, надеюсь, что смогу показать обновленную версию CaliberRM, включая Estimate ;)

Вся информация и регистрационная форма доступны со страницы практикума .