хорошая архитектура ит это баланс каких характеристик

Роль архитектуры в ИТ

Трудно поспорить со следующими утверждениями:

Внимание вопрос: где тут архитектура? Влияют ли на архитектуру требования к решению? Где заканчивается архитектурное планирование и начинается проектирование решения? Есть ли прямая связь между архитектурой и конечным решением? Должна ли архитектура транслироваться в дизайн решения?

Марк Смолли, хорошо знакомый читателям RealITSM, опубликовал на страницах портала IT Chronicles заметку под провокационным названием «Архитектура ИТ – не более, чем иллюзия?», в которой предпринял попытку дать лаконичный ответ на эти вопросы.

TOGAF 9.1 определяет архитектуру как:

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

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

При наличии архитектуры на проектирование конкретного решения влияет как требования к решению, так и архитектурные требования, которые применимы для всех решений в заданном организационном контексте», — поясняет Марк.

Тогда получается, что:

Эти тезисы Марк подкрепляет иллюстрацией:

Источник: IT Chronicles

Источник

Кратко о типах архитектур программного обеспечения, и какую из них выбрали мы для IaaS-провайдера

Есть множество типов архитектур ПО со своими плюсами и минусами. Далее поговорим об особенностях наиболее популярных из них и расскажем о своем переходе на микросервисы.

Типы архитектур ПО

Многоуровневая архитектура

Это одна из самых распространенных архитектур. На её основе построено множество крупных фреймворков — Java EE, Drupal, Express. Пожалуй, самый известный пример этой архитектуры — это сетевая модель OSI.

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

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

О многоуровневой архитектуре написано бесчисленное количество книг и статей. И сложились разные мнения о ее достоинствах и недостатках.

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

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

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

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

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

Когда мы в 1cloud начинали работу над внутренними системами нашего провайдера виртуальной инфраструктуры, то использовали именно этот тип архитектуры. На старте перед нами не стояла задача сделать IaaS-сервис, способный обработать трафик десятков или сотен тысяч пользователей. Мы решили оперативно выпустить продукт на рынок и начать нарабатывать клиентскую базу, а проблемы масштабирования решать по мере их поступления (и сейчас мы переводим все системы на микросервисную архитектуру, о которой далее).

Подобная взаимосвязь, между структурой организации и подходами к разработке приложений также продиктована законом Конвея, сформулированном еще в 1967 году. Он гласит: «Разрабатывая какую-либо систему, организации вынуждены придерживаться схемы, которая бы повторяла структуру коммуникаций внутри компании».

Событийно-ориентированная архитектура

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

Можно провести аналогию с покупкой автомобиля в салоне. Когда автомобиль находит нового владельца, его состояние меняется с «продается» на «продано». Это событие запускает процесс предпродажной подготовки — установку дополнительного оборудования, проверку технического состояния, мойку и др.

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

Примером реализации такой архитектуры может служить библиотека Java Swing. Если классу нужно оповещение о каком-либо событии, разработчик реализует так называемого слушателя — ActionListener (он «ловит» соответствующий эвент), и дописывает его к объекту, который это событие может сгенерировать.

На Wiki приводится следующий код реализации этого механизма:

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

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

Микроядерная архитектура

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

Как пример микроядерной архитектуры в книге O’Reilly приводится Eclipse IDE. Это простой редактор, который открывает файлы, дает их править и запускает фоновые процессы. Но с добавлением плагинов (например, компилятора Java) его функциональность расширяется.

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

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

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

Также сложно определить заранее (до начала разработки приложения) оптимальную степень дробления кода микроядра. А поменять подход позднее практически невозможно.

Хорошо подходит для:

Микросервисы

Похожи на архитектуру, управляемую событиями, и микроядро. Но используются тогда, когда отдельные задачи приложения можно легко разделить на небольшие функции — независимые сервисы. Эти сервисы могут быть написаны на разных языках программирования, поскольку общаются друг с другом при помощи REST API (например, с использованием JSON или Thrift).

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

Чаще всего микросервисы запускаются в так называемых контейнерах. Эти контейнеры доступны по сети другим микросервисами и приложениям, а управляет ими всеми система оркестровки: примерами могут быть Kubernetes, Docker Swarm и др.

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

Подробнее о механизмах масштабирования микросервисных систем можно почитать в книге Мартина Эббота (Martin L. Abbott) «Искусство масштабирования» (The Art of Scalability).

Сложно искать ошибки. В отличие от монолитных систем (когда все функции находятся в одном ядре), бывает сложно определить, почему «упал» запрос. За деталями приходится идти в логи «виновного» процесса (если их несколько, то проблема усугубляется).

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

Еще один недостаток — необходимость мириться с концепцией eventual consistency (согласованность в конечном счёте). У микросервисов есть собственные хранилища данных, к которым обращаются другие микросервисы. Информация об изменении этих данных распространяется по системе не мгновенно. Потому возникают ситуации, когда у некоторых микросервисов (пусть и на крайне короткий промежуток времени) оказываются устаревшие данные.

Почему мы в 1cloud переходим на микросервисы

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

У нас становится все больше партнеров, которые предоставляют свои решения на базе нашей платформы по франшизе. Появляются удаленные площадки и сервисы, которыми становится сложно управлять из единой точки (в частности, наше оборудование находится в нескольких дата-центрах в России, Казахстане и Беларуси).

Чтобы было проще масштабировать существующие функции и внедрять новые фичи, мы в 1cloud переводим всю нашу инфраструктуру на микросервисы.

Мы хотим выделить их в отдельные модули и вместо одной сложной базы данных получить N простых. Таким образом, в новой архитектуре каждой фиче будет соответствовать отдельная БД. Это гораздо удобнее и эффективнее в поддержке и разработке.

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

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

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

Что уже сделано

Пока мы реализовали только первый пилот: «Услугу Мониторинг». Остальные сервисы переведем на новые рельсы в конце 2018 — начале 2019 года.

Начать новый переход планируем в начале 2019 года и закончить его в конце следующего года.

Используют в крупных проектах с высокой нагрузкой, которым требуется повышенная безопасность.

Источник

Информационная архитектура — что это и как её создать

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

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

Что такое информационная архитектура

ДНК проекта. То, что вы создаёте, определяет существование проекта и всех его последующих воплощений на годы вперёд.

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

Зачем команде информационная архитектура

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

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

Инструмент для самоанализа

Вы создаёте схему, где постоянно ставите себя на место пользователя. Правильно ли вы понимаете его потребности? Удобно ли ему пользоваться продуктом? Достигает ли он своих целей? Получает ли удовлетворение?

Наглядная демонстрация концептуальных идей

Удобно сразу показать все концептуальные идеи продукта на одной наглядной схеме.

Руководство для проектирования и разработчиков

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

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

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

Гарантия жизнеспособности экосистемы пользователя

Людей нельзя научить радоваться мерзости. Она может быть привлекательна для кого-то, но при этом оставаться мерзостью. Красота остаётся красотой. Дисгармония в ИА сразу привлекает внимание, и вы можете подумать и исправить её на раннем этапе. Соответственно, результат будет более жизнеспособен.

Понимание сервиса или сайта как единого продукта

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

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

Ситуационный анализ включает:

Последний этап — SWOT-анализ. Этот метод позволяет графически зафиксировать всё, что вы узнали о проекте и сделать выводы.

Структура SWOT-анализа

После этого вы оформляете цели и задачи:

Бизнес-цели касаются денег, окупаемости.

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

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

Она состоит из трёх составляющих:

Например, для банковских сайтов это будет выглядеть так:

Если всё это описывать, можно потратить много времени. Это утомительно для вас и всех участников проекта. Поэтому всё, что вы вкладываете в проект, нужно уметь объяснять за 5 минут.

Особенности построения информационной архитектуры

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

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

Что является отдельной страницей, сервисом, состоянием навигации, описанием информационного блока?

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

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

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

Возьмём в пример банковские сайты. Они имеют в своей основе похожую архитектуру и пользовательские паттерны:

Похожая навигационная панель сайтов Тинькофф-банка и Альфа-банка

Если люди приходят на сайт и видят что-то другое, им приходится учиться. Это требует больше времени и сил.

Выберите базовую модель классификации

И придерживайтесь её на всех экранах проекта. Пользователь должен интуитивно понимать, как с ним разговаривают.

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

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

Если вы создаёте ИА, полезно иногда закрывать глаза, указывать в любой участок схемы и задавать вопросы. Если пользователь окажется в этой точке, он поймёт, как она связана с другими? Что это не отдельный экран, а часть продукта? Вспомнит ли как сюда попал, если отвлечётся на пять минут от экрана?

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

Человек покупает дрель. Но дрель сама по себе не потребность. Потребность — сделать дырку в стене, а потом человек поставит дрель на полку.

Существует несколько распространённых форматов взаимосвязей.

Иерархический формат

Подчинение от центра вглубь. Может быть представлен в виде ментальной карты, древовидного представления, логического представления.

В первом варианте мы видим взаимосвязи, но возникают вопросы с приоритетами. Мы не можем до конца понять замысел архитектора. Во втором варианте вводится маркировка, и прослеживается иерархия: «Личные финансы» — главная страница сайта, потом «VIP-клиентам», «Услуги для бизнеса» и так далее.

Сценарный формат

Более наглядный и более доступный неподготовленному взгляду.

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

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

Матричная структура

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

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

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

Пример оформления матричного перехода при помощи стандартного иерархического формата

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

Модель базы данных

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

Это наиболее дружелюбная к пользователю модель при должной поддержке интерфейса.

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

Информационная архитектура — это надолго

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

Предусмотрите возможное масштабирование как в рамках всего сайта, так и внутри отдельных разделов. Нужно понимать, что произойдёт с проектом через несколько лет: какие элементы отвалятся и как это отразится на ИА.

Сейчас ветка выглядит сбалансированно, но вы знаете, что через два года компания будет отказываться от этого бизнес-направления, а другое направление будет расти. Уже сейчас это можно учесть в ИА, чтобы без проблем для всего проекта «отвалиться» в нужное время.

Сделав базовый скелет, нужно решить, какой контент подавать на продуктовые страницы. Это тоже часть архитектуры.

Из чего состоят отдельные информационные объекты и как контент влияет на архитектуру? Какой будет адрес у проекта, как будут строиться заголовки, есть ли нестандартные форматы (таблицы, видео, аудио, файлы для скачивания)?

На схеме типовая продуктовая страница в формате информационной архитектуры:

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

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

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

Так замыкается круг разработки продукта.

Улучшайте качество взаимодействия с пользователями и не забывайте про вашу прибыль.

Статья подготовлена с использованием материалов лекции преподавателей курса Нетологии по UX/UI дизайну.

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.

Источник