Системная архитектура

Короткая ссылка: System-architecture-zaborov-2011

Ссылки сюда (3) →

Михаил Заборов

Руководитель направления «Торговые сети» CUSTIS

Финансовая газета — региональный выпуск (Москва), № 23 (июнь) 2011, стр.15.

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

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

Есть и другие сложности. Заказчик нередко плохо понимает, что ему нужно, и покупает систему ради «лучших практик». В такой ситуации описание требований крайне затруднительно.

Следует иметь в виду, что требования к масштабной системе — такой же большой и сложный объект, как и сама система, а значит, с ними возникают те же проблемы: например, невозможно проверить полноту требований и их соответствие ожиданиям заказчика. Кроме того, такие требования, описывающие поведение системы, не дают общего представления о ней. Например, определяя волка как млекопитающее, которое ходит на четырех лапах, живет в лесу и охотится на других животных, мы не даем понимания, что конкретно он из себя представляет.

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

Не следует забывать и о том, что бизнес не стоит на месте, для его развития требуются постоянные изменения, а описанные требования могут устареть прежде, чем будет разработано и внедрено ПО.

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

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

Компания BAA, управляющая большинством крупных аэропортов в Соединенном Королевстве, выяснила, что основная проблема, по которой при строительстве затягиваются сроки и превышается бюджет, состоит в том, что контракты пытаются переложить бóльшую часть рисков на подрядчиков. Поэтому при строительстве терминала 5 в аэропорте Хитроу была разработана особая форма контракта — так называемое соглашение Т5. По нему BAA брала весь риск проекта на себя, а подрядчики работали объединенными коллективами в небольших подпроектах с согласованной сметой и премиально-рисковым фондом. В случае, если стоимость подпроекта превосходила запланированные расходы, деньги для покрытия дополнительных затрат брались из премиально-рискового фонда. По завершении проекта средства из этих фондов были направлены на премирование рабочих групп.

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

Системная архитектура — это модель информационной системы, описанная в терминах, понятных бизнесу. Она отражает «суть» системы — ее назначение и базовые принципы устройства, то есть то, что не изменится ни при каких условиях (иначе это будет уже другая система). Например, биллинговая система выставляет счета, принимает по ним оплаты и ведет баланс лицевого счета. Это ее основные функции, определяющие базовые принципы устройства.

Система управления розницей снабжает товаром розничные магазины, организует возврат товара, контролирует межмагазинные перемещения и реализует сегмент учета товародвижения, связанный с розницей (товар на складе и товар в пути).

Система розничного магазина отвечает за автоматизацию всех процессов, связанных с перемещением и учетом товара в розничных торговых точках (кроме бухгалтерского учета).

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

Таким образом, системная архитектура отражает долгосрочные и ключевые договоренности между заказчиком и исполнителем. Как правило, она фиксируется в виде небольшого (около 10-20 страниц) документа. Помимо текста он включает наглядные схемы — графические проекции модели системы. Для его составления требуются опыт и квалификация. Главное, чтобы ключевые участники процесса разработки понимали этот документ одинаково и могли общаться в его терминах.

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

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

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

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

___________

¹'Поппендик М. Бережливое производство программного обеспечения. От идеи до прибыли: Пер. с англ. — М.: Вильямс, 2010. — С. 218—219.

---

Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».