ЛЕКЦИЯ 8 18 страница

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

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

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

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

Другой важной задачей начального этапа будет выбор и согласование вну-три команды наиболее подходящей методики или модели (framework) для де-тального описания архитектуры. В главе 2 рассмотрены несколько распространенных методик и даже указаны некоторые сравнительные характе-ристики. Какой-либо одной, обязательной к применению методики не существу-ет - каждая организация вправе выбирать ту, которая наиболее для нее удобна. Самым целесообразным будет выбор одной из методик в качестве основной с дополнением элементов других методик. Необходимым шагом будет документи-рование выбранного решения (или точнее, выбранного подмножества) с тем, чтобы это краткое, не более чем на 10 страниц, описание могло быть использо-вано командой проекта в качестве методологической основы.

Другими важными документами, которые будут использоваться в качестве основы, являются:

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

· процедуры рассмотрения и разбора исключительных ситуаций и отклоне-ний от стандартов архитектуры.

В целом, как отмечается в публикации, для успеха архитектурного проекта необходимы следующие пять элементов:

· тщательное планирование;

· адекватное финансирование и обеспечение ресурсами (участники, время);

· мотивация и реализация («кнут и пряник»);

· талант и квалификация команды;

· видение цели.

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

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

· недостаточная мотивация персонала команды может быть связана с ощу-щением «работы на полку» - если разработанные архитектурные решения не будут поддержаны соответствующими организационными мерами и по-литикой реализации на практике;

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

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

Создание организационных структур и выстраивание процесса управления разработкой, практическим использованием и обеспечением соответствия при-нятой архитектуре является одним из ключевых факторов успеха. Для этого процесс в английском языке используется термин «governance». Таким образом, эта функция управления и контроля включает два аспекта:

Дата добавления: 2015-04-25