Архитектура предприятия что же это такое и что включает в себя, история, значимость, начну обо всем по порядку.
Архитектура предприятия – концепция Архитектуры предприятия, которая включает в себя такие аспекты, как Бизнес‐архитектура, Архитектура информации, Архитектура прикладных систем и Технологическая архитектура, является способом объединения и синхронизации функциональных и бизнес‐потребностей организаций с возможностями информационных технологий в условиях их сложности.
Понятие "архитектура предприятия" появилось в 1987 г. в статье Дж. Захман "Структура архитектуры информационных систем", опубликованной в журнале " IBM Systems Journal".[?] Видение Захмана заключалось в том, что для обеспечения высокой ценности и гибкости бизнеса необходим целостный подход к архитектуре систем, в рамках которого каждая существенная проблема рассматривается с разных точек зрения. Такой подход к созданию архитектуры систем представляет собой то, что Захман изначально называл архитектурной структурой информационных систем, а впоследствии – структурой архитектуры предприятия.
В последующем Захман внес вклад в разработку архитектуры ИС Министерства обороны США. Эта попытка была предпринята в 1994 г., а сама концепция получила название "Базовая архитектура технического обеспечения для управления информацией" (Technical Architecture Framework for Information Management – TAFIM).
С этого периода началось активное развитие идеи архитектуры предприятий и организаций.
В 1998 г., четыре года спустя после разработки TAFIM и два года спустя после оформления этой методологии в виде акта Клингера – Коэна, методология TAFIM была официально отменена Министерством обороны. Все наработки по TAFIM были преобразованы в открытую группу, а затем – в новый стандарт, известный в настоящее время под названием TOGAF (The Open Group Architectural Framework). ([i])
Актуальность. Сегодня все больше руководителей и аналитиков начинают испытывать потребность в комплексном описании и планировании развития своей организации. Это им нужно как минимум для того, чтобы знать, что’ их организация представляет собой в реальности, поддерживать рациональный порядок ее устройства, а затем — приступить к ее планомерному развитию или трансформации с учетом всех важных обстоятельств. Таким целям служит «Архитектура предприятия» (АП, Enterprise Architecture) — важнейшая комплексная дисциплина нового времени. В мире наблюдается настоящий бум работ в этой области, в штатных расписаниях позиция «Enterprise Architect» заняла устойчивое положение, ведущие университеты разработали углубленные курсы и выпускают квалифицированных специалистов данного профиля.
В нашей стране подходы, затрагивающие развитие архитектуры предприятий, ограничиваются некоторым распространением должности «системный архитектор», а также попытками немногочисленных вузов включить обзорные разделы в другие курсы — по реинжинирингу бизнес-процессов или системной инженерии. Однако и в лидирующих по применению АП странах путь развития и применения этой дисциплины был вовсе не гладким, и здесь есть своя поучительная логика.
Одной из целей дипломной работы является попытка проследить условия появления и развития АП как дисциплины, выделить причины успехов и затруднений. А возможно — сказать и о вероятных направлениях её дальнейшей жизни. Все это может помочь в принятии решений о разворачивании архитектурных работ на конкретных предприятиях. Есть и другая цель: напомнить коренные задачи комплексного архитектурного подхода, которые часто забываются при освоении «навороченных» архитектурных методик и инструментов. Тем более что в практике формирования архитектур часто оказываются вполне работоспособными принципы и модели, введенные в жизнь еще пятнадцать лет назад.. [ii]
Стимулы оформления АП
Причины введения в оборот современных толкований предприятия и его архитектуры лежат в тех изменениях в жизни предприятий, которые начали происходить ещё в 70-х и 80-х годах. Среди главных изменений — начало перехода от рынка продавца к рынку потребителя, TQM (Total Quality Management) и конкуренция японских компаний как в мире, так и на внутреннем рынке США. Это побудило Эдвардса Деминга преобразовать методы повышения качества в подход CPI (Continuous Process Improvement), который проник в практику предприятий США. В единый комплекс были сведены цели и задачи бизнеса в конкурентной среде, особая ценность и роль людей, свойства используемых машин и технологий, аналитический подход к поиску причин имеющих место потерь и способов повышения конкурентоспособности, к опоре на измеримые показатели деятельности. Такое целостное представление было зафиксировано в четырнадцати принципах Деминга, которые в явном виде задавали как философию управления и культуру работников предприятия, так и постоянные изменения его процессов, в первую очередь за счет совершенствования базовых технологий и процессов.
В остро конкурентной среде организация бизнес-деятельности оформилась в виде комплексной дисциплины маркетингового управления предприятием (в первую очередь marketing management Ф. Котлера и М. Портера). Учитывалась необходимость преобразования всех компонентов предприятия(оргструктур, ценностных установок отдельных работников, базовых технологий и т. д.), учета всех различий территорий (рынков), на которых оно планирует работать, — от ценовых до культурных. Параллельно с этим процессный подход к совершенствованию предприятия стал выделяться в более явной форме и в конце 80-х годов вместе с идеями CPI проник в стандарты CMM (Capability Maturity Model).
Заметим, что в 80-х годах много говорилось о явно недостаточной отдаче, получаемой бизнесом от ИТ. Поэтому возросла значимость методов согласования ИТ-систем с реальными потребностями бизнеса — то, что и сегодня часто выделяется в отдельное направление «business & IT alignment». Так, в IBM длительное время развивалась методика BSP (Business Systems Planning), направленная на то, чтобы архитектура ИС выводилась из потребностей бизнеса и их приоритетов. Существовали и другие работы в этой области, но именно ведущие специалисты IBM по планированию архитектуры ИС дали определяющий толчок развитию АП как дисциплины.
В целом же в первую очередь нарастание именно бизнес-проблем, а затем развитие применения ИТ привело к тому, что стали востребованными комплексные методы описания предприятия, согласования различных его компонентов между собой (особенно таких «непонятных», как ИТ) и соответствующих трансформаций.
Первый виток АП
В этой ситуации в 1987 году появились первая, а в 1992‑м — вторая (в соавторстве с Дж. Сова) [1] статья Джона Захмана, в которой был предложен вариант обобщенной схемы или структуры (framework, или «фреймвок») для описания и анализа архитектуры: формально (по названию) еще архитектуры ИС, но по содержанию — уже предприятия. Схема Захмана давно стала стандартом де-факто и приобрела у нас популярность, однако разработанные для нее правила менее известны. Для сохранения логики изложения нужно напомнить ее основные свойства. Схема получила форму матрицы 6×6, в которой каждая ячейка задает свой тип описания (модели) свойств предприятия. Вся совокупность ячеек разделена на шесть столбцов матрицы — шесть аспектов деятельности предприятия:
- «ЧТО делается», или объекты/данные;
- «КАК делается», или функции/процессы;
- «ГДЕ делается», — размещение или инфраструктура;
- «КТО делает» — люди, орг. единицы;
- «КОГДА делается» — графики событий и работ;
- «ЗАЧЕМ делается» — стимулы, мотивы и стратегии деятельности.
Эти аспекты предлагается описывать в шести разных, но связанных представлениях, сгруппированных в строки матрицы. Для строк-представлений Захман применил аналогии с классическим архитектурным делом и строительством. Верхняя строка матрицы фиксировала представление «планировщика застройки», который рассматривает не одно здание, а все его окружение и то, как в это окружение вписывается здание. Вторая строчка фиксировала представление «владельца дома», третья — представление дизайнера, четвертая — того, кто будет руководить собственно строительными работами, пятая — взгляд тех, кто будет выполнять отдельные работы, а шестая относилась к эксплуатации дома. Посредством этой аналогии для АП задавались представления предприятия с позиций бизнеса, аналитиков-проектировщиков ИС, а также их разработчиков..)
Изначально матрица Захмана и описание ее применения были предназначены для совершенствования методики IBM BSP, однако вскоре стало ясно, что ее предназначение гораздо шире. В 1992 году Захман писал о своём удивлении по поводу того, как быстро его подход стал стандартом де-факто. Сегодня можно уверенно сказать, что это объясняется потребностями в комплексном рассмотрении предприятия и его ИТ, о которых говорилось выше, а также простотой представления матрицы (особенно в варианте 1987 года). По-настоящему удачной оказалась форма этой обобщенной схемы, воспринимаемая как своего рода таблица Менделеева для АП. Весьма ценной на мой взгляд явилась и аналогия с классическим архитектурным и строительным делом. Наконец, матрица Захмана много давала не только для соотнесения бизнеса и ИТ, но и для согласования работ в команде проектировщиков ИС. Надо сказать, что в работе 1992 года были заявлены и другие редко упоминаемые, но концептуально важные идеи, в частности:
- рекурсивность логики формирования моделей и метамоделей на основе одной обобщенной схемы;
- использование репозитория архитектурной информации для работы с разными моделями и их состояниями;
- управление архитектурой и изменениями предприятия на основе репозитория.
Для наглядного представления как происходит сам процесс инициации и формирования архитектуры я решил проиллюстрировать на примере
На этом рисунке отображена цель создания архитектуры и участники. Особенность данной схемы реализации заключается в том, что обратная связь здесь возникает между всеми и начальниками и подчиненными а сам процесс разбит на 4 этапа. В таких условиях будет легко определить слабое звено, если архитектура даст сбой. Успешность мероприятия заключается в заинтересованности участников в качестве выполняемой работы. В результате потребитель получает качественный продукт, а производитель автоматизированный процесс по его получению. Остается лишь совместить этот процесс с маркетингом, отобрав сильные стороны продукта, в итоге маркетинг становится главной задачей так, как в результате высокой конкуренции рынок производителя перешел в рынок потребителя. Это происходит до тех пор пока архитектура и товар не потребует изменений, а затем и маркетинг вновь подвергается изменениям.
Вообще архитектура предприятия нужна лишь производителям поскольку она подразумевает автоматизацию производства и снижение затрат на контроль и сокращение работников не требующихся для автоматизированного производства. Этот подход имеет как преимущества так и недостатки.
Рассмотрим преимущества: Снижение себестоимости продукта, увеличивается покупательская способность, повышение качества продукта за счет ликвидации человеческого фактора, отсутствие брака, амортизационные отчисления быстрее окупят автоматизацию т.к. снижаются затраты на работников. Главным показателем работы предприятия становится лишь график сбыта, поэтому бизнесмену будет проще ориентироваться в ситуации, он будет точно знать, по графику причину тех или иных событий, поскольку они будут связаны либо с рекламной работой, либо архитектура требует коррекции. Недостатки: Социальная роль бизнеса уходит на 2й план, остается лишь интерес бизнесмена, поскольку подход требует сокращений персонала, незаметные на 1 взгляд сбои в ИТ- инфрастуктуре могут привести к уничтожению целой партии товара, что приведет к серьезным затратам, дефицит персонала в стране по обслуживанию автоматизированного производства (увеличивает риск неустойчивости архитектурного звена).
А что же архитектура представлет из себе изнутри? Она подразделяется на 4 структуры:
Бизнес архитектура.
· предлагаемые и планируемые к реализации банком продукты и услуги (включая индивидуальные схемыих производства), формализованные в виде единого реестра продуктов и услуг, содержащего такжеклиентскую сегментацию, тарифы и владельцев продуктов;
· каналы продажи продуктов и услуг, построенные как на базе структурных и территориальныхподразделений предприятия, так и на базе современных информационных технологий;
· функции и процессы по реализации внешних и внутренних продуктов и услуг, образующие деревьяфункций и процессов (далее - бизнес-функции и бизнес-процессы);
финансовые и распорядительные документы (как в бумажном, так и в электронном виде),формализованные в виде единого реестра (альбома форм) документов банка;
· документопотоки, определяемые нормативными актами по внутреннему и внешнему документообороту;
· организационную структуру предприятия, включая штатное расписание предприятий и еготерриториальных подразделений, являющихся самостоятельными хозяйствующими единицами(юридическими лицами), комитеты, рабочие группы и ролевые функции отдельных сотрудников,должностные инструкции, положения о подразделениях и рабочих органах и другие документы,регламентирующие взаимоотношения и распределение ответственности между сотрудниками банка, атакже между структурными подразделениями банка.[iii] 
Информационная архитектура
Эта сфера знаний пока относительно нова, и находится в стадии развития; следовательно определение информационной архитектуры зависит о того, кто его дает. Вот определение, которое нравится нам:
Информационная архитектура занимается принципами систематизации информации и навигации по ней с целью помочь людям более успешно находить и обрабатывать нужные им данные.
Это означает, что оптимизация поисковой программы на вашем сайте с целью помочь посетителям быстрее найти то, что им нужно, является информационной архитектурой (information architecture - IA). Оптимизация же поисковой программы для балансирования нагрузки в ведение IA не входит. Разработка системы надписей в меню навигации на сайте - является IA. Решение о том, каким цветом будет оформлено это меню навигации уже не в ведении IA.
Почему так велико значение IA? Ну, например, представьте себе, что вы вложили несколько миллионов долларов в свой сайт. С эстетической точки зрения он выглядит великолепно, технологически совершенен, и на нем полным полно прекрасного материала. Но вот вы узнаёте, что пользователи не могут найти нужную им информацию, а вы сами не можете определить, куда следует положить новый материал и когда следует убирать старый. Вот здесь-то и возникает необходимость обратиться к информационной архитектуре.
Или представьте, что работники вашей компании испытывают такие трудности с поиском ответа на вопросы, которые задают им ваши клиенты, что они распечатывают каждую страницу интранет-сайта, так как боятся, что снова не смогут ее отыскать. Естественно, при изменении информации на сайте распечатки будут устаревать, но ваши работники не будут об этом знать, и следовательно они будут давать устаревшие, неправильные сведения вашим клиентам. Именно такого рода проблем позволяет избежать информационная архитектура. Мы даже сталкивались с ситуацией, когда работники компании сами выдумывали ответы для клиентов из-за того, что интранет-сайт был плохо структурирован.[iv] 