Опубликован: 03.02.2016 | Доступ: свободный | Студентов: 1332 / 259 | Длительность: 07:40:00
Лекция 5:

Сопровождение и развитие созданных архитектур программного обеспечения

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

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

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

Введение

После того, как программный продукт вышел на стадию промышленной эксплуатации, начинается процесс его сопровождения.

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

Если "видение" будет иметь достаточно четкие цели, то функциональность и архитектура программного продукта постепенно эволюционируют в направлении повышения качества бизнес процессов компании. Это будет сказываться на эффективности деятельности и результатах.

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

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

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

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

Роль и качества архитектора программного обеспечения

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

Множество руководителей испытывают определенные проблемы с наймом сотрудников на должность системного архитектора.

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

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

Один из "отцов" современного витка развития области информационных технологий, Мартин Фаулер, выделяет следующие архитектурные роли:

  • "Architectus Reloadus" – сотрудник-руководитель, принимающий большинство важных решений в процессах жизненного цикла программного продукта и делающий это по причине того, что "единый разум необходим для обеспечения концептуальной целостности системы", а также, вероятно, и потому, что "архитектор не верит в достаточно высокий для принятия таких решений уровень членов своей команды";
  • "Architectus Oryzus" - человек, осведомлённый обо всём, что происходит в проекте, следящий за всеми трудностями и помогающий их устранить до того, как они превратятся в серьёзные проблемы, программирующий вместе с разработчиками, работающий над требованиями, помогающий предвидеть и объяснять технические последствия нетехнических идей и требований.

Многообразие характеристик, которые выделяет Фаулер, говоря о архитекторе свидетельствует о том, что на современной стадии развития области информационных технологий нет устоявшегося профиля данной профессии и многое определяется на уровне личных качеств конкретного сотрудника.

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

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

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

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

Далее мы приведем список качеств и их "содержание", которые позволят системным архитекторам быть эффективными и добиваться поставленных результатов.

  • Авторитет

Пожалуй, самая важная и значимая характеристика системного архитектора, грамотное развитие и балансирование которой приносит наибольший вклад в достижение конечного результата. Авторитет системного архитектора не стоит путать с авторитетом, "заработанным" на позициях, в которых находился сотрудник, двигаясь по пути к роли системного архитектора. Безусловно, базис навыков, закладываемый успешным опытом позиций разработчика/аналитика/консультанта/тестировщика важен, но если системный архитектор не будет в состоянии предлагать результативные, и при этом эффективные, решения для продукта в целом, то он будет выглядеть недостаточно компетентным. Команда должна быть успешной. Доступность в общении системного архитектора не всегда способствует в достижении этой цели, а в большинстве случае, наоборот, мешает наработке авторитета и обоснованности вопросов к нему, заменяя это "дружеским" общением и подмене значимости архитектора, как проводника и "реализатора" архитектурных замыслов. Архитектор будет вынужден каждый раз не просто объяснять, а доказывать каждому члену команды целесообразность и необходимость каждого, даже самого мелкого решения, тратя на это бесценные силы.

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

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

  1. Отсутствие обратной связи от сотрудников

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

  2. Исключение возможности ошибки

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

  3. Синдром высокомерной замкнутости

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

  • Готовность и способность к взаимодействию

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

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

  • Определение наиболее эффективного и адаптируемого рабочего процесса

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

  • Дипломатичность

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

  • Ограничениях, накладываемых бизнес процессом или выбранной технологией реализации;
  • Необходимости минимизации бизнес/технических рисков;
  • Расхождении в требованиях, предъявляемых к программному продукту, различными заинтересованными сторонами.

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

  • Инициативность

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

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

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

  • Абстрактность мышления и способность, как к анализу, так и к синтезу информации

Системный архитектор должен уметь трансформировать неопределенное выражение, сформулированное в виде набора разрозненных бизнес или "околотехнических" понятий, в четкий и осязаемый результирующий артефакт процессов архитектурного проектирования, который смогут оценить все заинтересованные стороны разрабатываемого программного продукта. Его задача состоит в диагностировании абстрактных образов и связывании их с конкретными терминами и выражениями. Кандидаты на эту роль (о теме откуда "брать" системных архитекторов мы поговорим немного позже) часто берут на себя ответственность объяснить коллегам и руководству запутанные и трудноразрешимые проблемы, возникающие на протяжении всего жизненного цикла информационных систем. К ним быстро приходят оптимальные идеи, и они способны представить их в виде конкретных практических предложений, позволяющих продолжить успешное движение к достижению поставленных целей. Архитектор, безусловно, должен обладать глубокими знаниями и опытом для эффективного решения технических проблем, но он также должен четко представлять себе, как конечные пользователи будут взаимодействовать с разрабатываемым функционалом программного продукта.

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

  • Стадия анализа информации

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

  • Стадия проектирования

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

  • Стадия реализации проекта

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

  • Стадия тестирования

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

  • Стадия поддержки и обслуживания

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

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

Где же найти этих людей, которые смогут с успехом выполнять задачи системного архитектора? В каких учебных заведениях их готовят (и готовят ли)?

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

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

Кроме аспектов образования и самообразования необходимо привести аспекты "внешней" среды, в которой формирование системных архитекторов происходит более плодотворно, по сравнению с другими компаниями.

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

< Лекция 4 || Лекция 5: 12
Геннадий Андреев
Геннадий Андреев
Россия
Артемий Соболев
Артемий Соболев
Россия, Томск, Томский политехнический университет, 2006