Для успешного решения проблемы нужно её правильно сформулировать.
Я в качестве формулировки проблемы предпочитаю формулировать цель, которую нужно достичь. Это очень эффективный подход.
Во-первых, невозможно достичь результата, не понимая цели. И я категорически против каких-либо бесцельных телодвижений.
Во-вторых, сформулированная цель позволяет оценить возможность её достижения, выстроить концептуальное решение и создать план работ.
В-третьих, как бы вы не формулировали проблему, вам всё равно нужно будет поставить цель для её решения - так зачем же делать двойную работу.
Важно понимать, что формулирование проблемы и идентификация её причины - разные вещи и разные активности. Я часто вижу, что вместо формулировки проблемы люди занимаются диагностикой.
Не имея чёткой формулировки проблемы - её не решить. Нечёткая формулировка приведёт к ошибкам планирования, нарушениям качества, сроков и/или бюджета. Скорее всего, не имея чёткой формулировки, вы будете решать совсем не ту проблему, которая реально имеет место. Но если проблема сформулирована правильно, то у нас есть понятный ожидаемый результат, на основе которого мы можем планировать следующий шаг, при этом минимизируя риски.
Допустим, что потребителю важно иметь в интерфейсе некоторую витрину своего бизнеса. "Ну что тут сложного?", - думает руководитель проекта, - ведь всего-то сделать табличку-другую данных и вывести нужный разрез в пользовательский, - давайте сделаем витрину сразу, а остальную деятельность автоматизируем потом. Нет. Данные витрины ещё отсутствуют: они ведь зависят от автоматизации всей деятельности потребителя, а автоматизация ещё не готова. Таблички и интерфейс создаются быстро, но потом начинается головная боль с миграцией исторических данных: они не маппятся друг с другом, разъезжаются, выявляется масса ошибок. Да ещё и бизнес потребителя на месте не стоит, всё время меняется. То, что планировалось максимум на месяц, растягивается на полгода, съедая ресурсы, время и бюджет...
А причина простая: надо было отчётность делать, понимая всё закулисье бизнеса потребителя. Разбив деятельность на отдельные процессы и их этапы, можно было разобраться с данными, их взаимосвязями и особенностями формирования. И уже в конце собрать все результаты в отчётность.
Решая же проблемы "с хвоста", мы увидим, что за хвостом тянутся лапы, уши и острые зубы неведомого зверя, который ещё и всё время выворачивается. Проблема из маленькой и пушистой превратилась в большую и болезненную.
Со временем, по причинам постепенных «рывков» развития сферы информационных технологий, последующего масштабирования на все области деятельности человечества, архитектура системы и её программного обеспечения стала целиком и полностью предметом работы разработчиков программного обеспечения и в большинстве случаев, незримо подразумевалась как часть процессов жизненного цикла разработки информационных систем. Это было связано с тем, что ресурсов на создание информационных систем стало выделяться меньше, различные этапы «сращивались», а результатов от разработки, внедрения и применения стали ждать как можно раньше.
Вот ещё несколько примеров:
Есть задача спроектировать новую систему. Начальник дал задачу делать. Сформулировал требования в двух абзацах. "Чего тут не понятного?.". Но кто будет использовать эту систему, не ясно, потребностей нет, требуемых целевых показателей нет - и далее по списку. Почему-то я уверен, что систему сделают быстро, но потом будут доооолго доводить до удовлетворительного состояния, чтоб заказчик принял. Но прорывной система никогда не станет.
Надо посчитать КТС для её не готовой системы. Бывает. Надо же закупки планировать. Но опять же нет понимания, как система будет использоваться. Невозможно оценить нагрузки. В итоге, закупаем одно оборудование, потом оно окажется непригодным, покупаем другое оборудование, так? Ну да, есть облака. Но неверная оценка ресурсов может привести к тому, что договор будет заключен с провайдером, который конечную нагрузку не обеспечит. И что потом?
Ну, я знаю, что у вас agile, и что вы за короткие сроки поставки, и вообще тут прыжки веры, а я тут мешаюсь... Но, коллеги, agile не от слова "ад". И сделать систему на основе реальных потребностей, а не своих догадок, можно быстрее и качественнее, и денег на этом заработать тоже можно в разы больше. И потом заказчик и сам подкинет вам пару-тройку новых проектов, и другим вас порекомендует. Но почему мы ходим по тем же граблям десятилетиями?
С учетом постепенно возрастающего количества запросов к качеству информационных продуктов, складывающегося из множества различных компонентов, так долго продолжаться не может. Ибо инвестиции в бардак - увеличивают бардак.
Немного о себе
Сосредотачиваюсь на проектировании общей архитектуры информационной системы, включая взаимодействие между ее компонентами, интеграцию с другими системами и обеспечение общей эффективности;
Специализируюсь на проектировании и разработке приложений, включая выбор технологий, архитектурных шаблонов и определении структуры приложений и данных.
Ориентирован на выстраивание информационных систем с учетом бизнес-процессов и стратегии предприятия. Осуществляю взаимодействие между технологиями и бизнес-потребностями.
Занимаюсь проектированием структур и организации данных в информационной системе, включая базы данных, хранилища данных и методы их обработки.
Проектирую интеграции различных систем и приложений, обеспечивая их совместную работу и обмен данными.
Забочусь о построении безопасных информационных систем, включая аспекты защиты и управления доступом.
Занимаюсь проектированием систем, использующих облачные технологии, включая выбор облачных провайдеров, архитектурные модели и обеспечение безопасности в облаке.
Специализируюсь на построении систем, использующих архитектурный стиль микросервисов для создания расширяемых, гибких и легко поддерживаемых приложений.
Если коротко:
Прорабатываю архитектуру от общего к частному.
Ищу шаблоны, которые эффективны и понятны.
Выстраиваю шаблон до тех пор, пока он не будет ощущаться правильным.
Передаю шаблон ИИ для генерации сервисов — множества сервисов. ИИ отлично справляется с тиражированием показанного шаблона.
Это «правильный» путь? Нет. Это мой путь.
Лучший процесс - это тот, который соответствует вашему образу мышления. Моему сначала нужна структура.
Преподаю дисциплины системная и программная инженерия, архитектура предприятия, архитектура информационных систем, проектирование информационных систем в Российской академии народного хозяйства и государственной службы при Президенте Российской Федерации (РАНХиГС) и Государственном университете управления (ГУУ) для специальностей: 38.03.05 и 09.03.03.
Я следую рекомендациям, подходам и практикам, изложенным в:
Руководство Microsoft по проектированию архитектуры приложений
Приёмы объектно-ориентированного проектирования. Паттерны проектирования. (GoF)
Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем. (E. Evans)
Шаблоны интеграции корпоративных приложений (G. Hohpe, B. Wolf)
Путь аналитика. Практическое руководство IT-специалиста (А. Перева, В. Иванова)
Путь IT-менеджера. Управление проектной средой и IT-проектами (А. Перева, В. Иванова)
Разработка требований к программному обеспечению (Д. Битти; К. Вигерс)
и многое другое.