Нужно принимать во внимание потенциальный конфликт интересов "Заказчик - Аутсорсер". Аутсорсер может напринимать ТАКИХ архитектурных решений, что потом Заказчик окажется навсегда к нему привязан ))
возникло устойчивое ощущение, что они не предлагают никакого конкретного решения, подходящего для любых предприятий, а следовательно не имеют особой ценности.
У кого возникло это "устойчивое ощущение"? У автора статьи? А автор статьи пробовал применять TOGAF в реальных бизнес-кейсах? Может быть он тогда напишет что именно ему не понравилось TOGAF по сравнению с IAF?
Математики давно доказали, что в общем случае можно оптимизировать только одну цель. Остальные цели в задаче оптимизации нужно рассматривать как ограничения. У всех персонажей этого кейса должна быть ОДНА общая цель. Допустим мы ставим цель - максимизировать стоимость компании при условиях "ограничение1"..."ограничениеN". Если правильно моделировать мотивационный слой, то надуманый конфликт, описанный выше, просто исчезнет.
А почему у вас на рисунках "Корпоративная архитетекрута" отдельно, а цели и задачи, функции, процессы отдельно? Цели, Способности (=capabilities), Процессы - это тоже часть EA (я бы сказал что это главная ее часть )). Начинать создание EA нужно, ИМХО, не с анализа ИТ-ландшафта, а с анализа целей предприятия и его способностей достигать эти цели. И только потом опускаться на уровень ИТ-решений и смотреть а чего же там можно добавить\изменить, чтобу улучшить способности компании достигать ее цели. Практически во всех кейчах по созданию EA, которые попдалаись мне на глаза, телегу ставять впередли лошади. Начинают с описание и оптимизации ИТ-решений и инфраструктуры, совершенно забывая о бизнес-слое.
— Скажите, пожалуйста, куда мне отсюда идти? (какие ИТ-решения мне нужны?) — А куда ты хочешь попасть? — ответил Кот. (А какие цели и способы их достижения есть у твоей компании?) — Мне все равно... — сказала Алиса. (Я это не анализировала) — Тогда все равно, куда и идти, — заметил Кот. (Тогда тебе подойдут любые ИТ-решения или их отстуствие)
Поэтому первыми задачами центра Enterprise-архитектуры мы увидели: ...
Вот так всегда - начинают строить EA с ИТ-решений и технологий. Ставт телегу впереди лошади. Начинать нужно, ИМХО, с определения иерерхического "дерева" целей компании и перечня ее способностей эти цели достигать (=capabilities).
Хорошо бы в названии статьи сразу указывать о КАКОЙ именно архитектуре пойдет речь. TOGAF говорит нам, что бывают разные архитектуры: Enterprise Architecture, Business Architecture, Data Architecture, Solution Architecture, Infrastructure Architecture
Откуда вы взяли картинку "Пример подхода Звезды Кимбалла"? (Правило хорошего тона - указывать источники картинок). У Кимбалла нет единого EDW в 3-й нормальной форме. Данные из источников попадают в промежуточную область а затем в многомерные хранилища (в виде звезд или снежинок). Эти хранилища используют унифицированную модель измерений. А вот у Инмона есть "единый источник правды" в виде нормализованного EDW.
CRM — прежде всего инструмент. Чтобы он эффективно работал, компании нужна стратегия его использования.
Статегия использования инструмента? Интересно! Выходит, чтобы эффективно работать, столяру нужна стратегия использования рубанка? А уборщице стратегии использования веника и швабры? ))
Нужно принимать во внимание потенциальный конфликт интересов "Заказчик - Аутсорсер". Аутсорсер может напринимать ТАКИХ архитектурных решений, что потом Заказчик окажется навсегда к нему привязан ))
что у вас в тексте значит символ "
<="а) меньше или равно?
б) следует?
У кого возникло это "устойчивое ощущение"? У автора статьи?
А автор статьи пробовал применять TOGAF в реальных бизнес-кейсах? Может быть он тогда напишет что именно ему не понравилось TOGAF по сравнению с IAF?
Дайте, пожалуйста, ссылку на место в TOGAF где такое написано.
Когда читаешь такую статью ни о чем - отпадает всякое желание посещать ваши занятия.
Раз статья сполошная "вода", то наверное и занятия тоже.
OTUS , лучше писать пару качественных статей в месяц, чем вот такую "воду" ни о чем каждый день.
Отдавать принятие архитектурных решений на откуп аутсорсеру???
Двойка ИТ-директору "Спортмастера"!
Математики давно доказали, что в общем случае можно оптимизировать только одну цель. Остальные цели в задаче оптимизации нужно рассматривать как ограничения. У всех персонажей этого кейса должна быть ОДНА общая цель. Допустим мы ставим цель - максимизировать стоимость компании при условиях "ограничение1"..."ограничениеN".
Если правильно моделировать мотивационный слой, то надуманый конфликт, описанный выше, просто исчезнет.
Да кто ж пропускате на хабр такие статьи??? Слов много - а пользы ноль!
А почему у вас на рисунках "Корпоративная архитетекрута" отдельно, а цели и задачи, функции, процессы отдельно? Цели, Способности (=capabilities), Процессы - это тоже часть EA (я бы сказал что это главная ее часть )). Начинать создание EA нужно, ИМХО, не с анализа ИТ-ландшафта, а с анализа целей предприятия и его способностей достигать эти цели. И только потом опускаться на уровень ИТ-решений и смотреть а чего же там можно добавить\изменить, чтобу улучшить способности компании достигать ее цели.
Практически во всех кейчах по созданию EA, которые попдалаись мне на глаза, телегу ставять впередли лошади. Начинают с описание и оптимизации ИТ-решений и инфраструктуры, совершенно забывая о бизнес-слое.
— Скажите, пожалуйста, куда мне отсюда идти? (какие ИТ-решения мне нужны?)
— А куда ты хочешь попасть? — ответил Кот. (А какие цели и способы их достижения есть у твоей компании?)
— Мне все равно... — сказала Алиса. (Я это не анализировала)
— Тогда все равно, куда и идти, — заметил Кот. (Тогда тебе подойдут любые ИТ-решения или их отстуствие)
Вот так всегда - начинают строить EA с ИТ-решений и технологий. Ставт телегу впереди лошади. Начинать нужно, ИМХО, с определения иерерхического "дерева" целей компании и перечня ее способностей эти цели достигать (=capabilities).
Кроме Netaca есть еще Tetrad
About Tetrad - Tetrad - Department of Philosophy - Carnegie Mellon University (cmu.edu)
Кроме "Протеже" есть другие смециализированные моделеры?
С помощью каких инструментов можно создавать онтологии?
Третья часть о байесовском выводе все еще планируется к публикации?
Хоть бы какие-то МДМ-системы перечислили ((
Хорошо бы в названии статьи сразу указывать о КАКОЙ именно архитектуре пойдет речь.
TOGAF говорит нам, что бывают разные архитектуры: Enterprise Architecture, Business Architecture, Data Architecture, Solution Architecture, Infrastructure Architecture
Откуда вы взяли картинку "Пример подхода Звезды Кимбалла"? (Правило хорошего тона - указывать источники картинок). У Кимбалла нет единого EDW в 3-й нормальной форме. Данные из источников попадают в промежуточную область а затем в многомерные хранилища (в виде звезд или снежинок). Эти хранилища используют унифицированную модель измерений.
А вот у Инмона есть "единый источник правды" в виде нормализованного EDW.
"fabric" - это ткань или структура, а не фабрика. При неправильном переводе смысл термина "data fabric" теряется.
Статегия использования инструмента? Интересно!
Выходит, чтобы эффективно работать, столяру нужна стратегия использования рубанка? А уборщице стратегии использования веника и швабры? ))