Методологии проектирования

Записаться

Мы переходим к третьему модулю шестой лекции курса «Анализ требований к информационным системам». Сегодня мы продолжим говорить о аспектах архитектуры. В этом модуле будет продолжение заданного тренда.

Сегодня мы будем говорить о методологиях проектирования. В ходе этого модуля мы расскажем о том, что нужно для построения надежных архитектур, которые должны быть вписаны в информационный ландшафт предприятий. В этом рассказе будет много аспектов и деталей, влияющих на то, что необходимо учитывать для создания информационных систем, которые развиваются не сами по себе, а вместе со средой предприятия и на основе признаков, важных для развития в определенной бизнес-среде.

Сегодня мы рассмотрим разные методологии. Какие-то из них были популярны чуть раньше, какие-то популярны сейчас. Все они по-разному формируют рабочий контекст и требуют разного внимания. Начнем мы с квадранта Захмана, дальше перейдем к TOGAF, следом рассмотрим подробнее уже знакомый нам SAFe, ну и в конце поговорим о C4. Каждый из данных типов архитектур работает с разными организационными абстракциями, но в совокупности они помогают выстроить представление о том, для чего нужна архитектура, как ею управлять и на чем фокусироваться в ее развитии.

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

Начнем рассмотрение методологий проектирования с квадранта Захмана. Это подход к корпоративному проектированию, учитывающий множество факторов, каждый из которых вносит вклад в формирование законченного результата внедрения конкретной информационной системы. Этот тип архитектурного проектирования лучше всего характеризовать понятием корпоративной архитектуры, в которой конкретная информационная система – строительный блок. Этот блок должен быть поставлен в правильное время на правильное место. Корпоративная архитектура сочетает в себе два направления – бизнес-сфера и информационные технологии. Эта архитектура должна учитывать оба этих направления и оценивать, как каждая инициатива отражается на информационном ландшафте компании. Для этого квадрант Захмана, с учетом этих двух составляющих, изображается в виде матрицы. По горизонтали он концентрируется на бизнес-данных, бизнес-функциях, бизнес-представительстве, людях, времени и мотивации к изменениям, по вертикали – на целях и ограничениях, модели предприятия, модели систем, технологической модели, изменениях и функциях компании. На пересечении мы получаем взаимное влияние двух составляющих, выражающееся в виде конкретного артефакта, разработать который нужно для разработки и внедрения конкретной информационной системы. Квадрант Захмана – комплексный инструмент, который учитывает факторы, критичные для сопровождения и развития архитектуры компании. Это одна из первых архитектурных методологий, в которой нет ничего про процесс развития архитектуры, но очень подробно разобраны ее составляющие.

Исторически квадрант Захмана стал основой для следующих проектов внедрения системных архитектур. Этот подход испытал на себе сильное влияние технократического подхода к развитию организации, который описывает предприятие как цельный организм, в котором все взаимосвязано и влияет друг на друга. Квадрант Захмана разложит организацию на слои. Каждый нижележащий слой влияет на верхнележащий. Каждый слой сам по себе приносит ценность, но зависит от предыдущего. В основе всего – те функции, которые выполняет предприятие. Эти функции предполагают развитие архитектуры компании, но их недостаточно, чтобы разработать всю архитектуру.

По квадранту Захмана, каждое предприятие имеет свои аспекты. Данные отвечают на вопрос, что мы делаем, функции говорят о том, как мы это делаем, сеть компании – о том, как мы это делаем, время внедрения инициатив помогает нам с тем, когда мы это сделаем, а мотивация в решении помогает понять организациям, зачем она это делает. Организация представлена слоями. Нижний слой описывает операционную деятельность компании. Над ним – детальное представление, которое должно быть вне контекста изменений и показывать актуальную среду. Еще выше – технологическая модель, показывающая физическое представление технологий компании. Над ним – информационная модель системы, которая показывает ее логическое представление, та модель, которая должна представлять рабочие концепции. Ну и самый высокий уровень – это контекст, то есть цели и границы проводимых изменений.

Далее мы рассмотрим архитектурную методологию TOGAF – следующий виток эволюционного развития архитектурных методологий. Он уже более процессно-центричный. В основе TOGAF лежит понятие требований и управление ими. Требования поставляют изменения, и вовлеченным в TOGAF необходимо постоянно отслеживать требования, чтобы оценивать масштаб возможных изменений. Первая, отправная точка в работе над архитектурой – ее концепция, с которой все начинается. Архитектура создается на основе требований, стратегии компании, ее миссии и позиционирования. Это дает отправную точку в драйверах возможных изменений. Следом необходимо разрабатывать бизнес-архитектуру, то есть описание того, как концепция будет реализовываться за счет выполнения конкретных операционных процессов, реализующих ценность. Вслед за этим, понимая необходимые бизнес-изменения, разрабатывают архитектуру информационных систем. После этого мы переходим к планированию необходимой технологической платформы, то есть описанию того, как будут работать информационные системы. Все это дает прозрачное понимание возможностей и решений, которые должны быть реализованы в проектных группах. То есть постепенно, реализуя проекты, мы начинаем планировать переход от имеющегося состояния к целевому. По ходу необходимо иметь представление и планы реализации. Все это агрегируется в активности «управление реализацией». С такой подробной картой появляется возможность управлять тактическими и стратегическими архитектурными изменениями и направлять работу архитекторов.

На создание и развитие TOGAF большое влияние оказала процессная парадигма достижения результата, которая говорит о том, что, не имея конкретного процесса, невозможно претендовать на реализацию запланированного. На текущий момент методология TOGAF является одним из самых популярных взглядов на проектирование программных продуктов. Она наиболее распространена в чистом или адаптированном виде. Знание ее аспектов и этапов помогает не только разбираться в причинах и следствиях решений, принимаемых в компании на разных уровнях, но и обосновывать наиболее важные собственные решения.

Основные артефакты TOGAF – это архитектура как результат и требование, как основа для принятия архитектурных решений. TOGAF работает над представлениями архитектуры за счет реализации конкретных проектов. В качестве представлений архитектуры разрабатывают ее концепцию, бизнес-архитектуру, архитектуру информационных систем и технологическую архитектуру. Рабочие проекты дают возможности реализовать решения. Это должно достигаться плавными переходами от текущего к целевому состоянию. Так, управляя изменениями, мы реализуем конкретный вид архитектуры.

Следующую архитектурную методологию мы уже немного разбирали в этой лекции. Сейчас сосредоточимся на том, о чем мы еще не говорили. Итак, шаг за шагом, рассматривая каждый следующий подход, мы начинаем вовлекать в архитектурные методологии дополнительные аспекты, которые становятся важными для контроля за достижением задуманного архитектурного состояния. Сначала квадрант Захмана, который описывает, за чем нужно следить. Потом TOGAF, который кроме описания, за чем нужно следить, предлагает еще и то, как это нужно делать. SAFe в дополнение к этому предлагает роли, которые должны отвечать за реализацию каждого критичного архитектурного компонента. Немного истории. SAFe возник в ситуации развития Agile – подхода к разработке продуктов, при котором на первый план выходят прозрачность процесса, постоянное технологическое развитие продукта и доверительная коммуникация между всеми участниками, вовлеченными в процесс создания информационных продуктов и сервисов. Слои архитектуры SAFe мы уже подробно рассматривали, поэтому сейчас сместим фокус в сторону ролей, которые задействованы в этом фреймворке. На нижнем, тактическом слое реализации продуктов присутствуют команды разработки, состоящие из аналитиков, тестировщиков и программистов, SCRAM-мастеров, организующих процесс, а также владельцев продуктов, которые направляют тактическое развитие конкретного продукта. На следующем уровне представлены владельцы бизнес-направлений, продуктовые менеджеры, архитекторы систем и специалисты, организующие поставку продукта. Уровнем выше находятся клиенты и заказчики бизнес-изменений, архитекторы систем, менеджеры решений, ну и на верхнем уровне – корпоративные архитекторы и владельцы бизнеса. В основе такой архитектуры лежит LIN (Local Interconnect Network) – представление развития бизнес-архитектуры.

Развитие SAFe было взаимосвязано с распространением Agile в крупных организациях с большим количеством сотрудников, в которых важно не просто развивать конкретную информационную систему, а делать это согласовано с развитием ряда систем. SAFe испытывает на себе agile-веяния и гибкие подходы к достижению ценности, которые, в качестве условия своего развития, имеют работу в крупных бюрократических организационных структурах. SAFe не живет вне Agile, так как роли тактического уровня базируются на ролях методологии SCRAM и поток поставки ценности ориентирован именно на эту методологию.

Итак, разработка информационных систем в SAFe выполняется за счет команд и методологии SCRAM. Поддержка продуктов осуществляется на основе методологии Kanban. Акцент делается именно на техническом совершенствовании продуктов. SAFe большое внимание уделяет непрерывной поставке ценности. Для этого нужен высокий уровень технической архитектуры, организация постоянного мониторинга функционирования систем и постоянного оценивания удовлетворенности клиентов приносимых бизнес-решений. Разработка и проектирование бизнес-решений для SAFe выполняется за счет запуска непрерывных проектов, для которых выполняется оценка экономической целесообразности. SAFe требователен к уровню бизнес-управления организацией, так как именно бизнес-руководству и пользователям уделяется основное внимание при запуске инициатив. Это самая формальная и полная методология, которая во многом гарантирует результаты. Она описывает роли, функции и слои построения архитектур информационных систем, синхронизированных со всем информационным ландшафтом компании.

Мы рассмотрели все наиболее популярные методологии построения архитектур. А теперь сделаем выводы. На текущий момент сфера информационных технологий накопила достаточно мощный багаж подходов, инструментов по разработке и реализации архитектур. Это и менее формальные, и более формальные подходы, учитывающие множество разнообразных факторов. Какие-то инструменты описывают организацию в целом, другие акцентируются на создании информационных систем, а какие-то помогают адаптировать текущие веяния под архитектурные процессы. Подходы, разобранные нами, можно сочетать, но в качестве доминанты для организации должна быть выбрана единая модель построения архитектуры. Методологии помогают с организацией процесса и формированием желаемого результата. Под конкретные условия и ожидания нужно подбирать наиболее подходящую методологию. До встречи в следующий раз!