Проектные работы по развитию ИТ архитектуры предприятия

ДЛЯ РЕШЕНИЯ ПРОБЛЕМ, ВОЗНИКАЮЩИХ НА ЭТАПЕ РЕАЛИЗАЦИИ IT-ПРОЕКТА

научно-технический журнал «ТЕОРИЯ. ПРАКТИКА. ИННОВАЦИИ» ИЮНЬ 2017
http://www.tpinauka.ru/2017/06/Tukmacheva.pdf

В данной статье

рассматривается IT-компания, которая претерпевает трудности в проектной деятельности, такие как закономерные задержки в части сдачи сроков по проекту. Решение выявленных проблем осуществляется с помощью построения архитектуры проектной деятельности компании, используя модель Захмана.

поток информации. Раз за разом этим потоком становится все труднее

управлять. Предприятия не успевают оценивать, как будут взаимодействовать между собой отдельные элементы предприятия, как будет проходить интеграция отдельных технологических решений. Из-за озвученных выше проблем по оценкам различных консалтинговых компаний, примерно 50% ИТ-проектов в различных отраслях заканчиваются не так, как запланировано [3]. Одним из путей решения является методика построения архитектуры предприятия. Архитектура предприятия — это современная, инновационная и высокоэффективная концепция стратегического управления, использование которой позволяет быстрее и более целенаправленно изменять предприятие для реагирования на вариации внешней среды [2

времени. Также архитектура – это процесс, т.е. набор руководств, правил

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

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

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

Group и другими;
· Модель Захмана;
· Методика TOGAF;
· Методика POSIX 1003.23,

которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.
· FEAF – Federal Enterprise Architecture Framework (для гос. организаций)
· DoDAF ­– для Министерства Обороны США

Они позволяют решить проблему плохого взаимопонимания между вовлеченными в этот

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

более конкретно к процессу реализации IT-проектов для решения выявленных проблем.

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

За все время деятельности уже разработано не мало информационных систем,

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

автором было принято решение проанализировать деятельность копании в части осуществления

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

информационных систем и для разных заказчиков, а проблемы по затягиванию

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

строка представляет собой видение системы с конкретной точки зрения. Все

участники рассматривают одни и те же категории вопросов, соответствующие столбцам таблицы

(как?); 
Места выполнения этих процессов (где?); 
Участники и

ключевые организации (кто?); 
Управляющие события (когда?);
Цели и мотивация (зачем?).

бизнес в целом;
менеджер, рассматривающий структуру организации в бизнес терминах;

архитектор, описывающий бизнес-процессы в терминах информационных систем;
проектировщик, разрабатывающий модель БД и осуществляющий привязку бизнес-процессов к данным;
и разработчик, отвечающий за реализацию бизнес-процессов. Сама матрица представлена на Рисунке 1.

зрения разработчиков, не совсем относится к самой системе. Каждый разработчик

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

«As is»
о

со всех проектов, которые разрабатываются на предприятии. В такой ситуации

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

в проекте. Это может привести к подрыванию доверия со стороны

Заказчика. Чтобы избежать такой ситуации, автором предлагается следующая модель проектной деятельности (модель «To be»), представленная на Рисунке 4.

проектной группы будут входить: руководитель проекта, бизнес и системные аналитики,

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

с моделью «As is» (в части реализации проекта), но как

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

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

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

обеспечивает общий словарь и набор перспектив, или структур (framework), для

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

разбить все описание Архитектуры на отдельные разделы для упрощения их

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

– представления (области) архитектуры.
Модель представляется в виде таблицы, имеющей пять

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

уровню управления предприятием, если речь идет об архитектуре предприятия или

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

уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует

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

и те же категории вопросов, соответствующих столбцам в таблице, –

только с различным уровнем абстракции и детализации.

функции (как?)
· места выполнения этих процессов (где?)
· организации и персоналии–участники

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

они образуют функционально полное пространство для описания системы ("базис");
· порядок

следования колонок несущественен;
· каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
· базовые модели для каждой из колонок являются уникальными;
· соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
· заполнение клеток должно проводиться последовательно "сверху вниз"

этом уровне вводятся достаточно общие основные понятия, определяющие бизнес –

например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация).
 

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

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

привязка данных и операций над ними к выбранным технологиям реализации.

Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.

топологию сети, производителя и версию СУБД, средства разработки и собственно

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

в системе данные. На верхнем уровне достаточным будет простое перечисление

основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы "сущности-связи" (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п.

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

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

организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех

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

планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими

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

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

календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы.

порядок перехода от задач бизнеса к требованиям и элементам информационных

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

в отношении предприятия, то есть каждая проблема может быть соотнесена

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

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

на (относительно) независимых параметрах для целей анализа;
· но в то же время обеспечивает поддержку контекстных взаимосвязей, важных для сохранения целостности системы.
Минус: отсутствие встроенного механизма распространения изменений между элементами – сложно вносить изменения.