Архитектура систем и интеграция программного обеспечения | SYSTEMS ARCHITECTING AND SOFTWARE INTEGRATION

Первая часть материалов семинара опубликована в трех текстах на платформе telegra.ph для канала https://t.me/computersecuritybasics

Часть первая | текст 1| Введение. Процесс создания архитектуры

Часть первая | текст 2 | Основы создания архитектуры систем (1)

Часть первая | 3 | Основы создания архитектуры систем (2). Заключение

Modeling and design management | Моделирование и управление проектированием

The concept of modeling is as old as architecture itself and as modem as virtual reality. Its techniques need no further elaboration here. More important are its nature and purposes as seen in systems architecting.

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

Modeling serves systems architecting as a communication medium among participants, particularly between the the client and architect, but also among engineers, builders, users and the public. It and its close cousin, simulation, help manage the design by maintaining continuity of purpose and intent throughout the build cycle.

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

Like architecting, modeling is an art as well as a science. Like art, it is an abstraction of reality. Like art, it deals with perceptions, representations and visualizations. It adds new perspectives to uncertainty and tensions. It gives form to intuitive judgments about what is important or not, what to include in the model or not, and what is "good enough" for the purpose intended. The resultant system-level models become the principal deliverables of the architect; from them are derived engineering and manufacturing specifications and acceptance criteria.

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

But it must be understood that models are not reality, only abstractions of it. Because models cannot be complete without being identical to the system, itself, initial assumptions and exclusion decisions can be critical. The most dangerous assumptions are the unstated ones. Experienced architects, in any case, quickly learn that reality has ways of adding unexpected relationships, issues, constraints and phenomena to any model. Reality can demolish what look to architects-engineers like logical assumptions, especially if they involve human behavior or social acceptance. On the technical side, the difference between a system's model and its reality can become a major issue in the event of system failure. There is nothing more unnerving to a review board, confronted with seemingly clear indications of a specific system failure, than a firm comment from a model-oriented architect "It can't fail that way!" Which is right, the model or the data? It may be a surprise to some, but the model may be right and the cause of the failure must be sought elsewhere. A notable example was the explosion of a Titan space launch vehicle, erroneously assumed to be a failure of a joint between two solid rocket segments because a "similar" explosion had occurred in a Shuttle launch. (The real cause turned out to be debonding of the propellant from its case.)

Но следует понимать, что модели – это не реальность, а лишь её абстракции. Поскольку модели не могут быть полными, не будучи идентичными самой системе, исходные предположения и решения об исключениях могут иметь решающее значение. Самые опасные предположения – это невысказанные. Опытные архитекторы, в любом случае, быстро понимают, что реальность способна добавлять неожиданные взаимосвязи, проблемы, ограничения и явления в любую модель. Реальность может разрушить то, что архитекторы-инженеры считают логическими предположениями, особенно если они связаны с человеческим поведением или социальным принятием. С технической точки зрения, разница между моделью системы и её реальностью может стать серьёзной проблемой в случае её сбоя. Нет ничего более нервирующего для экспертной комиссии, столкнувшейся с, казалось бы, явными признаками конкретного сбоя системы, чем уверенное замечание архитектора, ориентированного на модель: «Такого сбоя быть не может!» Что верно – модель или наблюдаемые данные? Для некоторых это может оказаться неожиданностью, но модель может быть верной, и причину сбоя следует искать в чём-то другом. Ярким примером стал взрыв ракеты-носителя «Титан» (вероятно, имеется в виду катастрофа МБР Титан-II в 1980 году в штате Арканзас – прим.перев.), ошибочно принятый за разрушение стыка двух твердотопливных сегментов ракеты, поскольку «похожий» взрыв произошёл при запуске шаттла. (настоящей причиной оказалcя пробитый топливный бак из-за падения насадки ключа в шахту при плановом обслуживании)

It is often presumed that modeling ends with the completion of conceptual design. After all, it is often the case, reinforced by competitive procurement regulations, that the original architect leaves, or is assigned to another design effort, and the engineers and builders take over. But modeling continues, nonetheless. During every phase -- engineering, development, manufacturing, testing, operations and final assessment, diverse models are built and used by specialists in their work. Unwatched or unmanaged, these specialized models can negatively impact on the system as a whole, letting it drift from its original purposes in the interest of sub-optimization, often complicating an already complex design. Or, truly beneficial possibilities identified through the model can be discarded locally that might have been welcomed at a broader systems level.

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

The worst situation is having no model at all - no guide, no cross-check, no predictor of performance and no diagnostic tool for system failures. Then, when trouble strikes, appropriate response is almost impossible. One notorious real-life example is the recent lack of a flight simulator during anomalous spacecraft operations. Another was the lack of a model to show the effects of scale on system design. Not all sytems can evolve to larger purposes or be used efficiently for smaller ones. Examples are single-stage-to-orbit launch vehicles and closed-architecture personal computers.

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

Certification and the architect’s role in it | Сертификация и роль архитектора в ней

Certification is the architect’s assurance to the client that the system as built is acceptable and ready for use. Architectural certification, in a sense, is the grade given to the builder after the final exam of systems qualification and acceptance testing. Based in large part on it, the client pays the builder and takes responsibility for its operation.

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

The architect, as the agent of, and co-conceptualist with, the client, should be in a unique position to certify the system. More than anyone else, in as unbiased a way as is possible for a participant, the architect knows the client’s purposes, the systems functions, the design trades, the builder's methods and the decisions made along the way. Achieving this position of trust and respect by all the other stakeholders is not easy. It requires openness, tact, diplomacy, technical credentials, system-level objectivity and an acceptance by others of the architect's assigned role.

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

Clearly,the design of the "final exam" -- that is, the acceptance criteria —is crucial. They must be both complete and passable. The builder will build to pass that exam professionally but not in excess. The owner will be focused on system performance, which is not always the same thing as test results. There are bound to be tensions and disagreements, but they can be greatly reduced by agreement ahead of time on the acceptance criteria. Those criteria, though they may be modified by circumstances and agreement during the build, must be in place at the latest by the time of signing of the contract with the builder.

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

In short, certification does not and can not begin after system test. It must begin as part of system conceptualization and culminate with system acceptance by the client

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

System certification, like other individual parts of architecting, can be undertaken in other ways. One alternate is certification by a third party that performs testing independent of the builder's testing - an equivalent of a Good Housekeeping Seal of Approval for household goods, a Bureau of Standards test of conformance with standards, a Federal Aviation Administration safety certification, or an Operational Test and Evaluation report to the Department of Defense.

Сертификация системы, как и другие отдельные этапы проектирования, может осуществляться другими способами. Одним из вариантов является сертификация третьей стороной, которая проводит испытания независимо от тестирования, проводимого строителем, – аналога знака качества Good Housekeeping для бытовых товаров, теста соответствия стандартам Бюро стандартов, сертификации безопасности Федерального управления гражданской авиации или отчета об эксплуатационных испытаниях и оценке, представляемого Министерству обороны (речь об американских реалиях середины 90х годов – прим.перев.).

One notable difficulty has arisen in third party certifications. It can be traced back to the need for the certification process to begin early. The certifier must agree that the acceptance criteria are complete and passable, which often means engaging the certifier in judgments of system purpose. The certifier also will want either to observe (and comment upon) all the builder's tests or to perform parallel tests using separate test facilities The chances for basic disagreements on the design, build and test approach between certifier and the system team are always present, which can be disconcerting and costly to the client.

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

There can be serious consequences if the certification process is interrupted. Architects are often dismissed once a builder's contract is signed. The project is then turned over to engineers and managers who rethink and modify the concept to ease their own tasks or to rectify perceived defects. Continuity of purpose is easily broken, acceptance becomes a demonstration of "built to print" and conceptual integrity is reduced. The system will have been de facto re-architected without an architect.

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

Self-imposed limitations in scope | Самоограничения в сфере ответственности

Performing the role of the architect as agent of the client as a monitor of the build and as a certifier of the results has, over the years, resulted in the self-imposition of limits on what the architect should do. Generally speaking, the limitations are aimed at reducing perceptions of conflict of interest, maintaining objectivity, respecting chent prerogatives, focusing on the central purposes, and avoiding being overwhelmed by detail. The field may well be unique in not claiming universal applicability and primacy in all phases of engineering and management. In any case, the limitations are pragmatic and practical.

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

The limitations are: (Figure 7)

* Clients, not architects make value judgments (worth, acceptability, etc.). Architects, not clients (preferably) make technical decisions (feasibility, stability, etc.). These limitations insure proper division of responsibility between client and architect. An heuristic is, Don't try to tell the client what his life style should be. Respond with another question if the client asks, "What would you do in my case."

Ограничения следующие: (Рис. 7)

·      Оценочные суждения (ценность, приемлемость и т. д.) выносят клиенты, а не архитекторы. Технические решения (осуществимость, стабильность и т. д.) принимают архитекторы, а не клиенты (предпочтительный подход). Эти ограничения обеспечивают правильное разделение ответственности между клиентом и архитектором. Эвристика: не пытайтесь указывать клиенту, каким должен быть его образ жизни. Если клиент спросит: «Что бы вы сделали на моем месте», ответьте другим вопросом.

*         An architect should not attempt to be an expert on everything, only on those things which are critical to the system as a whole. Leave the specialties to the specialist (but gain and retain his confidence). This limitation is a practical one, overload on the architect, as well as an interpersonal one. The specialist must feel needed and trusted.

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

*         Purpose, not technology, comes first. Otherwise, the result will be a solution looking for a problem. The greatest single risk in schedule and cost overruns, according to an Aerospace Corporation study (circa 1991), is immature technology. The client wants systems functions, not risk-prone technological showpieces. Simplify, simplify, simplify can serve as a criterion for incorporating a new technology; i.e., if incorporating it simplifies the system and its acquisition as a whole, OK. If it complicates the system as a whole to little gain, forget it. Most new technology comes with unexpected encumbrances (supporting developments, new constaints, effects on other parts of the system, etc.). In any case, be sure that the client knows the risks involved and is kept well informed of them.

·      Цель, а не технология, должны быть на первом месте. В противном случае результатом будет решение, нацеленное на решение проблемы. Согласно исследованию Aerospace Corporation (около 1991 г.), наибольший риск, связанный с превышением сроков и бюджета, связан с незрелостью технологий. Заказчику нужны системные функции, а не рискованные технологические шедевры. Принцип «упрощать, упрощать, упрощать» может служить критерием для внедрения новой технологии: если внедрение упрощает систему и её приобретение в целом, то всё в порядке. Если же это усложняет систему в целом без существенного выигрыша, то о нём можно забыть. Большинство новых технологий сопряжено с непредвиденными трудностями (необходимость вспомогательной разработки, вновь выявляемые ограничения, влияние на другие части системы и т. д.). В любом случае, убедитесь, что заказчик знает о связанных с этим рисках и хорошо о них информирован.

*         Unless specifically contracted for, basic architecting does not include project managment (contracting, resource management, progress reports, scheduling, cost control, audits, etc.).10 This limitation is intended to reduce perceptions of conflict of interest, both technical and financial. An architect should not be in the position of deciding on, implementing, or profiting from a recommendation that the architect has made, particularly if it requires the expenditure of significant resources to achieve. As with any specialists, Leave management to the managers. There is also a practical reason for this limitation. Project management generally involves considerable staff. Architecting is best done in small teams (6-12 individuals). The architect can quickly spend more time administratively than in basic systems architecting.

·      Если это не оговорено отдельно, базовая архитектура не должна включать вопросы управления проектом (заключение контрактов, управление ресурсами, отчёты о ходе работ, планирование, контроль затрат, аудит и т. д.). Это ограничение призвано снизить вероятность возникновения конфликта интересов, как технического, так и финансового. Архитектор не должен быть в ситуации, когда ему приходится принимать решения, реализовывать или получать прибыль от своих рекомендаций, особенно если для их реализации требуются значительные ресурсы. Как и в случае с любыми специалистами, оставьте управление менеджерам. Существует также и практическая причина для этого ограничения. Управление проектами, как правило, требует значительного количества сотрудников. Архитектурное проектирование лучше всего осуществлять небольшими командами (6–12 человек). Архитектор может быстро потратить больше времени на административную работу, чем при проектировании базовой системной архитектуры.

Conclusion to Part One, Foundations | Заключение к первой части

Systems architecting is an art and science founded on a handful of core concepts and self-imposed limitations in scope. Its purpose is to bring structure to ill-structured purposes, to match desired functions with feasible forms at least to the point where the powerful analytic techniques of engineering can be employed. It begins with a joint architect-client conceptual design and largely concludes with the architect's certification to the client of conformity with agreed criteria for client acceptance.

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

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

Здесь будет ссылка на вторую часть лекции.