О. А. Йылмаз архитектура предприятия
Скачать 1.65 Mb.
|
Этап 1: Описание или уточнение Общего видения (видение общих требова-ний к архитектуре). Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура инфор-мации, архитектура приложений, технологическая архитектура и пр. Этап 3: Разработка или уточнение Плана реализации. При первой итерации этого процесса разрабатываются только те пред-ставления (view) архитектуры (предметные области, или домены, архитектуры), которые идентифицированы как наиболее приоритетные (2-3 области). Напри-мер, если будет принято решение, что наиболее острой проблемой является ин-вентаризация существующих на предприятии прикладных систем и составление плана изменения их портфеля (вывод из эксплуатации ряда прикладных систем, обновление или разработка новых), то такая область, как Архитектура прикладных систем, должна разрабатываться в приоритетном порядке. После завершения всех трех этапов первой итерации рабочая группа, от-вечающая за разработку архитектуры, продолжает разработку архитектур ос-тальных доменов (предметных областей), не проработанных ранее, с учетом на-копленного опыта и информации на предыдущих итерациях. Итого пересматривая состав этапов можно заметить следующее: Этап 1: Разработка Общего видения архитектуры Общее видение обеспечивает единое понимание проблемы между функци-ональным (бизнес-) руководством и людьми, отвечающими за информационн--коммуникационные технологии. Оно задает контекст для всей последующей разработки элементов архитектуры. Основными элементами Общего видения являются:
Этап 2. Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей На этан этапе ведется параллельная разработка Концептуальной архитек-туры, основанной на ранее определенных принципах и лучших практиках, а так-же более детальная проработка Архитектур отдельных предметных областей. При этом описание архитектуры как минимум включает моде-ли таких областей, как Бизнес-архитектура, Архитектура информации, Архитек-тура прикладных систем и Технологическая архитектура. Необходимо опреде-лить те предметные области, архитектура которых предполагает первоочеред-ную разработку на первой итерации процесса. Заметим, что основой разработки архитектур отдельных предметных обла-стей (доменов) служит Концептуальная архитектура. Концептуальная архитектура обеспечивает общий анализ всех даменов архитектуры с точки зрения идентифицированных на этапе разработки общего видения принципов и факторов влияния. Целью Концептуальной архитектуры является перевод требований, сформулированных в Общем видении, в набор конкретных принципов, которые будут использоваться на этапе разработки ар-хитектуры отдельных предметных областей. Этап 3: Разработка Плана реализации Этап 3 включает в себя следующие два шага:
В крупной организации или, например, в региональном или городском мас-штабе государственного управления работа по разработке архитектуры должна выполняться на нескольких уровнях. На уровне предприятия или регионально-го (городского) правительства должны приниматься общие решения, обеспечи-вающие совместимость и взаимодействие информационных систем, а также вы-рабатываться другие общие требования и стандарты. На уровне отдельных круп-ных бизнес-подразделений или департаментов должны разрабатываться архи-тектуры информационных систем соответствующих структурных подразделений, оптимизированные с учетом их функций, но в рамках общих принципов, опреде-ленных в масштабе предприятия (региона, города) в целом. Одним из результатов совместных усилий по разработке архитектур раз-личных уровней должен быть список информационных подсистем и сервисов, которые носят общий, «горизонтальный» характер, таких как управление общи-ми для предприятия информационными ресурсами и системами, общие системы идентификации и авторизации, общие системы контроля доступа к информаци-онным ресурсам и т.д. При организации архитектурного процесса может оказаться полезным ис-пользование упоминавшегося ранее стандарта IEEE 1471. Этот стандарт опреде-ляет рамочную модель, ориентированную на разработку комплексов с гаранти-рованной надежностью, требуемой, например, в военных, космических и авиа-ционных системах. Такая модель включает в рассмотрение понятия «участника» (stakeholder) и его представлений о целевой системе. На первый взгляд это мо-жет показаться тривиальным - ведь создание любой системы, в том числе и с ис-пользованием классических подходов, начинается со сбора, описания и анали-за требований. Принципиальным в данном случае является признание того фак-та, что в подавляющем числе случаев на практике совокупность требований яв-ляется, с одной стороны, неполной, а с другой - противоречивой. В общем виде можно сказать, что существуют два принципиально различных подхода в разработке Архитектуры предприятия: подход «сверху-вниз» предполагает достаточно широкий охват проблем и точное следование формальному процессу. Основу этому подходу положи-ли методики Захмана и Спивака. Он начинается со сбора информации, тре-бующейся для описания различных доменов архитектуры «как есть». Да-лее следует этап, связанный с описанием и реинжинирингом бизнес-проц-ессов, консолидации прикладных систем, выстраивание архитектуры дан-ных и, наконец, стандартизация технологической архитектуры. Например, многие государственные проекты ориентированы на этот подход (напри-мер, в США в рамках Федеральной архитектуры FEAF). В таблице 1.1 представлены преимущества и недостатки вышеуказанных подходов. Таблица 1.1 «Плюсы» и «минусы» разных подходов при разработке архитектуры предприятия
Подход «снизу-вверх», когда процесс начинается со стандартизации инфра-структурных технологий (технологическая архитектура), а затем развивает-ся в направлении решения проблем более высокого уровня и, в конечном итоге, решает вопросы, связанные с бизнес-архитектурой. Этот подход ви-димо, имеет более широкое распространение в бизнесе и в частном секторе. В зависимости от ряда факторов, предпочтение отдается тому или иному подходу. Например, когда проект разработки архитектуры должен быстро пока-зать отдачу, включая финансовую, или если разнообразие используемых в орга-низации технологий явно приводит к падению качества ИТ-сервисов, то предпо-чтительным является подход «снизу-вверх». Организации, которым нужно ре-шить с помощью архитектуры существенные проблемы, связанные с неэффек-тивностью или большим количеством излишних бизнес-процессов или с наличи-ем перегруженного набора прикладных систем, и которые готовы ждать как ми-нимум год получения видимых результатов от разработки архитектуры, должны использовать подход «сверху-вниз». Наилучшим вариантом, однако, может стать гибридный подход. В любом случае, выбранная стратегия должна отвечать кон-кретным потребностям организации, и в любом случае, требуется поддержка со стороны высшего руководства и понимание того, что создание архитектуры-это долговременный процесс изменений. Как мы уже отмечали, зачастую используется смешанный или гибридный вариант процесса, сочетающий черты обоих подходов. В самом начале проекта (процесса) разработки архитектуры организации очень часто стремятся как можно скорее выбрать одну из известных на рынке методик или создать на их основе свою собственную. Однако в действительнос-ти есть несколько «более первоочередных» моментов, важных для успеха про-екта в целом:
Рассмотрим каждый из этих аспектов более подробно. Прежде всего необходимо понять, какие факторы подталкивают пред-приятие к рассмотрению вопросов разработки архитектуры. Это могут быть, например, макроэкономические факторы, требующие переосмысления вклада ИТ в бизнес, или конкурентная ситуация, требующая новых прикладных систем и обеспечивающей инфраструктуры (например, децентрализации процесса приема заказов). Факторы могут быть связаны с изменениями в бизнес-стра-тегиях, например, с принятием решения об организации более индивидуали-зированной работы с клиентами, что потребует внедрения целого ряда новых информационных систем. Важно понимать, как эти факторы могут быть ис-пользованы при обосновании проекта разработки архитектуры перед высшим руководством. Основная сложность обоснования необходимости архитектурного проекта и выделения соответствующих инвестиций связана с тем, что прогнозируемые результаты обычно предполагают косвенное улучшение бизнеса организации, то есть являются, как правило, качественными и редко могут быть связаны с конкретными финансовыми выгодами. Даже в том случае, когда бизнес-показатели типа «увеличение стоимости акций компании» или «доля на рынке» измеримы, конкретные связи между ними и проведенным реформированием архитектуры предприятия обычно бывают трудно доказуемы. При этом аналитики МЕТА отмечают, что в настоя-щее время более чем в 70% компаний ИТ-служба все еще является центром за-трат, а более 90% ИТ-служб не имеют согласованных с бизнес-руководством фи-нансовых моделей, позволяющих количественно измерить эффект от внедрения ИТ для бизнеса. С точки зрения обоснования цифр экономии практически невозможно дать какие-то общие, применимые на все случаи, оценки затрат, связанных с отсутст-вием архитектуры ИТ. Это зависит от уникальности ситуации в каждой конкрет-ной организации. Экономия может быть достигнута, в частности, за счет сокра-щения расходов, связанных с повторным использованием оборудования или программного обеспечения, за счет сокращения времени разработки, оптимиза-ции расходов на ведение проектов, снижения стоимости технической поддерж-ки, приобретения новых активов или экономии за счет более простой адаптиру-емости системы, построенной на базе единой архитектуры, к изменению требо-ваний бизнеса. Последняя составляющая выгоды обычно становится заметной при сравнении затраченных усилий, средств и времени для проведения измене-ний в различных подразделениях организации с отличающимися исходными ар-хитектурами. В целом, по данным опроса МЕТА, снижение величины расходов на ИТ в расчете на одного сотрудника в случае реализации единой корпоративной архитектуры может достигать величины порядка 30%. По оценке Gartner отсут-ствие архитектуры приводит к 12-18% дополнительных затрат, связанных толь-ко с эксплуатацией ИТ-инфраструктуры. Важно иметь в виду, что учет только прямых финансовых выгод зачастую оказывается недостаточным для оправдания инвестиций, так что приходится ис-пользовать более сложные методики, чтобы включить в обоснование проекта косвенные выгоды для бизнеса организации. С другой стороны, еще одним су-щественным аспектом, который необходимо принимать во внимание при пере-ходе к новой архитектуре, является увеличение рисков, связанное с тем, что ко всем рискам, постоянно присутствующим в ИТ-системе (такими, как выход из строя оборудования или ошибка персонала), добавляются еще и риски, связан-ные с изменениями. Во многих организациях информационные технологии уже исчерпали воз-можности по повышению продуктивности в таких областях, как скорость выпол-нения транзакций и бизнес-процессов. Поэтому традиционное обоснование ин-вестиций в информационные технологии, заключающееся в подсчете возврата на инвестиции (ROI - Return on Investment), может не обеспечить должного ре-зультата. Показатель ROI требует возврата инвестиций в рамках рассматривае-мого проекта, поэтому этот показатель является тактическим по своей природе и не адекватным для задачи обоснования инвестиций в архитектуру информа-ционных технологий. Инвестиции в архитектуру предприятия, эффект от использования которой может быть не столь очевиден в течение трех-пяти лет, требуют иных мер оценки эффективности, Возможной стратегической альтернативой является величина «Возврата на основные фонды» (ROA - Return on Assets), которая будет стимули-ровать компанию оценивать архитектуру ИТ с точки зрения повышения эффек-тивности своих основных фондов. Другим полезным показателем может быть «Возврат на возможность» (Return on opportunity). Он не является формальной финансовой метрикой, но описывает влияние инвестиций на бизнес. По оценкам Gartner, именно продуктивность информационных технологий как основных фондов в среднесрочной перспективе (2007 год) будет опреде-лять рыночную капитализацию компаний. Поэтому рыночная ценность органи-эаций, которые обеспечивают эффективность использования ИТ как основных фондов и тем самым получают более высокую прибыль на единицу инвестиро-ванного капитала, будет возрастать. По тем же прогнозам, к 2007 году корпора-тивная архитектура будет критическим фактором в области управления риска-ми. Скорость реагирования, динамичность (agihty) и гибкость организации, а также прозрачность отчетности будет оцениваться через наличие архитектуры предприятия. Именно архитектура будет задавать уровень риска, которым орга-низация должна управлять. При этом управление рисками осуществляется как на микро-уровне, то есть уровне отдельных проектов, где основной фокус связан с выработкой конкретных мер для снижения определенного риска или с проти-водействием ему, так и на макро-уровне портфеля ИТ-проектов в целом. На этом макро-уровне должен достигаться определенный компромисс между инвести-циями в связанные с высоким риском инновационные проекты и традиционны-ми стандартными решениями, у которых как отдача, так и риск невысоки. Общей задачей будет являться формирование такого портфеля, когда эффекты от ИТ в целом превысят риски потерь. Если бизнес-руководители (которые, в конце концов, выделяют все необхо-димые финансовые ресурсы) не поддержат усилия по выработке архитектуры ИТ, то им стоит готовить себя к еще большим затратам в будущем, поскольку они неиз-бежно окажутся в ситуации, когда они зададут себе вопрос: «Почему же мы тра-тим так много средств для получения таких посредственных услуг от ИТ-службы?» Следует иметь в виду, что при принятии решения о необходимости разра-ботки архитектуры предприятия - пока эффект от нее не доказан практикой,- следует избегать отнесения расходов по ее разработке на бизнес-подразделения организации или на бюджет конкретного ИТ-проекта. Точно так же, как в строительстве существует должность главного архитек-тора города или проекта так и в организации кто-то должен быть ответственным за развитие архитектуры предприятия в целом, а информационных систем в частности. С уче-том отмеченной ранее тесной связи между архитектурой информационных тех-нологий и бизнес-архитектурой, один и тот же человек может отвечать за обе эти области. По оценкам МЕТА Group, должность «Главного архитектора» введена при-мерно в 30% компаний. Собственно название этой должности, вообще говоря, может быть любым, так что за разработку архитектуры могут быть ответственны-ми, например, «Заместитель руководителя ИТ-службы» или «Директор по ИТ-стратегии». Гораздо более важным является статус данной должноспги в орга-низации. Существует большое количество примеров, когда такое «громкое на-звание» должности на самом деле используется одним из рядовых аналитиков в составе ИТ-службы, у которого нет реальных прав и возможностей влияния на ситуацию. В этом случае ответственность на практике размазывается (со всеми вытекающими из этого последствиями) по всей команде проекта, а то и по всем руководителям подразделений в ИТ-службе организации. Еще большую акту-альность эти вопросы могут иметь для государственных организаций и разра-ботки архитектуры «электронного правительства». Интересным является вопрос об оптимальном составе команды проекта по разработке архитектуры. Обычно выделение отдельных структур считается це-лесообразным для достаточно больших по размеру ИТ-служб, насчитывающих порядка 100 и более сотрудников. Даже для больших организаций рекомендует-ся ограничивать состав основной команды 7-8 сотрудниками, а для более де-тальной проработки доменов архитектуры (частных архитектур данных, прило-жений и пр.) создавать отдельные проектные группы. В меньших организациях чаще используется матричный метод когда в ко-манду проекта входят представители различных подразделений. Однако в лю-бом случае принципиальным скорее является не наличие или отсутствие фор-мальной кадровой структуры, а применение соответствующих методологий для формирования архитектуры и управления всем процессом. Для Главного архитектора такие качества, как положительная харизма,уве-ренность при общении с высшим руководством, системный подход и осведом-ленность в бизнесе, умение распределять работу между подчиненными могут явиться более критичными, чем знание конкретных технологий. Оптимальный состав команды, по мнению МЕТА, должен включать специа-листов со следующими ролями: | ||||||||||||||||||
Похожие:
 | Программа дисциплины ит-инфраструктура предприятия Компоненты архитектуры информационных технологий (ИТ). Процессы управления ит. Бизнес-архитектура. Архитектура инфраструктуры. Понятие... | | Программа дисциплины ит-инфраструктура Компоненты архитектуры информационных технологий (ИТ). Процессы управления ит. Бизнес-архитектура. Архитектура инфраструктуры. Понятие... |
| Программа дисциплины «Архитектура предприятия» для направления 080500. 62 «Бизнес-информатика» Программа предназначена для преподавателей, ведущих данную дисциплину, учебных ассистентов и студентов направления подготовки 080500.... | | Программа дисциплины «Современные erp-системы» «Теория информационных технологий и систем», «Архитектура корпоративных информационных систем» а также иметь представление о современных... |
| Инновационно-инвестиционная деятельность в электронном бизнесе преподаватель... Архитектура предприятия (продвинутый уровень). Управление электронным предприятием |  | Предпринимательская деятельность Руководитель предприятия. Отношения руководителя предприятия и собственников предприятия |
| Управление доходами и рентабельностью предприятия Доходы и расходы предприятия влияют на финансовый результат предприятия, целью же любого предприятия является получение прибыли.... | | Тема урока Колич часов Введение в искусство архитектуры. Архитектура и среда. Архитектура и ее функция в жизни человека |
| Рабочая программа Основной образовательной программы (ооп) Специальность 270301 «Архитектура» «Архитектура, специализация «Дизайн интерьера», утвержденных Министерством образования РФ 29 апреля 2002 г., №20-2902 – Б | | Реферат Основной целью дипломной работы, является применение процедуры... Ооо «Орион». В связи с поставленной целью проводится анализ показателей финансового состояния предприятия. Рассчитываются показатели... |
| Реферат «архитектура древнего рима» Связанная в своем развитии с постоянно меняющимися материальными потребностями человека, с развитием науки и техники, архитектура... | | Содержание Введение 3 Заключение 5 Список литературы 6 Эффективное управление оборотными средствами предприятия имеет огромное значение для достижения максимально возможного уровня прибыльности... |
| Рабочая программа Учебной дисциплины архитектура предприятия для... Программа составлена в соответствии с Федеральным государственным образовательным стандартом высшего профессионального образования... | | Реферат по курсу: Архитектура вс на тему: Архитектура квантовых компьютеров Квантовые компьютеры на основе молекул органических жидкостей с косвенным скалярным взаимодействием между ними и методов ядерного... |
| Реферат по курсу: Архитектура вс на тему: Архитектура квантовых компьютеров Квантовые компьютеры на основе молекул органических жидкостей с косвенным скалярным взаимодействием между ними и методов ядерного... | | Программа дисциплины «Архитектура предприятия» для направления 080500. 62 «Бизнес-информатика» Программа предназначена для преподавателей, ведущих данную дисциплину, учебных ассистентов и студентов направления 080500. 62 «Бизнес-информатика»... |
