Описание архитектуры ИТ-решения не самая простая практика. И уж точно не следует приступать к её освоению с заполнения шаблона описания архитектуры. Тем не менее, такого рода шаблоны существуют и кто-либо из представителей заказчика информационной системы не редко требует описать архитектуру. Обычно, такого рода запрос поступает от персонажа, именуемого главным архитектором, и потому я возьму на себя смелость дать несколько рекомендаций о том, как это следует делать. Обычно, в качестве шаблона используются производные от RUP-овского Software Architecture Document скачать который можно, например, здесь. Существенно реже можно встретить TOGAF-овский Architecture Definition Document и уж вряд ли вам попадется ISO-шный Architecture description. Поэтому ориентироваться будем на первый шаблон. Разделы такого документа кроме введений и определений включают следующий набор архитектурных представлений:
- Use-case view
- Logical view
- Process view
- Deployment view
- Implementation view
- Data view (optional)
В общем, все в строгом соответствии с моделью архитектуры «4+1 architectural view model» от Philippe Kruchten (Иногда к перечисленным разделам добавляют описания программных интерфейсов. Я же люблю дополнять этот документ разделом «Открытые вопросы и предположения».) Казалось бы, все просто. Берем книжку по UML и начинаем рисовать картинки. Сначала UML диаграмму вариантов использования, потом диаграмму классов и т.д… А вот и ни разу не так!
Замечание 1. Разработка архитектуры решения – это процесс, состоящий, как минимум, из следующих этапов:
- Анализ и структурирование в виде моделей требований и прочей проектной информации. Кстати, для значительного количества моделей, полученных в ходе структурирования проектных данных, раздела в шаблоне не найдется. Это не значит, что их не надо включать в описание архитектуры.
- Выбор варианта реализации.
- Описание варианта реализации.
- Согласование предложенной архитектуры.
Это надо учитывать при планировании и оценке трудоемкости. Кроме того, каждый этап требует различных действий. На первом этапе мы не собираем требования. Сбор требований – задача аналитика и в том или ином виде они должны быть. Мы внимательно их читаем, уточняем, задаем вопросы и структурируем их в виде моделей. Это может быть итеративный процесс внесения структуры в поток требований, но такой поток должен быть. Нет требований – нет архитектуры. Далее. Выбирать и согласовывать вариант реализации лучше до того, как мы плотно займемся его описанием. Меньше придется переписывать. Непосредственно проектирование, т.е. придумывание из головы чего-то нового, занимает незначительную часть времени. Как правило, за нас все уже придумали и потому:
Замечание 2. Традиционный процесс проектирования не подходит для большинства проектов. Обычно в проектах используются уже готовые системы, так называемые COTS (Commercial off the shelf ) или уже существующие ИТ-решения. И потому все перечисленные модели надо основывать на описании уже существующих приложений. Правда, частенько, таких документов не существует и вот их приходится собирать(создавать заново). Тем не менее, вы не можете придумать заново ни свою модель данных, ни компонентную структуру системы, ни варианты использования. Все что вы можете сделать, так это «вписать» требования в существующие решения. Иначе, в худшем случае ваша архитектура нанесет непоправимый вред существующей системе, нарушив её концептуальную целостность, а в лучшем – вашу архитектуру просто выкинут и сделают по-своему. С данными ситуация не самая сложная. Все сущности, которые вы хотите реализовать в системе, должны являть частными случаями уже существующих сущностей. В каком-то смысле это напоминает отношение наследования в диаграмме классов. Но не всегда архитектура используемой системы позволяет реализовать отношения наследования. Чаще работа заключается в том, что вы берете существующую модель данных и придумываете набор типов (стереотипов) для того, что вам нужно на этой модели создать: создаете список типов обращений, придумываете поля заявок и workflow их обработки и т.п. С компонентами – хуже. В принципе, готовая программная платформа должна поставлять вам узлы(nodes, говоря языком UML) для создания и развертывания ваших новых компонент. SQL server(узел) служит для того, чтоб вы создавали собственные компоненты со стереотипами таблица, отношение, хранимая процедура и т.д., BPMS – для моделей процессов, джава-портал — для создания портлетов и т.п. Но когда речь заходит не о программных платформах, а о бизнес-приложениях все становиться загадочным и туманным. Готовое решение, вроде бы есть, но достоверных данных о том, как его следует использовать, что и где на ней нужно создавать и развертывать нет. Это не правильно. Я бы воздержался от использования таких систем.
Замечание 3. На каком уровне детализации остановиться? Безусловно, ответ на этот вопрос зависит от целей разработки описания архитектуры. Обычно, мы делаем описание архитектуры решения для проекта. Для того, чтоб распланировать фазу «реализация», успешно произвести разработку(доработку) ИТ-систем, осуществить их развертывание и ввод в эксплуатацию. Потому и детализация должна быть достаточной для решения этих задач. Каждый квадратик с архитектурных рисунков превращается в строчку проектного плана, а стрелочки показывают взаимозависимость работ. Практически как на UML диаграмме развертывания. Зависимость одного компонента от другого говорит о том, что нет смысла приступать к его разработке не дождавшись хотя бы спецификации программного интерфейса от второго компонента. Вообще, все эти квадратики нужны для того, чтоб можно было выделить набор работ, которые можно будет вести параллельно, не таская всех участников проекта на многочасовые совещания. Наличие архитектуры помогает сохранить доверие между командами или индивидуумами, позволяя им действовать независимо друг от друга. Как правило, в отдельный набор задач можно вынести закупку лицензий и оборудования и разработку ПО. Описание процессов позволяет разделить разработку с подготовкой и согласованием инструкций и регламентов. Внутри разработки одна команда идет писать базу данных, другая бизнес-логику, третья – отчетность четвертая интеграцию с внешними источниками и т.д. Если кто-то настаивает на излишней детальности архитектурного описания и не может ответить на вопрос — зачем это нужно, то данного персонажа следует вежливо послать. Можно использовать и более миролюбивую модель процесса проектирования – каждый создает свой раздел документа, а архитектор сводит все в единое целое. В общем, конечно, замечания довольно поверхностные. Кому-то они могут показаться банальными (но тогда возьмите и допишите в эту заметку свой раздел). Но, если не следовать хотя бы этим рекомендациям, смысла в проектировании ИТ-решений будет не много
Ссылки по теме:
- Роль ИТ-архитектора в организации
- Интеграция новых приложений в корпоративный ИТ-ландшафт
- Software product management (3) Change management
- О вреде проектного управления
Картинка взята с сайта: http://www.uml-diagrams.org/
Очень интересная заметка.
Вообще я последнее время активно сталкиваюсь с ситуацией, когда «архитектурная практика» при внедрении фактически заканчивается на уровне ПО. Когда, например, с точки зрения заказчика создается новая АС, реализующая конкретные функции. А с точки зрения исполнителя всего лишь осуществляется развертывание и доработка кастомизируемого приложения типа 1С. И нефункциональные требования к системе идут лесом, потому что архитектор в проекте — максимум уровня ПО (т.е. «мега-крутой разраб») и он не знает ничего про отказоустойчивость решения, архитектуру инфраструктуры, безопасность и вообще гармонизацию бизнес- и ИТ-процессов.
Не так давно именно в подобном проекте делал описание архитектуры всей системы по Кратчену — через 4 вида. Поскольку система с технической точки зрения достаточно простая, получился относительно простой набор диаграмм — диаграмма классов (Logic View), диаграмма компонентов (Implementation View), диаграмма развертывания (Deployment View) и развернутое описание функций в качестве Process View. На мой взгляд получилось достаточно содержательно.
Максим, спасибо!
Интересная статья! Однако, зачастую, заказчики ориентируются не на UML или TOGAF, а на сложившиеся практики (common practice), основанные на ГОСТ (ГОСТ 34.003-90, ГОСТ 34.602-89, РД 50-680-88 — виды структур ИС: функциональная, техническая, организационная, программная, информационная), старом IEEE 1471 (концептуальная, логическая архитектура и физическая реализация), и привнесенных подходах крупных интеграторов (напр.: Functional, Application, Data, Technical Architecture, Workflow Library). В этом случае сложно говорить о каких-то стандартных шаблонах архитектуры решения, кроме «общих практик» и картинок Visio. Как было правильно замечено, описание архитектуры решения это – результат целого процесса. И с точки зрения понимания этого процесса и подготовки документов для Заказчика, могут оказаться действительно полезны и шаблоны UML, и шаблоны TOGAF (их лучше взять из https://www2.opengroup.org/ogsys/catalog/I092 и https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=i093), и стартер-пак ISO/IEC/IEEE 42010.
Спасибо за ссылки. А с ГОСТами это, действительно, отдельная история
There is a problem in the first paragraph – «Обычно, такого рода запрос поступает от персонажа, именуемого главным архитектором». Usually, a chief architect has NO this responsibility. A solution architect must provide the solution architecture document because of the standing IT governance.
The complexity of the solution architecture document is very enterprise-maturity-dependent. Usually, I use the following list as the starting point and then trim it for a particular client. Chapters 2-10 have AS-IS, TO-BE and Delta clauses.
1 Objectif du dossier Architecture
2 Interopérabilité des Systèmes d’Information
3 Architecture Métier
4 Architecture de données métiers
5 Architecture de services métiers et de flux d’activités
6 Architecture fonctionnelle
7 Architecture conceptuelle (vue 6)
8 Architecture technique (vue 7)
9 Sécurité
10 Architecture technique de données et échange
11 Check-list standard CTI pour toute qualification
12 Nomenclature de composantes architecture
13 Service et Support
14 Recommandations / notes
In addition, the EA group provides many guidance materials how to design solutions and enterprise conventions for various artefacts (e.g. modelling procedure). An EA repository contains existing dependencies and recommended components.
Ideally, the EA group makes available a configurator which selects one of the several standardised solution architectures (in-house dev, platform-based, COTS, external development, etc.). Of course, Solution architect and PM have to fill a very detailed form but easy-to-understand.
If the solution architecture done correctly then the project becomes a set of easy-to-deliver-in-agile-way mini-projects.
At the end of the project, the EA repository must be updated.
Thanks,
AS