Наверное, я ещё не дорос до понимания энтерпрайзных решений. Вижу
мы поэтапно рассмотрим, как формировалась система управления знаниями
и приготовился в статье по этим самым этапам наблюдать формирование системы. Какие-то довольно общие абзацы, модное "единая цифровая среда" и т.п. И бац (выделение моё):
мы выбрали для импортозамещения российскую платформу TEAMLY, которая отвечает всем этим требованиям
Т.е. вся ваша система выродилась в покупку софта, который даже адаптировать не пришлось, потому что оно отвечает всем требованиям? Ещё. Я не верю, что готовый сторонний сложный продукт прямо на входе "отвечает всем этим требованиям". Чудеса прям. Что-то тут не так, мутная статья какая-то. (наивно) Ах, неужели рекламная?!
Вижу результат в виде описания полезных методов. Делай хорошо, не делай плохо. А есть формализованный результат? Например, статья началась с чек-листа. В итоге, что с ним?
Или я неправильно понял смысл статьи, и это просто повествование?
Не очень нравится "Общая схема при проектировании". На мой взгляд, решение об использовании API принимается для системных требований, а не функциональных. Но тут, наверное, просто формулировки не совсем точные, а смысл понятен
Как минимум, п.1 - Анализ бизнес-требований - не является шагом по проектированию API. Пункты 2 и 3, скорее всего, тоже. Доказательство от противного: в результате анализа БТ архитектор принял решение убрать пару микросервисов в один сервис. И где здесь проектирование API?
API - лишь один из способов реализации технических (системных) требований системы, а не бизнес-требований. Как вариант (не универсально): БТ - Функц.Т - СистемныеТ - арх.решение, и потом только начинается проектирование API. В вашем примере - это где-то после п.3 (который необязательно реализуется именно API)
(спасибо за шаг навстречу пожеланиям трудящихся! ) )
С первым понятно, что это часть анализа проекта, ценность именно для проекта. Повторюсь, на мой субъективный взгляд, IDEF0 не для заказчика (но для отчётных доков - да, для солидности).
(Всё ждал третьего "SAP сбежал", но не случилось. Шутка)
На шаге 2.
Есть: Вы рисуете IDEF0, зачем-то показываете её заказчику, который её не понимает. Ок, понятно, что про рабочее взаимодействие с заказчиком не думаем. Ну хоть формально что-то показали
Должно быть: Всё классно, но где артефакт, который вы покажите заказчику как результат анализа? Не увидел / не понял
О, а на шаге 4 зачем показывать заказчику системный анализ, в чём прикол заказчику в этом знании, тем более, утверждении решения для кодинга?
Прочитал только самое первое предложение и не понял, зачем автор вообще создал статью. Достаточно посмотреть на описание вакансий - в 95% открыто декларируются требования (необязательно со словами "БА/СА"), что нужны БА с СА и СА с БА. Неужели статью быстрее было написать? Или цель статьи другая, но автор не смог её сформулировать?
Спасибо за статью. Интересно посмотреть решение управления требованиями в данном случае. Когда заказчиков (у вас - кураторов) больше одного, то в проектах часто вижу бардак. Осторожно отношусь к методам оценок, где требуются веса. Тут и сами критерии надо правильно подобрать, а потом ещё и угадать с весом каждого. С другой стороны, если работает, значит, решение жизнеспособно.
В workflow Jira "ожидание заверения" - это приёмка заказчиком (куратором)? Всеми или чьё требование было? Из текста не понял
К кругу вопросов и задач, которые стоят перед EA можно отнести:
Определение и решение об оборудовании, на котором будет работать приложение и/или его части.
EA лично выбирает оборудование? Это же отдельная большая область знаний, есть специально обученные (без иронии) инженеры, в этих железках очень много нюансов. И выбор оборудование обычно должен идти после (или итерационно) с "выбором SA фреймворков"
Для большинства работников IT (и не IT тоже) системное мышление - хард скилл. Точно для аналитиков, архитекторов.
Если определение термина не противоречит логике, уже хорошо. Невозможно раз и навсегда дать определение таким терминам, они и сложные, и постепенно меняется их наполнение. Системное мышление - целыми курсами преподают, как это уложить в строчку-две? Никак
Сначала пытался понять, чек-лист ТЗ - валидация на что тут? На соответствие БТ, на "качество" (по критериям) самого дока? Не понял.
Потом увидел, что
для повышения качества постановок на разработку (и, в основном, для сокращения поступающих вопросов от коллег :)) я сформировала свой чек-лист того, что необходимо учитывать в ТЗ
Тут уже попытался понять, что такое "ТЗ" в статье. Судя по всему, здесь это синоним постановки на разработку. На мой взгляд, так не надо делать. ТЗ в мире разработки ИС - вполне конкретный вид документа, формализован в различных методиках, стандартах.
Ну и, честно говоря, вижу изобретение велосипеда, причём неотшлифованного. Есть модели документирования разработки ИС, от бизнес-целей до каких-нибудь эксплуатационных на готовый продукт. Соответственно, есть методики валидации этих доков. В данном случае, странно видеть в чек-листе то, что должно быть описано (формализовано) до постановки на разработку. Чек-лист постановки - это, фактически, трассировка задач в постановке требованиям на функциональность
Слишком общая статья. Интерпретация/компиляция существующих материалов. Русский язык такой, что приходится продираться через нагромождение конструкций в поисках смысла. Что мешает быть проще? Вы там в SimbirSoft на таком же языке внутренние доки/артефакты делаете, что ли?
Зачем сначала описывать второй по счёту подход (Code First), а затем первый? Ну так бы и перечислили в нужном порядке
Честно говоря, пока для себя не понял, чем отличается Code First от Design First. В первом случае также есть дизайн контракта API перед кодингом: "An API code first approach doesn’t mean that you won’t have an API design". Попозже поизучаю оригинал )
Всё-таки, прежде чем употреблять аббревиатуру, необходимо один раз в начале текста полностью прописать её расшифровку. НСИ - широкоупотребимая, но не все с ней часто сталкиваются, не у всех на слуху.
Раздел "Какие данные стоят дорого?" - в топку. Его надо или подробно, или не надо совсем. Кто занимается оценкой данных для бизнеса - это лишние словеса. Кто не занимается - невозможно в нескольких параграфах обзорно раскрыть подтему. А тема - про управление/владение данными, а не про их оценку.
Надеюсь, читатели здесь с критическим мышлением, и не воспринимают 1:1 постулаты "Топ типовых ошибок ..". Например, хотелось бы посмотреть на ИС, которая обходится без дубликатов данных, особенно коммерческая.
Вопрос автору. В "Низкое качество данных = потеря денег" есть такое
...1000 из 5000 сотрудников банка было занято подготовкой отчетов вручную и исправлением ошибок и несоответствий в справочниках
4.1. Какое (прямое) отношение подготовка отчётов вручную имеет к качеству данных? Это вопрос к качеству системы, хранящей в нужной структуре и обрабатывающей эти данные. А не к качеству данных
4.2. Предложите свой вариант, где ошибки и несоответствия в справочниках устранялись бы не вручную. Очень интересно увидеть такое решение
В "Основные данные (НСИ)" есть такое:
нормативно-справочная информация (НСИ) или основные данные (master data)
(о, вот и расшифровка аббревиатуры. Не прошло и полстатьи).
5.1. Если master data - основные данные, то как тогда у вас называются неосновные данные? Вы уверены, что master data - это основные данные?
5.2. Вы уверены, что НСИ являются основными данными для ИС? Вы много видели систем, основная задача которых является работа с "относительно неизменными" данными?
В "Оптимальный путь управления НСИ"
6.1. приведены типы НСИ с их +/-, но нет никакого описания, что значат эти названия. Что такое "Аналитическая НСИ"? Почему "Аналитическая НСИ" не может быть "Централизованной", а "Централизованная" - "Гармонизированной"? Честное слово, ничего не понял
6.2. "Централизованная НСИ" - "Единая версия правды". Расскажите это архитекторам ИС. Я, конечно, понимаю, что речь про верхний логический уровень. Но см. мой п.3. В физически распределённых системах, насколько помню, недостижимо 100% идентичности данных в каждый момент времени. Поэтому применяют целый ряд (недешёвых) механизмов, от встроенных в БД до изворотов в бизнес-логике ИС, позволяющих приблизиться к этой "единой версии правды"
6.3. Про Уровень 2
Следующий слой – корпоративное хранилище данных (КХД, DWH), где хранятся необходимые для работы различных бизнес-систем данные. Система НСИ находится именно в этом слое, где она обеспечивает доступность этих данных, их актуальность, качество и правильную структуру.
Если у вас НСИ находится в хранилище, то беда вашей ИС. В хранилище хранят данные НСИ, а не НСИ. (Не, вы, конечно, можете забабахать всю логику НСИ в БД, но... лучше пусть про это расскажут более специалисты, чем я). НСИ - это полноценная, со своей бизнес-логикой, система по работе с данными. Ей место в вашем Уровне 3. Ну если, конечно, ваша НСИ - не табличка в Excel (не, тут я не прав, в Excel , при желании, можно сделать полноценную НСИ, но тут про целесообразность).
6.4. А что вообще эти "Уровни"? Уровни чего? Это же иерархические уровни, правда? Тогда каким образом одна группа потребителей данных (у вас Уровень 1) внезапно болтается где-то под Хранилищем, а другая группа (Уровень 3) - восседает над Хранилищем? Где логика?
В "Разберем пример проекта..." не понял, куда вы дели 3 системы-источника для вашей НСИ (вы же не сказали, источники чего - пусть будут для НСИ). Как вы можете объединить источники, если, скорее всего, вы даже не их владелец?
Итого по всей статье. Ощущение, что или автор порой не различает данные (хранение, БД/СУБД), их представление для потребителей (управление, СУБД) и систему-потребителя данных (НСИ), а также некоторые логики ИС, и перегрузил монструозным маркетингом статью, или что я не владею особой терминологией и логикой НСИ, поэтому много чего не понимаю тут.
Всё, что я хотел показать и сказать, сделал в 1-м комменте. Извините, нет времени на перефразирование
Наверное, я ещё не дорос до понимания энтерпрайзных решений.
Вижу
и приготовился в статье по этим самым этапам наблюдать формирование системы.
Какие-то довольно общие абзацы, модное "единая цифровая среда" и т.п. И бац (выделение моё):
Т.е. вся ваша система выродилась в покупку софта, который даже адаптировать не пришлось, потому что оно отвечает всем требованиям?
Ещё. Я не верю, что готовый сторонний сложный продукт прямо на входе "отвечает всем этим требованиям". Чудеса прям. Что-то тут не так, мутная статья какая-то. (наивно) Ах, неужели рекламная?!
Пока не выполнена валидация требований, в т.ч. зависимости, за API браться не надо. И не надо будет возвращаться к требованиям при проектировании API
Что не так?
Было бы замечательно формулировать заголовки, исключающий двоякое прочтение
В BPMN - моделируем BPM
В BPMS - применяем разработанную модель BPM
Верно?
Вижу результат в виде описания полезных методов. Делай хорошо, не делай плохо.
А есть формализованный результат? Например, статья началась с чек-листа. В итоге, что с ним?
Или я неправильно понял смысл статьи, и это просто повествование?
Домен (модель всего продукта) должен иметь свой ограниченный контекст?
"Сегодня" существуют ИБП и мобильный инет.
(Не спец, но вроде и без инета можно обилечивать)
Спасибо за ответ, стало понятнее
Не очень нравится "Общая схема при проектировании".
На мой взгляд, решение об использовании API принимается для системных требований, а не функциональных. Но тут, наверное, просто формулировки не совсем точные, а смысл понятен
Как минимум, п.1 - Анализ бизнес-требований - не является шагом по проектированию API. Пункты 2 и 3, скорее всего, тоже.
Доказательство от противного: в результате анализа БТ архитектор принял решение убрать пару микросервисов в один сервис. И где здесь проектирование API?
API - лишь один из способов реализации технических (системных) требований системы, а не бизнес-требований.
Как вариант (не универсально): БТ - Функц.Т - СистемныеТ - арх.решение, и потом только начинается проектирование API. В вашем примере - это где-то после п.3 (который необязательно реализуется именно API)
За подробный пример API - спасибо
(спасибо за шаг навстречу пожеланиям трудящихся! ) )
С первым понятно, что это часть анализа проекта, ценность именно для проекта. Повторюсь, на мой субъективный взгляд, IDEF0 не для заказчика (но для отчётных доков - да, для солидности).
Т.е. USM, ок. Спасибо за ответ
(Всё ждал третьего "SAP сбежал", но не случилось. Шутка)
На шаге 2.
Есть: Вы рисуете IDEF0, зачем-то показываете её заказчику, который её не понимает. Ок, понятно, что про рабочее взаимодействие с заказчиком не думаем. Ну хоть формально что-то показали
Должно быть: Всё классно, но где артефакт, который вы покажите заказчику как результат анализа? Не увидел / не понял
О, а на шаге 4 зачем показывать заказчику системный анализ, в чём прикол заказчику в этом знании, тем более, утверждении решения для кодинга?
Прочитал только самое первое предложение и не понял, зачем автор вообще создал статью.
Достаточно посмотреть на описание вакансий - в 95% открыто декларируются требования (необязательно со словами "БА/СА"), что нужны БА с СА и СА с БА. Неужели статью быстрее было написать? Или цель статьи другая, но автор не смог её сформулировать?
Спасибо за статью. Интересно посмотреть решение управления требованиями в данном случае. Когда заказчиков (у вас - кураторов) больше одного, то в проектах часто вижу бардак.
Осторожно отношусь к методам оценок, где требуются веса. Тут и сами критерии надо правильно подобрать, а потом ещё и угадать с весом каждого. С другой стороны, если работает, значит, решение жизнеспособно.
В workflow Jira "ожидание заверения" - это приёмка заказчиком (куратором)? Всеми или чьё требование было? Из текста не понял
Одно смутило:
EA лично выбирает оборудование? Это же отдельная большая область знаний, есть специально обученные (без иронии) инженеры, в этих железках очень много нюансов.
И выбор оборудование обычно должен идти после (или итерационно) с "выбором SA фреймворков"
Для большинства работников IT (и не IT тоже) системное мышление - хард скилл. Точно для аналитиков, архитекторов.
Если определение термина не противоречит логике, уже хорошо. Невозможно раз и навсегда дать определение таким терминам, они и сложные, и постепенно меняется их наполнение. Системное мышление - целыми курсами преподают, как это уложить в строчку-две? Никак
Сначала пытался понять, чек-лист ТЗ - валидация на что тут? На соответствие БТ, на "качество" (по критериям) самого дока? Не понял.
Потом увидел, что
Тут уже попытался понять, что такое "ТЗ" в статье. Судя по всему, здесь это синоним постановки на разработку.
На мой взгляд, так не надо делать. ТЗ в мире разработки ИС - вполне конкретный вид документа, формализован в различных методиках, стандартах.
Ну и, честно говоря, вижу изобретение велосипеда, причём неотшлифованного.
Есть модели документирования разработки ИС, от бизнес-целей до каких-нибудь эксплуатационных на готовый продукт. Соответственно, есть методики валидации этих доков.
В данном случае, странно видеть в чек-листе то, что должно быть описано (формализовано) до постановки на разработку. Чек-лист постановки - это, фактически, трассировка задач в постановке требованиям на функциональность
Слишком общая статья. Интерпретация/компиляция существующих материалов.
Русский язык такой, что приходится продираться через нагромождение конструкций в поисках смысла. Что мешает быть проще? Вы там в SimbirSoft на таком же языке внутренние доки/артефакты делаете, что ли?
Зачем сначала описывать второй по счёту подход (Code First), а затем первый? Ну так бы и перечислили в нужном порядке
Честно говоря, пока для себя не понял, чем отличается Code First от Design First. В первом случае также есть дизайн контракта API перед кодингом: "An API code first approach doesn’t mean that you won’t have an API design". Попозже поизучаю оригинал )
С одной стороны, серьёзный и полезный обзор НСИ.
С другой, есть сомнения:
Всё-таки, прежде чем употреблять аббревиатуру, необходимо один раз в начале текста полностью прописать её расшифровку. НСИ - широкоупотребимая, но не все с ней часто сталкиваются, не у всех на слуху.
Раздел "Какие данные стоят дорого?" - в топку. Его надо или подробно, или не надо совсем. Кто занимается оценкой данных для бизнеса - это лишние словеса. Кто не занимается - невозможно в нескольких параграфах обзорно раскрыть подтему. А тема - про управление/владение данными, а не про их оценку.
Надеюсь, читатели здесь с критическим мышлением, и не воспринимают 1:1 постулаты "Топ типовых ошибок ..". Например, хотелось бы посмотреть на ИС, которая обходится без дубликатов данных, особенно коммерческая.
Вопрос автору. В "Низкое качество данных = потеря денег" есть такое
4.1. Какое (прямое) отношение подготовка отчётов вручную имеет к качеству данных? Это вопрос к качеству системы, хранящей в нужной структуре и обрабатывающей эти данные. А не к качеству данных
4.2. Предложите свой вариант, где ошибки и несоответствия в справочниках устранялись бы не вручную. Очень интересно увидеть такое решение
В "Основные данные (НСИ)" есть такое:
(о, вот и расшифровка аббревиатуры. Не прошло и полстатьи).
5.1. Если master data - основные данные, то как тогда у вас называются неосновные данные?
Вы уверены, что master data - это основные данные?
5.2. Вы уверены, что НСИ являются основными данными для ИС?
Вы много видели систем, основная задача которых является работа с "относительно неизменными" данными?
В "Оптимальный путь управления НСИ"
6.1. приведены типы НСИ с их +/-, но нет никакого описания, что значат эти названия.
Что такое "Аналитическая НСИ"? Почему "Аналитическая НСИ" не может быть "Централизованной", а "Централизованная" - "Гармонизированной"? Честное слово, ничего не понял
6.2. "Централизованная НСИ" - "Единая версия правды". Расскажите это архитекторам ИС. Я, конечно, понимаю, что речь про верхний логический уровень. Но см. мой п.3. В физически распределённых системах, насколько помню, недостижимо 100% идентичности данных в каждый момент времени. Поэтому применяют целый ряд (недешёвых) механизмов, от встроенных в БД до изворотов в бизнес-логике ИС, позволяющих приблизиться к этой "единой версии правды"
6.3. Про Уровень 2
Если у вас НСИ находится в хранилище, то беда вашей ИС.
В хранилище хранят данные НСИ, а не НСИ. (Не, вы, конечно, можете забабахать всю логику НСИ в БД, но... лучше пусть про это расскажут более специалисты, чем я).
НСИ - это полноценная, со своей бизнес-логикой, система по работе с данными. Ей место в вашем Уровне 3. Ну если, конечно, ваша НСИ - не табличка в Excel (не, тут я не прав, в Excel , при желании, можно сделать полноценную НСИ, но тут про целесообразность).
6.4. А что вообще эти "Уровни"? Уровни чего? Это же иерархические уровни, правда? Тогда каким образом одна группа потребителей данных (у вас Уровень 1) внезапно болтается где-то под Хранилищем, а другая группа (Уровень 3) - восседает над Хранилищем? Где логика?
В "Разберем пример проекта..." не понял, куда вы дели 3 системы-источника для вашей НСИ (вы же не сказали, источники чего - пусть будут для НСИ). Как вы можете объединить источники, если, скорее всего, вы даже не их владелец?
Итого по всей статье. Ощущение, что
или автор порой не различает данные (хранение, БД/СУБД), их представление для потребителей (управление, СУБД) и систему-потребителя данных (НСИ), а также некоторые логики ИС, и перегрузил монструозным маркетингом статью,
или что я не владею особой терминологией и логикой НСИ, поэтому много чего не понимаю тут.