Информационные технологии и управление предприятием

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

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

Рис. 7.1. Модель архитектуры предприятия

Зачем требуется понятие архитектуры

Использование понятия «архитектура предприятия» позволяет установить связь между бизнесом предприятия и параметрами информационной системы – функциями системы и интероперабельностью данных.

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

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

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

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

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

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

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

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

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

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

• приведение предприятия в соответствие с намерениями – реальное обеспечение того, что преобразованное предприятие будет соответствовать исходным требованиям;

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

• облегчение управления изменениями в любых аспектах предприятия:

– конвергенция – использование стандартных информационных технологий;

– улучшение связи между основными подразделениями и подразделениями информационных технологий в пределах всего предприятия на основе использования стандартизированного словаря;

– наглядное представление предприятия, которое помогает связывать и описывать большие системы и облегчает управление в сложных средах;

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

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

• совершенствование процессов планирования капиталовложений и инвестиционного управления;

• появление возможностей повышения качества и гибкости используемых приложений без увеличения затрат (стандартизация);

• достижение экономии на основе совместного использования услуг в масштабах всего предприятия;

• упрощенная интеграция наследуемых, перемещаемых и новых систем.

Описание слоев архитектуры

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

• бизнес-слой;

• архитектура данных;

• интеграция физических данных;

• концептуальная модель/модель процессов;

• архитектура приложений;

• технологическая архитектура;

• техническая модель.

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

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

•  персональные контакты (личные встречи, телефонные переговоры, видеоконференции);

•  электронные средства (факсимильная связь, Web-браузеры, информационные киоски и др.);

•  бумажные документы (подача бумажных документов с помощью традиционной почты);

•  сервис-провайдеры (коммерческие поставщики услуг или предприятия смешанного типа).

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

Для поддержки интероперабельности данных необходимо:

• использовать стандартные синтаксисы;

• применять промышленные словари с момента начала разработки и использовать их в качестве отправной точки;

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

• обеспечивать совпадение семантики разделяемых (совместно используемых) элементов данных;

• использовать стандартные интерфейсы для услуг документирования.

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

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

Секретность, как и безопасность, должна отражаться во всех компонентах модели интероперабельности.

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

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

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

Техническая модель показывает, как взаимодействуют те или иные компоненты.

Архитектура информационной системы

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

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

Элементы информационной системы (такие, как сетевое оборудование, серверы, средства хранения данных, системное ПО, стандартные приложения и т. п.) оцениваются с учетом ситуации в отрасли, степени использования в организации, целесообразности исключения из системы в течение перспективного срока (старение) или временного сохранения, целесообразности развития, целесообразности проведения переоценки его роли в будущем. При определении стратегии обычно выделяются среднесрочный (12–24 месяца) и перспективный (24–60 месяцев) периоды (рис. 7.2).

Рис. 7.2. Периоды планирования

Оценка перспективности развития проводится с учетом следующих факторов:

• стратегии развития, расширения бизнеса, изменения отношений с клиентами и поставщиками;

• общемировых тенденций развития информационных технологий;

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

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

• управление приложениями;

• управление данными;

• управление информацией;

• управление пользователями и их доступом;

• сети и коммуникации;

• платформы;

• управление системами;

• информационная безопасность и т. п.

Домены, в свою очередь, включают несколько функциональных областей, например, в домен «Управление системами» входят следующие области:

• управление активами (Asset management);

• управление изменениями (Change management);

• управление событиями (Event management);

• поддержка пользователей (Help Desk);

• обеспечение непрерывности бизнеса (Business continuity) и др.

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

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

Домен:

• описание, область охвата (какие аспекты ИТ-системы входят/не входят в данный домен);

• функциональные области, принципы, лучшие практики, тренды.

Функциональная область:

• описание, область охвата, ссылка на домен;

• кросс-ссылки на другие функциональные области;

• методологии, технологические области;

• требования к документированию.

Технологическая область:

• описание, ссылка на функциональную область;

• обоснование выбора единственного или множественных продуктов (вендоров, приложений).

Продукт/приложение:

• описание, ссылка на технологическую область;

• информация о вендоре, классификация;

• условия использования, политика миграции.

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

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

• документирование, рецензирование, информирование, изменение;

• проверка соответствия, поддержка актуальности;

• организация управления разработкой.

Метод Захмана

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

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

Рис 7.3. Формализованное представление модели предприятия по методу Захмана

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

Рис. 7.4. Типы моделирования

Использование моделей (рис. 7.5) на разных стадиях развития системы проиллюстрировано в табл. 7.1.

Рис. 7.5. Модели развития системы

Таблица 7.1. Использование методов моделирования

Примечание к табл.:

о – обязательное использование;

н – не обязательное, но возможное использование.

В 1987 году Джон Захман опубликовал полезную схему развития архитектуры информационной системы. Такая схема создает контекст для описания различных представлений архитектуры разрабатываемой системы. Эти представления соответствуют тому, как видят систему ее заказчик, проектировщик и разработчик, причем в разрезе трех выбранных аспектов, к которым относятся данные, функции и сетевая структура. В схеме Захмана строке соответствует точка зрения какого-либо участника проекта по созданию системы. Аспекты представлены в схеме колонками (рис. 7.5).

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

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

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

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

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

Три аспекта, рассмотренных в схеме, приводят к различным архитектурным представлениям каждой из точек зрения. Аспекты соответствуют вопросам «Что?», «Как?» и «Где?», относящимся к конечному продукту (информационной системе). Каждому аспекту соответствуют разные методы формирования представления.

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

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

Колонка сетевой структуры соответствует вопросу «Где?». Архитектурные представления в этой колонке описывают местоположение элементов системы и механизмы их взаимодействия.

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

Глава 8 Методика создания корпоративных информационно-управляющих систем

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

Последние годы отмечены качественным расширением понятия «система», широко используемого в международных комитетах и профессиональных сообществах, ориентированных на информационные технологии. На современном этапе под системой понимается «комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям». Следует сказать, что это определение достаточно близко к определению понятия «автоматизированная система», приведенного в ГОСТ 34.003-90 (Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Термины и определения): «в процессе функционирования автоматизированная система представляет собой совокупность технических средств, организационно-методических и технологических документов и специалистов, использующих их в своей профессиональной деятельности».

В стандартах присутствует и четкое определение понятия «ИТ-система». Так, в ГОСТ Р ИСО/МЭК ТО 10000-1-99 информационно-технологическая система определяется как «набор информационно-технологических ресурсов, предоставляющий услуги по одному или нескольким интерфейсам».

Для целей данной книги используется понятие КИУС, эквивалентное понятию ИТ-системы.

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

• программного обеспечения;

• информационного обеспечения;

• технических средств;

• обслуживающего персонала.

Экономическими предпосылками создания и использования КИУС являются:

• обеспечение гибкости рыночной стратегии;

• эффективное взаимодействие с партнерами;

• эффективная работа с клиентами;

• эффективное управление ресурсами и процессами;

• оперативное получение достоверной информации;

• анализ больших информационных объемов.

В современных условиях руководителей предприятий интересует:

• агрегация данных (а не обилие конкретных значений);

• динамика, перспективы, тенденции (а не статика);

• корпоративные решения (а не решения для подразделений);

• минимальные затраты на поиск требуемой информации;

• полнота и непротиворечивость информации;

• аналитические срезы для поддержки принятия решений.

С их стороны к корпоративным системам в современных условиях предъявляются следующие требования:

• решение всего комплекса задач бизнеса;

• сбалансированная стоимость владения;