Фактор влияния: услуги, инфраструктура и приложения
В COBIT (Control Objectives for Information and Related Technologies) приведен пример фактора влияния: услуги, инфраструктура и приложения. Специфические элементы, относящиеся именно к инфраструктуре, приложениям и услугам, в целом достаточно очевидны. Например, хорошая практика — использовать хранилище данных об архитектуре решения.
Заинтересованные стороны — это лица или группы, которые влияют на решение или зависят от него. Целевые уровни услуг — согласованные показатели качества услуг. Жизненный цикл услуг, инфраструктуры и приложений также имеет место: это этапы их существования от планирования до изменения или вывода.
Базовая, целевая и переходная архитектура
Вводятся важные понятия:
| Понятие |
Смысл |
| Базовая архитектура |
Архитектура инфраструктуры, приложений и услуг, которая работает сейчас. |
| Целевая архитектура |
Архитектура, к которой нужно перейти. |
| Переходная архитектура |
Промежуточное состояние между базовой и целевой архитектурой. |
Если ставится задача перехода на новую архитектуру, возможны разные варианты. Можно сразу перейти от базовой архитектуры к целевой. Можно ввести промежуточную архитектуру. Можно выделить фрагменты и постепенно обновлять их до целевого уровня. Это не обязательный шаблон, а иллюстрация того, о чем нужно думать при описании фактора влияния.
Хорошие практики
Среди хороших практик описано повторное использование. Также важен выбор: покупать или создавать? Со времени создания COBIT 5 появилась третья возможность — не покупать и не создавать, а арендовать, использовать облачные решения или комбинировать облачные, собственные и покупные решения. Такие практики меняются быстро.
Простота и гибкость — это не сами хорошие практики, а следствия применения хороших практик или свойства архитектуры. Не нужно буквально интерпретировать то, что написано в COBIT. Часто это остается на полуинтуитивном уровне.
Управление архитектурой и связи с другими факторами
Управление архитектурой также описано через возможные варианты, но они не исчерпывают все реальные ситуации. В качестве внешних хороших практик предполагается ITIL (Information Technology Infrastructure Library) с точки зрения управления услугами и отчасти инфраструктурой. Кроме того, нужно учитывать связь этого фактора влияния с другими факторами, включая культурно-поведенческие аспекты.
Краткие итоги
Управление архитектурой начинается с признания того, что услуги, инфраструктура и приложения не существуют изолированно. Их описание задает рамку для решений: что уже работает, к какому состоянию нужно прийти и какие промежуточные шаги допустимы. Практическая ценность такого подхода в том, что он позволяет не смешивать текущее состояние, желаемое состояние и план перехода. Если этого не делать, изменения рискуют стать набором несогласованных инициатив, где инфраструктура, приложения и услуги развиваются по разным логикам.
Разделение базовой, целевой и переходной архитектуры помогает управлять сложностью. Базовая архитектура фиксирует реальность, целевая задает направление, а переходная делает путь выполнимым. При этом переход не обязан быть единственным или универсальным. В одних случаях оправдан прямой переход, в других — промежуточные состояния или постепенное обновление отдельных фрагментов. Выбор зависит от масштаба изменений, рисков, ресурсов и готовности организации. Поэтому архитектурное решение становится не догмой, а инструментом согласования действий.
Хорошие практики также требуют критического взгляда. Повторное использование, покупка, создание, аренда и облачные модели — это не взаимоисключающие варианты, а спектр возможностей. Их комбинация может быть практичнее, чем следование одному шаблону. Важно понимать, что простота и гибкость не возникают сами по себе: они являются результатом продуманных решений. Если организация стремится к ним напрямую, без изменения архитектурных принципов и практик, результат может быть неустойчивым.
Связь с ITIL и культурно-поведенческими аспектами показывает, что архитектура не сводится к техническому описанию. Управление услугами, инфраструктурой и приложениями затрагивает роли, ответственность, коммуникацию и поведение людей. Поэтому практическое применение требует не только знания фреймворков, но и умения адаптировать их к конкретному контексту. COBIT и подобные источники дают ориентиры, однако их нельзя превращать в жесткий регламент. Их ценность — в постановке вопросов, которые помогают принимать более осознанные архитектурные решения.
Фактор влияния охватывает услуги, инфраструктуру и приложения. В COBIT (Control Objectives for Information and Related Technologies) приведен пример такого фактора. Специфические элементы, относящиеся к инфраструктуре, приложениям и услугам, в целом достаточно очевидны. Хорошая практика — использовать хранилище данных об архитектуре решения.
Важно учитывать заинтересованные стороны, целевые уровни услуг и жизненный цикл услуг, инфраструктуры и приложений. Заинтересованные стороны — это лица или группы, которые влияют на решение или зависят от него. Целевые уровни услуг — согласованные показатели качества. Жизненный цикл — этапы существования от планирования до изменения или вывода.
Вводятся три архитектурных понятия. Базовая архитектура — та, что работает сейчас. Целевая архитектура — та, к которой нужно перейти. Переходная архитектура — промежуточное состояние. Если ставится задача перехода на новую архитектуру, возможны разные варианты: сразу перейти от базовой к целевой, ввести промежуточную архитектуру или постепенно обновлять отдельные фрагменты. Это не обязательный шаблон, а иллюстрация того, о чем нужно думать при описании фактора влияния.
Среди хороших практик — повторное использование. Также важен выбор: покупать или создавать? Со времени COBIT 5 появилась третья возможность: арендовать, использовать облачные решения или комбинировать облачные, собственные и покупные решения. Такие практики меняются быстро. Простота и гибкость — не сами хорошие практики, а следствия их применения или свойства архитектуры. Не нужно буквально интерпретировать COBIT.
Управление архитектурой описано через возможные варианты, но они не исчерпывают все реальные ситуации. В качестве внешних практик предполагается ITIL (Information Technology Infrastructure Library) для управления услугами и отчасти инфраструктурой. Нужно учитывать связь этого фактора с другими факторами, включая культурно-поведенческие аспекты.
1. Фактор влияния охватывает услуги, инфраструктуру и приложения.
2. Базовая архитектура описывает текущее работающее состояние.
3. Целевая архитектура задает желаемое состояние.
4. Переходная архитектура может использоваться как промежуточный шаг.
5. Возможны разные пути перехода: прямой, через промежуточное состояние, по фрагментам.
6. Хранилище данных об архитектуре решения — хорошая практика.
7. Повторное использование относится к хорошим практикам.
8. Выбор между покупкой, созданием, арендой и облаком требует учета контекста.
9. Практики быстро меняются, поэтому нельзя опираться только на старые шаблоны.
10. Простота и гибкость — следствия практик, а не сами практики.
11. ITIL используется для управления услугами и отчасти инфраструктурой.
12. Культурно-поведенческие аспекты нужно учитывать вместе с архитектурой.
1. Какие области включает фактор влияния, связанный с услугами?
2. Что такое базовая архитектура?
3. Чем целевая архитектура отличается от базовой?
4. Зачем может понадобиться переходная архитектура?
5. Какие варианты перехода от базовой архитектуры к целевой возможны?
6. Почему нельзя считать описанный путь перехода единственно правильным?
7. Какую роль играет хранилище данных об архитектуре решения?
8. Какие практики относятся к хорошим в описанном факторе влияния?
9. Как изменился выбор между покупкой и созданием решений?
10. Почему простота и гибкость не являются хорошими практиками сами по себе?
11. Как связаны управление архитектурой и ITIL?
12. Почему при управлении архитектурой важно учитывать культурно-поведенческие аспекты?
