Все пути исчезают, но …

solutionwayНекоторые моменты, затронутые на серии прошедших вебинаров и в ходе курса «Мастерская проектирования ИТ-решений» представляются мне достаточно важными, чтоб вынести их в отдельную запись в блоге. Напомню, что занимались мы такой дисциплиной как архитектура решений (Solution Architecture) и потому логично будет начать с определения предмета рассуждений. Согласно TOGAF

Solution Architecture A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.

Прежде чем прокомментировать это определение я позволю себе привести одно вспомогательное определение, взятое из руководства по бизнес-анализу IIBA BABOK Guide v.3 (2.1 The Business Analysis Core Concept Model™)

Solution A specific way of satisfying one or more needs in a context.

Проще говоря, Solution или решение – это конкретный путь удовлетворения некоторой потребности в имеющем место быть окружении. В том случае если потребность выявлена и определена как цель, то архитектура решения (описание конкретного пути) – это маршрут достижения этой цели. Пара существенных замечаний:

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

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

Вернемся к определению solution architecture.  Согласно ему, задача архитектуры решения состоит в оказании помощи по переводу требований в нечто, называемое словом vision, высокоуровневую спецификацию и набор задач по реализации решения. Проще всего с набором задач. Это те самые отрезки пути, о которых мы рассуждали чуть выше и одновременно описание структуры работ для проектного менеджера.  Они и описываются в высокоуровневой бизнес/ИТ спецификации. Таким образом функция архитектора решения заключается в подготовке подробной и верной WBS для менеджера проекта (или релиза). Но прежде чем заниматься описанием маршрута, разработкой детальной легенды путешествия, нужно выбрать один маршрут из множества альтернативных вариантов. Именно этот выбор и фиксируется непонятным артефактом, именуемым vision. Здесь надо снова погрузиться в TOGAF, рассказывающий про vision довольно детально. Приведу следующую цитату (7.4.8 Develop Architecture Vision):

The Architecture Vision typically covers the breadth of scope identified for the project, at a high level. Informal techniques are often employed. A common practice is to draw a simple solution concept diagram that illustrates concisely the major components of the solution and how the solution will result in benefit for the enterprise.

Business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Business scenarios may also be used at more detailed levels of the architecture work

This step generates the first, very high-level definitions of the baseline and target environments, from a business, information systems, and technology perspective

Собственно, разработкой этого самого architecture vision мы и занимаемся в ходе обучения. Сначала на самом верхнем уровне, а затем погружаясь в прикладную, интеграционную и технологическую архитектуры. Задача эта не слишком хорошо формализована, т.к. нигде особо не сказано, что такое simple solution concept diagram и как её следует делать. А ведь её надо не только нарисовать, но и потом рассказать человеческим языком в ходе презентации ИТ-решения. Рассказать так, чтоб оно было понятно бизнес-заказчику и руководителям. Ну, или по крайней мере у них сложилось ощущение, что им все понятно. Кстати, слово vision можно перевести на русский как обзор решения. А вся эта деятельность довольно близка к тому, что в отечественной традиции называется концептуальным проектированием.

И напоследок самое интересное. Во многих в организации возникает вопрос: а зачем все это вообще делать? Не проще ли сформулировать требования, пригласить системного интегратора и поручить ему доставить нас прямёхонько в пункт назначения (аналогии с одноименным фильмом – случайны). А как он уж будет эту задачу решать это его дело (прорубит просеку прямиком до точки B и проложит по ней автостраду или же изобретет прибор для телепортации – не важно). В принципе, госкомпании часто так и поступают, но в более бюджетных случаях лучше подходит модель турагентства: самолет, трансфер, отель.  Можно даже учесть особые пожелания заказчика, дополнив маршрут экскурсией по городу, и включить в ней посещение какой-нибудь достопримечательности – исторические руины унаследованной ERP системы, например.

Но если серьезно, вопрос: зачем мы декомпозируем задачу на части(систему на модули) – правильный и уместный. Его надо четко излагать заказчику и руководству. Три основные выгоды:

Сокращение сроков разработки за счет параллельного ведения работ. Т.е. мы не ждем, пока программист закончит создание уровня абстракции и приступит к разработке пользовательского интерфейса, а зовем двух программистов. Выдаем им спецификацию API и отправляем одного разрабатывать бизнес-логику для его реализации, а второго – пользовательский интерфейс, использующий этот API. Потом собираем все вместе. Речь конечно чаще идет о командах разработки и важный аспект – команды разработчиков не масштабируются! Вы не можете взять 20 программистов и отправить их писать одну программу. Это понял еще Фредерик Брукс в 1975 году и описал в легендарной книжке «Мифический человеко-месяц». Пять человек объединить в одну команду можете, а двадцать уже не можете. Есть дно исключение, называемое…. нет,  не agile, continuous integration, но это отдельная история. Кроме параллельной организации работ по созданию ПО, мы выделяем из общей задачи другие активности: закупку и подготовку оборудования, разработку новых процессов и регламентов к ним, в общем подготовку всех прочих видов обеспечения, так подробно перечисленных в отечественных ГОСТах

Вторая выгода – специализация. Человек лучше делает то, что он вынужден делать регулярно. Это уже скорее из области экономики и разделения труда. Посмотрите вот эту лекцию про принцип сравнительного преимущества. Даже если кто-то все делает хуже, чем все остальные, можно найти работу, которую целесообразно ему поручить. К этой выгоде относятся такие вещи, как выбор программного средства и инструментов разработки и а так же повторное использование. Повышение производительности труда достигается за счет использования правильных инструментов (Говоря языком экономистов – замена натурального труда овеществлённым трудом). В нашем случае это использование программных платформ, готовых компонент или внешних сервисов. Почему люди пользуются общественным транспортом, а не ходят пешком? Потому, что кооперация позволяет сделать этот способ транспортировки более выгодным (дешевым и быстрым, см. Николас Карр «Блеск и нищета информационных технологий»). Это же влечет за собой определенные неудобства: наличие остановок до которых надо еще добраться, расписание движения и т.д.

Третья группа выгод – локализация изменений. Мы хотим спроектировать систему так, чтоб возможные изменения не затрагивали сразу все её части, а ограничивались минимальным набором модулей. Это основная выгода от проектирования программных средств. Две предыдущие были скорее вспомогательными. Гибкость (толерантность к внесению изменений) и возможность повторного использования позволяют сделать нам решение для поддержки целого класса задач, как уже поставленных, так и возможных в будущем. Из этих модулей мы будем потом разрабатывать новые релизы решения в архитектуре костыли и заплатки. Это только с нашей, айтишной точки зрения неправильно и плохо. А с точки зрения бизнеса: “производить – значит комбинировать имеющиеся в нашей сфере вещи и силы. Производить нечто иное или иначе — значит создавать другие комбинации из этих вещей и сил” (Теория экономического развития Йозефа Шумпетера) – это новаторство и предпринимательство. Подробнее про жизненный цикл ИТ-решения см. Модель основных понятий бизнес-анализа.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *