Рассмотрим как можно применять матрицу корпоративной
архитектуры и какую помощь она оказывается при разработке
программных систем, в том числе и в аспекте человеческого
фактора. Естественно, эту матрицу можно использовать для
обнаружения, прогнозирования и предупреждения кризисов,
которые связаны с различным видением или представлением
программного комплекса с точки зрения, скажем, разработчиков
или заказчиков, с точки зрения разных сторон, которые участвуют
в разработке. То есть вообще говоря, с точки зрения различных
аспектов человеческого фактора. При этом, особое значение имеет
архитектурная схема системы. Архитектура, по определению, — это
компоненты и связи, из которых строится система. Поэтому
при наших трех срезах: динамическом — процессном, статическом
— на уровне данных, и на уровне компонент, мы можем видеть
существенный пробел, который в этой матрице, скажем,
отсутствует, или противоречие между компонентами различных
видов систем, которые могут, скажем, в том или ином виде
присутствовать и отсутствовать на определенных этажах нашей
таблицы. Таким образом можно выявлять ошибки архитектурного
проектирования, ошибки моделирования бизнес-процессов
и, конечно же ошибки взаимодействия между компонентами
на уровне данных. Предположим, возникают компоненты,
которые должны передавать определенные виды данных смежным
системам, но на соседнем этаже нашей матрицы, на соседнем слое,
систем, которые должны с ними взаимодействовать, скажем,
систем управления цепочками поставок, взаимодействие
с поставщиками, заказчиками, контрагентами или другими
компонентами отсутствуют. Таким образом, мы можем видеть
какие пробелы допущены при архитектурном проектировании,
моделировании бизнес-процессов или проектировании на уровне
схем данных. Ошибки, эти пробелы, определяются как раз
в основном человеческим фактором. Какие выводы можно сделать
по результатам рассмотрения матрицы корпоративной архитектуры.
Ну, прежде всего, такая матрица действительно хорошо подходит
для решения вопросов противоречия в архитектуре кризисных
ситуаций, в архитектуре корпоративных систем. Анализ
архитектуры, который включает неполное и не совсем правильное,
не вполне верное решение с точки зрения организации
программных систем на уровне их представления в форме
компонентов и связей. Ошибки могут включать: дублирование
функций, недостаток или определенные избыточные компоненты
и, естественно, как на уровне процессов, так и на уровне данных
и компонент. Таким образом, кризисные ситуации, которые
возникают или могут возникать в связи с различными углами
зрения, будем говорить, определенных типов разработчиков
или, скажем, различными мнениями разработчика и заказчика,
как двух сторон процесса производства программного продукта,
могут приводить к такого рода противоречиям недостаточным
или избыточным компонентам. Матрица подскажет, в каком случае
появляются такого рода пробелы, коллизии или противоречия.
Поможет найти компромисс для разрешения кризисных ситуаций.
Кроме того, она поможет, вернувшись, скажем, в ретроспективе
к предыдущим проектам, оценить их ход, проанализировать их ход
и понять какие ошибки были допущены или посредством чего мы
избежали определенных ошибок, определенных кризисных
ситуаций, в том числе и прежде всего, конечно же, при разработке
крупномасштабных программных систем. Ну и, судя по тому,
что было сказано все эти ошибки или большинство этих ошибок
инициируются именно человеческим фактором. И поэтому,
такого рода матрица дает нам возможность предсказать
и предупредить ошибки, которые человеческим фактором
вызываются и, таким образом, этот человеческий фактор позитивно
настроить на производство более эффективного для кризиса
программного обеспечения как в командах, так и на личном плане.
