Учебник 4CDTO О цифровизации и цифровой трансформации
- Автор: Кирюшин Сергей, Борисов Евгений
- Год: 2020
- Язык: русский
- Жанр: Бизнес
Электронная книга - «Учебник 4CDTO О цифровизации и цифровой трансформации». Краткое содержание книги:
• ПО промежуточного слоя (сервера приложений и другие средства интеграции);
• вычислительная инфраструктура (серверное оборудование, СХД и т. д.);
• сетевые сервисы (локальная и глобальная сетевая инфраструктура, технологии доступа);
• сервисы безопасности.
Все эти каталоги моделируются в виде реестров. Каждый элемент или компонент реестра паспортизируется. Паспортизация всех элементов архитектуры характеризует качество работы архитектурной группы предприятия. Отсутствие паспортов на компоненты архитектуры чаще всего указывает на небрежность работы архитектора и, как правило, ведет к дискредитации работы всей архитектурной практики.
Данный слой систематизирует (выделяет, каталогизирует, связывает) оборудование, линии, здания, материалы, склады и логистические каналы, и другую важную и контролируемую в масштабе предприятия инфраструктуру производственного характера.
Следующие каталоги архитектурных компонентов составляются для данного слоя:
• каталог оборудования (или типов оборудования);
• каталог материалов (или типов материалов);
• каталог производственных площадок;
• каталог физических систем и каталог их взаимодействий;
• каталог сооружений.
Появление в архитектурной практике 6-го производственного слоя знаменует этап, когда корпоративная архитектура перестаёт быть исключительно прерогативой ИТ. Это ставит корпоративного архитектора на ранг выше ИТ-архитектора. В полностью цифровых компаниях эта разница может не ощущаться, но таких компаний пока единицы, хотя именно они и задают основной драйв рынку.
Мы рассмотрели шесть наиболее часто моделируемых архитектурных слоев. Каждый слой состоит из каталогов (слоев 2-го порядка). Элементы каталогов связаны друг с другом (объекты с объектами, системы с системами, процессы — с процессами и подпроцессами, цели — с целями и подцелями, требования с требованиями) — такая систематизация обеспечивает контроль целостности слоя. Но элементы каталогов также связаны и с элементами других каталогов (системы с функциями, цели с процессами, данные с интеграциями)! А это уже обеспечивает целостность всей корпоративной архитектуры и возможность трассировать изменения различной природы: влияние целей на процессы, процессов — на системы, систем — на инфраструктуру и в любом другом направлении, снизу вверх, со стороны в центр и т. д. — см Рис. 2.3.2.
Рис. 2.3.2. Архитектура, как многослойная конструкция.
Отдельно стоит обратить внимание на упоминаемый в этом разделе термин — компонент архитектуры. Что следует запомнить:
• Компонент архитектуры (architecture building block) — это не только строительный блок в модели, но зачастую инвентаризованный объект реальности: система, API-метод, микросервис, цель, KPI, подразделение, функция подразделения, требование.
• Компонент архитектуры может быть абстрактным — классом, категорией, типом, ролью. В таком случае от архитектора требуется понимание связи абстрактной категории с физическими сущностями или явлениями предприятия, которые репрезентирует данная абстракция.
• Компонент архитектуры должен быть паспортизирован независимо от того, отражает он физическое явление/предмет или некую абстракцию над ними. Иначе такой компонент будет недолговечным и пустым по своей сути.
Построение моделей из одних лишь абстрактных элементов содействует, как правило, одной цели — быстрому формированию или реконструкции замысла системы-предприятия. Однако такие модели имеют ограниченную востребованность и, не будучи приземленными на физические части бизнеса (процессы, функции, сервисы и прочее), они становятся уделом абстрактных архитекторов.
Тщательно описанная архитектурная модель предприятия является затратным и весьма длительным проектом. Действительно ли это необходимо? Здесь следует снова обратить внимание на врезку с определением архитектуры согласно Стандарту IEEE 42010:2011: «архитектура какой-либо системы представляет собой то, что является существенным относительно рассматриваемой системы в ее окружающей среде. Не существует единственной характеристики того, что является существенным или основным для системы». То есть архитектор предприятия сам должен решить, какие части архитектуры являются существенными и будут ли они подлежать тщательному описанию или проектированию. Второй фактор — это стоимость построения модели. Стоимость модели должна оправдывать стоимость решений, принимаемых по ней. Любая ошибка в выборе технологии, бизнес-модели, системы, канала продаж, будущего продукта, партнера или экосистемы, а также неспособность внедрить свой замысел в жизнь обернутся для компании миллионами и миллиардами убытков. Модель должна предсказывать предстоящую сложность реализации и планируемую отдачу нововведений для бизнеса. Модель позволяет «проиграть» ситуации будущего, лучше его спланировать и даже специфицировать. Таким образом, чем больше масштаб планируемой трансформации и, как следствие, чем больше ресурсов и времени потребуется на ее воплощение в жизнь, тем выше затраты на архитектурирование, и тем важнее модель, по которой данную трансформацию будут оценивать. Модель же становится и образом будущего предприятия. Это направление в системном дизайне получило название Model Driven Architecture и развивается в рамках консорциума OMG (см. Ссылку 2.3.4).