?

Log in

Сегодня вышел спецвыпуск «Архитектура предприятия на практике» (№6 2014) журнала Information Management. В него вошла моя статья «Методология создания и развития архитектурной практики компании».

Подписчики журнала могут познакомиться со статей по ссылке: http://infomanagement.rucio.ru/index.php?route=magazine/material&path=48&product_id=304

Аннотация статьи:

В предыдущих моих статьях вы познакомились с архитектурным фреймворком TOGAF 9. Но, как показывает опыт, при первом рассмотрении TOGAF кажется громоздким и сложным для применения в реальной жизни. Поэтому в этой статье, мы поговорим о том, как использовать методы архитектуры предприятия и как создать архитектурную практику в компании. Она основана на методике World-Class Enterprise Architecture, разработанной группой экспертов консорциума The Open Group. Статья состоит из трех частей.

  1. Часть 1. Модель функций архитектурной практики.Архитектурная практика представляет собой бизнес-функцию предприятия. Для создания архитектурной практики в конкретной компании можно взять за основу модель функций архитектурной практики (Enterprise Architecture Capability Model).
  2. Часть 2. Как создавать и развивать архитектурную практику? Шесть основных шагов. Для разработки плана развития архитектурной практики сложно предложить точный алгоритм, но в любом случае вам придется выполнить шесть основных шагов: выявить стейкхолдеров и их потребности, определить необходимый набор функции архитектурной практики, расставить приоритеты внедрения функций, оценить текущее и целевое состояние архитектурной практики, выбрать исполнителей задач развития и необходимые инструменты.
  3. Часть 3. Учебный пример: как архитектурная практика может помочь банку в «кризисные времена».В этой части статьи я опишу учебный пример создания архитектурной практики банка, основанный на методике World-Class Enterprise Architecture.

Originally published at Практический подход к ИТ-архитектуре. You can comment here or there.

В книге «Архитектура Предприятия» я не заслуженно обошел вниманием системы для управления Архитектурой Предприятия (Enterprise Architecture Tools). Настало время устранить этот пробел.

Когда стоит задуматься о внедрении такого инструмента?

В первое время, для создания и обмена архитектурными артефактами (все возможные схемы, описания и таблицы) большинство команд архитекторов успешно используют MS Office, специальные шаблоны и электронную почту. В лучшем случае, дополняют их порталом.  Но, со временем, это приводит к ряду проблем.

  • Артефактов и их версий становится все больше и больше. И уже никто не знает где актуальная версия, зачем нужен был тот или иной документ и т.д.
  • Артефакты связаны друг с другом. Если изменяешь один, то возможно потребуется поменять ещё несколько. Через какое-то время кто-то что-то обязательно забудет, и ваше стройное описание архитектуры предприятия начинает «плыть».
  • «Кто в лес, кто по дрова». Сложно обеспечить единые стандарты разработки и обновления документов, целостность общей модели. Особенно, с учетом того, что команда периодически приобретает новых архитекторов, которые привыкли работать по другим правилам. Артефакты начинают делать в разных не всегда совместимых инструментах. Например, кто-то работает на Mac’ах, кто-то на Windows.
  • Не к каждому артефакту должен быть доступ у всех потенциальных пользователей системы. Не только с точки зрения информационной безопасности, то и потому что каждый должен получать необходимую информацию в удобном для него виде, а не выискивать её в сотне непонятных ему схем и документов.
  • Изменения в артефактах отражают историю развития архитектуры предприятия. Эту историю нужно сравнивать с планом развития архитектуры предприятия для план-факт анализа.
  • «Сложно увидеть лес за деревьями». Думаю, вы понимаете, насколько сложен анализ информации, которая хранится в большом количестве документов. Скорость, достоверность и наглядность – это не про отчет, который 3 дня делали в Excel.

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

В следующих статьях мы поговорим о функциональности систем управления архитектурой предприятия и основных решениях на рынке.

Originally published at Практический подход к ИТ-архитектуре. You can comment here or there.

Как сделать успешным проект по развитию корпоративной архитектуры (enterprise architecture)?

В этой статье собраны 10 факторов успеха архитектурного проекта.

  1. Четкие цели. Для проекта жизненно необходимы четкие и понятные цели. Причем достижение этих целей должно быть важно для спонсора проекта и ключевых заинтересованных лиц.
  2. Быстрые результаты. Проект должен обеспечивать достижение краткосрочных целей. Важно поддерживать интерес спонсора к проекту. Для этого нужно быстро достигать необходимых для компании результатов, которые он сможет записать себе в актив. Если ближайшие результаты будут через 3 года, то интерес к проекту сильно упадет.
  3. Активно работать со всеми заинтересованными лицами. В рамках проекта часто решаются вопросы, которые требуют участия топ-менеджмента, других важных и очень занятых людей. Найдите способы вовлекать их в проект. Конечно, не стоит их звать на все совещания или дергать каждый день по разным вопросам. Но вы можете привлечь в проект их доверенных лиц, присылать справку по проекту, для встреч с ними готовить списки вопросов с вариантами ответов.
  4. Избегать революционных изменений. Они очень красиво выглядят на бумаге, но их тяжело реализовать в жизни. Метод постепенных улучшений часто более эффективен.
  5. Отслеживайте ценность результатов. Для каждого архитектурного решения нужно оценить выгоды, сроки, затраты и риски. Их нужно обязательно согласовывать со спонсором и заинтересованными лицами. Результаты проекта должны давать ценность компании.
  6. Обеспечить максимальное повторное использование ИТ-активов компании. Все сломать и переделать – это долго и дорого. А ломать то, что действительно работает, глупо. Зачастую информационные системы и оборудование компании используются на 15-30% возможностей. Это отличная возможность для получения быстрых результатов с минимальными затратами.
  7. Архитекторы должны активно работать с бизнесом и ИТ-проектами. А не генерировать гениальные идеи на основе «лучших практик». Работа «в поле» для многих начинающих архитекторов крайне некомфортна. Они боятся показаться некомпетентными. Хотя то, что ИТ-специалисты знают глубже конкретные технологии, чем архитекторы, совершенно нормально. Как и то, что бизнес знает лучше, как работает компания. Работа с людьми – единственный способ достичь результатов.
  8. Максимально использовать и распространять информацию. Основной актив архитектурного проекта – это информация. Нужно сделать доступ к ней максимально быстрым и удобным. А также рассказывать всем, что у вас есть и как они могут это использовать.
  9. Контроль результатов проектов реализации. Для проектов реализации, которые часто делают внешние исполнители, важна формальная приемка результатов. Закрыл проекты актами и сбежал. Архитекторы должны собрать единую систему из результатов нескольких проектов. Поэтому держите руку на пульсе.
  10. Говорить с людьми на понятном языке. Говорить с бизнесом на языке бизнеса. Говорить с ИТ на языке ИТ. Без сленга архитекторов. Важность коммуникации часто недооценивают. Контролируйте не только, что вы говорите, но и как, когда и кому. Если вас не понимают, это ваша вина. И очень большая проблема.

Originally published at Практический подход к ИТ-архитектуре. You can comment here or there.

Сейчас в ИТ-сфере горячая пора — «Конец Года». Нужно сделать все, что внезапно продали, до конца года. Полгода думали, потом было лето, затем месяц подписывали контракт. А теперь срочно работать. До конца года нужны результаты. Важно соблюсти сроки. Качество не так важно.

Кто-то уже смирился и уже научились жить с этим. Кто-кто ругает руководство.

В чем-то они правы. Степень зрелости управления в нашей стране ещё далека от идеала. Но прогресс явно положительный. По крайней мере по моим наблюдениям. Может быть мне просто везет на хороших людей.

На просторах интернета нашел свежую статью Ицхака Адизеса «Managerial Problems of Russia», автора книг на тему менеджмента. В ней вы найдете интересный взгляд на российские особенности менеджмента. На всякий случай, сохраню её к себе.

Read the rest of this entry »

Originally published at Практический подход к ИТ-архитектуре. You can comment here or there.

Tags:

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

А те, кто смогут её удерживать, будут новой элитой. Так как их результативность будет во много раз выше, чем у остальных. Они очень быстро захватят ведущие позиции в науке, бизнесе и т. д. Если архитектор не может долго концентрироваться на одной задаче, то очень скоро настанет конец его карьеры.

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

Блокировка развлекательных сайтов

«Cold Turkey» (http://getcoldturkey.com/)- программа для блокирования доступа к определенным сайтам в интернете. Серфинг в интернете – это один из основных способов потерять концентрацию. Вы сами знаете список ваших «любимых» сайтов. Заблокируйте их на время и спокойно работайте.

Screenshot

Медитация

Раньше я тоже думал, что это из области религиозных практик. Но в одной из книг по личностному росту медитация была одним из рецептов по повышению концентрации. Работает это так. Выберете 5-10 минут, когда никто вас не будет беспокоить. Удобно садитесь. Ваша задача не думать ни о чем кроме вашего дыхания. Отключите внутренний диалог. Считайте вдохи-выдохи. Главное, ни о чем не думать кроме дыхания. Как только появилась посторонняя мысль, возвращайтесь к дыханию. Сначала попробуйте 10 медленных вдохов-выдохов. Затем 20. 30 и т.д.

Отдых

Способность к концентрации значительно возрастает, если вы полноценно отдыхаете. То есть без компьютера и интернета. Прогулка на 15 минут после обеда. Выходные на природе.  Отпуск без ноутбука.

Спорт

Понятно, что даже при наличии абонемента в спортзал вы будите ходить туда не регулярно. Аврал, болезнь, свидание, встреча с друзьями и т.д. Заставить себя бегать по утрам каждый день хотя бы месяц почти невозможно.

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

По личному опыту, привычка делать утреннюю гимнастику (10 минут) встраивается за 3 месяца при достаточной мотивации. Если вам до дома от метро нужно ехать одну остановку, то лучше пройти пешком.

P.S. Так шаг за шагом можно вернуть власть над своим мозгом.

P.P.S. Я тоже лишь в начале это пути. Но каждый крохотный шаг приближает вас к цели.

Originally published at Практический подход к ИТ-архитектуре. You can comment here or there.

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

У каждого из нас есть не одна история о том, как в одной компании шел ИТ-проект. Менеджер, идеолог и архитектор в одном лице каждое утро хватал шашку, забирался на броневичок, и раздавал задания. «Ты делаешь то, ты это и т.д.».

Он хорошо знал предметную область, регулярно общался с бизнес-пользователями. Также проверял, что и как сделано и корректировал других участников проекта. «Делай не так, а вот так». Через несколько месяцев появлялась информационная система, которая после тестирования и отладки, была вполне работоспособна.  Результат есть, но при этом не было написано ни строчки документации.

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

Но факт остается фактом – документации нет, а  результат есть.

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

Документация есть, а  результатов нет.

Что же нужно, чтобы заставить документы работать?

Ответ: Люди, которые в рамках процессов и проектов будут выполнять целенаправленные действия по реализации идей, изложенных в этих документах, будут корректировать их для учета изменений в компании, будут присматривать за реализацией  и т.д.

Если результатом проекта будет документ и не запланированы другие проекты по реализации идей из этих документов, то результат будет нулевым.

Понимание этого  особенно важно для тех, кто работает над архитектурой предприятия.

Originally published at Практический подход к ИТ-архитектуре. You can comment here or there.

Получил письмо от IBM

Вчера в почтовом ящике обнаружил долгожданное письмо. Я уже отчаялся его получить, так как из-за бюджетного кризиса в США не работала почта, да и наша почта тоже не подарок.

SONY DSC

Когда вы получаете сертификат от IBM, то на электронную почту вам приходит электронный сертификат (e-Certificate). Другие вендоры (например Oracle, EXIN, PMI) присылают бумажный сертификат, пластиковую карточку или значок.

C недавнего времени, если у вас есть желание получить бумажный сертификат IBM, то вы можете заказать его на сайте IBM за символическую плату в $6.20. Плюс пересылка по обычной почте в $5.80 или экспресс-доставка через UPS за $29.95. Ещё сверху накинут налоги. Не помню сколько.

Я долго откладывал заказ бумажных сертификатов. И хочется побаловать свое эго, и колется.  И денег платить надо, и не факт, что доставят. Поэтому я заказал всего 3 сертификата из 10 имеющихся.

С обычной доставкой. Итого $26.56.

Что было в конверте?

IBM_Certs

Конверт из хорошего картона выглядел как заядлый путешественник. Потрепанный, но не помятый.  Внутри него была папка с сертификатами и пластиковыми карточками (wallet cards). За $6.20 вы получаете и то и другое. Отдельно купить нельзя.

Карточки понравились, особенно прозрачный логотип IBM.

Сертификаты сделаны на очень тонкой бумаге. Это разочаровало. Зато на них есть огромные блестящие печати с логотипом IBM :)

P.S. В некоторых случаях нужно иметь бумажный сертификат. Например, чтобы повесить на стенку в офисе. Или показать работодателю, который оплатил сдачу экзаменов и курсы.

P.P.S. Скорее всего, эта статья будет интересна только тем, кто сдавал экзамены IBM.

Originally published at Практический подход к ИТ-архитектуре. You can comment here or there.

Zachman Framework. Строки

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

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

  1. Идентификация (Identification). Сначала топ-менеджеры компании намечают границы изменения.  Они смотрят на него с высоты птичьего полета. В рамках интервью они очень эмоционально рассказывают свою идею. Больше продают, чем объясняют. Чтобы как-то формализовать изменение на этом этапе архитекторы готовят высокоуровневое описание рамок изменения. Например, описываются ключевые группы сущностей, которые участвуют в изменении, необходимы для него, на которые повлияет изменение и т.д.
  2. Определение (Definition). На этом этапе формируем описание того, как изменится бизнес компании для реализации этого изменения. Когда и как поменяется орг. структура, обязанности сотрудников, бизнес-процессы и т.д.
  3. Представление (Representation). Затем описываем, как изменится системы компании, обеспечивающие функционирования бизнеса. Важно отследить зависимость систем друг от друга, совместить их циклы развития со временем изменения и т.д.
  4. Спецификация (Specification).  Формируется подробное описание того, что и как нужно изменить в компонентах систем. Изменение кода инф. систем, спецификации на новое оборудование и куда оно будет установлено и т.д.
  5. Конфигурация (Configuration). На этом этапе выполняются работы по реализации изменения. Все, что нужно было выполнить, реализуем в нужной последовательности правильными людьми.
  6. Готовая система (Instantiation). Ура! Изменение внедрено. Проверяем, как оно повлияло на компанию.

P.S. Обычно в компании реализуется несколько изменений. Те из них, что зависят друг от друга надо объединять в программы (Program of projects) и воплощать совместно.

Originally published at Практический подход к ИТ-архитектуре. You can comment here or there.

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

Рукописные книги были уделом избранных. Тех, кто умел читать, уважали и боялись. Считалось, чтобы научиться читать нужны особые навыки, например усидчивость. То есть способность к концентрации.

В 15 веке был изобретен печатный станок. И это изменило мир. Книги стали доступны многим. И каждый находил в них что-то свое. Те, кто прочитал много книг, вызывали уважение и зависть многих людей. Умный и начитанный были синонимами.

Потом появились газеты и журналы. Они стали заменой слухов и сказок для городских жителей. Чтение газет не требовало активной работы мозга. Те же самые слухи только на бумаге. Для них не было нужды в длительной концентрации и глубоком погружении в тему. Поток информации становился все больше.

С появлением Интернета и Веб 2.0 поток информации стал огромным. Есть нужда в информации – найдет Google. Можно не читать книги, достаточно подписаться на несколько блогов по теме. Или периодически читать новости.  Или ленту друзей на Facebook. Или twitter L

Ой, прошло полдня, а ничего полезного не сделано.

Поток информации все больше, концентрацию удерживать всё труднее. Статью длиннее экрана вы скорее проскарируете, чем прочитаете. Сколько книг по специальности вы прочитали в этом году?

Мы перешли от модели «Один пишет, многие читают» к модели «Многие пишут, никто не читает».

Есть ли выход?

Начните с того, что читайте небольшие статьи по специальности. Например, на моем сайте. Маленькое дело, но каждый день.

P.S. Завтра будет следующая статья по Zachman Framework.

P.S.S. Статья написана по мотивам интервью Николоса Карра.

Originally published at Практический подход к ИТ-архитектуре. You can comment here or there.

Latest Month

April 2015
S M T W T F S
   1234
567891011
12131415161718
19202122232425
2627282930  

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Lilia Ahner