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

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

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

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

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

The foundations of systems architecting | Основы создания архитектуры систем

Systems architecting is based on a small number of synergistic core concepts. Roughly in their order of appearance, they are: a systems approach, a purpose orientation, cofied experience, ultraquality, modeling, and certification. Omitting any of them sharply undercuts the total. By general consensus - and for good reasons - judgments of worth, detailed subsystem expertise, technology development and project management are usually placed outside its scope.1 Each of these concepts will be discussed briefly

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

A systems approach | Системный подход

One of the simplest and most useful definitions of a system is that it is a collection of different elements which together produce results unachievable by the elements alone.2 The key words here are collection, different, together and unachievable. The results, system-level functions, are achievable only by the system as a whole; for example transportation is the system-level function of an automobile and life is that of the human body.

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

The primary purpose of systems is to produce these functions; that is, to add value to that of the elements, themselves, by making connections between them. Hence, the principal focus of the systems approach, and the principal design leverage of its practitioners, is at the interfaces. One conservative strategy of architecting, posited in 1964 by a classical architect, is that the best architectures are those with the fewest interface mis-fits.

Основная цель систем – выполнять эти функции, то есть повышать ценность самих элементов, создавая связи между ними. Следовательно, основное внимание системного подхода и основной рычаг воздействия его специалистов сосредоточены на интерфейсах. Одна из консервативных стратегий архитектурного проектирования, сформулированная в 1964 году классическим архитектором (Alexander, Christopher. Notes on the Synthesis of Form Harvard University Press, 1964), заключается в том, что наилучшая архитектура — это архитектура с минимальным количеством несоответствий интерфейсов (mis-fits, компонентов, которые недостаточно хорошо подходят для интеграции в систему – прим.перев.).

But herein lies a dilemma. Generally speaking, the more system functions that are desired, the more elements (and still more interrelationships) are needed. But the more there are, the greater the risk of instability4 if not chaos. This phenomenon is all too often encountered in evolving computer communication networks, electric power grids, nonlinear feedback control systems - and software. Even though the individual elements or modules may be stable, the system may not Once again, the system behaves differently than the sum of the individual behaviors of the elements.

Но здесь кроется дилемма. Как правило, чем больше системных функций требуется, тем больше элементов (и тем больше взаимосвязей) требуется. Но чем их больше, тем выше риск возникновения нестабильности (Klir, G.J. Architecture of Problem Solving Plenum, 21-22, 1985), если не хаоса. Это явление слишком часто встречается в развивающихся компьютерных сетях связи, электросетях, нелинейных системах управления с обратной связью и программном обеспечении. Даже если отдельные элементы или модули могут быть стабильны, система может быть нестабильной. Опять же, система ведет себя иначе, чем сумма индивидуальных поведений элементов.

For these reasons, systems to be successful must be viewed as a whole, the specialty of system architects, analysts and engineers. As to be expected, these practitioners are experts in system functions and interfaces and how they fit together. In any case, for them to try to be expert in all the facets of all the elements is impractical and counterproductive.

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

But architects would be remiss in their responsibilities for the system as a whole if they knew little or nothing of the "insides" of the elements. On that count, they are justifiably wary of software hidden routines, commercial off the shelf (COTS) items and reused software. Obviously,the depth of understanding must be selective. An appropriate criterion is how critical the individual subsystem, discipline, or detail is to the system as a whole. (Figure 4)

Но архитекторы не справлялись бы со своей ответственностью за систему в целом, если бы знали мало или совсем ничего о «внутренностях» её элементов. В связи с этим они обоснованно опасаются скрытых программных процедур, готовых коммерческих решений (COTS) и повторно используемого программного обеспечения. Очевидно, что глубина понимания должна быть избирательной. Соответствующим критерием является критичность отдельной подсистемы, дисциплины или детали для системы в целом. (Рисунок 4)

Predictably, as systems become smarter and smarter, systems architects and engineers will have be expert in critical software techniques, languages, routines and architectures. If so, we shouldn’t be surprised if before long the best systems architect-engineers come from the software field instead of electronics and control systems which have supplied them to date.

Как и ожидалось, по мере того как системы становятся всё более интеллектуальными, системным архитекторам и инженерам придётся быть экспертами в критически важных программных методологиях, языках, процедурах и архитектурах. Если это так, то неудивительно, если вскоре лучшие системные архитекторы и инженеры начнут работать в сфере программного обеспечения, а не в сфере электроники и систем управления, где они работали до сих пор (статья примерно конца 80х гг.).

Purpose orientation | Ориентация на целевое назначение

Next in importance as a core concept is that architecting is inherently purpose-driven. That is, the client's purposes come first. A first objective of client and architect is to discover and then maintain those purposes throughout system conception and build. They will, or should, drive system design, analysis and implementation. Experience demonstrates that the client's initial statement of purpose -- that is, the needed system functions - may well be internally contradictory, mixed up with preconceived "solutions," based on erroneous assumptions, and poorly derived from more fundamental purposes. The client seldom can rank-order requirements, even if each is eminently reasonable, without some idea of what the system might be like. There is nothing more dismaying than excellent engineering, construction, and management that has been wasted on a system without a valid purpose. Whatever time and however many iterations it takes to establish the purpose, it is worth it. As Bob Spinrad of Xerox put it in 1988 in the context of software, "All the serious mistakes are made in the first day! Worse yet, you may have to live with them for decades."

Следующим по важности ключевым понятием является то, что архитектура изначально ориентирована на цель. То есть, цели клиента всегда на первом месте. Первостепенная задача клиента и архитектора — выявить эти цели и поддерживать их на протяжении всего процесса разработки и построения системы. Они будут или должны определять проектирование, анализ и реализацию системы. Опыт показывает, что первоначальное заявление клиента о цели, то есть необходимые системные функции, может быть внутренне противоречивым, смешанным с предвзятыми «решениями», основанным на ошибочных предположениях и плохо выведенным из более фундаментальных целей. Клиент редко может ранжировать требования, даже если каждое из них в высшей степени разумно, не имея представления о том, какой может быть система. Нет ничего более удручающе, чем превосходные инженерные, строительные и управленческие решения, потраченные впустую на систему без обоснованной цели. Сколько бы времени и сколько бы итераций ни потребовалось для определения цели, оно того стоит. Как сказал Боб Спинрад из Xerox в 1988 году в контексте программного обеспечения: «Все серьёзные ошибки совершаются в первый день! Хуже того, вам, возможно, придётся жить с ними десятилетиями».

The first step in architecting is therefore establishing, jointly with the client, a good match of acceptable system functions with a feasible system form (a systems architecture). As a classical architect might put it, architecting is making "form fit function." The process is unavoidably top-down and, of course, purpose-driven. Its tools will be discussed shortly. But first, to better understand systems architecting, a contrasting way of building complex systems - client-less.

Таким образом, первым шагом в архитектурном проектировании является совместное с заказчиком установление соответствия приемлемых системных функций и осуществимой системной форме (системной архитектуре). Как сказал бы классический архитектор, архитектурное проектирование — это «соответствие формы и функции». Этот процесс неизбежно идёт сверху вниз и, конечно же, ориентирован на цель. Его инструменты будут рассмотрены ниже. Но сначала, чтобы лучше понять системное проектирование – это альтернативный способ построения сложных систем, не требующий участия заказчика.

From the foregoing rationale, for architecting to work properly, there must be a real client/sponsor willing and able to make value judgments of what is acceptable and satisfactory, to decide what is "good" or "bad." (The client, more than anyone else, knows that there can never be an "optimum.'’) But very successful complex systems have been and are built without such a client.

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

Consumer products (PCs, TVs, automobiles), are built with, at best, a surrogate client (marketing and sales). During the Cold War, some defense systems were built "bottom up" driven by the assumed combat value of new technologies (hypersonic flight, stealth, fly-by-wire) against high-tech opposition. The closest thing to a client was an uneasy combination of the Secretary of Defense, the Unified and Specified Commands, The President and the Congress. By default, the technologists made most of the decisions. For lack of a better term, this client-less approach might be called "technical innovation," because technology is the driver.

Потребительские товары (ПК, телевизоры, автомобили) производятся, в лучшем случае, с привлечением суррогатного клиента (маркетинга и продаж). Во времена холодной войны некоторые системы обороны разрабатывались «снизу вверх», исходя из предполагаемой боевой ценности новых технологий (гиперзвуковой полёт, малозаметность, система дистанционного управления) в условиях высокотехнологичного сопротивления. Наиболее близким к «клиенту» было непростое сочетание министра обороны, Объединённого и Особых командований, президента и Конгресса. По умолчанию большинство решений принимали технологи. За неимением лучшего термина, такой подход без привязки к клиенту можно было бы назвать «техническими инновациями», поскольку движущей силой являются технологии.

In some sense, the two approaches are time reversed. (Figure 5) One combined approach is to use them in series, architecting first to establish guidelines followed by incremental, technology-driven upgrades. MS-DOS, copying machines, television sets and launch vehicles are typical examples.

But, when all is said and done, unless a system has a valid, valued purpose, it will not last. Architecting begins with that truth by putting purpose first

В каком-то смысле эти два подхода меняются местами. (Рис. 5) Один из комбинированных подходов заключается в их последовательном использовании: сначала разрабатывается архитектура для установления основных принципов, а затем постепенные технологические усовершенствования. Типичными примерами являются MS-DOS, копировальные аппараты, телевизоры и ракеты-носители.

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

Codified experience | Систематизированный опыт

Even more than engineering, architecting is based on practical experience. Large scale, complex systems pose special problems. Space systems, communication networks, weapons, computers and other complex systems take years, even decades, to design, build, deploy and operate. Product-line architectures may last just as long, even if their technologies change. There are very few systems architects who have had an opportunity to work on more than one or two major programs. The lessons learned in the first program may be unique to the first program or now obsolete, technically, socially or politically.

Архитектура, даже в большей степени, чем инженерия, основана на практическом опыте. Крупномасштабные, сложные системы создают особые проблемы. Проектирование, создание, развёртывание и эксплуатация космических систем, сетей связи, оружия, компьютеров и других сложных систем занимают годы, а то и десятилетия. Архитектура продуктовых линеек может существовать столь же долго, даже если технологии в них меняются. Очень немногие системные архитекторы имели возможность работать более чем над одной-двумя крупными программами (программными продуктами или системами – прим.перев.). Уроки, полученные в первой программе, могут быть уникальными для неё или устаревшими с технической, социальной или политической точки зрения.

The problem is actual today because a whole generation of architect-engineers with 25 to 50 years’ experience in major complex systems are leaving the work force. At the same time, a wide array of new systems needs to be architected — and by software-literate people young enough to commit 20-25 years to their accomplishment

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

It is not a new problem. It has been around as long as the pyramids and been tackled by builders of cathedrals, warships, electric power distribution and telephone systems. Their solution, still valid, is to codify, or formalize, practical experience so that it can be transferred between programs and generations of architects. Most of the formalisms are quantative; that is, expressible in numbers. In the building trades this codification results in building codes. In defense system acquisition it generates military specifications, a primary mechanism for retaining corporate memory. In engineering, it results in algorithms, tradeoff charts, equations and handbooks.

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

Less well known but possibly broader in its application across the disciplines of engineering, business and social disciplines, are insightful "lessons learned," or heuristics. Because they are less well known, this paper will concentrate on them. The ones shown here are in italics.

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

Heuristics are an attempt to codify experience by condensing, in a few words, enough common experience to offer a useful guidelines for system building. The word "heuristic" is traceable to a Greek word meaning to find or to guide. "Heuristics" is also used in computer science to describe certain problem solving techniques. It is one of four architecting techniques — the normative, rational, participative and heuristic — and most distinguishes it from systems engineering. It is the most inductive, a-rational and experiental of the set. A few examples: (Figure 6)

Эвристика – это попытка систематизировать опыт, сжимая в нескольких словах достаточное количество общего опыта, чтобы предложить полезные рекомендации для построения систем. Слово «эвристика» происходит от греческого слова, означающего «находить» или «направлять». «Эвристика» также используется в информатике для описания некоторых методов решения задач. Он является одним из четырёх методов проектирования: нормативного, рационального, партисипативного (кооперационного, то есть преимущественно заключающегося в кооперации или сотрудничестве заинтересованных сторон – прим.перев.) и как раз эвристического, и он наиболее отличен от классической системной инженерии (см. Lang, Jon Creating Architectural Theory Van Nostrand Reinhold, 1987; Rowe, P. G. Design Theory The МГГ Press Cambridge, MA 1987; Rechtin, E. A Collection of the Best Student Papers on Systems Architecting ,1988-1993 University of Southern California, 1994). Эвристика – наиболее индуктивный, нерациональный и эмпирический из всех методов. Вот несколько примеров: (рис. 6)

*         Two descriptive heuristics, Murphy's Law: If it can fail it will and a conflicting one, If it ain't broke, don't fix it provide a telling contrast between the automotive industry strategies of Japan and other countries in the 1980's. The first heuristic, calls for zero defects, the second reinforces the status quo on any organization wary of change.

·      Два описательных эвристических принципа, закон Мёрфи: «Если что-то может сломаться, оно сломается», и противоположный ему: «Если не сломалось, не чини», — наглядно демонстрируют контраст между стратегиями автомобильной промышленности Японии и других стран в 1980-х годах. Первый эвристический принцип призывает к отсутствию дефектов, второй закрепляет статус-кво в любой организации, опасающейся перемен.

*         Simplify, simplify, simplify is one of the best prescriptive-heuristics for dealing with Murphy's Law.

·      «Упрощай, упрощай, упрощай» — один из лучших предписывающих эвристик для работы с законом Мёрфи.

*         All the serious mistakes are made in the first day, mentioned earlier, also has associated prescriptive heuristics. Two of them are: Don't assume the original statement of the problem is the right one and Build in and maintain options as long as possible. You will need them.

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

*         Some heuristics provide still more direct guidance, such as In partitioning, choose the elements so that they are as independent as possible, that is, elements with low external complexity and high internal complexity also expressible as In partitioning a system into subsystems, choose a configuration with minimal, but effective, communications between the subsystems.

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

The first of these heuristics came from the aerospace industry, the second from the automotive industry. Simplify came from commercial aircraft, Serious mistakes from copier products, and Partitioning from aerospace and its software sector. Yet they are evidently broadly applicable as shown by their intuitive acceptance by practitioners in other fields. 8 Their acceptance almost invariably is pragmatic - they seem to work. No mathematical or statistical proof seems necessary and in any case, none exists. Applicability is by example, case by case, context by context. As such, heuristics, like any technique, have their characteristic limits.9

Первая из этих эвристик пришла из аэрокосмической промышленности, вторая – из автомобильной. «Упрощение» (Simplify) – из коммерческой авиации, «Серьёзные ошибки» (Serious faults) – из копировальной техники, а «Разбиение» (Partitioning) – из аэрокосмической отрасли и её программного обеспечения. Тем не менее, они, очевидно, широко применимы, о чём свидетельствует их интуитивное принятие специалистами из других областей. 8 Их принятие почти всегда прагматично – они, похоже, работают. Никакие математические или статистические доказательства, похоже, не требуются, и, в любом случае, их не существует. Применимость определяется конкретным примером, конкретным случаем, контекстом. Таким образом, эвристика, как и любой метод, имеет свои характерные ограничения.

About six years ago we at the University of Southern California became seriously interested in heuristics as tools for systems architects (and others). About 100 appeared in a textbook followed by hundreds more in subsequent student research reports8 on systems they worked on in industry. The sheer number was a surprise, certainly, but it has posed a serious problem for further research - how best to access and use them. An early conclusion of such research is that a remarkable number of heuristics, discovered in one field, apply in many others with only a change in wording (for example, into business administration). The same heuristic may apply throughout a product life cycle. Because they are experience-based, they tend to be more useful at avoiding disaster than at generating marvels; but, used as check lists, some of them evidently can inspire or refine  new ideas and products.

Около шести лет назад мы в Университете Южной Калифорнии серьёзно заинтересовались эвристикой как инструментом для системных архитекторов (и других специалистов). Около 100 из них были упомянуты в учебнике (Rechtin, E., Systems Architecting, Creating & Building Complex Systems. Prentice Hall, New York 1961), а затем ещё сотни – в последующих студенческих исследовательских отчётах (автор ссылается на них, но они не опубликованы – прим.перев.) о системах, с которыми они работали в промышленности. Само количество, безусловно, стало неожиданностью, но оно создало серьёзную проблему для дальнейших исследований – как лучше всего получить к ним доступ и использовать их. Одним из первых выводов таких исследований является то, что значительное количество эвристик, обнаруженных в одной области, применимо во многих других, лишь с изменением формулировки (например, в бизнес-администрировании). Одна и та же эвристика может применяться на протяжении всего жизненного цикла продукта. Поскольку они основаны на опыте, они, как правило, более полезны для предотвращения катастроф, чем для сотворения чуда; но, будучи использованы в качестве чек-списков, некоторые из них, очевидно, могут вдохновлять или помогать совершенствовать новые идеи и продукты.

Clearly, systems architects do not live on deductive analytics alone. They also need inductive guidelines and lessons learned by their predecessors to structure their ill- structured environment, purposes and products.

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

Ultraquality, a quality too high to be measured | Сверхкачество, качество, превосходящее возможности его измерения

Quality is a measure of excellence. Ultra means beyond. Ultraquality is excellence beyond the ability to measure it. In this instance it means a failure rate so low it is impractical to measure with any degree of statistical confidence. The ultraquality challenge reaches its peak at certification when the architect must assure a client that the level of reliability is high enough that a first-of-a-kind, unprecedented system can be accepted and used - even though the hardware and software are untestable to that level!

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

Ultraquality is a non-negotiable requirement for many complex systems — safe nuclear power plants, manned space flight, single flights to the outer planets, multi-hundred passenger airliners, carcinogen-free food products, secure transmissions systems, and electronic financial transactions.

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

The challenge is greatly increased by the nature of human intolerance of failure. Demonstrably, the level of tolerance is progressively lower the greater the size and complexity of the system. Home appliances should not fad more than 1% of the time. A still smaller failure rate is demanded for an automobile, even less for an airliner, and still less of manned space flight. Thus as complexity and piece part count increases, the tolerated failure rate per part drops to a point where it can't be certified without unobtainable numbers of parts over unavailable time. Only microprocessor chips have demonstrated a reliability per operation that decreases with the number of operations performed.

It is no wonder that unthinking integration of available parts or modules into larger systems can be a prescription for trouble.

Проблема значительно усугубляется природой человеческой нетерпимости к отказам. Очевидно, что уровень толерантности тем ниже, чем больше размер и сложность системы. Бытовая техника не должна выходить из строя чаще, чем в 1% случаев. Ещё меньший уровень отказов требуется для автомобиля, ещё меньший для авиалайнера и ещё меньший для пилотируемого космического корабля. Таким образом, по мере увеличения сложности и количества деталей допустимый уровень отказов на деталь падает до точки, когда её невозможно сертифицировать без невероятной детализации в течение недоступного времени. Только микропроцессоры продемонстрировали степень надёжности в расчете на одну операцию, которая снижается с количеством выполненных операций.

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

Techniques have been developed to address this challenge. Available modules must be recertified for the larger systems. Zero defects, simplification, carefully-introduced redundancy (or its complex management can cause failure), rigorous elimination of single point failures, and inspiring the work force are a few of the measures required.

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

Systems architects really have no choice; they must be obsessive about quality, especially that of their own design. Least forgiveable are the "planned accidents" which cause users, from nuclear plant operators to airline pilots, to make fatal mistakes. Quality is not something to be left to the builder, the parts supplier, the quality assurance staff or the test crew, vital as their contributions are to the whole. It must be designed in and maintained. It is the architect's responsibility to see that it is.

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

Далее: Основы создания архитектуры систем (2). Заключение