Архитектура решения: Архитектура ИТ решений. Часть 1. Архитектура предприятия / Хабр

Что такое ИТ-архитектура? | GPI

Автор: Алексей Сахань

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

Помочь руководству Компании в принятии решений по данным вопросам может разработка ИТ-архитектуры. Что это и зачем она нам нужна?

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

  • Комплексность автоматизации
  • Если не предполагается комплексная автоматизация, то определение направлений деятельности, бизнес-процессов или подразделений, которые будут автоматизироваться
  • Порядок автоматизации, сроки отдельных этапов
  • Выбор используемых продуктов, систем, платформ
  • Применение заказных разработок
  • Используемые методики интеграции
  • Способы реализации проектов (использование услуг сторонних Компаний, аутсорсинг, выполнение работ силами собственного подразделения и пр.)
  • Способы поддержки основных ИТ-сервисов (традиционный, SLA)

ИТ-архитектуру можно определить термином «организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие». Таким образом, разработанная ИТ-архитектуры должна ответить на следующие вопросы:

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

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

Проблема построения ИТ-архитектуры изучается более 20 лет. Разработано множество методологий построения ИТ-архитектуры, однако ни одна из методологий не считается идеальной, отвечающей всем потребностям. Наиболее простой для использования считается методология, получившая название «Структура Джона Захмана». Внешний вид «Структуры Джона Захмана» представлен в виде Таблицы 1. Для формализованного описания ИТ-архитектуры организации могут использовать различные форматы. Важно, чтобы организация использовала такой формат описания, который бы обеспечивал легкий для понимания способ руководства по развитию всех аспектов ИТ в организации.

Таблица 1

УЧАСТНИКИДанныеФункцииСетьЛюди
Время
МотивацияРЕЗУЛЬТАТ
ЧТО?КАК?ГДЕ?КТО?КОГДА?ПОЧЕМУ?
Бизнес-руководителиПланировщикСписок важных понятий и объектовСписок основных бизнес процессовТерриториальное расположениеКлючевые организацииВажнейшие событияБизнес-цели и стратегииСфера действия
Владелец, менеджерКонцептуальная модель данныхМодель бизнес процессовСхема логистикиМодель потока работ (workflow)
Мастер-план реализации
Бизнес-планМодель предприятия
ИТ-менеджеры и разработчикиИТ-архитекторЛогические модели данныхАрхитектура приложенийМодель распределенной архитектурыАрхитектура интерфейса пользователяСтруктура процессовРоли и модели бизнес-правилМодель системы
ПроектировщикФизическая модель данныхСистемный проектТехнологическая архитектураАрхитектура презентацииСтруктуры управленияОписание бизнес-правилТехнологическая (физическая) модель
РазработчикОписание структуры данныхПрограммный кодСетевая архитектураАрхитектура безопасностиОпределение временных привязокРеализация бизнес-логикиДетали реализации

 

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

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

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

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

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

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

Помочь руководству Компании в принятии решений по данным вопросам может разработка ИТ-архитектуры. Что это и зачем она нам нужна?

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

  • Комплексность автоматизации
  • Если не предполагается комплексная автоматизация, то определение направлений деятельности, бизнес-процессов или подразделений, которые будут автоматизироваться
  • Порядок автоматизации, сроки отдельных этапов
  • Выбор используемых продуктов, систем, платформ
  • Применение заказных разработок
  • Используемые методики интеграции
  • Способы реализации проектов (использование услуг сторонних Компаний, аутсорсинг, выполнение работ силами собственного подразделения и пр.)
  • Способы поддержки основных ИТ-сервисов (традиционный, SLA)

ИТ-архитектуру можно определить термином «организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие». Таким образом, разработанная ИТ-архитектуры должна ответить на следующие вопросы:

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

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

Проблема построения ИТ-архитектуры изучается более 20 лет. Разработано множество методологий построения ИТ-архитектуры, однако ни одна из методологий не считается идеальной, отвечающей всем потребностям. Наиболее простой для использования считается методология, получившая название «Структура Джона Захмана». Внешний вид «Структуры Джона Захмана» представлен в виде Таблицы 1. Для формализованного описания ИТ-архитектуры организации могут использовать различные форматы. Важно, чтобы организация использовала такой формат описания, который бы обеспечивал легкий для понимания способ руководства по развитию всех аспектов ИТ в организации.

Таблица 1

УЧАСТНИКИДанныеФункции
СетьЛюдиВремяМотивацияРЕЗУЛЬТАТ
ЧТО?КАК?ГДЕ?КТО?КОГДА?ПОЧЕМУ?
Бизнес-руководителиПланировщикСписок важных понятий и объектовСписок основных бизнес процессовТерриториальное расположениеКлючевые организацииВажнейшие событияБизнес-цели и стратегииСфера действия
Владелец, менеджерКонцептуальная модель данныхМодель бизнес процессовСхема логистикиМодель потока работ (workflow)Мастер-план реализацииБизнес-планМодель предприятия
ИТ-менеджеры и разработчикиИТ-архитекторЛогические модели данныхАрхитектура приложенийМодель распределенной архитектурыАрхитектура интерфейса пользователяСтруктура процессовРоли и модели бизнес-правилМодель системы
ПроектировщикФизическая модель данныхСистемный проектТехнологическая архитектураАрхитектура презентацииСтруктуры управленияОписание бизнес-правилТехнологическая (физическая) модель
РазработчикОписание структуры данныхПрограммный кодСетевая архитектураАрхитектура безопасностиОпределение временных привязокРеализация бизнес-логикиДетали реализации

 

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

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

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

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

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

Архитектура решения | ИСЕРВ

  1. Главная
  2. Решения
  3. Импортозамещение
  4. Архитектура решения

Компоненты архитектуры

Компонент Технология Ответственность

СУБД

PostgreSQL

Хранение данных системы (OLTP, OLAP)

Хранимые процедуры (отчеты)

Модель

XML

Объектная модель данных приложения и правила валидации

Разметка интерфейса приложения. Представления данных

Статусная моделью. Конечный автомат переходов

Настройка прав на объекты модели

Клиентское приложение

React+Redux SPA

Аутентификация пользователей

Отображение интерфейса и данных из модели

Реализация UI бизнес-логики (custom контроллеры)

Асинхронный запуск серверных обработок (Actions)

Шина данных

RabbitMQ+ Python

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

Асинхронное выполнение серверных обработок

Распределение и масштабирование обработчиков (workers)

Сервер исполнения процессов

Camunda (Java)

Автоматизация бизнес-процессов на основе нотации BPMN 2.0

Интеграция с внешними веб-сервисами

Автоматизация документооборота

Сервер отчетов

PowerBI

Создание и исполнение отчетов из разных источников

Сервисы бизнес-логики

Python + Celery

Воркеры исполнения сервисов бизнес-логики

Динамическое управление нагрузкой (увеличение/уменьшение кол-ва воркеров)

Средства логирования и трасировки

Jaeger +

Elasticsearch +

Kibana

Сбор, централизованное хранение и обработка журналов со всех компонентов, входящих в состав системы

Трассировка и профилирование времени выполнения методов, входящих в состав прикладных компонентов системы, а также межкомпонентных вызовов

Кеш-сервер

Reddis+WebDav

Временное хранение результатов выполнения ассинхронных обработок (в т.ч. отчеты, пакеты интеграции и пр.)

СУБД. PostgreSQL

  • Postgres Pro — российская СУБД на основе PostgreSQL (postgrespro.ru)​:
    • переработана для соответствия требованиям корпоративных заказчиков​
    • входит в реестр российского ПО (см reestr.minsvyaz.ru/reestr/65273/)​
    • сертификат ФСТЭК СВТ 5, НДВ 4​
    • версия Enterprise содержит ряд существенных доработок, для работы с БД большого объема, высокой производительности и с повышенными требованиями к надёжности (postgrespro.ru/products/postgrespro/enterprise)​
  • Совместимая с Omni-US схема данных. Jsonb-расширения для доп.полей​
  • Расширенный инструментарий логирования на уровне БД.
  • Откат изменений данных​ Поддержка меток времени с временными зонами. 
  • Возможность работы логики БД в sync/async-режиме​
  • Возможность реализации логики на уровне БД

Модель приложения​

  • Слой метаданных, описывающий вид и поведение UI:​
    • Описание атрибутов и метаданных бизнес-объектов приложения​
    • Определение правил проверки значений реквизитов​
    • Описание состава, внешнего вида и расположения визуальных элементов представлений (View)​
    • Настройка варианта вывода представления (включая одновременное отображение списка и формы)​
    • Настройка условий отображения элементов представлений в зависимости от их значений​
    • Настройка правил безопасности при доступе к данным​
    • Привязка обработчиков событий (action) к разделу приложения​
    • Привязка разделов к пунктам меню
  • Визуальная настройка модели (сущности, формы, списки)​
  • Доступ к модели и данным через REST-интерфейс​

Клиентское приложение​

  • Single Page Application на основе React + Redux + DevExtreme ​
  • Аутентификация и ведение клиентской сессии пользователя​
  • Динамическое отображение представлений модели и данных в них​
    • Динамическая подгрузка представлений с сервера и их визуализация​
    • Реализация базовых CRUID-операций с данными в представлениях​
    • Валидация введенных значений в форме.
    • Обработка ошибок и предупреждений при сохранении данных​
    • Управление состоянием формы.
    • Условное форматирование. ​
    • Отображение операций с в представлениях и обеспечение их вызова​
  • Интеграционная шина для прикладных контроллеров, заданных для представления​
    • Взаимодействие с сервисной шиной​
    • Асинхронный запуск операций на сервисной шине​
    • Publisher событий интерфейса для обработчиков на шине​
    • Subscriber асинхронных нотификаций от сервисной шины​

Сервисная шина​

  • Среда для универсального обмена сообщениями между сервисами.
    • Регистрация сервисов на шине. Маршрутизация до сервиса​
    • Издатель-подписчик (Pub/Sub)​
    • Удаленный вызов процедур (sync/async)​ Получение списка сервисов.
    • Получение списка операций сервиса​
  • Сервисы на шине представляют собой компоненты бизнес-логики​
    • Реализуют общий интерфейс взаимодействия через шину​
    • Не имеют ограничений по технологии реализации​
    • Реализуют операции, список которых регистрируется на шине​
    • Операции сервисов видны в модели приложения и доступны для подключения в интерфейсе​
  • Операции – компоненты сервиса, реализующие функциональность:​
    • Процедуры бизнес-логики (python, sp pgsql)​
    • Пакеты интеграции и отчеты (результаты исполнения в WebDAV)​
    • Кастомные источники данных для интерфейса​
    • BPMN процессы (camunda)

Шина данных. Компоненты реализации​

    ​​
  • RabbitMQ​
    • Брокер сообщений​
    • Маршрутизация сообщений​
    • Pub/Sub​
  • Celery/Flower​
    • удаленный вызов процедур поверх RabbitMQ (async/sync)​
    • Масштабирование загрузки​
    • Управление нодами воркеров​
    • Мониторинг загрузки сети​
  • Сервисы маршрутизации и управления метаинформацией ​ (rest-сервис на python falcon)​
    • Регистрация/список сервисов и их операций​
    • Получение точки запуска операции​

Сервер процессов на основе​ Camunda

    ​​
  • BPMN рабочие процессы
  • DMN таблицы принятия решения
  • Инструментарий создания автоматизированных бизнес процессов
  • Интеграция с блоком документооборота Omnis​
  • АРМ для выполнения задач сотрудниками​
  • Мониторинг​

Логирование и трасировка​

  • Сквозное логирование работы всех компонентов системы в исторической ретроспетиве
    • Параметры и заголовки к REST-сервисам​
    • Запросы к БД (ORM->СУБД)
    • Операции на шине​ Ошибки.​
    • Ветвление внутри операций (mdc)​
  • Сборка логов всех компонентов в централизованное хранилище
  • Полнотекстовый поиск по логам
  • Построение дерева и профиля вызовов​
​​

Разрабатываем раздел «Архитектурные решения» по технологии MinD


Дмитрий Поварницын
Ведущий аналитик по строительному направлению, компания АСКОН

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

Современные BIM­системы имеют объектно­ориентированные инструменты и стандартизированные решения. Это значит, что они рано или поздно ограничивают пользователя в выборе нестандартных форм и решений.

КОМПАС­3D является универсальной системой для трехмерного моделирования, в которой можно создавать любые твердотельные формы или их композиции. Также в системе есть множество специализированных инструментов для разных отраслей промышленности, в том числе и для выполнения проектных работ. Речь идет о таких строительных приложениях, как «Архитектура: АС/АР», «СПДС­помощник», «Менеджер объектов строительства» и инструмент создания, структурирования и хранения интеллектуальных элементов «КОМПАС­Объект». Эти четыре приложения являются лишь небольшой частью технологии MinD, разработанной компанией АСКОН.

Технология MinD позволяет проектировать здания и сооружения на основе простой, современной, и в то же время эффективной методики. Суть данной технологии заключается в том, что всё проектирование происходит на чертежных листах, а результатом работы является проектная документация. Нет никаких моделей­посредников или абстрактных видов, через которые затем будут генерироваться чертежи, как это принято во многих системах, работающих по технологии BIM. В MinD чертежи создаются сразу, без участия посредников или обязательного информационного моделирования. Часто архитектору или проектировщику просто не хватает времени для информационного моделирования, так как чертежи нужно получить и распечатать в кратчайшие сроки. Особенно остро эта проблема ощущается во время работы над небольшими проектами, когда создание информационной модели становится нецелесообразным.

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

Но как совместить и то и другое? Как сделать так, чтобы информационное моделирование помогало при проектировании зданий и одновременно не мешало срочным работам?

У технологии MinD есть неоспоримое преимущество: точно так же, как любая BIM­система, она позволяет создавать информационную модель здания, которую можно увидеть в трехмерном пространстве в любой момент времени. Однако здесь такая возможность не является обязательным условием для проектирования: на любом этапе работы можно было отказаться от использования информационного моделирования или вообще его не использовать. Хочешь — создавай информационную модель, хочешь — быстро проектируй, используя автоматизированные инструменты своей специализации.

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

В статье мы будем говорить о приложениях, которые упоминались выше: на конкретном примере двухэтажного коттеджа я покажу, как с помощью технологии MinD совместно с базовыми инструментами КОМПАС­3D можно создавать уникальные архитектурные решения и целые архитектурные композиции.

Всю работу мы проведем в КОМПАС­3D V14 SP1, дополнительно используя архитектурные инструменты из Строительной конфигурации.

Разработка концепции объекта

В качестве примера мы будем рассматривать проект двухэтажного коттеджа. Для создания уникальной концепции, объемно­планировочного решения, проработки декоративных элементов, композиции и получения качественной 3D­модели, на основе которой можно создать фотореалистичные изображения, а также объединения всего этого в завершенный проект архитектору понадобится множество программ­инструментов.

Идею или концепцию можно просто набросать на листке бумаги или смоделировать в универсальном редакторе трехмерной графики (рис. 1). Для этой цели подойдет базовый КОМПАС­3D с широкими возможностями создания сложных или замысловатых форм.

Рис. 1. Набросок концепции коттеджа

Объемно­планировочное решение можно легко создать с помощью приложения «Архитектура: АС/АР». Для этого в нем присутствуют все необходимые автоматизированные инструменты. Сперва создадим новый документ «Чертеж» формата A2, активируем вид с масштабом 1:100 и на нем разместим сетку координационных осей, к которой впоследствии будем привязывать наши архитектурные элементы.

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

Рис. 2. План коттеджа

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

На планировке, конечно, сложно контролировать все трехмерные параметры объектов, поэтому время от времени нужно создавать 3D­модель и проверять себя. Делается это просто — при помощи одной кнопки Построение 3D­модели в менеджере объектов строительства (МОС) — рис. 3.

Рис. 3. Создание 3D-модели на основе плана с помощью МОС

Рис. 4. Трехмерная модель первого этажа коттеджа

Стоит помнить о том, что архитектор не всегда оперирует стандартными объектами. В нашем случае также есть необходимость создания нестандартных архитектурных объектов, например таких, как пятиугольные окна. В новой версии Строительной конфигурации для КОМПАС­3D V14 SP1 появилась функция «Пользовательский элемент». Она позволяет быстро расширять базы стандартных объектов и типовых решений, включенных в поставку, любыми пользовательскими наработками. Таким образом, архитектор может легко создавать «свои» виды объектов. Рассмотрим возможности добавления пользовательского элемента на примере нестандартного окна.

Рис. 5. Каталог окон

В приложении «Архитектура: АС/АР», в команде Окно появились дополнительные кнопки, которые позволяют создавать и управлять пользовательскими элементами (рис. 5). Пользовательские объекты можно создавать с нуля либо использовать готовые решения как шаблоны для формирования новых. Найти подобный элемент и немного его доработать легче, чем создавать новый элемент с нуля. Выберем среди нестандартных окон такой вид окна, который проще всего будет использовать для превращения его в пятиугольное.

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

Рис. 6. Интерфейс диалогового окна для создания пользовательских объектов

Интерфейс Пользовательского элемента достаточно прост в применении. Выгрузим из базы на диск параметрическую модель и Вид спереди шаблонного окна (рис. 6).

Далее эти файлы отдельно откроем в КОМПАС­3D и проведем редактирование размеров и формы окна базовым функционалом системы в соответствии с потребностями. В параметрическом фрагменте добавим новый сегмент и привяжем к нему параметрические размеры. То же самое проделаем в 3D­модели окна на его первоначальном эскизе (рис. 7).

Рис. 7. Добавление нового параметрического сегмента окна

Здесь есть один важный момент: нужно создать группу, образующую контур окна, чтобы проем в стене правильно формировался для такого вида. Подробнее об этом говорится в специальном документе «КОМПАС­3D V14. Строительная конфигурация. Руководство администратора», который входит в комплектацию Строительной конфигурации.

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

Далее последовательно загружаем измененные файлы с различными проекциями в создаваемый Пользовательский элемент (рис. 8).

Рис. 8. Добавление проекций нового вида окна

Рис. 9. Размещение пользовательского окна на плане

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

В нашем проекте «Коттедж» также требуется создание пары угловых окон. Воспользуемся уже знакомым нам функционалом «Создание пользовательского элемента». Для этого возьмем подходящий шаблон и подобным образом переделаем модель (рис. 10).

Рис. 10. Создание углового окна

Так как в плане окно будет отрисовано нестандартно, отредактируем вид сверху.

Угловое окно у нас должно разместиться одновременно в двух стенах. Однако функционал приложения не позволяет вставлять окно сразу в несколько стен, поэтому воспользуемся командой Окна и просто разместим окно в углу стыка стен (рис. 11).

Рис. 11. Размещение пользовательского углового окна на плане

Рис. 12. 3D-модель стены с угловым окном

Окно разместилось там, где надо, однако проемы в стенах автоматически не получились. Для этого вручную создаем нужные проемы за счет добавления стен высотой до подоконника углового окна и установки дополнительных балок над окном. После этого 3D­окно будет выглядеть как надо (рис. 12).

Возможности нового функционала по созданию пользовательских элементов имеют огромный потенциал и расширяют практически все базовые инструменты, что, в свою очередь, позволяет создавать любые объекты для их использования на чертежах (2D) и в 3D­моделях. Так как 2D и 3D — это, по сути, различные представления одного элемента, можно использовать любые упрощения, которые потребуются на чертежах, а также задействовать параметризацию таких элементов для возможности многократного использования в различных проектах.

Рис.13. План первого этажа

Закончим создание плана первого этажа (рис. 13), и на его основе быстро создадим все остальные этажи или уровни на разных видах и чертежных листах. С помощью Менеджера объектов строительства это делается легко и быстро. В итоге мы имеем все необходимые планировки на чертежных листах, уже частично оформленные и готовые для печати (рис.14а, б, в).

Рис.14. План нулевого (а), второго (б) этажей и кровли (в)

Рис. 15. 3D-модель коттеджа, выполненная по технологии MinD

Далее мы отображаем 3D­модель, проверяем на коллизии и возможные конфликтные пересечения объектов и тут же исправляем все обнаруженные недочеты (рис. 15). В этом и заключается бесспорное преимущество наличия в проекте 3D­модели.

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

Формировать такие композиции с помощью функционала создания пользовательских элементов можно, но это будет нерационально, поскольку такие элементы, как правило, разовые и нигде больше не повторяются. Подобные элементы проще и, в некоторых случаях, гораздо удобнее создавать непосредственно в 3D­модели. Для этого воспользуемся универсальными инструментами моделирования КОМПАС­3D. Стоит сразу заметить, что нет такой архитектурной формы, которую невозможно воспроизвести с помощью базовых инструментов КОМПАС­3D. В этом заключается основное преимущество всех универсальных редакторов объектов трехмерной графики. Поэтому создание сложных архитектурных форм — это дело техники и наличия знаний основ моделирования в КОМПАС­3D.

Для начала стоит предупредить, что наша 3D­модель будет полностью перезаписываться при каждом новом вызове генерации 3D­модели. Это связано с тем, что параметры уровней, их относительное положение и состав в информационной модели могут кардинально меняться. Именно поэтому необходимо каждый раз перезаписывать модель. Чтобы избежать этого, но оставить возможность доработки информационной модели через планировки, следует произвести лишь одно действие — переименовать головной файл модели. Для этого достаточно в открытом файле вызвать команду меню «Сохранить как…» и вписать иное название модели. Благодаря тому что при генерации модели в КОМПАС­3D создается множество файлов отдельных частей, таких как, например, уровни, колонны, балки, лестницы, площадки, оконные и дверные заполнители, конструкции и т.д., а все эти объекты объединяет головной файл формата A3D, то подобным образом можно создавать сколько угодно вариаций моделей под разными именами, которые объединяют в себе все внутренние объекты.

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

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

Рис. 16. Эскиз архитектурной композиции по оси Б (а) и оси Г (б)

Сделать их можно и с помощью инструмента отрисовки стен приложения «Архитектура: АС/АР»: в этом случае места сопряжения будут автоматически обработаны.

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

Рис. 17. Модель коттеджа с архитектурной композицией

Рис. 18. Моделирование ландшафта

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

Рис. 19. Модель коттеджа с ландшафтом

Таким образом, используя базовые инструменты моделирования и широкие возможности КОМПАС­3D, можно добиться впечатляющих результатов и воплотить любую архитектурную идею в жизнь. В нашем случае речь идет о готовой 3D­модели.

Эту модель можно и нужно использовать для быстрого автоматического получения фасадов и разрезов. На чертежных листах располагаем соответствующие ассоциативные проекции — фасады, разрезы. Если предполагается, что модель в дальнейшем будет изменяться, то ассоциативные связи разрушать не обязательно. Но доработать такие проекции всё же придется. Быстро оформить чертежи согласно требованиям СПДС можно с помощью приложения «СПДС­Помощник». «Отточить» внешний вид фасадов также помогут базовые инструменты КОМПАС­График (рис. 20).

Рис. 20. Чертеж с фасадами коттеджа

Рис. 21. Вид сверху на коттедж и размещение линий разрезов

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

Полученные разрезы могут потребовать неких оформительских штрихов, однако всё это можно сделать достаточно быстро (рис. 22).

Рис. 22. Разрезы и изометрическая проекция коттеджа

Важным моментом в информационном моделировании являются не только автоматически получаемые виды и разрезы, но и автоматическое получение актуальных спецификаций. Информационные модели, созданные по технологии MinD, автоматически выдают данные в соответствующие спецификации по ГОСТ (рис. 23).

Рис. 23. Спецификации и ведомости

Представляем объект заказчику

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

Фотореалистичные изображения модели можно получить с помощью еще одного приложения для КОМПАС­3D — Artisan Rendering, разработанноого английской компанией LightWorks, специализирующейся на реалистичной визуализации трехмерной графики. Для это нужно открыть файл 3D­модели и запустить приложение Artisan Rendering. Откроется окно отдельного приложения, в котором модель и отобразится.

В этом приложении группе однотипных объектов можно назначать любые материалы, текстуры и отражающие свойства. Также можно настроить внешнее освещение, добавить произвольный фон, настроить камеру и качество визуализации. В общем, в Artisan Rendering есть все необходимые инструменты для создания фотореалистичных изображений. Интерфейс приложения привычен любому дизайнеру и прост в освоении (рис. 24).

Рис. 24. Фотореалистичное изображение коттеджа в Artisan Rendering

Для получения фотореалистичного изображения архитектор также может использовать такой привычный ему инструмент, как 3ds Max. Для передачи модели из системы КОМПАС­3D используется формат STL (рис. 25а, б).

Рис. 25. Фотореалистичное изображение коттеджа, выполненное в программе Autodesk 3ds Max

***

Проект, который мы рассматривали в статье, наглядно демонстрирует, что совместное применение технологии MinD и инструментов трехмерного моделирования КОМПАС­3D позволяет достичь впечатляющих результатов как для архитекторов, так и для проектировщиков. Технология MinD удовлетворяет современным требованиям информационного моделирования зданий. Более того, она ничего не навязывает специалистам и не ограничивает их в своей профессиональной деятельности. С помощью нового функционала приложений и возможностей свободного моделирования в КОМПАС­3D можно создавать архитектурные проекты, воплощать в жизнь любые архитектурные идеи и замыслы, создавать шедевры.  


MinD (Model in Drawing — модель в чертеже) — технология, которая дает возможность использовать интеллектуальные строительные и технологические элементы, конструкции и оборудование для проектирования зданий и сооружений различных сложности и назначения. В общую технологию в единой графической среде КОМПАС­3D увязаны специализированные приложения (АС/АР, КМ, ОВ, ВК, ТХ, ЭС и др.), Менеджер объектов строительства и инструмент создания, хранения и использования строительных элементов КОМПАС­Объект.

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

САПР и графика 11`2013

Архитектура «1С:Предприятия» как продукт инженерной мысли

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

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

Сначала сделаем небольшое замечание по терминологии. Эта статья не ориентирована исключительно на тех, кто имеет дело с системой программ «1С:Предприятие». Как нам кажется, она может быть интересна многим специалистам, интересующимся развитием технологий экономических и корпоративных приложений, независимо от того с какими продуктами они работают. Поэтому в данной статье мы постараемся лишь в минимальном объеме использовать терминологию, специфическую для «1С:Предприятия». В некоторых случаях мы будем использовать для близких понятий различные термины, приводя их аналоги и необходимые разъяснения.

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

За что боремся

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

Так вот, основная задача платформы «1С:Предприятие» заключается, прежде всего, в реализации данного подхода при разработке и использовании бизнес-приложений. Разумеется, заодно решаются и традиционные задачи, связанные с производительностью, эргономикой, функциональностью и т. д. Но именно повышение уровня абстракции позволяет перейти от технических и низкоуровневых понятий к более содержательным и высокоуровневым, а значит приблизить их к языку пользователей и специалистов в предметной области. В конечном итоге это позволяет значительно ускорить и унифицировать как саму разработку системы, так и ее сопровождение.

Платформа и бизнес-приложения

Пожалуй, наиболее концептуальными в архитектуре «1С:Предприятия» являются само наличие платформы и понятие бизнес-приложения.

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

В «1С:Предприятии» было введено четкое разделение на платформу и бизнес-приложение. Платформа представляет собой так называемый framework, в котором функционирует бизнес-приложение. Мы не смогли найти точного перевода этого слова на русский язык. С одной стороны framework можно считать фундаментом для построения приложений, а с другой — средой исполнения. Кроме того, платформа содержит, разумеется, и инструментарий, необходимый для разработки, администрирования и поддержки бизнес-приложений. Такое приложение является самостоятельной сущностью и может выступать в качестве отдельного программного продукта, но полностью опирается на технологии платформы.

Заметим, что понятие платформы и платформенно-ориентированного построения приложений сейчас является общепринятым и трактуется гораздо шире, чем просто способность работать в определенной операционной системе. Под платформой понимается среда исполнения и набор технологий, используемые в качестве основы для построения определенного круга приложений. Фактически, приложения базируются на нескольких платформах, образующих многослойный пирог. При этом важно, что платформа предоставляет разработчику определенную модель, как правило, изолирующую его от понятий и подробностей более низкоуровневых технологий и платформ. Такова и платформа «1С:Предприятие», позволяющая использовать самые разные технологии более низкого уровня, не меняя кода бизнес-приложений.

Например, она предлагает разработчику собственную модель работы с данными и изолирует его от особенностей конкретного хранилища данных, а это позволяет, не изменяя бизнес-приложение использовать в нем различные хранилища. К примеру, в качестве БД при решении задач небольшого масштаба может применяться собственный файловый движок, а для работы в масштабе предприятия — MS SQL Server.

Ключевым качеством платформы «1С:Предприятие», пожалуй, является достаточность ее средств для решения задач, стоящих перед бизнес-приложениями. Это позволяет обеспечить очень хорошую согласованность всех технологий и инструментов, которыми пользуется разработчик. Ведь часто именно наличие «швов» между различными технологиями становится причиной самых серьезных проблем. Простейший пример — система типов. В платформе «1С:Предприятие» разработчик использует одну систему типов данных и для взаимодействия с БД, и для реализации бизнес-логики, и для построения интерфейсных решений:

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

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

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

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

Инструментальные средства «1С:Предприятия» представляют собой не некий дополнительный «toolkit», а являются неотъемлемой составляющей платформы. Они ориентированы в равной степени, как на разработку решений, так и на их адаптацию при внедрении на конкретном предприятии. Эти средства поставляются с каждым комплектом 1С:Предприятия и применяются как для внесения небольших изменений, например, в макет печатной формы, так и для существенной доработки прикладного решения включая структуры данных и бизнес логику. Возможности эффективного внесения изменений в приложение при его внедрении заложены в самих этих инструментах, а, кроме того, этому способствует и архитектура построения прикладного решения. В следующих разделах статьи мы постараемся проиллюстрировать данный тезис.

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

Метаданные — способ описания бизнес-приложения

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

В основе бизнес-приложения лежат метаданные. Они представляют собой структурированное декларативное его описание. Метаданные образуют иерархию объектов, из которых формируются все составные части прикладной системы и которые определяют все аспекты ее поведения. Фактически, при работе бизнес-приложения платформа «проигрывает» (интерпретирует) метаданные, обеспечивая всю необходимую функциональность.

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

Что дает такой подход к построению бизнес-приложения? Во-первых, при описании метаданных широко используется визуальное редактирование. Это позволяет свести существенную часть разработки к визуальному проектированию, не требующему кропотливого написания кода. Однако у данного подхода есть и другие не менее важные преимущества. Описывая прикладное решение в терминах метаданных, разработчик «сообщает» платформе много очень полезной информации, которую та может эффективно использовать в самых различных целях. На основе метаданных система автоматически «выстраивает» большую часть механизмов и объектов, обеспечивающих функционирование прикладного решения. Например, описания метаданных платформе достаточно для того, чтобы автоматически сформировать пользовательский интерфейс системы, обеспечивающий ввод и редактирование взаимосвязанной информации. Другой пример — возможность построения даже конечным пользователем, не имеющим навыков программирования, достаточно сложных отчетов.

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

Эта идеология (Metadata Driven) сегодня находит все большее применение во многих перспективных разработках.

Построение приложения на основе модели

В «1С:Предприятии» изначально заложена строгая ориентация на построение прикладного решения на основе определенной модели.

Этот подход является весьма перспективным и по нашей оценке будет доминирующим в обозримом будущем в современных средствах разработки. Идеи построения бизнес-приложений на основе модели, например, нашли воплощение в архитектуре MDA (Model Driven Architecture) консорциума OMG.

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

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

Очевидным следствием этого подхода является изоляция разработчика бизнес-приложения от деталей технологий хранения информации, организации трехуровневой архитектуры и т. д. Например, как уже отмечалось выше, все прикладные решения, базирующиеся на «1С:Предприятии», без каких-либо изменений работают как с собственным файловым движком БД, так и с сервером БД. При этом необходимые структуры данных создаются и изменяются системой автоматически на основе описания метаданных, и разработчику не приходится вникать в детали форматов хранения конкретных СУБД. Манипулирование данными в приложении также описывается в высокоуровневой модели и автоматически исполняется с учетом особенностей используемого хранилища.

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

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

Например, описание в метаданных тех или иных объектов (сущностей) сразу определяет и соответствующие типы встроенного языка программирования и необходимые для их хранения структуры БД. Все последующие манипуляции этими объектами, как в памяти, так и в БД выполняются единообразно, не требуя преодоления «барьеров» между различными нотациями, принятыми при работе с СУБД и с универсальными языками программирования.

Управление данными

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

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

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

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

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

В «1С:Предприятии» используется смешанный подход, который с одной стороны имеет много общего с подходами, заложенными в перспективных разработках других фирм, но с другой стороны обладает и существенными отличиями.

Для всех операций модификации данных (создания, изменения и удаления) в «1С:Предприятии» применяется исключительно объектная техника. Это означает, что разработчик взаимодействует с БД не на уровне записей, а с помощью объектов, соответствующих хранимым в БД сущностям. Для изменения хранимых данных, ему не нужно писать сложные запросы и преобразовывать результаты их обработки в объекты языка программирования. Достаточно получить объект из базы данных, изменить его свойства и снова сохранить. Разработчик имеет при этом возможность написать обработчики событий, связанных с изменением данных, выполняя с их помощью различные проверки и изменяя при необходимости другие данные. Система обеспечивает эффективную технологическую поддержку объектного подхода, осуществляя, например, кэширование объектов, контроль объектной и ссылочной целостности и т. д. Для чтения данных может использоваться как объектная техника, так и декларативный язык запросов, который основывается на классическом SQL, но имеет ряд существенных расширений. Расширения направлены с одной стороны на поддержку работы с объектами, хранящимися в базе данных, а с другой — на эффективное решение экономических задач. Ниже мы рассмотрим язык запросов более подробно:

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

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

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

Здесь, немного забегая вперед, следует сказать, что в модели «1С:Предприятия» реализована наиболее современная концепция работы с информацией, сочетающая три способа представления данных — хранение сущностей в базе данных, их представление в языке программирования в виде объектов и отображение в формате XML. Фактически любая информация может в зависимости от текущего режима работы представляться одним из этих трех способов.

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

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

Такой подход позволяет органично вписывать «1С:Предприятие» в будущие гетерогенные решения, которые по нашей оценке (и она совпадает с оценкой многих экспертов) получат со временем самое широкое распространение.

Одной из отличительных особенностей модели «1С:Предприятия», не имеющей, как нам кажется, прямых аналогов в других подобных системах является деление всех прикладных данных на те, что имеют объектную природу и не имеющие таковой. Заметим, что для манипулирования и теми и другими используется объектная техника.

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

В результате такого смыслового разделения сущностей платформа «1С:Предприятие» фактически предлагает разработчику готовую методологию для наиболее естественного решения различных задач манипулирования данными в соответствии с природой этих сущностей.

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

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

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

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

Еще одной важной особенностью объектной техники, принятой в платформе «1С:Предприятие», является то, что те же объекты, которые присутствуют в модулях на встроенном языке (как для объектных, так и для не объектных сущностей) используются и для отображения данных в интерфейсе. Элементы управления форм непосредственно связываются с нужными объектами, и обеспечивают их отображение и редактирование пользователем без какой-либо помощи со стороны разработчика.

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

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

Еще одним важным решением в части работы с данными в «1С:Предприятии» является поддержка в полях таблиц составных типов данных. Эта возможность, насколько нам известно, не имеет близких аналогов в других системах. При описании типа поля какого-либо объекта можно выбрать не только один из доступных типов, но и практически любую (с некоторыми ограничениями) их комбинацию. Например, в поле «Плательщик» в документе, отражающем операцию с банком, допускается хранение ссылки на юридическое или физическое лицо в зависимости от конкретной операции. Хотя приведенный пример является достаточно простым, возможность работы с составными типами позволяет решать такие задачи, как хранение произвольных характеристик товаров, ведение аналитического учета на бухгалтерских счетах по любому составу аналитических разрезов, настраиваемых пользователем и т. д. Важно, что система не просто предоставляет возможность хранения в одном поле разнородных значений, а делает это прозрачным для разработчика способом. Прежде всего, необходимо отметить полную поддержку работы с полями составных типов «движка» базы данных и языка запросов. Для этих полей поддерживается весь набор стандартных операций (сравнение, агрегирование и т. д.). Другим важным моментом является поддержка составных типов в интерфейсных механизмах системы. Например, поле ввода, связанное с данными такого составного типа, предоставляет весь набор возможностей редактирования (выбор типа; редактирование значений всех типов, входящих в указанное поле; ограничение выбираемых типов).

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

Прежде всего, следует отметить поддержку в языке запросов объектов, хранящихся в БД. Все операторы языка запросов обеспечивают работу со ссылочными типами (полями, хранящими ссылки на объекты БД). Например, поддерживается обращение к полям в нотации «через точку» без ограничения количества уровней. Можно указать в запросе выборку такого поля, как «Товар.Производитель.Страна.Наименование». Для объектов базы данных допускается обращение к вложенным таблицам и как к отдельным таблицам, и как к обычным полям объекта, содержащим коллекции записей.

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

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

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

Стандартные прототипы прикладных объектов

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

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

В модели разработки «1С:Предприятия» используется подход, которому мы не нашли явного аналога в других системах. Здесь все прикладное решение описывается метаданными в виде совокупности прикладных объектов, выбираемых из жестко определенного набора прототипов (классов). Можно было бы назвать создаваемые объекты бизнес-компонентами, а их прототипы шаблонами (patterns). Каждый такой прототип отвечает за отражение вприкладном решении определенной совокупности объектов или процессов предметной области, имеющих схожие поведенческие характеристики и сходную роль в общей картине решения.

Примерами таких прототипов в «1С:Предприятии» являются «Справочники», «Документы», «Регистры накопления». Каждый прототип имеет некоторую базовую реализацию, которая определяет особенности функционирования, создаваемых на основе данного прототипа объектов: структуру хранимых сущностей вместе с некоторыми предопределенными полями, набор типов языка программирования, методы, свойства и события, а также типовые для решаемой задачи операции, способы отображения и редактирования, методы регулирования прав доступа и т. д.


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

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

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

Таким образом, структура метаданных «1С:Предприятия» является не просто набором описаний объектов в определенных унифицированных терминах. Все прикладное решение, фактически, состоит из объектов, четко разделенных по тем ролям, которые они играют в бизнес-приложении. Такой подход существенно усиливает эффект и от описания системы в терминах метаданных, и от построения приложения на основе модели.

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

Использование предопределенных прототипов обеспечивает стандартизацию модели построения прикладных решений. Такая стандартизация, возможно, не очень существенна для одного отдельно взятого бизнес-приложения, но она имеет огромное значение при создании индустрии разработки и поддержки множества прикладных решений. Стандартизация позволяет существенно упростить задачи проектирования и в несколько раз снижает сложность и трудоемкость сопровождения. Например, если необходимо подключить к проекту еще одного специалиста или передать другому сотруднику поддержку и развитие решения, новый разработчик может после беглого просмотра структуры метаданных буквально за несколько минут составить общее представление о строении и основной функциональности прикладного решения, так как в структуре метаданных все прикладные объекты сгруппированы по принятым в модели «1С:Предприятия» функциональным ролям. В дальнейшем он сможет также быстро разбираться в устройстве и бизнес-логике отдельных подсистем. По опыту эти показатели существенно отличаются от тех, которые достигаются при использовании других подходов к описанию приложения.

Прикладные объекты и механизмы

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

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

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

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

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

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

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

Весьма интересными являются прототипы объектов «1С:Предприятия», применяемые в механизме сложных периодических расчетов. Этот механизм можно рассматривать как универсальный инструмент для решения задач расчета зарплаты любой сложности. На самом деле, расчет зарплаты является наиболее типичным применением данного механизма, но сам механизм не имеет ориентации именно на эту задачу и успешно используется для решения других задач, требующих описания периодических расчетов со сложными взаимосвязями, например, расчета дивидендов, стоимости коммунальных услуг и т. д. Он содержит набор типовых стратегий, примером которых может служить вытеснение одних видов расчетов другими при их пересечении на шкале времени. Применительно к задаче расчета зарплаты эта возможность решает весь комплекс проблем, связанных с пересекающимися по времени начислениями и удержаниями, для которых определены сложные правила взаимного исключения. Другим примером является возможность установки взаимосвязи между различными видами начислений и удержаний по периоду действия. Таким образом, механизм представляет определенную математическую модель, устанавливающую связи между различными видами расчетов и предоставляет разработчику действующие на основе этой модели механизмы обработки информации.

Не углубляясь далее в подробности этого механизма, стоит отметить, что он позволяет полностью описать схему расчета зарплаты на основании предоставляемых прототипов прикладных объектов и заложенных в них возможностей. На примере данного механизма можно достаточно наглядно продемонстрировать эффект от использования предлагаемого подхода. Мы не имеем на данный момент информации о наличии в каком-либо средстве разработки экономического софта подобного механизма. Во всех известных нам случаях модуль расчета зарплаты (Payroll) реализуется ценой достаточно больших затрат и на проектирование и на реализацию. Причем этот модуль приходится существенно или полностью переписывать для каждой страны, так как он сильно привязан к местному законодательству. Применение механизма сложных периодических расчетов в «1С:Предприятии» позволяет перевести разработку такого модуля от проектирования «с чистого листа» к реализации по стандартной схеме. По нашей оценке это сокращает затраты на порядок, но самое главное, существенно упрощается внесение изменений в процессе поддержки системы.

Еще одним характерным примером служит механизм характеристик, предназначенный для решения задач, которые плохо согласуются с классической реляционной моделью базы данных. Одной из таких задач, является построение структуры для отражения разнообразных свойств (характеристик) номенклатуры товаров или изделий. Если создается решение для одной организации с четкой ориентацией на определенную группу товаров, то все необходимые реквизиты можно заложить непосредственно в структуру каталога товаров. Например, для дилерской фирмы по продаже автомобилей ими будут цвет, объем двигателя и т. д. Однако если создается тиражное бизнес-приложение, или решение для организации, занимающейся производством или продажей разнообразной номенклатуры, этот вариант не подходит, так как очевидно, что состав характеристик должен зависеть от конкретной группы номенклатуры и добавление каждой новой группы не должно сопровождаться доработкой прикладного решения. Очевидно, что реализация такого решения плохо ложится в реляционную структуру и требует особого подхода. Реализованный в «1С:Предприятии» механизм характеристик предоставляет разработчику типовое средство решения подобных задач. Специализированный прототип предназначен для организации хранения списка видов характеристик. При этом каждому такому виду приписывается свой тип данных. Например, объем двигателя будет задаваться числом, а цвет выбираться из справочника. Важно, что конкретные виды характеристик могут не только определяться в самом приложении, но и добавляться пользователем в процессе эксплуатации системы без изменения прикладного решения. При этом разработчик может задействовать данный механизм в самых различных ситуациях, например, для хранения логически связанных комбинаций характеристик номенклатуры и расчета себестоимости в разрезе имеющихся комбинаций.

Еще одним интересным решением является механизм бизнес-процессов (work-flow), позволяющий разработчику организовать совместную работу пользователей при выполнении типовых последовательностей деловых операций. Во многих существующих информационных системах для решения задач work-flow используются специализированные продукты, которые приходится интегрировать с приложениями, решающими экономические задачи. В платформе «1С:Предприятие» механизм бизнес-процессов полностью интегрирован в систему таким образом, что ни разработчик ни пользователь не видят «швов» разделяющих этот механизм и другую функциональность. Этот механизм включает средства для описания в прикладном решении схем бизнес-процессов, и их ролевой маршрутизации, для формирования заданий, выполняющихся в каждой точке маршрута, для управления бизнес-процессом и организации его связи с другими функциями прикладного решения.Данный механизм предоставляет разработчику гибкие возможности управления ветвлением процесса и формирования задач. Например, кроме обычного условного ветвления разработчик может визуально описать параллельное прохождение нескольких веток маршрута, и указать точку их слияния. Допускается направление одного задания группе потенциальных исполнителей, например, если выписать счет должен один из менеджеров отдела. И наоборот, в некоторой точке маршрута можно инициировать несколько заданий, например, если финансовые отчеты должны представить все руководители отделов. Ролевая маршрутизация позволяет формировать задачу не только непосредственно конкретному сотруднику, но и распределять задачи по ролям, подразделениям и другим критериям, которые может описать разработчик прикладного решения. При осуществлении ролевой маршрутизации разрешается указывать текущее распределение обязанностей сотрудников с учетом временных замещений, совмещений нескольких должностей и т. д. Важно отметить, что данный механизм предлагает готовую стратегию автоматизации совместной деятельности работников предприятия. Для описания простейших бизнес-процессов достаточно визуального задания схемы маршрута и указания условий ветвления в их узловых точках. Все остальные действия выполняются системой автоматически. При реализации сложных бизнес-процессов усилия разработчика требуются в основном для тесной их увязки с функциями прикладного решения.

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

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

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

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

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

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

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

Механизм сведений предназначен для решения задач, связанных с хранением разнообразной информации об объектах в различных разрезах.

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

Еще раз подчеркнем, что в модели «1С:Предприятия» прикладные механизмы и лежащие в их основе прототипы — это не просто набор шаблонов, которые разработчик может использовать «по мере надобности». Всё прикладное решение с необходимостью основывается на использовании предлагаемого набора прототипов.

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

Высокоуровневая модель интерфейса

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

Основной идеей построения интерфейса, реализованной в «1С:Предприятии», является максимальное использование информации из метаданных, а также объектов манипулирования данными с тем, чтобы вся конструкция не требовала детальной настройки со стороны разработчика и функционировала по большей части автоматически. Мы уже говорили выше, что объекты встроенного языка, используемые для манипулирования данными, применяются и для их отображения в интерфейсе. Разработчику достаточно связать такой объект с элементом управления и механизм интерфейса полностью возьмет на себя организацию просмотра и модификации данных. Однако, наибольший эффект достигается за счет установления связи между объектом манипулирования данных и самой формой, а не с отдельными элементами управления. В таком случае вся функциональность формы, относящаяся к просмотру и редактированию данных, а также ее связь с другими формами, обеспечивается системой автоматически. Для этого в «1С:Предприятии» реализован механизм расширений форм и расширений элементов управления. Расширения автоматически «включаются в работу» с учетом типа данных, с которыми связан элемент управления или форма.

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

Другим интересным примером является табличное поле. Этот элемент управления представляет собой мощный механизм визуализации и редактирования данных, предоставляющий пользователю возможность просмотра и редактирования больших списков, за счет динамического считывания. Мы уже говорили выше о механизме динамического считывания, как одном из средств манипулирования данными. В механизме интерфейса «1С:Предприятия» он позволяет просматривать массивы данных практически неограниченного размера без считывания их в память целиком. При этом с точки зрения пользователя навигация по списку практически не отличается от просмотра данных, находящихся в памяти компьютера. Данный механизм поддерживает гибкие возможности поиска и фильтрации, просмотра иерархических структур, редактирование данных в списке и в отдельных формах, настройку состава колонок и их сортировки, печать списков и их экспорт в различные форматы и т. д.

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

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

Важно что, интерфейс «1С:Предприятия» обеспечивает работу не просто отдельных форм и элементов управления. Штатная механика управления формами прикладных объектов обеспечивает различные варианты связей между форами используемые при выборе значений, множественном подборе, детализации информации и т. д. Фактически, платформа «1С:Предприятия» предлагает разработчику готовую стратегию организации всего интерфейса бизнес-приложения имеющую способы реализации практически всех необходимых сценариев работы пользователей.

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

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

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

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

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

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

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

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

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

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

Следует упомянуть и о Web-расширении — механизме, позволяющем реализовывать Web-интерфейс к прикладным решениям «1С:Предприятия». Мы не будем рассказывать о деталях технологического устройстве этого механизма. Наиболее интересным в его реализации, на наш взгляд является то, что он также как и основной (rich) интерфейс максимально использует для автоматического формирования Web-форм информацию из метаданных, а также знания о назначении и устройстве прототипов прикладных объектов. Форма для редактирования любого объекта или просмотра списка объектов создается Web-расширением автоматически или может быть определена разработчиком вручную в проекте. Если разработчик описывает форму самостоятельно, то в его распоряжении специализированные элементы управления, которые не только позволяют организовать связь с теми или иными данными, но и предоставляют всю необходимую функциональность по просмотру и редактированию. Например, в полях ввода поддерживается выбор из форм-списков и подбор по первым буквам, в списках поддерживается иерархический просмотр, настройка пользователем фильтрации и сортировки. Система предоставляет большой набор стандартных действий по «обслуживанию» данных и самостоятельно организует связь между формами приложения. Таким образом обеспечивается единообразие двух вариантов пользовательского интерфейса (разумеется, с поправкой на особенности среды Web), а также максимальная автоматизация их разработки, основанная на использовании информации из метаданных.

Одним из наиболее важных, на наш взгляд, следствий построения пользовательского интерфейса на основе стандартных средств предоставляемых платформой является то, что интерфейс всех прикладных решений «1С:Предприятия» построен единообразно. Это позволяет пользователям максимально применять накопленный ранее опыт. Освоив приемы работы с интерфейсом одного бизнес-приложения, пользователь легко начнет работать с любым другим прикладным решением «1С:Предприятия».

Интеллектуальные механизмы подготовки отчетов

В любом бизнес-приложении имеются два основных механизма, обеспечивающих взаимодействие пользователя с системой. Это интерфейс, предназначенный для ввода информации, и средства подготовки отчетов. Поскольку механизмы получения отчетов отвечают, прежде всего, за представление пользователю информации, необходимой для принятия управленческих решений, естественно, что в «1С:Предприятии» им уделено особое внимание.

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

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

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

Выборка исходной информации осуществляется на основе описаний, выполненных с помощью языка запросов «1С:Предприятия». Поскольку при этом активно используются готовые виртуальные таблицы учетных механизмов, текст запроса для достаточно сложного отчета будет занимать всего несколько строчек. Его вовсе не обязательно писать вручную. В большинстве случаев запрос формируется средствами визуального конструктора и зачастую вся процедура сводится к выбору источника данных и указанию полей итогов. Данный инструмент позволяет визуально формировать логические конструкции практически неограниченной сложности, включая объединения запросов и вложенные запросы, а также способен «поднимать» для редактирования текст запроса, расположенный в любом месте модуля.

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

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

Кроме того, построитель автоматически включает в сформированный отчет всю информацию, необходимую для расшифровки отдельных ячеек отчета (drill-down). Эта расшифровка выполняется в интерактивном режиме- буквально одним щелчком мыши по выбранной ячейке отчета может быть автоматически сформирован более детальный отчет на основании данных этой ячейки и информации, содержащейся в исходном отчете:

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

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

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

В отличие от большинства электронных таблиц табличный документ «1С:Предприятия» может содержать таблицы, имеющие очень большие размеры, как по вертикали, так и по горизонтали. У него богатый набор изобразительных возможностей, позволяющий с одной стороны создавать хорошо оформленные аналитические отчеты, а с другой — подготавливать регламентированные бланки с точной привязкой содержащихся в них объектов к локальным координатам. В отличие от стандартных электронных таблиц здесь разрешается описывать строки с различными настройками ширины колонок. Это необходимо для создания сложных отчетов включающих несколько разноформатных таблиц.

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

Важно, что средство генерации табличных документов служит не только для получения статических печатных форм. В нем имеется мощный интерактивный механизм для управления многоуровневыми группировками, расшифровки ячеек отчета (drill-down), автонастройки ширины колонок и т. д. Допускается сохранение отчета в различных форматах (html, xls, txt). Кроме того, для интерактивного анализа многомерной информации в табличном документе может использоваться сводная таблица, которая позволяет непосредственно управлять группировкой информации и составом отображаемых данных, не обновляя отчета.

Чрезвычайно важным качеством табличного документа является возможность использования его в качестве полнофункционального механизма ввода и редактирования информации. Такой документ может содержать любые элементы управления, используемые в формах «1С:Предприятия», как в самих ячейках и рисунках, так и поверх ячеек. Это особенно полезно в тех случаях, когда одна и та же форма должна представлять собой и отчет, и инструмент для редактирования информации. Примером может служить отчет о плановых показателях, которые разрешается корректировать.

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

Весьма полезен также механизм интеллектуального анализа данных (data mining), с помощью которого прикладное решение можно с минимальными затратами оснастить такими аналитическими инструментами, как кластерный анализ, дерево решений и т. д.

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

Построение распределенных и интегрированных информационных систем

Еще одной «козырной картой» платформы «1С:Предприятие» являются механизмы обмена данными.

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

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

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

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

Наличие в платформе эффективных, не требующих сложной настройки механизмов обмена обязано, прежде всего, общей архитектуре построения прикладных решений, реализованной в платформе «1С:Предприятие». Мы уже говорили, о том, что органичный переход к распределенным и интегрированным системам обеспечивается объектной техникой манипулирования данными, используемой в «1С:Предприятии». Система соответствующих объектов обеспечивает штатные возможности сохранения (persistence) любых прикладных данных в формате XML. Кроме того, благодаря наличию стандартных прототипов прикладных объектов платформа способна автоматически задавать для каждого объекта необходимую гранулярность передачи изменений и стратегию обмена в соответствии с его назначением. Основной проблемой большинства известных систем обмена и репликации является то, что в заложенной в них семантике описания данных не содержится сведений о том, какими порциями выполнять обмен, как разрешать коллизии, как обеспечивать логическую целостность и непротиворечивость данных. Из-за этого разработчику при использовании подобных механизмов обычно приходится детально описывать процедуры обмена для каждого информационного массива.

Механизмы обмена «1С:Предприятия» функционируют на уровне стандартных прототипов прикладных объектов и поэтому имеют в своем распоряжении всю необходимую информацию такого рода изначально. Разработчику необходимо только указать, что в обмене участвуют объекты определенного вида. Далее все действия, по регистрации изменений, формированию сообщений, загрузке данных и разрешению коллизий будут выполняться автоматически. Разработчик, конечно, имеет возможность вручную выполнить «тонкую настройку», но она потребуется только в отдельных случаях.

Другая важная особенность механизмов обмена «1С:Предприятия» — их соответствие передовым мировым концепциям интеграции информационных систем. Мы прекрасно понимаем, что сегодня ни один разработчик экономического софта не может считать себя «царем горы», которому нет необходимости заботиться о тесном взаимодействии с системами других вендоров. В данном контексте взаимодействие — не просто умение вызвать какую-то функцию из другой программы или экспортировать в нее какие-либо данные. Речь идет о построении сложных гетерогенных систем, в которых несколько разнородных прикладных решений образуют слаженно действующий ансамбль. Очевидно, что эта тенденция станет в обозримом будущем одной из доминирующих на рынке экономических систем. Механизмы обмена «1С:Предприятия» имеют высокую готовность к работе в гетерогенных системах сегодняшнего и завтрашнего дня не только за счет того, что весь обмен производится на формате XML, но, что еще более важно, в силу идеологического соответствия реализованных решений указанной тенденции. Уже сегодня механизмы обмена «1С:Предприятия» позволяют осуществлять взаимодействие не только с отдельными приложениями, но и с перспективными интеграционными платформами.

Поставка и обновление прикладных решений

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

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

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

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

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

А также…

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

Выполнение алгоритмов бизнес-логики разработчик может по своему усмотрению переносить на сервер «1С:Предприятия». Это позволяет ему управлять распределением нагрузки между клиентом и сервером. При этом от разработчика не требуется специальных навыков построения трехуровневых архитектур, знания сетевых протоколов и т. д. Все технологические детали система берет на себя и обеспечивает рациональное использование серверных ресурсов за счет поддержки stateless-модели, кэширования и разделения системных ресурсов и т. д.

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

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

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

В «1С:Предприятии» поддерживается протоколирование действий пользователей в журнале регистрации. Система имеет несколько уровней протоколирования, которые могут функционировать автоматически, не требуя дополнительных усилий со стороны разработчика. Прежде всего, разумеется, фиксируются начало и окончание сеансов работы пользователей, административные операции с информационной базой, а также регистрируемые ошибки. За счет того, что все изменения в БД выполняются исключительно в объектной технике (через объекты, отвечающие за манипулирование данными), система может автоматически регистрировать их в журнале, причем будет делать это независимо от того, как они выполнялись (интерактивно или программно). Разработчик может также реализовать внесение в журнал любых других записей, которые система не способна фиксировать автоматически, например, информацию об отправке факса или формировании отчета. Важно заметить, что журнал регистрации реализован как отдельный системный механизм. Он не использует для хранения информации базу данных «1С:Предприятия», а, следовательно, его ведение не создает существенной дополнительной нагрузки на систему и не замедляет работу пользователей.

Итак…

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

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

Сформулируем еще раз несколько общих принципов, лежащих в основе модели «1С:Предприятия»:

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

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

Начиная в 1996 г. работы в этом направлении, и даже выпустив первую версию платформы, мы, конечно, не были абсолютно уверены в правильности выбранного пути. За пошедшее с тех пор время концепция системы успешно развивалась, и сегодня она воплощена в платформе «1С:Предприятие 8». Строго говоря, в мире не так уж много специализированных технологий, ориентированных именно на быстрое создание бизнес-приложений. Однако становится все более очевидным, что данный путь лежит на стратегическом направлении развития бизнес-софта.

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

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


Статья опубликована в газете PC Week/Russian Edition (издается по лицензии международного издательского дома Ziff-Davis Media Inc.), NN 46 , 47 и 48 за 2004 г. Перед публикацией на сайте v8.1c.ru в статью был внесен ряд дополнений, по техническим причинам не вошедших в газетный вариант, а также добавлены иллюстрации.

Фирма «1С» благодарит редакцию PC Week/RE за сотрудничество и помощь при подготовке статьи к публикации.


Архитектурные решения, работы по подготовке и разработке архитектурных решений

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

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

В нашей компетенции — грамотная разработка архитектурных решений в рамках комплексного проектирования объектов любой сложности. В ГК IR Proekt вы можете заказать подготовку документации на различные здания, которые планируется построить или реконструировать в Московской области.

Доверьте эту работу нам и получите экономически оправданный проект. Архитектурно-планировочное решение будет отвечать всем требованиям отраслевых стандартов.

Преимущества нашей компании — решать задачи комплексно

Утверждение
архитектурно-градостроительного
облика

Проработка потенциала
земельного участка или
объекта реконструкции

Проектирование всех
стадий, разделов,
любой сложности

Согласования и
утверждение в ИСОГД

Получение разрешения
на строительство

Архитектурное проектирование зданий и сооружений: состав раздела АР

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

Графическая часть архитектурного решения

Графическая часть архитектурного решения содержит:

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

Текстовая часть архитектурного решения

Текстовые части архитектурных решений содержат следующие сведения.

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

Порядок разработки архитектурных решений

Разработка архитектурных решений проходит в три этапа.

1. Разработка эскизного проекта

Создание эскизного проекта предполагает разработку общей концепции объекта (3D-визуализации) без детализации. 3D-визуализация дает представление о:

  • внешнем облике объекта;
  • планах этажей;
  • наглядном представлении фасадов;
  • планировке прилегающей территории;
  • и т. д.

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

2. Разработка архитектурного решения на стадии П

На данном этапе решаются следующие принципиальные задачи.

  • Обеспечение соответствия архитектурных особенностей здания противопожарным, санитарно-гигиеническим и экологическим требованиям.
  • Определение всех технико-экономических показателей.
  • Детальная разработка графической и текстовой частей АР.

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

3. Разработка архитектурного решения на стадии Р

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

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

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

Почему стоит заказать разработку архитектурного решения именно у нас

  • Привлекательная стоимость. Цены на услуги по разработке архитектурных решений при проектировании различных объектов на уровне рыночных, при этом итоговая оплата производится за результат.
  • Внушительный опыт. Мы работаем с 2001 года. За это время мы разработали и реализовали огромное количество проектов.
  • Профессионализм. Разработкой архитектурных решений занимаются высококвалифицированные архитекторы, дизайнеры и специалисты иных профилей.
  • Удобство. Все работы оплачиваются по мере их выполнения.
  • Передовые технологии. Мы досконально разбираемся в текущих тенденциях и предлагаем лучшие современные архитектурные решения.
  • Оперативность. Решаем поставленные задачи в максимально короткие сроки. Находим пути ускорения согласований.

Порядок оказания услуг

Стоимость разработки архитектурных решений в Московской области

Стоимость разработки архитектурного решения в каждом конкретном случае определяется в индивидуальном порядке и зависит от следующих факторов.

  • Место расположения здания.
  • Особенности участка.
  • Тип объекта.
  • Его габариты, площадь и конструктивные особенности.
  • Необходимость проработки нестандартных решений.
  • Особенности проектирования прокладки инженерных систем.
  • Сложность реализации требований заказчика и пр.

Заказать проектирование архитектурных решений в Московской области в ГК IR Proekt вы можете по телефону или на сайте. Наш специалист предоставит консультацию и подготовит коммерческое предложение.

Наши работы

Посмотрите на работы компании IR-Proekt

Заявка на консультацию по архитектурным решениям (АР)

Оставьте свои данные и мы свяжемся с Вами в ближайшее время!

Анализ объема допустимой застройки за 1 рабочий день Гарантия получения разрешения на строительство по договору

Архитектура решения — Портал поддержки типовых решений

Описание архитектуры решения

 

В состав ПТР «АИС ЛОД» входят следующие подсистемы:

1.      Подсистема авторизации и аутентификации пользователей.

2.      Подсистема взаимодействия с пользователями.

3.      Подсистема лицензирования отдельных видов деятельности.

4.      Подсистема интеграции с внешними системами.

5.      Подсистема взаимодействия с внешними системами.

6.      Подсистема отчетности.

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

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

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

Подсистема интеграции с внешними системами предназначена для осуществления интеграции со СМЭВ, ЕСИА и ЕПГУ.

Подсистема взаимодействия с внешними системами предназначена для экспорта данных из ПТР «АИС ЛОД» и дальнейшей передачи этих данных во внешние системы, такие как: модуль Росалкогольрегулирование, ИС «Мониторинг лицензирования».

Подсистема отчетности предназначена для формирования и отображения оперативной отчетности по лицензионной деятельности.

как принимать решения о развитии территорий»

Визуалиация проекта на Бадаевском заводе, Herzog&de Meuron + APEX

Городские конфликты — характерная черта современной России. Часто возмущение вызывают не справедливые раздражители вроде разрушения памятников или мусорных свалок, а заметные и достойные обсуждения современные проекты.

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

21 января, 18:00-19:30 по московсковскому времени

Место проведения: ZOOM с прямой трансляцией в facebook «Проект Россия»

 

Приглашенные спикеры

— Алексей Новиков, президент компании Habidatum

— Евгений Быков, руководитель проектов, заместитель исполнительного директора Проектного бюро АПЕКС

— Ольга Большанина, главный архитектор проектов Herzog&de Meuron

— Александр Кривенцов, архитектор, руководитель бюро «Циркуль»

— Олег Шапиро, архитектор, руководитель бюро Wowhaus

— Мария Макушева, социолог, директор центра социологических исследований «Платформа»

Модераторы

Юлия Шишалова, главный редактор «Проект Россия», и Мария Элькина, архитектурный критик

Архитектор решений: роль и обязанности

Время чтения: 12 минут

Согласно результатам обзора ландшафта управления проектами и портфелем за 2017 год, 49% компаний, опрошенных Planview, видели провал проекта за последние 12 месяцев.

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

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

Что такое архитектор решений?

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

Архитектор решения — это человек, который руководит практикой и представляет общее техническое видение конкретного решения.

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

Каждый из этих терминов включает несколько аспектов, которые мы обсудим в статье. Если вы хотите быстро узнать все подробности, посмотрите наше видео о роли архитектора решений.

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

Корпоративный архитектор vs архитектор решений vs технический архитектор

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

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

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

Архитектура решения в контексте предприятия и техническая архитектура

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

Что такое корпоративный архитектор?

Архитектура

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

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

Что такое архитектор программного обеспечения?

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

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

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

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

Архитектура решения и ее основные процессы

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

Соответствие решений корпоративной среде

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

Удовлетворение требований всех заинтересованных сторон

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

Учет ограничений проекта

Каждый проект имеет свои ограничения, обычно называемые ограничениями. К ним относятся:

  • техника
  • рисков
  • область применения
  • стоимость
  • качество
  • время
  • ресурсов

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

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

Выбор технологического стека проекта

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

Соответствие нефункциональным требованиям

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

Поскольку мы обсудили общие цели внедрения архитектуры решения, давайте разберем их на конкретные обязанности и базовые навыки.

Описание ролей и обязанностей архитектора решения

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

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

Обязанности архитектора решения напрямую вытекают из практических процессов:

  • Анализ технологической среды
  • Анализируем специфику предприятия
  • Анализ и документирование требований
  • Установка рамок сотрудничества
  • Создание прототипа решения
  • Участие в отборе технологий
  • Разработка управляющего решения
  • Сопровождение управления проектами

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

Набор навыков и опыт архитектора решений

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

Техническая подготовка и опыт

Для предоставления руководству и инженерным командам технических рекомендаций архитектор решения должен иметь технический опыт и не менее восьми лет опыта работы в одной или нескольких ИТ-областях, включая, помимо прочего:

  • ИТ-архитектура, инфраструктура и облачная разработка
  • Инжиниринг и проектирование архитектуры программного обеспечения
  • Бизнес-анализ
  • DevOps
  • Управление проектами и продуктами

Отличные коммуникативные навыки

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

Глубокие аналитические способности

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

Навыки управления проектами и ресурсами

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

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

Сертификация архитектора решений

Сертификаты

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

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

Доступно множество сертификатов ИТ-архитекторов, большинство из которых привязаны к конкретному поставщику, т. Е. Ориентированы на освоение определенной технологии. Вот краткий обзор самых популярных.

Сертификат архитектора решения AWS

Программа AWS Certified Solutions Architect предлагает сертификаты на ассоциированном и профессиональном уровнях в зависимости от вашего опыта.Оба они нацелены на архитекторов, которые работают с технологиями AWS для создания и развертывания приложений и систем.

Экзамен сертифицированного архитектора решений AWS — младший экзамен занимает 130 минут и стоит 150 долларов. Amazon рекомендует кандидатам иметь как минимум 1 год практического опыта до прохождения теста. Вот список основных доменов этого экзамена:

Список основных предметных областей и их весовых коэффициентов, источник: Exam Guide

Сертифицированный архитектор решений AWS — профессиональный экзамен для старших архитекторов с опытом работы от 2 лет и младшим дипломом.Это займет 180 минут, а его стоимость — 300 долларов. Вот схема содержания:

Список основных предметных областей и их весовых коэффициентов, источник: Exam Guide

Сертификаты

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

Сертификация архитектора решений Azure

Корпорация Майкрософт имеет ряд сертификатов для архитекторов решений, наиболее известными из которых являются сертификаты Microsoft Certified: Azure Solutions Architect Expert.Этот курс предназначен для кандидатов, которые специализируются на решениях, работающих в Microsoft Azure, и хорошо разбираются в инфраструктуре Azure.

Сертификат Azure Solutions Architect Expert можно получить после сдачи двух экзаменов: AZ-303: Microsoft Azure Architect Technologies и AZ-304: Microsoft Azure Architect Design (ранее AZ-300 и AZ-301). Цена каждого из них зависит от страны, в которой проводится экзамен (165 долларов для США).

Вот обзор навыков, измеренных этими тестами.Вкратце, AZ-303 ориентирован на решение технических задач, таких как:

  • внедрить и контролировать инфраструктуру Azure,
  • внедрить решения для управления и безопасности,
  • реализуют решения для приложений, а
  • внедряет платформы данных и управляет ими.

Содержание AZ-304 оценивает такие навыки как:

  • контроль проектирования,
  • фирменный стиль и безопасность,
  • хранилище проектных данных,
  • проектирует непрерывность бизнеса, а
  • проектная инфраструктура.

Сертификат ITIL

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

В описании указано, что для получения сертификата вы должны быть в состоянии « объяснить и обосновать, как вы лично выбрали и применили ряд знаний, принципов, методов и приемов из ITIL Framework и вспомогательных методов управления для достижения желаемых бизнес-результатов. в одном или нескольких практических заданиях ». Таким образом, для этого экзамена не существует учебного курса или фиксированной программы, поскольку каждый кандидат будет проходить тестирование в рамках своего уникального опыта.

Сертификат ITIL Expert является необходимым условием для получения этих учетных данных.Кандидат также должен иметь более 5 лет опыта работы на руководящих, управленческих или консультативных должностях высокого уровня. Как только эти условия будут выполнены, кандидаты должны будут зарегистрироваться в PeopleCert (утвержденном экзаменационном институте Axelos), заполнить заявку и представить свое резюме. Затем предложение по улучшению бизнеса должно быть представлено вместе с рабочим пакетом, который демонстрирует практические навыки кандидата в применении принципов ITIL в реальных бизнес-кейсах.После этого кандидаты должны будут успешно пройти собеседование с оценочной комиссией, где им будет задан вопрос об их опыте.

Стоимость экзамена и учебных курсов зависит от места проживания.

Сертификат облачного архитектора Google

Google также предлагает ряд ролевых сертификатов. Professional Cloud Architect — это тот, кто использует облачные технологии Google в своих решениях. Согласно исследованию Global Knowledge, второй год подряд это самая высокооплачиваемая ИТ-сертификация.Опять же, это не только для архитекторов решений, но и для любого профессионала, имеющего дело с облачной архитектурой Google.

Экзамен длится 2 часа, регистрационный взнос составляет 200 долларов. Google рекомендует по крайней мере 3 года опыта, прежде чем пытаться пройти тест. Также важно помнить, что он требует повторной сертификации каждые два года. Руководство к экзамену (а также учебные материалы и примеры вопросов) доступно и перечисляет 6 аспектов экзамена:

  1. Проектирование и планирование архитектуры облачного решения;
  2. Управление и предоставление инфраструктуры решения;
  3. Проектирование с учетом требований безопасности и соответствия;
  4. Анализ и оптимизация технических и бизнес-процессов;
  5. Управление внедрением; и
  6. Обеспечение надежности решения и эксплуатации.

Когда компании нужен консалтинг по архитектуре решения

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

Рассмотрим случаи, когда рекомендуется консультация по архитектуре решения:

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

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

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

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

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

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

Заключительные слова

Архитектура решения

является основой любого ИТ-проекта, независимо от того, применяете ли вы эту практику или нет.Сознательно внедряя архитектуру решения, вы создаете структуру, которая объединяет технологии, ресурсы и навыки с определенными бизнес-целями.

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

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

Что такое архитектор решений? Жизненно важная роль для согласования ИТ-бизнеса

Определение архитектора решений

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

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

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

Обязанности архитектора решений

Хотя должностные требования и обязанности зависят от компании или отрасли, это общие ожидания архитектора решений:

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

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

Навыки архитектора решений

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

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

Согласно данным PayScale, популярные технические навыки архитекторов решений включают:

  • SAP Business Warehouse
  • AWS и Azure
  • Apache Kafka
  • ServiceNow
  • Informatica
  • Управление данными
  • Жизненный цикл разработки программного обеспечения
  • Аналитика больших данных
  • Корпоративная служебная шина (ESB)
  • Опыт работы с корпоративной архитектурой
  • Опыт работы с фреймворками ИТ-архитектуры
  • Понимание ИТ-безопасности, инфраструктуры и управления

Заработная плата архитектора решений

Средняя зарплата архитектора решений составляет 119 000 долларов в год, согласно данным PayScale.Заявленная заработная плата варьируется от 75 000 до 160 000 долларов в год, а средний рабочий уровень — около 76 000 долларов в год. Самые высокооплачиваемые архитекторы решений находятся в Сан-Хосе и Сан-Франциско, где средняя заработная плата составляет 144 000 и 132 000 долларов в год соответственно.

Архитекторы решений в начале своей карьеры сообщают о средней зарплате 94 000 долларов в год. По мере увеличения опыта к середине карьеры средняя заявленная зарплата колеблется от 115 000 до 137 000 долларов в год. Средняя заработная плата для начинающих архитекторов решений с опытом работы 20 и более лет составляет 135 000 долларов в год.

Сертификат архитектора решений

Как архитектор решений вы хотите получить сертификат по любым навыкам или технологиям, применимым в вашей отрасли или области. Навыки и знания, которые вам понадобятся, могут варьироваться в зависимости от должности, но вы всегда можете найти сертификаты и курсы для индивидуальных навыков, необходимых для работы, таких как Java, AWS, Azure или Apache Kafka.

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

Авторские права © IDG Communications, Inc., 2021.

Архитектура решения — обзор

Архитектура решения

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

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

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

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

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

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

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

На рисунке 6.4 показана одна из возможных архитектурных моделей решения для приложения FLARP. В этой архитектуре приложение FLARP имеет ссылки на ряд дополнительных приложений для получения или отправки данных.Эти интерфейсы проиллюстрированы на примере запрашивающей системы, использующей «открытую стрелку» в строке, и отвечающей системе, использующей «закрытую стрелку». Например, FLARP запрашивает информацию у службы проверки кредитоспособности, а служба проверки кредитоспособности ответит информацией, необходимой FLARP. Обратите внимание, что на данный момент типы интерфейсов не определены, а отдельные серверы или сетевые компоненты не связаны с корпоративным приложением. Все эти аспекты корпоративного приложения будут определены в процессе разработки приложений и технической архитектуры.

Рисунок 6.4. Архитектура решения FLARP.

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

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

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

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

Что такое архитектор решений? Все, что вам нужно знать

Карьера архитектора решений многогранна. Если вы подумываете о том, чтобы стать архитектором решений, но не знаете, что именно влечет за собой эта работа, вы попали в нужное место.

Вот все, что вам нужно знать о том, чем занимается архитектор решений и как им самому стать.

Что такое архитектор решений?

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

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

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

«Обычно у компаний уже есть операционные системы, информационный контекст и требования к интеграции — Архитектура решения помогает гарантировать, что новая система будет соответствовать существующей корпоративной среде «, — утверждает AltexSoft, Inc., консалтинговая компания по технологиям и решениям. «Для выполнения этой задачи архитектор решения должен понимать, как все части бизнес-модели работают вместе, включая процессы, операционные системы и архитектуры приложений. Понимая эти процессы, они смогут разработать конкретное решение, которое лучше всего подходит для среды».

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

В статье для Equinox It архитектор решения Коста Хахладакис добавил, что «основная часть определения архитектуры решения — это понимание и решение проблем основных заинтересованных сторон». Для него лично он обнаружил, что заинтересованные стороны и их потребности можно грубо охарактеризовать следующим образом:

  1. Повышение производительности или снижение затрат (высшее руководство)
  2. Оптимизация повседневной деятельности (бизнес-пользователи)
  3. Обеспечение безопасности, стабильности и поддерживаемая среда (ИТ-поддержка)

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

Согласно Sokanu, платформа для подбора карьеры, которая помогает людям найти свою идеальную карьеру, поэтому архитекторы решений сосредотачиваются на следующем:

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

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

Эта работа содержит множество нюансов, и вы можете задуматься: Сколько зарабатывает архитектор решений?

Опытный архитектор решений (в который входят сотрудники с опытом работы от 10 до 20 лет), по данным PayScale, может рассчитывать заработать в среднем 131 000 долларов.Среднее значение основано на 1548 зарплатах, что означает, что некоторые архитекторы решений могут зарабатывать больше или меньше.

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

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

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

Однако сертификаты не всегда необходимы.

«Хотя эти опытные ИТ-специалисты, возможно, за годы получили ряд сертификатов, подтверждающих их компетенцию в отношении определенных технологических продуктов, они обычно узнают о таком большом количестве новых продуктов, что получение сертификатов для всех них становится непрактичным», — говорится в сообщении Computer Science Degree. Центр.

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

«Некоторые организации, такие как Программа сертификации ИТ-архитекторов Open Group, не требуют традиционных экзаменов; от кандидатов могут потребовать представить резюме на основе навыков для проверки или участия в индивидуальном или командном проекте», — говорится в исследовании. com. «Частная консалтинговая компания iCMG Enterprise Architecture имеет двухуровневый процесс сертификации, состоящий из курса архитектуры, за которым следует двухчасовой онлайн-экзамен, и второй уровень на основе тематического исследования.В результате получается сертификация «Сертифицированный архитектор программного обеспечения».

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


Не пропустите подобные статьи. Подпишитесь!

Анна-Мари Хулис — феминистка, журналист-фрилансер и страстный поклонник приключений, склонный к импульсивным одиночным путешествиям.Она целыми днями пишет о расширении прав и возможностей женщин со всего мира. Вы можете следить за ее работой в ее блоге HerReport.org и следить за ее путешествиями в Instagram @her_report, Twitter @herreport и Facebook.

Корпоративные архитекторы против архитекторов решений против доменных архитекторов

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

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

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

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

Четыре области архитектуры

Архитектура

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

Бизнес-архитектура описывает организационную структуру предприятия и какие функциональные возможности необходимы для реализации видения бизнеса. Бизнес-архитектура отвечает на вопросы ЧТО и КТО:

  • КАКИЕ бизнес-видение, стратегия и цели организации определяют создание бизнес-услуг или возможностей?
  • ВОЗ предоставляет определенные бизнес-услуги или возможности?

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

  • КАК ранее определялись как реализованные бизнес-услуги или возможности?

Архитектура данных описывает структуру логических и физических активов данных и ресурсов управления данными организации. Знания о ваших клиентах из анализа данных позволяют вам улучшать и постоянно развивать бизнес-процессы.

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

Архитектор предприятия

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

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

  • Анализ текущих тенденций в области технологической архитектуры и предоставление рекомендаций
  • Оценка приложений на соответствие корпоративным и бизнес-стандартам
  • Определение жизнеспособности архитектуры, связанной с организационными изменениями
  • Обучение технологического персонала передовым методам в таких областях, как модели и основы управления

Архитектор решений

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

Роли и обязанности архитектора решений включают:

  • Управление группами разработки приложений на этапах проектирования и строительства
  • Обучение и наставничество младшего персонала
  • Сотрудничество с разработчиками приложений для достижения бизнес-целей
  • Контроль стратегических отношений в технологической среде

Доменные архитекторы

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

  • Бизнес-архитектор
  • Архитектор приложений
  • Информационный архитектор
  • Технический архитектор
  • Архитектор данных
  • Архитектор безопасности

Корпоративные архитекторы против архитекторов решений против доменных архитекторов

  • Enterprise Architect определяет, какая проблема требует решения.
  • Solutions Architect переводит проблему в решение.
  • Доменный архитектор работает в рамках решения для ответственного домена (т. Е. Бизнес-архитектор работает в рамках бизнес-архитектуры вместе с корпоративным архитектором; аналогично, архитектор приложения отвечает за архитектуру приложения, работает вместе с другими архитекторами домена).

Подключение бизнес-архитектуры к архитектуре решения — IasaGlobal

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

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

Артефакты бизнес-архитектуры

  • Возможности модели
  • Стратегическая карта — Балансные карты
  • Холст бизнес-модели
  • Сети зависимостей преимуществ
  • Цепочки создания стоимости
  • Модель бизнес-процесса
  • Организация бизнеса
  • Модели управления стоимостью (средства оценки успеха в захвате стоимости)
  • Деловые и технические модели / документы целевого состояния

Благодаря объединенной организации архитекторов (подробнее об этом), архитекторы находятся в постоянном общении, независимо от структуры отчетности, и, следовательно, опережают планирование и жизненный цикл проекта.Такая модель рассматривает ВСЕХ архитекторов как профессионалов в рамках жизненного цикла стратегии и реализации и требует глубокого понимания входов и выходов бизнеса для решения бизнес-архитектуры. Без глубокой взаимосвязанности входов и выходов архитектуры можно ожидать следующих результатов:

1. Бизнес-архитекторы будут подвергаться риску из-за отсутствия а) вклада в ценность бизнеса из-за низкого уровня точности выполнения трансформации и б) отсутствия понимания технических результатов, связанных с долгосрочным неэффективным управлением целевым состоянием.

2. Архитекторам решений не хватит подкупа и, следовательно, приверженности результатам проекта.

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

4. Архитекторы решений и бизнес-архитекторы будут работать над разными целями и часто считают, что друг у друга не хватает направления, способностей или понимания.Будет значительная группа людей, говорящих что-то вроде: «О, эта группа НЕ НАСТОЯЩИЙ архитектурная команда». Это приводит к проблемам с доверием на протяжении всего жизненного цикла.

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

Кто такой архитектор решений: обязанности, навыки и преимущества для бизнеса

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

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

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

Что такое архитектура решения

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

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

Итак, что именно делает архитектор решений, чтобы сделать это правильно?

Чем занимается архитектор решений?

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

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

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

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

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

Обязанности архитектора решения

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

Итак, ключевые обязанности архитектора решения включают:

  • Оценка архитектурной системы и технологической среды компании
  • Анализируем специфику и процессы компании
  • Рассмотрение, анализ, составление технических требований
  • Настройка платформы для совместной работы
  • Создание прототипа решения
  • Определение технологических средств решения
  • Управление процессом разработки
  • Выявление, управление, снижение возможных рисков
  • Общение с клиентами и командами разработчиков

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

Навыки архитектора решений

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

  • Компьютеры и операционные системы
  • ИТ-инфраструктура
  • Облачная разработка
  • Разработка архитектуры программного обеспечения
  • DevOps
  • Система безопасности
  • Бизнес-анализ
  • Управление проектами и продуктами

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

Когда вашему проекту нужен архитектор решений

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

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

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

Проект предполагает цифровую трансформацию компании . Цифровая трансформация — это перевод бизнеса основных офлайн-операций в онлайн. Такой процесс требует увязки технологий с потребностями и перспективами бизнеса.

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

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

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

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

Как архитектор решений может помочь вашему бизнесу

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

По этой причине влияние архитектора решений на компанию сводится к следующему:

  • Поиск наилучшего решения, подходящего для вашего бизнеса
  • Предотвращение ненужной траты времени, денег и усилий
  • Модерация вопросов, возникших по проекту (технических и межличностных)
  • Обеспечение более беспрепятственного общения между командой и руководителями
  • Построение правильной стратегии развития проекта
  • Успешный запуск продукта

Подводя итоги

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

About Author


alexxlab

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *