Вижу результат в виде описания полезных методов. Делай хорошо, не делай плохо. А есть формализованный результат? Например, статья началась с чек-листа. В итоге, что с ним?
Или я неправильно понял смысл статьи, и это просто повествование?
Не очень нравится "Общая схема при проектировании". На мой взгляд, решение об использовании 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 системы-источника для вашей НСИ (вы же не сказали, источники чего - пусть будут для НСИ). Как вы можете объединить источники, если, скорее всего, вы даже не их владелец?
Итого по всей статье. Ощущение, что или автор порой не различает данные (хранение, БД/СУБД), их представление для потребителей (управление, СУБД) и систему-потребителя данных (НСИ), а также некоторые логики ИС, и перегрузил монструозным маркетингом статью, или что я не владею особой терминологией и логикой НСИ, поэтому много чего не понимаю тут.
Честно пытаюсь понять, что такое API-first, но не могу.
...API-First. Это когда сначала проектируются API, а уже потом — сам сервис/система, форматы и правила описания этих самых API
Что тогда такое - проектирование API? Почему форматы и правила описания вынесены за пределы проектирования? Итого, что должно быть первым в таком подходе?
Что означает эта фраза?
Я head профессии по системному анализу
Глава по профессии? Ведущий в профессии? Быть head внутри компании внутри какого-то структурного подразделения или направления - понятно. Но как это - во всей профессии? Не могу понять смысл
В целом, сплошной текст тяжело воспринимается. Полезно было бы основные мысли отобразить визуально. Тот же процесс API-first, например
А мне, как ни странно, статья понравилась ) Тоже против солянок. Но тут выглядит как простое и доступное изложение, как аналитику выполнить интеграцию, от бизнес-целей (о чём некоторые мидлы и сеньоры почему-то забывают) до основных паттернов технических решений. Этакий быстрый справочник
В своём примере - "заказчик может прийти с требованием хочу показать людям сколько идти до ближайшено отделения почты" - это уже можно (с некоторой натяжкой, конечно, но) считать потребностью бизнеса. И следует (а не идёт в начале!) ваше решение - "эти данные забрать из Яндекс api".
А бизнес ваша реализация не интересует, бизнесу надо понимать дебет/кредит и время. Будет это интеграция, или прогнать 100500 человек по городу - ему без разницы.
Ещё раз: бизнесу не нужна никакая интеграция - ни новая, ни старая, ни ещё какая-либо. Ему нужно решение для своих целей. Интеграция - лишь вариант реализации
Ура. Теперь можно выкинуть все толстенные талмуды по системному дизайну, а также по требованиям к системе (зачем они, ведь вот же готовый дизайн на "всё"). Мы получили то, о чём втайне мечает каждый спец в своей области - универсальную таблетку на все случаи жизни. Всех архитекторов можно смело увольнять
Вижу результат в виде описания полезных методов. Делай хорошо, не делай плохо.
А есть формализованный результат? Например, статья началась с чек-листа. В итоге, что с ним?
Или я неправильно понял смысл статьи, и это просто повествование?
Домен (модель всего продукта) должен иметь свой ограниченный контекст?
"Сегодня" существуют ИБП и мобильный инет.
(Не спец, но вроде и без инета можно обилечивать)
Спасибо за ответ, стало понятнее
Не очень нравится "Общая схема при проектировании".
На мой взгляд, решение об использовании 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 системы-источника для вашей НСИ (вы же не сказали, источники чего - пусть будут для НСИ). Как вы можете объединить источники, если, скорее всего, вы даже не их владелец?
Итого по всей статье. Ощущение, что
или автор порой не различает данные (хранение, БД/СУБД), их представление для потребителей (управление, СУБД) и систему-потребителя данных (НСИ), а также некоторые логики ИС, и перегрузил монструозным маркетингом статью,
или что я не владею особой терминологией и логикой НСИ, поэтому много чего не понимаю тут.
Для меня слишком абстрактно. Нельзя ли поконкретнее - где, как это применить при проектировании ИС?
Честно пытаюсь понять, что такое API-first, но не могу.
Что тогда такое - проектирование API? Почему форматы и правила описания вынесены за пределы проектирования?
Итого, что должно быть первым в таком подходе?
Что означает эта фраза?
Глава по профессии? Ведущий в профессии? Быть head внутри компании внутри какого-то структурного подразделения или направления - понятно. Но как это - во всей профессии? Не могу понять смысл
В целом, сплошной текст тяжело воспринимается. Полезно было бы основные мысли отобразить визуально. Тот же процесс API-first, например
А мне, как ни странно, статья понравилась )
Тоже против солянок. Но тут выглядит как простое и доступное изложение, как аналитику выполнить интеграцию, от бизнес-целей (о чём некоторые мидлы и сеньоры почему-то забывают) до основных паттернов технических решений. Этакий быстрый справочник
Мы на каких-то разных языках говорим.
В своём примере - "заказчик может прийти с требованием хочу показать людям сколько идти до ближайшено отделения почты" - это уже можно (с некоторой натяжкой, конечно, но) считать потребностью бизнеса. И следует (а не идёт в начале!) ваше решение - "эти данные забрать из Яндекс api".
А бизнес ваша реализация не интересует, бизнесу надо понимать дебет/кредит и время. Будет это интеграция, или прогнать 100500 человек по городу - ему без разницы.
Ещё раз: бизнесу не нужна никакая интеграция - ни новая, ни старая, ни ещё какая-либо. Ему нужно решение для своих целей. Интеграция - лишь вариант реализации
Ура. Теперь можно выкинуть все толстенные талмуды по системному дизайну, а также по требованиям к системе (зачем они, ведь вот же готовый дизайн на "всё").
Мы получили то, о чём втайне мечает каждый спец в своей области - универсальную таблетку на все случаи жизни. Всех архитекторов можно смело увольнять
Пару скринов хотя бы, если можно