Дефрагментация мозга. Софтостроение изнутри

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

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

Совмещение

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

Рис. 8.

Уровни АИС в разрезе концептуальных слоёв

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

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

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

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

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

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

В такой ситуации нет ничего необычного, потому что практика управления «по кейсам» [95] , то есть прецедентам, является широко распространённой в среде менеджеров среднего звена. Критичность основной массы проектов в ИТ снижается, соответственно, большая часть решений переходит из технической плоскости в управленческую. Эта тенденция будет только усиливаться.

Любопытно, что в русском языке слово «менеджер» имеет весьма точный, но основательно подзабытый в эпоху советской России перевод «приказчик». Магическая сила слов! Получил бы популярность клон игры «Монополия», если бы его в конце 1980-х годов назвали «Приказчик»? Теперь сравните пару «менеджер проекта» и «тестировщик» против другой: «приказчик» и «инженер-испытатель»…