Критерий нашей модели, как было показано выше, это оценка реализации задачи или требования потребителя в конкретной системе. Не следует изобретать Америку или открывать велосипед.
Мы собрали или сформулировали функциональные и нефункциональные требования к системам и разложили их на две кучки: специфические требования к данному классу систем и общие.
В итоге имеем оценку системы в части ее :
технического устройства, например, встраиваемость системы в новый ИТ-ландшафт, масштабирование или структуру БД и
специфические критерии системы, относящиеся к функциональным требованиям конкретной предметной области, например, распределение задач между сотрудниками, для фронтальных систем или систем связанных с операционной деятельностью, авторизация карточных операций и т.д. В этой части материала мы рассмотрим именно эту, постоянную, часть нашей модели оценки.
Критерии распределены по блокам и группам, так и будем их рассматривать. Структура приведена для общего понимания, а детали модели приведены в этой и следующей частях этого материала. Хотелось бы заметить, что здесь я могу привести лишь "эскиз" модели, полная версия публикации, пока во всяком случае, не подлежит.
Первый блок «Общие сведения» состоит из трех групп критериев и оценивает команду продукта, фазу его (продукта) развития, зрелость и ограничения по использованию.
Первое, что хотелось бы отметить это то, что сама по себе система может быть несказанно крутой «в моменте», но что будет в среднесрочной перспективе?
Какое может быть авторское сопровождение продукта ?
Как быстро и качественно команда поставщика будет реализовывать пожелания заказчика?
Хватит ли у нее (команды) что называется мощности? А вдруг у поставщика есть очень «жирный» клиент и ваши пожелания будут иметь не самый высокий приоритет?
Какими компетенциями обладает команда системы, какие задачи ей действительно по плечу?
Разумеется, все выше сказанное должно быть отражено в контракте на поставку и поддержку, но рассмотреть это аспект системы нужно еще до заключения контракта. На это и направлена первая группа критериев общей части модели (таблица 1).
Структура представления информации это :
Общая задача раздела критериальной модели {«Хватит ли ресурсов ….»}
Критерий с уникальным идентификатором - это поможет нам в дальнейшем {«1.1»}
Постановка задачи или проблемы, которую анализирует заданный критерий {«какие «чистые» …»}
Данные технологической анкеты - это данные, на основе которых и производится анализ. Что такое технологическая анкета посмотрим чуть позже. Данные иллюстрируется некой псевдоформулой, которая дает понимание первичных данных. Детали в анкете, технологической анкете.
Критерии модели оценивают задачу не "по заверениям поставщика", а по объективным данным. Конечно все можно, как и говорилось выше, зафиксировать в контракте, но как пропишешь в контакте «огонь в глазах» или "желание работать"? Лучше сначала посмотреть на объективные данные, а потом решать : нужен ли нам такой поставщик и только после это составлять контракт.
Вторая группа критериев характеризует положение системы на рынке:
Насколько она распространена (есть много или мало специалистов поддержки)?
Насколько «зрел» продукт – это новый инновационный продукт с возможными детскими болезнями, но готовый меняться по требования заказчика или это уже продукт с длинной историей, развитие которого уже клонится к закату?
Признан ли продукт какими-то регуляторами, внесен ли во всевозможные реестры ПО и т.д.?
Как реагировала команда продукта в изменения ситуации на рынке. С каким интервалом, после указа Президента, вышла импортозамещенная версия или как быстро удовлетворены требования МинЦифры или ЦБ РФ ?
В третьей группе критериев оцениваются ограничения эксплуатации продукта, которые могут оказаться решающими при выборе системы. Если вас в конкретной ситуации эти ограничения не касаются, просто пропустите этот раздел.
Как можно протестировать продукт?
Как дорабатывать, если есть такая возможность?
Какие политические риски есть в системе или в технологиях, которые она использует?
На этом блок общей информации завершен, а Вы (если угодно) можете добавить свои критерии. Сделаем мiр лучше!
Следующие блоки уже относятся к архитектуре системы непосредственно. На очереди блок корпоративной архитектуры, это очевидно специфические для конкретной функциональной области критерии (см. Разметим площадку), но небольшая общая часть все же есть. Приведем весь блок целиком, т.к. разбивать его на отдельные таблицы большого смысла не имеет. Наберем еще критериев – расширим.
Так по сути два блока,
первый очень небольшой, но может иметь ключевое значение: в каких культурах и традициях система может успешно эксплуатироваться
второй уже более объемный: как встраивать систему в принимающий ландшафт: средства аутентификации/авторизации, как можно синтегрировать систему с существующими процессами на уровне пользовательского интерфейса (UI) и API. Средства криптозащиты информации (СКЗИ), может кому-то важно индонезийские и т.д.
Теперь, пора «копнуть» внутренности системы, ее прикладную архитектуру. Как устроена система, на какие компоненты она разделена, в какому поколению архитектуры относиться: клиент-сервер с толстым клиентом или микросервисы. Какие технологии задействованы с системе в части хранения данных, кэширования, обработка данных и т.д.
Что делать с поколениями архитектур систем детально можно посмотреть в материале по трансформации архитектуры ВТБ – эпизод 2. Лирико-исторический.
Архитектура решает, прежде всего задачи обеспечения нефункциональных требований в части надёжности и производительности. Какими средствами решения этих задач, обеспечена эта система? Производитель вообще озаботился таким вопросом? Кстати, если ваши условия эксплуатации требуют суперНадежности – обратите особое внимание на эти критерии или наоборот, посмотрите, не будут ли эти средства системы вообще лишними для вашего случая. Зачем платить за то, что все равно не будешь использовать или эти средства будут «греть воздух», так бывает. Как в одном анекдоте верблюжонок спросил у мамы : "Зачем нам с тобой весь этот тюнинг (горбы, подошвы, язык, влагоНезависимость и т.д.) в Московском зоопарке?".
Далее переходим к технической архитектуре:
какие технологии нужны системе?
какое системное или прикладное ПО требуется?
в каких конфигурациях может эксплуатироваться система?
нет ли использовании уникальных продуктов третьей стороны, может нужна уникальная «железка»?
Теперь архитектура данных. Зачем ее смотреть, что это даст? Когда мы смотрим функциональную декомпозицию системы на модули и компоненты, мы имеем возможность оценить качество проектирования системы, какие решения в нее заложены, на что рассчитана система. Это грузовик для бездорожья или городской универсал? По структуре данных нужно провести такой же анализ. Нет ли каких-то архитектурных решений в системе, которые могут иметь негативные последствия в ходе эксплуатации (ошибки проектирования)?
в БД есть хранимые процедуры, т.е. бизнес логика в СУБД, что может отрицательно сказаться на производительности
структура БД развивается хаотично. Каждый разработчик создает свои таблицы, не глядя на общую структуру. Можем иметь одну, по сути предметной области, сущность, но в разных таблицах
на что рассчитана схема БД : на задачи OLPT или OLAP, есть ли отдельная база для оперативной отчётности, предусмотрены ли средства сегментирования (партиционирования БД), что заложено в систему для архивации данных
насколько модель предметной области системы соответствует модели данных ИТ-ландшафта потребителя (их же интегрировать надо или передавать данные в хранилище)
Система не «висит» в воздухе, она должна интегрироваться в ИТ-ландшафт. Блок критериев "Архитектура интеграции" описывает возможности интеграции системы.
Какие стили интеграции поддерживаются – синхрон/асинхрон, пакетный обмен или потоковая обработка?
Есть ли развитые средства обмена данными или требуются доработки?
Не окажут ли фоновые задачи выгрузки отрицательное влияние на другие модули системы
У всех больная тема отгрузки данных в корпоративное хранилище, если таковое имеется, так не лучше сразу посмотреть, как это заложено в систему, чем после внедрения «негодовать».
И последний раздел блока Архитектура – Архитектура безопасности. Часто вопрос в части безопасности звучит даже так :
а вообще про безопасность думали?
комплексно думали или по остаточному принципу?
Обычно требования по безопасности довольно общие и как они реализованы это предмет , часто субъективной дискуссии проектировщиков и экспертов по безопасности. "Градус" такой дискуссии сильно возрастает после аварий и «взломов» (для тех, кто понимает о чем я). Обычно в данном вопросе схема работы постФактум. Если у системы есть модели угроз – значит поставщик крепко подумал на эту тему. Это очень хороший знак. На самый крайний случай – какие средства аутентификации, авторизации и журналирование работы пользователей, чтобы после инцидента хотя бы разобраться.
Я часто сталкивался с тем, что про ребят из эксплуатации (поддержки и обслуживание) обычно забывают. Для «не забыть» в модели имеется раздел критериев оценки «Эксплуатация». Функционально система может быть прекрасна, но обслуживать ее сущее мучение. Большое количество аварий в «проме» происходит по причине ошибок в настройке и выводе в "пром" обновлений. Чаще все такие аварии классифицируются как «Человеческий фактор», но всегда ли ошибка «эксплуатации» является первопричиной? А если средства эксплуатации спроектированы отвратительно и в них трудно не ошибиться. У меня был случай, проектировщик с недолеченной «детской болезнью крутизны в программизме» предусмотрел в системе 10 000 суперГибких настроек, без перекрёстного контроля целостности, а потом сотрудник эксплуатации что-то перепутал и кто виноват в такой ошибке – настройщик или производитель рояля? Я на стороне настройщика. В данном разделе предусмотрен анализ на минимальные средства поддержки эксплуатации системы: журналирование, настройки, средства управления, тестирования и т.д. Именно, что есть «из коробки», а не «можем доработать вашему желанию».
На этом блоки критериев, относящихся к архитектуре системы (корпоративная, прикладная, интеграции и т.д.) рассмотрены, мы знаем, как приземлить систему в «принимающий» ИТ-ландшафт, это техника, а люди?
Что нужно в ИТ-команде потребителя, для успешной эксплуатации системы в данном конкретном случае?
Какие инструменты, люди и компетенции нужны?
Что должно быть в производственном процессе «принимающей» организации?
Что нужно для самостоятельного (если это предусмотрено) развития системы в организации-потребителе?
Возможно этого ничего не нужно, но тогда просто явно отметим – не нужно и сюрпризов не будет. По крайней мере в этой части.
На этом мы закончили рассмотрение критериев оценки технического совершенства системы. Теперь время перейти к оценке функциональности. Действительно нельзя сравнивать процессинг с CRMом, нельзя оценивать АБС как ДБО. Об этом в следующей части.
