Бесконечные разговоры об облачных и корпоративных архитектурах сообществу профессионалов порядком надоели, мало того, многим облачная тема уже практически в самом начале ее появления представлялась затасканной. О ней, по их представлениям, слишком много говорят в общих выражениях, а в итоге приходится наблюдать, как в аудиториях при упоминании облаков у значительной части присутствующих появляется снисходительное, ироническое настроение. По состоянию на март 2012 года 80% из числа опрошенных в США руководителей информационных подразделений осознают значение перехода к облакам, но тем не менее в их реальных шагах наблюдается очевидная заторможенность — только 20% предпринимают активные действия. И это при том, что по прогнозам Forrester Research, в 2020 году на облака во всем мире будет затрачено более 240 млрд долл., что означает пятикратный рост по сравнению с нынешними расходами.

 

От адаптивной инфраструктуры — к адаптивному предприятию

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

Леонид Черняк

Не лучше дело обстоит и с корпоративными архитектурами — практически мыслящим представителям ИТ эта тема кажется попросту навязанной. Их отношение объяснимо, и в жизни потребность в профессиональной архитектуре возникает только тогда, когда складываются необходимые условия — прежде всего, когда у заказчика есть ресурсы, возможность выбора, когда у него имеются соответствующие требования. А если всего этого нет, то архитектура не нужна — ни строительная, ни компьютерная. Тысячелетиями все постройки, бывшие исключительно утилитарными (народными), создавались исходя из здравого смысла, без привлечения архитекторов. Как специальность архитектура появилась из потребности возводить культовые сооружения. Аналогичная ситуация наблюдается и при создании информационных систем: пока выбор был невелик и реальной потребности не было, любые, чаще всего псевдопрофессиональные, разговоры об архитектуре оставались притянутыми. Не случайно в статье «Нужна ли нам архитектура?» («Открытые системы», № 06, 2008) Марина Аншина заметила: «Об архитектуре предприятия (Enterprise Architecture) говорят сегодня все кому не лень». Можно добавить в качестве комментария к этой мысли известную фразу из чеховской «Свадьбы», точно отражающую распространенное в среде ИТ отношение к тем, кто рассуждает о корпоративной архитектуре: «Они хочут свою образованность показать и всегда говорят о непонятном». И еще — «Слава богу, прожили век без образования и вот уж третью дочку за хорошего человека выдаем». Переводя на язык ИТ — обходились мы без архитектуры и отлично жили. Однако вместе с облаками открылась возможность выбора, и теперь при создании сложных информационных систем уже не обойтись без архитектуры.

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

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

 

EDF — корпоративная кэш-память

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

Леонид Черняк

Одно из достоинств облачных решений в том, что они не только позволят рациональнее использовать все виды информационных ресурсов, смещая затраты от капитальных (CapEx) в сторону эксплуатационных (OpEx), но и обеспечивают более тесную взаимосвязь между инфраструктурой бизнеса и поддерживающей ее информационной инфраструктурой. Результатом этого становится «облачное предприятие» Cloud Enterprise, построенное по соответствующей ему архитектуре Cloud Enterprise Architecture (CEA), которую можно считать синонимом Next Generation Enterprise.

Предприятие следующего поколения (как и культовые сооружения) невозможно строить без архитектурного проекта, и здесь облачная архитектура встречается с корпоративной. Тема чрезвычайно актуальна, и не случайно в конце 2012 года в ответ на запрос “Cloud Computing” в сочетании с “Enterprise Architecture” любой поисковик неожиданно выдает в ответ колоссальное количество страниц, причем многие из них в формате pdf, а обычно это документы, опубликованные компаниями, — значит, дело принимает серьезный оборот.

Oблачная платформа как результат эволюции

Популярные лет десять назад инициативы типа utility computing или autonomic computing не смогли получить широкое признание, поскольку опережали время, и только с появлением облаков открылась практическая возможность для реализации заложенных в них идей:

  • модель оплаты по мере использования ресурсов с минимальным начальным вкладом;
  • эластичность — пользователь потребляет ровно столько ресурсов, сколько ему нужно;
  • отсутствие привязки к определенному местоположению;
  • доступ к ресурсам в виде сервисов из произвольных мест в различных форматах.

Все эти качества не придуманы и не изобретены, а сформировались в результате эволюции корпоративных ИТ-инфраструктур. Начальное представление о таких инфраструктурах возникло в начале шестидесятых вместе с появлением мэйнфреймов IBM System/360. На первых порах для ввода использовались перфокарты, а для вывода — только печать, но вскоре был предложен терминальный доступ VTAM (Virtual Telecommunications Access Method), обеспечивающий работу на алфавитно-цифровых терминалах по протоколу SNA (Systems Network Architecture) — в какой-то мере аналогу TCP/IP. В результате уже на мэйнфреймах сложилась инфраструктура, напоминающая облака, достаточно перечислить такие ее атрибуты, как виртуальные машины, отказоустойчивость, нереляционные базы данных и, что, пожалуй, самое главное, — централизованное управление.

 

Покорение сложности ИТ

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

Ефим Натис

Близость технологических подходов далекого прошлого и современности, разделенных между собой тремя десятилетиями, дает основание верным адептам мэйнфреймов говорить, что уход в сторону открытых систем был ошибкой. С уверенностью можно сказать — это не так, и причины не только экономические. Да, мэйнфреймы были дороги и доступны ограниченному количеству организаций, но следует учитывать и социальные причины. В 70-е и 80-е годы в активную жизнь входило поколение бэби-бума, и тогда же установился более демократический миропорядок, что и нашло свое отражение в ИТ. В этом контексте не случайна была роль Университета Беркли, до сих пор остающегося самым левым в США, — для нового поколения главными словами стали Unix и ПК. Как следствие, стали развиваться архитектуры клиент-сервер в двух версиях — с толстым и тонким клиентами, конкурировавшими между собой на протяжении многих лет.

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

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

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

 

Через шумиху к светлому будущему

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

Леонид Черняк

Следующим шагом в развитии корпоративных систем стали интернет-приложения, основанные на HTTP и HTML, стандартизованных консорциумом W3C, браузерах и серверах HTTPD (HyperText Transfer Protocol Daemon). Использование HTML делало такие решения удобными для доступа к приложениям на мэйнфреймах, но их недостатком стали ограниченные возможности для работы с клиент-серверными и трехзвенными архитектурами. Это ограничение было преодолено с появлением новых технологий, например таких, как AJAX (Asynchronous Javascript and XML), поддерживающих «богатые функционально» приложения (Rich Internet Application, RIA). В начале двухтысячных с появлением и ростом популярности XML, SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration) и WSDL (Web Services Description Language) стало складываться впечатление, что Сеть сама по себе станет платформой для приложений. Любой может создать сервис, описать его на WSDL, UDDI позволит найти то, что нужно, а SOAP — использовать сервис. Но с самого начала идея сервисов через WWW казалась сомнительной из-за отсутствия необходимой управляемой инфраструктуры. В итоге стандарт SOAP существует до сих пор, а WSDL и UDDI практически забыты, но идея сервисов осталась, и теперь она прочно связана с SOA, а SOAP стали расшифровывать как Service-Oriented Architecture Protocol.

Cервисы и сложные системы

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

Леонид Черняк

Термин SOA был предложен в 1996 году аналитиком Gartner Ефимом Натисом, но до 2001 года о сервисной архитектуре никто не вспоминал, а потом стала ясна перспективность этой архитектуры как отражения природы изменений, происходящих в корпоративных системах. Оказалось, что SOA есть следствие закономерного эволюционного процесса — при переходе от мэйнфреймов к клиент-серверным конфигурациям и далее к SOA изменяется функциональность, пересматриваются представления об информации и данных, а это явления более глубокие, чем простые изменения в аппаратной или программной архитектуре.

В 1997 году профессор Рамеш Челлаппа первым предложил термин “cloud computing”, и вскоре состоялся прочный союз SOA с облаками, плодом которого стали самые разнообразные вещи, предоставляемые в виде тех или иных услуг — «все как сервисы» (XaaS).

Из совокупности разнообразных сервисов складывается желаемая облачная экосистема предприятия (Enterprise Cloud Computing Ecosystem), являющаяся на данный момент венцом в эволюционном развитии корпоративных платформ и базисом для предприятия будущего. Теоретически такая среда делится на:

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

Другие сервисы — Monitoring as a Service, Communication as a Service, Data as a Service, Information as a Service, Desktop as a Service, Storage as a Service — нарушают стройность облачной картины и существенно ее усложняют. Получается, что, с одной стороны, сервисный подход упрощает логику взаимодействия приложений, а с другой — инфраструктура предприятия становится намного сложнее.

Таким образом, наступило время всерьез заняться архитектурой инфраструктуры предприятия — пора строительства «на глазок» закончилась, и появился реальный интерес к Cloud Computing в сочетании с Enterprise Architecture.

 

Архитектура со всех сторон

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

  • бизнес-архитектура (Business Architecture), охватывающая миссию предприятия, задачи и соответствующие операционные модели;
  • архитектура предприятия (Enterprise Architecture), устанавливающая связь между задачами бизнеса и возможностями ИТ;
  • информационная архитектура (Information Architecture), а скорее, архитектура данных, поскольку она состоит из классификации и структур хранения данных;
  • архитектура технической инфраструктуры (Infrastructure Architecture), традиционно она состоит из серверов, систем хранения, сетей, приложений.

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

Если идти снизу, от ИТ, то обычно выделяют три подмножества архитектур.

  • Системная архитектура — концептуальная модель, определяющая структуру, поведение и другие общие взгляды на систему. В современном представлении системная архитектура обеспечивает такие важнейшие качества, как готовность, гибкость, производительность и надежность.
  • Программная архитектура — как концепция была предложена в исследованиях Эдскера Дейкстры и Дэвида Парнаса в конце 60-х. Она получила развитие в связи с появлением сервисной архитектуры и ее преемников.
  • Аппаратная архитектура — взаимосвязь между отдельными компонентами, термин был предложен в 1959 году Фредериком Бруксом, сыгравшим решающую роль в создании мэйнфреймов IBM System/360. Выделяют общую архитектуру связи между процессором и памятью — например, схема фон Неймана, NUMA, кластеры. Иногда слово «архитектура» используют как синоним для более раннего термина «системы команд», в этом смысле оно вошло в практику с появлением микропроцессоров, особенно в тех случаях, когда сравнивали сокращенную систему команд RISC с комплексной CISC. Под микроархитектурой обычно понимают организацию уровнем ниже, чем система команд.

Развитие архитектур сверху вниз началось намного позже, в 1987 году, благодаря работе Джона Захмана “A framework for information system architecture”, главная заслуга которого в распространении архитектурного представления на все предприятие в целом.

Сам термин Enterprise Architecture в русском языке может переводиться по-разному в зависимости от контекста — либо в связке с ИТ, либо применительно ко всему предприятию. В первом случае слово enterprise используется как прилагательное, и термин можно перевести как «корпоративная архитектура, ориентированная на ИТ», здесь речь идет об архитектуре не всего предприятия, а только его информационных систем. Иначе говоря, EA здесь рассматривают на приземленном аппаратно-программном уровне, оставляя в стороне глобальную структуру предприятия и взаимосвязи между отдельными компонентами. Соответственно, архитекторы, занятые в этой сфере, входят в команду ИТ и находятся в подчинении у директоров информационных служб или директоров по технологиям.

Во втором случае слово enterprise используется как существительное, и точнее будет говорить об архитектуре всего предприятия, а не только об ИТ. Те, кто выстраивают такого рода архитектуру, работают непосредственно на высшее руководство компании, и для обозначения их деятельности стоило бы использовать не enterprise-architecture, а эквиваленты — например, business-transformation (преобразование бизнеса) или strategic guidance (стратегическое управление). Такие архитекторы используют в своей работе несколько методик.

  • Структура Захмана для архитектуры предприятий. Структура представляет собой таксономию для упорядочения так называемых архитектурных артефактов (проектной документации, спецификации и моделей). В структуре учитываются лица, которым адресован артефакт (например, владелец бизнеса и строитель), и конкретная проблема (например, проблема с данными и функциональностью), которую необходимо устранить. По словам самого Джона Захмана, архитектура предприятия представляет собой логическую структуру для классификации и упорядочения описательных представлений предприятия, существенно важных для управления предприятием, а также для разработки корпоративных систем.
  • Методология TOGAF (The Open Group Architecture Framework). Принадлежит консорциуму The Open Group и служит для описания процессов.
  • Архитектура федеральной организации FEA. Попытка федерального правительства США привести бесчисленное множество агентств к единой и повсеместно используемой архитектуре.
  • Методология Gartner. Набор практических рекомендаций.

Все четыре методики отличают именно менеджерское отношение к делу и отсутствие научного подхода, при котором предприятие не рассматривается как сложная система.

 

Предприятие следующего поколения

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

 

Эпоха великого переселения ИТ

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

Леонид Черняк

Динамичность (Dynamic Enterprises). Впервые термин Dynamic Enterprise Architecture (DEA) был предложен в 2001 году, но тогда еще не было адекватных технологий, а совсем недавно вышла книга “Dynamic Enterprise Architecture, How to make it work”, где не только определяется предмет — динамика, но и то, как следует идти к ней. Подход DEA позволяет интегрировать сервисы, предоставляемые различными облаками и различными провайдерами, ресурсы могут перераспределяться так, как нужно в данный момент, что и придает требуемую динамичность.

Адаптивность (Adaptive Enterprises). В конечном счете адаптивность означает согласованность между запросами на те или иные сервисы со способностью их гармонизации. С начала десятилетия эта тема была в центре внимания компании Hewlett-Packard, которая воплотила ее в программе Darwin. Удивительно, что практически все составляющие, в том числе виртуализация в том виде, как мы ее сегодня понимаем (виртуализация серверов, приложений, сетей и систем хранения), была предусмотрена уже тогда в технологиях, собранных под шапкой Utility Data Center (UDC), предназначенных для построения центров обработки данных. В IBM аналогичное решение назвали On-Demand Enterprise.

 

Мэйнфреймы XXI века

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

Леонид Черняк

Глобальная интеграция (Globally Integrated Enterprise). Этот термин в 2006 году озвучил Сэм Палмизано, бывший в то время президентом IBM, таким образом подчеркивая переход мировой экономики на новый транснациональный уровень. Облачные технологии, в первую очередь глобально распределенные системы хранения данных, усиливают эту концепцию.

Прозрачное предприятие (Liquid Enterprise). Этот взгляд на предприятие был предложен примерно десять лет назад компанией BEA до поглощения ее Oracle. Его суть в наведении мостов между людьми, процессами и данными, в создании горизонтальных коммуникаций и в конечном итоге — в формировании социальных компьютерных систем (Enterprise Social Computing). В последние годы эти взгляды воплощаются в методах краудсорсинга, и здесь облака с их природной централизацией и практически неограниченной возможностью предоставления любых ресурсов по требованию дают возможность множеству людей работать с одними и теми же данными. Иногда как синоним используется термин Connected Enterprise.

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

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

 

Этапы пути к предприятию будущего
Этапы пути к предприятию будущего

 

Купить номер с этой статьей в PDF