Solution архитектура что такое
Solution Architect: Кто Это и Какие у Него Обязанности
Содержание
Многие компании заранее могут увидеть, что проект окажется неудачным. Соответственно, они имеют шанс изменить результат и достигнуть успеха. Это требует внезапной трансформации большинства процессов в соответствии с новыми требованиями рынка.
Такая трансформация требует особой экспертизы и набора практик для согласования бизнес-фокуса с технологическими решениями. В противном случае, изменение методов работы не даст улучшения эффективности.
Поэтому, в любой компании, которая нацелена на развитие, развита архитектура решений. Это практика проектирования, описания и управления решениями в зависимости от задач и проблем бизнеса.
Подобная практика породила соответствующую должность – архитектор решений. Это Лицо, ответственное за руководство практикой и представление общего технического видения конкретного решения. Работа архитектора решений включает в себя множество аспектов и обязанностей, о которых и пойдет речь в статье.
Из чего состоит архитектура программного продукта
В первой из них основной фокус – построение экосистемы и решение стратегических проблем высшего уровня (объединение ключевых требований, анализ потоков данных и т.д.). Бизнес архитектура приводит к понимаю того, какие техническая средства необходимы для поддержания программного продукта.
Архитектура решений – промежуточная составляющая между бизнес-процессами и технологическими решениями. Она включает в себя поиск технических решений для разных задач, описание структуры и поведения ПО, определение функций и этапов для каждого решения.
Технологическая архитектура включает в себя инженерные проблемы. Иными словами, это аппаратная составляющая программного продукта. Она описывает системное ПО, стандарты на программно-аппаратные средства, системы управления и т.д.
Исходя из этого мы видим, что в ИТ архитектуре есть три соответствующих уровня должностей – Enterprise Architect (EA), Solution Architect (SA) и Technical Architect (TA).
Роль архитектора решений
За простым «как делать» в работе архитектора решений кроется множество задач, таких как выбор фреймворков для работы, контроль за развитием программного продукта, решением спорных ситуаций у разработчиков. Почему же так важна эта работа?
Кроме того, именно архитектор решений отвечает за соблюдение всех требований в ходе разработки. Он же должен изучить ограничения проекта, чтобы проанализировать допустимые альтернативы и снизить риски.
В общем, архитектор решений – это связующее звено между технической группой и руководителем проекта. Он обеспечивает скорость и точность передачи информации, а также контролирует ключевые процессы разработки.
Какими навыками должен обладать архитектор решений
Архитектор решений – это не высшее и не низшее звено в процессе разработки программного продукта, но без него невозможно получить необходимый результат. Именно поэтому, архитектор решений должен обладать как общими навыками управления проектам, так и исключительными способностями.
Экспертная коммуникация. Роль SA – обеспечить выполнение проекта в срок. Поэтому он должен быть в состоянии четко донести технические аспекты, риски, проблемы и преимущества каждого решения.
SA – это центральный элемент для всех сторон, вовлеченных в решение, от бизнес-аналитиков и до разработчиков. Соответственно, он должен уметь объяснить выбранные подходы на всех уровнях. При этом, ему необходимо обладать человеческими качествами для предоставления советов и объяснений, ведения переговоров и оказания положительного влияния.
Управление рисками. Как снизить риски? Необходимо уметь пользоваться тестами производительности, безопасности, взаимодействия с пользователем и другими. Если SA не способен проанализировать показатели подобных тестов, то его работа окажется безуспешной.
Технические знания. SA не сможет дать совет или объяснить какое-то решение, если он не обладает достаточными знаниями в технических аспектах проекта. Такая должность подразумевает понимание всех технических дисциплин, которые задействованы в разработке.
Ориентация на детали. В ходе разработки программного продукта очень важна скрупулезность. Но такая черта характера у всех развита по-разному. Архитектор решений – это человек, который должен уделять наибольшее внимание деталям. Ведь именно они определяют возможные риски, а также помогают разделить ценные и незначительные элементы программного продукта.
Рациональное распределение. Для обеспечения быстрого и качественного результата нужно большое количество ресурсов. Но если их распределить неправильно, то итог все-равно будет негативным. Архитектор решений должен иметь информацию о всех доступных ему ресурсах и использовать их наиболее оптимальным путем.
Аналитические навыки. Разработка решений требуют понимания того, как связаны различные части бизнеса. Потому SA должен разобраться в корпоративной стратегии и реализовать все бизнес-процессы, которые определяют способы достижения целей компании. Таким образом, архитектор решений постоянно должен проводить аналитическую работу на разных уровнях бизнеса.
Обязанности архитектора решений
В общем, архитектор решений – это человек, который отвечает не только за разработку, но и за практическую реализацию идей. Он должен иметь четкое представление о продукте и понимать, какую пользу этот продукт принесет бизнесу. Кроме того, архитектор решений транслирует это видение всей команде разработчиков кода, чтобы они могли создать программный продукт.
Неотъемлемой частью разработки является выбор технологического стека. Архитектор решений обязан принимать участие в этой процедуре. Главная цель в данном случае – найти, какой стек будет наиболее подходящим для конкретного проекта.
Почему компании платят архитекторам решений
Таким образом, компании платят за оптимизацию бизнес-процессов и создание условий для масштабирования. Сколько? В среднем – 100 тысяч долларов в год. При этом, архитектор решений не получает меньше 80 тысяч. А вот максимальный показатель уже зависит от страны и компании, в которой работает человек. К примеру, в Австралии, в 2019 году максимальная оплата труда SA составила 106 тысяч долларов, в то время, как в США – 196 тысяч.
Заключение
Архитектура решений лежит в основе любого ИТ-проекта, независимо от того, применяется ли такая практика или нет. Преднамеренно внедряя архитектуру решений, компания создает структуру, которая объединяет технологии, ресурсы и навыки команды с определенными бизнес-целями.
Прежде, чем начинать работу над новым проектом, необходимо изучить структуру компании и основные требования. Конечно, можно сделать это лично. Но можно делегировать все соответствующие полномочия архитектору решений. Его роль и значимость будет замечена моментально.
Подробно о рабочих буднях, особенностях профессии и способах стать архитектором журналистке Highload рассказал Solution Architect компании Ciklum Константин Ходыкин.
Опыт в CRM-системе помог получить работу Solution Architect
Solution Architect компании Ciklum Константин Ходыкин
Мое увлечение IT началось с глубокого детства, когда я в пять лет впервые увидел на работе у родителей компьютер. Когда вырос, стал дипломированным инженером. Сначала работал оператором базы данных, контент-менеджером, потом начал писать на С# в украинской IT-компании. Позже устроился в рекламное агентство, которое организовал мой одногруппник: мы писали сайты-визитки для украинских заказчиков.
Solution Architect — специалист, который владеет техническим бэклогом, ставит технические задачи разработчикам, а также помогает им понять, как и почему мы делаем те или иные вещи. Еще архитектор предоставляет документацию, выясняет архитектурно значимые требования у заказчика. Например, в беттинговых компаниях (компании, принимающие ставки на спорт — прим. ), очень важно быстродействие, особенно в лайв-беттинге, когда можно делать ставки прямо во время мероприятия. И нужно не просто достичь определенного значения быстродействия, а быть быстрее конкурентов — иначе продукт провалится на рынке.
Профессия предполагает много общения
Вообще эта профессия предполагает много общения, потому для архитектора важны коммуникационные скиллы: он помогает командам работать в правильном направлении, занимается координацией между различными командами, вендорами. При переговорах с клиентом или командой разработки он должен правильно доносить мысль, предлагать решение проблемы, обосновывать, почему решение именно такое.
Также важны бизнес-скиллы. Необходимо иметь общее понимание бизнеса, что является бизнес-драйверами для организации, какие ее цели — это нужно, чтобы определить, какие требования важны для того или иного продукта. Также следует уметь мониторить рынок, разбираться в бизнес-доменах.
У архитектора много задач
Архитектор может исполнять обязанности дизайнера в плане оформления системы, ее проектирования. Кроме того, он составляет технический бэклог, осуществляет бизнес-анализ, выступает как тимлид на небольших проектах или проджект-менеджер — на более крупных внутренних проектах, может заменить девопса.
У архитектора может быть много задач:
Архитектор может заниматься несколькими проектами одновременно, каждый день может быть комбинация разных видов деятельности. Я как архитектор работал в командах от двух до 350 человек. Чем больше компания, тем больше регламентирована работа архитектора.
Solution Architect становятся специалисты двух направлений
Как правило, Solution Architect становятся специалисты двух направлений — разработчики либо девопсы. Полезно для начала вырасти до сеньор-позиции, побыть тимлидом, подкачать навыки коммуникации и менеджмента. Лучшего учителя, чем практика, не бывает. Также существуют курсы, сертификации по архитектуре.
Кроме того, нужно самостоятельно искать возможности выполнять обязанности Solution Architect. Если компания предоставляет план персонального роста, следует обсудить это со своим менеджером, познакомиться с архитектором и работать с ним. Нужно стараться больше вовлекаться в работу, вникать в требования, искать способы попасть на позицию или в менторские программы. Иначе ты не станешь Solution Architect после десяти курсов.
Архитектура и архитекторы
Относительно давно посетил семинар посвященный управлению архитектурой и ее контролю и все хотел описать полученные знания, так как информации было много, и большая ее часть была весьма полезна. Могу сказать, что представления мои об архитектуре сильно расширились, и тема оказалась более глубокой и широкой, нежели я себе ее представлял. Но это и хорошо, есть отправные точки, которые можно будет самостоятельно проработать в будущем. Итак, заканчивая с лирикой, хочу предоставить краткий конспект по архитектуре.
Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии. Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.
Отличия Enterprise Architect от Solution Architect
EA разрабатывает глобальный план работы приложения, взаимодействия его с другими приложениями. SA работает над конкретным ПО. При этом EA постоянно следит за тем, как именно развивается приложение и может вносить коррективы в концептуальные части приложение.
Например, в какой-то момент появляется потребность в новом приложении Х, которое использует данные, которые генерирует приложение А. В таком случае ЕА принимает решение о выделении части приложения А в отдельный сервис, который будет поставщиком данных для приложения Х. Таким образом может быть заметно сокращена работа по реализации нового приложения.
Из представленного примера легко прийти к заключению о том, что EA должен очень хорошо прорабатывать, анализировать и следить за тем, как работают все приложения вместе, иметь всю информацию в наглядном и структурированном виде, для того, чтобы можно было принимать описанные решения. Повторное использование сервисов и данных, помнить или знать специфику данных и сервисов, все это входит в ответственность EА.
На мой взгляд, SA должен быть практикующим программистом, так как требуется знать достаточно хорошо продукты и фреймворки с которыми предстоит работать, знать ограничения и сильные стороны технологий которые будут использованы. В свою очередь EA точно так же не оторван от мира технологий, так как надо знать концептуальные различия в общих технологиях, быть в курсе тенденций их развития. Так как принятые решения в глобальном плане развития ПО могут похоронить все последующие проекты, либо сделать их разработку долгой и трудной, если выбор будет не соответствовать технологической структуре бизнеса.
Уровни ответственности и влияния
На данной, схеме показаны зависимости и отношения между разными уровнями архитектурного планирования. Влияние их друг на друга. Комментировать не стоит, я думаю.
Про каждый элемент из списка можно погуглить отдельно, но в целом понятно, что они означают. Остается наверно выбрать наиболее удобный формат представления.
Работа архитекторов
Некоторые люди высказывались о том, как построен процесс принятия решений в их компаниях. Например, при утверждении плана на год обязательно участие архитекторов, которые стараются сделать анализ возможности реализации в необходимые сроки. Определяют какие проекты потребуют наибольшего вложения сил, какие могут стать потребителями только и не потребуют много ресурсов.
Определенных средств для разработки и контроля никто не называл. Так или иначе, используется компиляция средств из Visio, SharePoint, Wiki.
Для меня остаются открытыми вопросы того как оценивать тенденцию в росте данных, механизмы управления данными. Лучшие практики по миграции архитектур, как идет работа систем при модернизации. Много, много вопросов возникает практического характера, которые я постараюсь выяснить у практикующих людей, с которыми познакомился на семинаре. Если будет результат, то напишу дополнительно.
Из дополнительного материала можно порекомендовать TOGAF9 и блог Nick Malik.
Архитектура ИТ решений. Часть 1. Архитектура предприятия
I. Вступление
Архитектура распределяет массы и объемы.
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.
Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы «собственного исполнения». Такая работа, естественно, требовала привлечения специалиста высокой квалификации. А как это сделать дешево и сердито, чтобы призванный варяг был «и чтец и жнец и на дуде игрец»? Решили без всяких излишеств разработчика ПО, поименовать архитектором, и заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их на свое усмотрение, принимать самостоятельные решения и т.п…
Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют достаточно низкоуровневое проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути — является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове.
И документации вроде бы много, но она разрознена по репозиториям проектов, Вики системам и т.п. Найти логически целостное описание решения и рекомендации по его использованию крайне сложно, а уж проследить ответвляющиеся частные технические решения по цепочке: от потребностей пользователя, до конечной поставки заказчику, вообще не реально, И это несмотря на то, что для заказчика обычно готовится некая версия на базе типового продукта, доработанного в соответствии с его специфическими потребностями. А ведь иногда бывает так необходимо отследить, например, с кем связан компонент, который предполагается использовать при проектировании нового модуля. С кем он, так сказать, разделен шестью рукопожатиями, и какое пагубное влияние могут оказать все эти неучтенные связи на стабильность его поведения.
Подобная ситуация царит во многих крупных ИТ компаниях. Вроде есть архитекторы и архитектурные советы и прочие атрибуты «высокой» архитектуры, а порядка в этом царстве не наблюдается. По вышеперечисленным симптомам, выходит, что на предприятии свирепствует – «острая архитектурная недостаточность».
Мне стало интересно разобраться со всеми аспектами архитектуры, собрав в данной статье структурированно и последовательно информацию о том, что же такое ИТ архитектура, кто такие ИТ архитекторы, и «с чем их едят».
II. Определение понятия «архитектура»
А что можно думать об архитектуре?
Она, как солнце: большая, блестящая и она рядом.
Роджер Желязны. (Мастер сновидений)
Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.
Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:
Довольно лаконичное определение, дополнив которое можно приблизится к пониманию, что же принято ассоциировать с явлением — ИТ Архитектура.
Во-первых, это специально подобранный, набор структурных элементов, организованных определенными способами для взаимодействия друг с другом, складывающихся в единый программно-аппаратный комплекс. Я бы еще добавил: выстроенный в угоду достижения определенных бизнес целей.
Во-вторых, место «совокупности этих элементов», как части, в более крупных системах, включая поведение, точки взаимодействия и т.п. То есть возможность абстрагирования рассматриваемой архитектуры на более высокий уровень, и соответственно детализация архитектуры в наборы составных архитектур нижнего уровня.
В-третьих, использование всеми участниками — единого подхода для организации решений в процессе производства информационных систем.
Раз уж речь зашла о едином подходе, давайте внесем ясность и в этот вопрос:
Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом заинтересованных лиц (2).
Ведь в ходе проектирования, разработки, развития и модернизации программной системы, «совокупность решений о ее организации» (Архитектура), требует постоянного обсуждения со всеми заинтересованными лицами проекта, включая бизнес. Опять же принципиально, чтобы все при этом выстраивали перед собой одну и туже картинку, в том числе учитывающую текущее актуальное состояние архитектуры.
Итак, размявшись на общих положениях и задав направление для исследования понятия Архитектура, продолжим углубляться в суть этого явления.
1. Разделы ИТ Архитекторы
Поскольку понятие ИТ архитектуры охватывает целый букет аспектов производства программных продуктов, начиная еще от определения целей автоматизации и заканчивая аж утилизацией устаревшего в какой-то момент ПО, принято делить его на несколько частей:
1) Информационная архитектура (Enterprise Information Architecture, сокр. EIA), набор методик и инструментов, описывающий информационную модель предприятия. Включает:
4) Бизнес-архитектура предприятия (Enterprise Business Architecture, ЕВА) — целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес-целями. В ходе построения бизнес-архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.
Соответственно для работы с каждым из вышеперечисленных разделов, требуется своя группа заинтересованных лиц, имеющих различную квалификацию и предпочтения, а возможно и цели. Поэтому многочисленные этапы ведения проекта порождают артефакты, описывающие аспекты архитектуры в разных стилях и жанрах. В добавок, они создаются чаще всего разнородными инструментами, используя разнообразные нотации, приемы, представления и т.п.
Стало быть, каждому разделу архитектуры соответствует как минимум одна группа стейкхолдеров, имеющая свои взгляды на представления и методы описания архитектуры. Подыщем определение для этой реалии.
Архитектурная группа описаний (англ. architectural view) — представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания (2).
Разобравшись вкратце с концепцией, направлениями и разделами архитектуры, а также выявив несовпадения в представлениях архитектуры разными группами заинтересованных лиц, перейдем к разбору непосредственно самих этих представлений (артефактов), отражающих архитектуру.
2. Представления ИТ Архитекторы
Нередко наблюдаю ситуации, когда очень интересные и перспективные замыслы гинут в болоте непонимания, только лишь из-за оторванности генератора идеи от общего уровня сознания профсообщества. Иными словами, он пытается донести концепцию, которая в его мыслях сложена в цельную и стройную идею, выдавая окружающим лишь ее “огрызки”: «ну ведь остальное и так понятно». А это «остальное» действительно не всегда понятно для электората, и он голосует против бредовой и непонятной с его точки зрения идеи, своим равнодушием и игнорированием. Автор же задумки зачастую просто не смекает, почему же все пошло не так, и отчего никто не проникся чудо решением.
По всей вероятности нужна была какая-то подводка. А очень может быть, сначала надо было открыть людям целый новый мир, и только потом, в его свете, доносить эту свою идею. Это сродни тому, как иностранцу, не владеющему твоим родным языком, объяснять на нем теорию относительности Эйнштейна. Особенно если ты ее сам как-то не очень…
Очевидно, что и для эффективного представления архитектурных решений всем заинтересованным лицам, требуется некий способ, позволяющий доступно, но достаточно развернуто донести их суть до максимально широкого круга лиц. Таким способом может служить принятый в организации стандарт — Архитектурное описание и соответствующие методы их поддержания. Для более точного осмысления этого явления, пустим в ход и их определение:
Архитектурное описание (англ. architectural description) — рабочий продукт, использующийся для выражения архитектуры (2).
Архитектурный метод описания (англ. architectural viewpoint) — спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам (2).
Тем самым, выделенные архитектурные группы, используя единые архитектурные методы описания, значительно повышают эффективность своей работы, достигая максимально согласованного и целостного восприятия обсуждаемых проблем.
Но можно ли загнать специалистов разных направлений, имеющих разную квалификацию, а возможно и образ мышления, в единые рамки, и действительно ли это так необходимо?
Например, диаграмма, описывающая формирование целей и показателей на основании выявления стекхолдеров, вызовов и их проблематики см. рис.1, по своей природе очень сильно отличается от диаграмм со схемой прокладки сети, а также диаграмм в нотации UML и прочих.
Рисунок 1. Модель выработки целей и показателей
На практике использование разнородных артефактов является большой проблемой, поскольку теряется возможность сквозной трассировки архитектурных решений от целей и стратегий к потребностям, далее к описанию бизнес-процессов и функций системы, от них к структуре данных и поведенческим моделям, от моделей к макетам экранов и т.д. по цепочке. Ведь создают все эти артефакты специалисты разных архитектурных групп, которые формировались сами по себе, подбирая годами под себя оптимальные инструменты и методики.
Фиксируя все эти разнообразные описания и представления, возникает резонный вопрос: Как же их объединить в некий всеобъемлющий контекст?
Например, для разработки больших информационных систем еще в конце прошлого века использовали модель Закмана (3), в качестве схемы организации архитектурных артефактов.
Модель Закмана основана на дисциплине классической архитектуры и призвана обеспечить общее толкование архитектурных аспектов и предоставить набор перспектив, или структур (framework), для описания сложных корпоративных систем.
Сама модель представляется в виде матрицы — таблицы, имеющей пять строк и шесть столбцов, см. рис. 2. Каждая ячейка таблицы – презентует набор артефактов, раскрывающих один из насущных аспектов архитектуры.
Рисунок 2. Представление модели Закмана
Примечательно, что основная идея матрицы помимо того, чтобы вынудить заполнить все ячейки, не пропустив важные характеристики системы, состоит и в определении последовательности заполнения. Ведь только заполнив одни ячейки, открывается возможность на основании их заполнить следующие, пока пазлы не сложатся в цельную картинку. Таким образом, различные по своему представлению архитектурные описания ложатся в разные ячейки матрицы и ею же увязываются в единое архитектурное полотно.
Стоит отметить, что на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Модель Закмана со временем дорабатывалась и послужила прародителем для многих архитектурных каркасов и спецификаций.
Одной из таких актуальных спецификаций является например, графический язык ArchiMate, содержащий набор понятий для описания архитектуры предприятия и фреймворк, представляющий логическую структуру для классификации этой информации Последняя версия стандарта 3.0 вышла в июне 2016 года.
В ArchiMate, при создании моделей, используются базовые понятия «элемент» и «отношение» см. рис.3. На основе элементов и отношений строятся модели предприятия или его отдельных частей.
Рисунок 3. Основные понятия ArchiMate 3.0
Вся прелесть подхода состоит в том, что элементами могут быть проекции самых разнообразных реальных сущностей и явлений, встречающихся в жизни. Например, мотивационные элементы (стейкхолдеры, драйвер мотивации, цель, результат, ценность и т.д.), элементы организации и поведения (исполнители, роли, процессы, функции, события, взаимодействие и т.д.), бизнес элементы (информационный актив, соглашение, продукт/услуга, компонент приложения, интерфейс приложения, автоматизируемая функция и т.д.), технологические элементы (узел/ресурс, устройство, коммуникационная сеть, технологический процесс и т.д.). Каждый вид элемента представлен на диаграммах своим уникальным обозначением. Таким образом в одном информационном пространстве могут сочетаться столь разные отражения сущностей, явлений, событий, действий и т.д., образующих архитектуру предприятия.
Сами модели располагают в одной из ячеек каркаса на пересечении Слоя (уровень представления) и Аспекта. Схематично структура фреймворка представлена на рис. 4.
Рисунок 4. Слои фреймворка ArchiMate 3.0
В качестве Слоев рассматриваются конструктивные субсистемы предприятия, образующие некое самодостаточное представление (срез) организации. А Аспекты в свою очередь относят элементы, к одному из трех основных типов:
1) Активный структурный элемент (active structure element) позиционирует его, как некую сущность, которая способна выполнять определенные действия
2) Пассивный структурный элемент (passive structure element) позиционирует его, как некоторый объект, над котором выполняются действия.
3) Элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами.
Более подробно ознакомится со спецификацией можно в обзоре ArchiMate (4).
Такого рода инструменты позволяют объединить в единое информационное пространство разнородные аспекты архитектуры, используя унифицированное архитектурное описание и методы, обеспечивая трассировку между диаграммами и элементами.
Погрузившись во все эту «карусель» сложностей и разнообразия возникает один немаловажный вопрос: А всегда ли необходимо выполнять такой сложный и ресурсоемкий процесс описания архитектуры? На самом деле существует несколько подходов к ее построению, например:
1) Стандартный подход, заключается в разработке или выборе на начальном этапе общей схемы и правил для описания архитектуры. На основании выработанных стандартов, описывается базовая (текущая) архитектура, и отталкиваясь от нее, проектируется целевая (новая). Определив разницу, формируют мероприятия по переходу от базовой архитектуры к целевой. Только после этого начинается конструирование, приобретение и разработка компонентов системы. В качестве недостатков, можно выделить: существенные начальные инвестиций, как финансовые, так и временные. Также этот подход может привести к тому, что называется «паралич из-за анализа».
2) Подход «статус-кво». Разработка рассматривается как реакция на те или иные возникающие затруднения или воздействия.
3) Сегментный подход, опирается на модель разработки сегментов архитектуры в рамках общей структурированной схемы. Он сосредотачивается на главных областях бизнеса. Позволяет сократить возможные риски, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта. Могут возникнуть проблемы на этапе интеграции сегментов.
3. Резюме раздела
Итак сделаем краткую выжимку из рассмотренного нами материала:
Со следующей частью статьи можно ознакомиться, перейдя по ссылке