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

Разрабатываемый комплекс состоит из инструментария, платформы разработки, типовой архитектуры модулей проектируемых систем, а также комплекта программных компонентов для поддержки командной разработки и автоматизации процессов сборки CD и развертывания CI (состав модулей р. 6 "Обзор составных частей программного комплекса").

Рынок информационных систем и средств их разработки и поддержки является достаточно широким как по сфере применения, так и по составу.
Для упрощения анализа продукты ИТ можно разделить по способу использования:
1. StandAlong клиентские приложения – приложения, полностью выполняющиеся на устройстве конечного пользователя (ПК, мобильные устройства).
2. Клиент-сервер приложения – клиентские приложения, выполняющиеся на устройстве конечного пользователя и ведущие обмен данных с удаленным сервером для хранения/обмена данных.
3. WEB- приложения- частный случай клиент-сервер приложения, когда клиентское приложения представляется сервером, но выполняется на устройстве конечного пользователя в WEB браузере.

В данной классификации наименее требовательным являются клиентские приложения, как правило их разработка ведется с помощью инструментария предоставляемого поставщиком целевой операционной системы.
При использовании Клиент-сервер и WEB решений автоматически появляются требования к дополнительной проработке следующих вопросов:
1. Аутентификация.
2. Авторизация.
3. Аудит.
4. Журналирование.
5. Совместное использование ресурсов.
6. Масштабируемость.
7. Простота обслуживания и обновления.
8. Протоколы взаимодействия с клиентским ПО.
9. Версионность и совместимость протоколов взаимодействия с клиентским ПО.

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

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

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

В виду отсутствия стандартных решений, следует классифицирровать источник требований к выбору технологий и программно-аппаратным ресурсам систем данного типа:
1. Требований нет, можно использовать все доступные решения.
2. Требования архитектуры сформулированные в ходе процесса разработки архитектурного проекта.
3. Исторически принятая в организации-разработчике системы типовая архитектура.
4. Требования архитектуры организации заказчика.

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

Указанные особенности приводят к следующим сложностям:
1. Осуществление выбора среди аналогов продуктов с учетом цены, особенностей применения, лицензирования и других аспектов (например СУБД Postresql, Oracle, MSSQL, MySQL и т.д.).
2. Появляется этап «Архитектурный проект», который является предварительным к разработке в целом.
3. Кадровые проблемы:
a. Вводится дополнительная позиция «Архитектор»;
b. Предъявляются дополнительные требования к разработчикам, т.к. им требуется время изучить технологии, заложенные архитектурой, что приводит к дополнительным временных затратам и дефектам в будущем (в виду отсутствия опыта их использования);
c. Требуется рекрутинг сотрудников с наличием всех компетенций, описанных архитектурой, что предоставляет дополнительные требования к уровню оплаты труда и временным затратам на подбор.
4. В случае внесения изменений в архитектуру, либо замены поставщика одного из используемых решений, требуется глобальный рефакторинг кода, повторное тестирование и стабилизация. Что приводит к временным и финансовым затратам, и вероятно приведет к изменению кадрового состава.

Крайне важно рассматривать уровень требований и возможности непосредственного заказчика. Это может быть:
1. Собственная разработка.
2. Частный заказчик.
3. Малый бизнес.
4. Крупный или корпоративный бизнес.

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

К нефункциональным требованиям процесса разработки следует отнести следующие:
1. Совместная разработка.
2. Трекинг задач.
3. Процесс непрерывной разработки.
4. Процесс непрерывной поставки.
5. Обслуживание тестовой/рабочей среды.
6. Мониторинг обслуживаемых сред и т.д.

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

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

Упрощая анализ дифференцируем продукты ИТ по способу использования:
1. StandAlong клиентские приложения – приложения, полностью выполняющиеся на устройстве конечного пользователя (ПК, мобильные устройства).
2. Клиент-сервер приложения – клиентские приложения, выполняющиеся на устройстве конечного пользователя и ведущие обмен данных с удаленным сервером для хранения/обмена данных.
3. WEB-приложения – частный случай клиент-сервер приложения, когда клиентское приложения представляется сервером, но выполняется на устройстве конечного пользователя в WEB браузере.

Учитывая предпосылки, описанные в р.3 "Предпосылки к разработке" целью данной разработки является разработка программного комплекса (р. 2 "Состав комплекса"), реализующиего следующие принципы:
- охват всех аспектов производственного процесса приложений корпоративного уровня;
- реализация шаблонной архитектуры унифицированной системы;
- реализация шаблонного масштабируемогой модуля системы;
- реализация промежуточного слоя, предназначенного для решения типовых задач и паттернов проектирования;
- разработка обобщенного API для инкапсуляции различий между различными реализациями аналогов решений;
- разработка реализации обобщенного API для принятых в настоящее время стандартов de-facto;
- разработка инструментария общего назначения.

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

Prota Platform & Tortuga Project является идеальным решением для прототипирования и разработки, параллельной с этапом «Архитектурного проекта», за счет инкапсуляции вендорных решений

Программный комплекс состоит из следующих частей:

1. Платформа «Prota» (Pro2all, Professional solutions to all; аналоги неизвестны)

Инструментарий общего назначения:
- Библиотеки утилит;
- Конструктор запросов БД;
- Менеджер сущностей БД;
- Машина состояний.

API платформы и реализации паттернов разработки:
- Сервис межмодульного синхронный обмена;
- Сервис межмодульного асинхронного обмена;
- Сервис распределенных задач;
- Сервис обратного вызова;
- Сервис справочных данных;
- Сервис аудита;
- Сервис мониторинга;
- Сервис кэширования;
- Сервис журналирования;
- Сервис конфигурирования;
- Сервис распределения прав доступа;
- Сервис healthcheck;
- Сервис авторигистрации;
- Планировщик- распределенных задач;
- Сервис HTTP;
- Поток страниц- паттерн wizard`ов.

Реализация API (типовой набор):
- Платформа - Spring Boot;
- HTTP/RPC - Jersey;
- JSON- Jackson;
- IPC синхронный- Jersey+Jackson;
- IPC асинхронный- Kafka;
- БД- PostgreSQL.

Шаблонный модуль приложения;

2. Модуль «Stubman» - эмулятор API внешних систем, менеджер тестовых данных (аналоги неизвестны);

3. Модуль «Configstore» - централизованный репозиторий конфигурации (аналоги неизвестны);

4. Модуль «ServiceDiscovery»- сервис контроля динамического окружения (аналоги неизвестны);

5. Модуль «Visor» - прокси сервер, обеспечивающий доступ к сервисам внутренней сети из сети Internet без публичного IP (аналоги неизвестны).

6. Комплекс ПО, входящих в проект «Tortuga Project»:
- Модуль «Holoman» - менеджер задач/сборки исходного кода CD (аналог Jankins, Hudson, TeamCity);
- Модуль «Puppetmaster» - менеджер развертывания сборок CI (аналог Kubernates);
- Модуль «Greppo»- репозиторий исходного кода Git (аналог BitBucket, GitHub);
- Модуль «Holdcell»- репозиторий сборок (аналог Nexus);
- Модуль «Messhut»- трекер задач (аналог Jira).

Все модули комплекса реализованы на платформе Prota, что гарантирует из совместимость, платформонезависимость и возможность интеграции на уровне API.

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