?

Log in

Zachman Framework. Столбцы

В одной из прошлых статьей мы говорили, что Zachman Framework – это матрица 6х6, в каждой из ячеек которой содержится уникальная модель или представление компании под определенным углом. Что же находится в столбцах знаменитой схемы Захмана? Захман предлагает посмотреть на компанию через призму определенных вопросов, освещающих компанию под определенным углом. Такой подход позволят гарантировать полный охват всех аспектов компании.

Вопрос Область Типы моделей
What (Что) Inventory Sets (Набор объектов) Сущности, важные для компании, и связи между ними.
Как (How) Process Flow (Процессы) Как работают процессы в компании.
Когда (When) Distribution Sets (Сети распространения) Где компания ведет бизнес. Где производит, куда поставляет и т.д.
Кто (Who) Responsibility Assignments (Распределение ответственности) Люди, их роли и их обязанности. Орг. Структура компании.
Где (Where) Time Cycles (Временные интервалы) События и временные циклы, важные для компании. Сезонность продаж, длительность производственного цикла и т. д.
Почему (Why) Motivation Intensions (Мотивирующие замыслы) Цели компании и её владельцев, стратегия компании и т.д.

Вот так, если кратко.

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

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

Википедия говорит, что

«Онтология — это попытка всеобъемлющей и детальной формализации некоторой области знаний с помощью концептуальной схемы. Обычно такая схема состоит из структуры данных, содержащей все релевантные классы объектов, их связи и правила (теоремы, ограничения), принятые в этой области. Этот термин в информатике является производным от древнего философского понятия «онтология».

Если по-простому, онтология – это структура (документы, рисунки и таблицы) для описания сложного объекта, такого как компания. Методология – это, прежде всего, набор процессов. Процессы, основанные на правильной структуре, дают гарантированный результат. Процессы без структуры дают непредсказуемый результат.

Соответственно, Zachman Framework – это основа для разработки описания архитектуры предприятия. В качестве основы для процессов стоит использовать другой фрейворк, например TOGAF.

P.S. Получилось немного заумно, но это важно для понимания фрейворка Закхмана.

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

Zachman Framework. Часть 1

В начале 80х годов прошлого века Джон Захман предложил идею, которая для ИТ-отрасли сравнима с Периодической Таблицей Менделеева. Он придумал первый фреймворк для описания сложных систем, таких как корпорация. Так сказать стал отцом Архитектуры Предприятия (Enterprise Architecture).

Захман соединил два подхода для решения аналитических задач, известные с древних времен:

  1. Набор основных вопросительных слов Что, Как, Когда, Кто, Где и Почему (What, How, When, Who, Where, and Why). На основе  ответов на эти вопросы можно построить всестороннее целостное описание сложных идей.
  2. Адаптированный процесс воплощения идей в жизнь, первоначально придуманный древнегреческими философами. Идентификация, Определение, Представление, Описание, Конфигурация и Реализация (Identification, Definition, Representation, Specification, Configuration and Instantiation).

Zachman Framework представляет собой матрицу 6х6, где столбцы соответствуют вопросительным словам, а строки этапам процесса воплощения идеи. Каждая ячейка содержит простую модель или представление предприятия.

В 2011 году была опубликована 3-я версия этого фреймворка. Вот она:

ZF3.0

 

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

 

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

Несерьёзный пост…

В блоге Дениса Запиркина прочитал статью «Эпоха работоспособности». Думаю, каждый из нас может рассказать историю, когда вам позарез нужны были какие-то сервисы, но вы их не могли получить из-за того, что

  1. «Программа не работает».
  2. «Компьютер сломался».
  3. «Не работает отправка…».
  4. «Программа это не умеет».

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

А через год, когда закрывал тот бизнес, я с таким уже не сталкивался. Все прошло, как по маслу.

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

Нельзя, просто так взять и уйти из ИТ.

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

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

Фрейворков для Архитектуры Предприятия разработаны десятки. В 90е не было проработанных методик, поэтому пионеры Архитектуры Предприятия разрабатывали свои собственные фреймворки. А сейчас каждый хвалит свое детище.  Вот несколько самых популярных:

  • Zachman Framework – первый и самый известный фрейворк. Его разработал Джон Захман – «отец» Архитектуры Предприятия.
  • Federal Enterprise Architecture Framework (FEAF) – фреймворк, разработанный одним из агенств Правительства США для всех структур Правительства США.
  • The Open Group Architecture Framework (TOGAF) – фреймворк, созданный международной организацией, в которую входят сотни известных компаний.
  • The SAP Enterprise Architecture Framework (EAF) – фреймворк, разработанный компанией SAP на основе TOGAF.
  • EA3 Cube Framework.

Если вам интересно познакомится с каждым из них, то рекомендую поискать в Википедии Enterprise Architecture Framework и дальше по ссылкам.

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

В 99% случаев ИТ-директор – спонсор архитектурной практики и архитектурных проектов. В чем его интерес? Что дает ИТ-Директору архитектурная практика?

Вот несколько причин для ИТ-директора поддержать архитектурную практику:

  1. Главный секрет хорошего управленца – это делегировать все, что можно, и все, что нельзя. Кто-то должен понять потребности бизнеса и увязать их с развитием ИТ. Чем больше компания, тем больше такой работы. Кто-то в ИТ-службе должен посещать совещания бизнес-подразделений, говорить с бизнесом на одном языке. Чем больше адекватных контактов между бизнесом и ИТ, тем больше поддержка со стороны бизнеса у ИТ и, как следствие, влияние ИТ-директора.
  2. ИТ-директору нужно видеть всю картину целиком. И при необходимости быстро получать детальную информацию в концентрированном виде. Он может либо сам собирать и структурировать информацию об бизнесе и ИТ, либо поручить эту работу кому-то другому.
  3. Ещё нужен советник или советники, с которыми можно обсудить технические решения и которые помогут контролировать их реализацию. Они должны хорошо ориентироваться в технологиях и бизнесе. Понимать, как устроена и чем живет ваша компания. И не претендовать на место ИТ-директора. Корпоративные архитекторы отлично для этого подходят.
  4. Для ИТ-директора важно удержать лучших технарей. Они уже добились максимума в своей области. Чтобы они не заскучали и не уволились, вы дадите им ещё одну ступеньку для роста. Сделаете их архитекторами. Хорошие специалисты в дефиците. А их увольнение всегда проблема.
  5. Четкое понимание бизнеса и роли ИТ в нем, перспектив развития, актуальных проблем компании значительно облегчает формирование и обоснование ИТ-бюджета, продвижение ИТ-проектов.
  6. Во всех книгах по управлению рекомендуют работать над управлением рисками. Это требует огромного количества времени, ресурсов, управленческих усилий и … информации. Без глубокого понимания, как действительно работает ИТ, управление рисками – фикция.

 

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

Из предыдущих статей вы узнали основные задачи, которые можно решить методами Архитектуры Предприятия (Enterprise Architecture или Корпоративная Архитектура).

Насколько они актуальны для вашей компании?

Даже если очень актуальны, у вас могут быть законные вопросы:

  • Нужна ли Архитектура Предприятия в вашей компании прямо сейчас, или стоит подождать?
  • Стоит ли тратить время и ресурсы на внедрение её методов?
  • Может быть, все ваши проблемы можно решить какими-то другими способами?

Это важные и правильные вопросы. У любой управленческой задачи всегда есть несколько решений. И Архитектура Предприятия лишь одно из них. Более того, она нужна не всем компаниям.

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

Какие компании получат от Архитектуры Предприятия максимальную ценность?

Оцените вашу компанию по следующим критериям:

  1. Вашу компанию можно отнести к крупному или среднему бизнесу. До тех пор, пока все технологии компании со всеми подробностями помещаются в одной голове, об Архитектуре Предприятия думать рано. Для малого бизнеса Архитектура Предприятия как пятое колесо.
  2. Бизнес компании зависит от ИТ. Если в вашей компании многие бизнес-процессы завязаны на ИТ. И развитие бизнеса невозможно без быстрой и качественной доработки ИТ. Есть целые отрасли, которые зависят от ИТ: банки, страховщики, прочие финансисты, сервисные компании, госорганы, технологические компании, энергетика, транспорт, производство и т. д.
  3. Компания активно развивает ИТ. Если в компании идет более 5-7 ИТ-проектов или хотя бы один проект по внедрению ERP или CRM, то Архитектура Предприятия спасет от большей части переделок, ошибок, несостыковок, задержек и прочих проблем, связанных с межпроектным взаимодействием. У кого-то должна быть общая картинка будущего и понимание процесса развития. Иначе кусочки пазла, созданные в разных проектах, не сойдутся. Важно, чтобы такой человек в компании был не один.
  4. У компании периодически происходят кризисы в ИТ.
    •  Не все ИТ-проекты заканчиваются успешно, уложившись в сроки и бюджет. Если руководство вашей компании устало от провалов, задержек, превышения бюджетов ИТ-проектов, то стоит задуматься о внедрении Архитектуры Предприятия.
    • В информационных системах происходят сбои, которые негативно влияют на   бизнес. Вплоть до остановки бизнес-процессов. Сбои вызваны проблемами в интеграции, просчетами в инфраструктурных решениях, временными решениями и просто бардаком.
  5. Компании важна скорость, качество и эффективность развития ИТ. Есть компании, чей бизнес развивается со скоростью во много раз быстрее, чем привыкли айтишники. И ИТ становятся тормозом в развитии компании. Без гармоничного развития всех элементов компании тяжело лететь вперед. Представьте себе, в вашу карету впрягли двух коней и гигантскую черепаху. С чьей скоростью будет двигаться ваша карета?

Если из пяти критериев для вашей компании справедливы хотя бы три, сейчас самое время задуматься о внедрении Корпоративной Архитектуры.

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

Некоторые архитекторы ругают TOGAF за сложность. Действительно, когда сталкиваешься
с этим фреймворком впервые, он кажется нагромождением идей и методик. Сразу же куча вопросов.

  • Что из этого всего нужно в вашей компании? А что не нужно?
  • Нужно ли писать кучу документов, или не нужно?
  • И т.д.

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

К тому же, сложные проблемы не имеют простых решений. Поэтому не стоит искать «волшебную таблетку», там где её нет. Более того архитекторам платят деньги, чтобы они разбирались со сложными вещами. Но многим лень.

Так что засучиваем рукава и вперед. Копать! В смысле, разбираться, адаптировать, внедрять и т.д.

P.S. Не хотите сами, наймите консультанта, например меня :)

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

Умные учатся на своих ошибках, мудрые на чужих, а дураки совсем не учатся.
Как ИТ-архитектор, вы будете совершать ошибки и получать за них … обратную связь от руководства. От этого никуда не денешься. Это часть процесса вашего обучения и саморазвития. Но тот кто предупрежден, тот вооружен.
За прошедшие две недели вы познакомились с 7 критическими ошибками ИТ-Архитектора.

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

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

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

Если сервер, то самый лучший IBM P795. Если ERP, то SAP со всеми опциями. Хотя можно обойтись более простым решением. Но перфекционизм заставляет выбирать самое дорогое. Нужно же сделать все по-правильному. С первого раза.

Посмотрите, как делает свои датацентры Google и Amazon. Много дешевого железа. Бесплатный софт. Двукратное и трехкратное резервирование.

Google создает первые версии своих продуктов. Смотрит, как на них реагирует рынок. И решает их дальнейшую судьбу. Либо развивает, либо убивает.

Понятно, что хочется сделать все по-правильному с первого раза. Но так не бывает. Без пилотов и постепенного улучшения тяжело получить рабочее решение.

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

 

 

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