Zachman Framework 1987 года

Если начать интересоваться Корпоративной архитектурой (Архитектурой предприятия) или просто ИТ-архитектурой, то можно столкнуться с упоминанием Модели Захмана (Zachman Framework 1987 года). Изначально она позиционировалась как модель для Информационных систем и в оригинальной статье 1987 г. (A Framework for Information Systems Architecture) это особо подчеркивалось. Уже тогда существовала полная структура на 6 столбцов, хотя в самой статье 1987 г. и говорилось о трех (остальные 3: ответственность, сроки, мотивация были в приложении A). Это объяснялось сложностью восприятия и неготовностью сообщества в 1987 г. к столь сложным концепциям. Со временем модель развивалась и в 2011 г. превратилась в The Zachman Framework for Enterprise Architecture. The Enterprise Ontology. Ценность этой модели с точки зрения Корпоративной архитектуры вопрос спорный (особенно с учетом наличия Zachman International, Inc.), скорее она подойдет для моделирования предприятия с уклоном в информационные технологии, но моя статья не об этом, а о том, что статья 1987 г. интересна с исторической точки зрения, так как в ней появилась идея, что одна и та же сложная вещь или элемент могут быть описаны для разных целей разными способами с использованием разных типов описаний (позволяет разным людям смотреть на одно и то же с разных точек зрения, что создает целостный взгляд на окружающую среду). Эта идея потом нашла свое развитие во многих архитектурных практиках: есть заинтересованные стороны, у которых есть свои интересы и виденье системы, каждый из них видит интересующие его аспекты со своей точки зрения. Это те самые view, viewpoint, perspective, concern, stakeholder и т.д.

Самой статьи A framework for information systems architecture by J. A. Zachman 1987 в текстовом виде я не нашел, есть в виде скана в pdf. Я перевел ее машинным способом с небольшими ручными правками для себя, в качестве знакомства с историей вопроса.

Важные моменты для правильного восприятия идей Захмана, не только Enterprise Ontology от 2011 года, но и идей 1987 года:

• Это не методология (то есть не метод или процесс) создания реализации (экземпляра) объекта. Это онтология (формализация некоторой области знаний с помощью концептуальной схемы), то есть в данном случае описание структурированного набора важных компонентов объекта (двумерная схема классификации). Это описание необходимо для работы с этим объектом, и в данном случае этот объект – предприятие в самом широком смысле этого понятия. Онтология выражена в виде каркаса (фреймворка) с некоторыми правилами для этой структуры.
• Строки – это не детализаций, это трансформация от строки к строке. Декомпозиция (т. е. детализация до более высокого уровня детализации) происходит внутри каждой ячейки. Каждая строка представляет общий вид решения с определенной точки зрения. Верхняя строка или перспектива не обязательно имеют более полное понимание целого, чем нижняя строка. Каждая строка представляет собой отдельную, уникальную перспективу и результат каждой перспективы должен обеспечивать достаточную детализацию для определения решения на уровне перспективы и должны явно переводиться в следующую строку ниже. Каждая перспектива (строка) должна учитывать требования других перспектив и ограничения, налагаемые этими перспективами.
• Столбцы – это интеграция (интеграция между ячейками по строкам). Эта интеграция ответов на вопросы: Что? Как? Где? Кто? Когда? Почему? обеспечивает всестороннее, комплексное описание сложных идей.
• Модели предприятия ИНТЕГРИРУЮТСЯ по горизонтали, а ТРАНСФОРМИРУЮТСЯ по вертикали.
• Только последняя, нижняя, 6-я строка – это экземпляр (результат), все остальные с 1-й по 5-ю – это абстракции (архитектура).
• В ячейках примитивные модели, никаких сложных моделей и других нотаций. Представления в каждой ячейке матрицы – это разные представления, разные по контексту, значению, мотивации и использованию.
• Все, что владельцы имеют в виду (строка 2 – Бизнес-концепции), должно быть тем, что на самом деле создано на предприятии (строка 6 – Предприятие).
• Цепочка овеществления от абстрактной идеи до экземпляра: строка 1 – идентификация, строка 2 – определение, строка 3 – представление, строка 4 – спецификация, строка 5 – конфигурация, и строка 6 – экземпляр.

С историей развития Zachman Framework можно ознакомиться тут.

Версия статьи в word: A-framework-for-information-systems-architecture-Zachman

pdf который переводил: the-zachman-framework-enterprise-architecture-original-paper-1987

Собственно сама статья 1987 года:

A framework for information systems architecture by J. A. Zachman 1987
With increasing size and complexity of the implementations of information systems, it is necessary to use some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of the system. This paper defines information systems architecture by creating a descriptive framework from disciplines quite independent of information systems, then by analogy specifies information systems architecture based upon the neutral, objective framework. Also, some preliminary conclusions about the implications of the resultant descriptive framework are drawn. The discussion is limited to architecture and does not include a strategic planning methodology.	С увеличением размера и сложности реализаций информационных систем необходимо использовать некоторую логическую конструкцию (или архитектуру) для определения и управления интерфейсами и интеграции всех компонентов системы. В этой статье определяется архитектура информационных систем путём создания описательной структуры из дисциплин, совершенно независимых от информационных систем, затем по аналогии определяется архитектура информационных систем, основанная на нейтральной, объективной структуре. Кроме того, делаются некоторые предварительные выводы о последствиях результирующей описательной структуры. Обсуждение ограничено архитектурой и не включает методологию стратегического планирования.
The subject of information systems architecture is beginning to receive considerable attention. The increased scope of design and levels of complexity of information systems implementations are forcing the use of some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of the system. Thirty years ago, this issue was not at all significant because the technology itself did not provide for either breadth in scope or depth in complexity in information systems. The inherent limitations of the then-available 4000 machines, for example, constrained design and necessitated suboptimal approaches for automating a business.	Теме архитектуры информационных систем начинает уделяться значительное внимание. Возросший объем проектирования и уровни сложности реализаций информационных систем вынуждают использовать некоторую логическую конструкцию (или архитектуру) для определения и управления интерфейсами и интеграции всех компонентов системы. Тридцать лет назад этот вопрос не имел никакого значения, поскольку сама технология не обеспечивала ни широты охвата, ни глубины сложности информационных систем. Например, ограничения, присущие имеющимся на тот момент 4000 машинам, ограничивали проектирование и требовали неоптимальных подходов к автоматизации бизнеса.
Current technology is rapidly removing both conceptual and financial constraints. It is not hard to speculate about, if not realize, very large, very complex systems implementations, extending in scope and complexity to encompass an entire enterprise. One can readily delineate the merits of the large, complex, enterprise-oriented approaches. Such systems allow flexibility in managing business changes and coherency in the management of business resources. However, there also is merit in the more traditional, smaller, suboptimal systems design approach. Such systems are relatively economical, quickly implemented, and easier to design and manage.	Современные технологии быстро устраняют как концептуальные, так и финансовые ограничения. Об этом нетрудно порассуждать, если не реализовать, очень большие, очень сложные системные реализации, расширяющиеся по масштабу и сложности, чтобы охватить все предприятие. Можно легко определить достоинства крупных, комплексных, ориентированных на предприятия подходов. Такие системы обеспечивают гибкость в управлении бизнес-изменениями и согласованность в управлении бизнес-ресурсами. Тем не менее, есть также преимущества в более традиционном, меньшем по размеру и неоптимальном подходе к проектированию систем. Такие системы относительно экономичны, быстро внедряются и проще в проектировании и управлении.
In either case, since the technology permits «distributing» large amounts of computing facilities in small packages to remote locations, some kind of structure (or architecture) is imperative because decentralization without structure is chaos. Therefore, to keep the business from disintegrating, the concept of information systems architecture is becoming less an option and more a necessity for establishing some order and control in the investment of information systems resources. The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems.	В любом случае, поскольку технология позволяет «распределять» большие объёмы вычислительных средств небольшими пакетами в удалённые места, необходима какая-то структура (или архитектура), поскольку децентрализация без структуры – это хаос. Поэтому, чтобы уберечь бизнес от распада, концепция архитектуры информационных систем становится не столько вариантом, сколько необходимостью для установления определённого порядка и контроля при инвестировании ресурсов информационных систем. Связанные с этим затраты и успех бизнеса, все больше зависящий от его информационных систем, требуют дисциплинированного подхода к управлению этими системами.
On the assumption that an understanding of information systems architecture is important to the development of a disciplined approach, the question that naturally arises is «What, in fact, is information systems architecture?» Unfortunately, among the proponents of information systems architecture, there seems to be little consistency in concepts or in specifications of «architecture», to the extent that the words «information systems architecture» are already losing their meaning! Furthermore, it probably is not reasonable to expect reconciliation or commonality of definition to emerge from the professional data processing community itself. The emotional commitment associated with vested interests almost demands a neutral, unbiased, independent source as a prerequisite for any acceptable work in this area.	Исходя из предположения, что понимание архитектуры информационных систем важно для разработки дисциплинированного подхода, естественно возникает вопрос: «Что, собственно, такое архитектура информационных систем?» К сожалению, среди сторонников архитектуры информационных систем, по-видимому, мало согласованности в концепциях или спецификациях «архитектуры» до такой степени, что слова «архитектура информационных систем» уже теряют своё значение! Кроме того, вероятно, неразумно ожидать согласования или общности определений от самого профессионального сообщества по обработке данных. Эмоциональная приверженность, связанная с законными интересами, почти требует нейтрального, непредвзятого, независимого источника в качестве предварительного условия для любой приемлемой работы в этой области.
In any event, it likely will be necessary to develop some kind of framework for rationalizing the various architectural concepts and specifications in order to provide for clarity of professional communication, to allow for improving and integrating development methodologies and tools, and to establish credibility and confidence in the investment of systems resources.	В любом случае, вероятно, потребуется разработать какую-то основу для рационализации различных архитектурных концепций и спецификаций, чтобы обеспечить ясность профессионального общения, обеспечить возможность совершенствования и интеграции методологий и инструментов разработки, а также создать доверие и уверенность в инвестировании системных ресурсов.
Although information systems architecture is related to strategy, both information strategy and business strategy, this paper deliberately limits itself to architecture and should not be construed as presenting a strategic planning methodology. The development of a business strategy and its linkage to information systems strategies, which ultimately manifest themselves in architectural expression, is an important subject to pursue; but it is quite independent of the subject of this work, which is defining a framework for information systems architecture.	Хотя архитектура информационных систем связана со стратегией, как информационной стратегией, так и бизнес-стратегией, этот документ намеренно ограничивается архитектурой и не должен быть истолкован как представляющий методологию стратегического планирования. Разработка бизнес-стратегии и её связь со стратегиями информационных систем, которые в конечном итоге проявляются в архитектурном выражении, является важной темой для изучения; но это совершенно независимо от предмета этой работы, которая определяет структуру архитектуры информационных систем.
Derivation of the architectural concept	Разработка архитектурной концепции
In searching for an objective, independent basis upon which to develop a framework for information systems architecture, it seems only logical to look to the field of classical architecture itself. In so doing, it is possible to learn from the thousand or so years of experience that have been accumulated in that field. Definition of the deliverables, i.e., the work product, of a classical architect can lead to the specification of analogous information systems architectural products and, in so doing, can help to classify our concepts and specifications.	В поисках объективной, независимой основы, на которой можно было бы разработать структуру архитектуры информационных систем, представляется логичным обратиться к области самой классической архитектуры. Поступая таким образом, можно извлечь уроки из тысячелетнего или около того опыта, накопленного в этой области. Определение результатов, то есть рабочего продукта, классического архитектора может привести к спецификации аналогичных архитектурных продуктов информационных систем и, таким образом, может помочь классифицировать наши концепции и спецификации.
With this objective in mind, that is, discovering the analogous information systems architectural representations, the following is an examination of the classical architect’s deliverables produced in the process of constructing a building. [1]	С учётом этой цели, то есть обнаружения аналогичных архитектурных представлений информационных систем, ниже приводится анализ результатов классического архитектора, полученных в процессе строительства здания. [1]
Bubble charts. The first architectural deliverable created by the architect is a conceptual representation, a «bubble chart», which depicts, in gross terms, the size, shape, spatial relationships, and basic intent of the final structure. This bubble chart results from the initial conversations between the architect and prospective owner. A sample of such an initial conversation follows:	Схемы с кружками и стрелками. Первый архитектурный результат, созданный архитектором, представляет собой концептуальное представление, «схему с кружками и стрелками», которая в общих чертах отображает размер, форму, пространственные отношения и основное назначение конечной структуры. Эта схема с кружками и стрелками является результатом первоначальных бесед между архитектором и потенциальным владельцем. Ниже приводится пример такого первоначального разговора:
I’d like to build a building. What kind of building do you have in mind? Do you plan to sleep in it? Eat in it? Work in it? Well, I’d like to sleep in it. Oh, you want to build a house? Yes, I’d like a house. How large a house do you have in mind? Well, my lot size is 100 feet by 300 feet. Then you want a house about 50 feet by 100 feet? Yes, that’s about right. How many bedrooms do you need? Well, I have two children, so I’d like three bedrooms.	– Я бы хотел построить здание. – Какое здание вы имеете в виду? Вы планируете спать в нем? Есть в нем? Работать в нем? – Ну, я бы хотел в нем спать. – О, Вы хотите построить дом? – Да, я бы хотел дом. – Какой большой дом Вы имеете в виду?» – Ну, мой участок размером 100 на 300 футов. – Тогда Вам нужен дом размером примерно 50 на 100 футов? – Да, это примерно так. – Сколько спален Вам нужно? – Ну, у меня двое детей, так что я бы хотел три спальни.
Note that each question serves to pose a constraint (the lot size) or identify a requirement (the number of bedrooms) in order to establish the «ballpark», or approximate conditions, within which any design will take place. From the above dialogue, the architect can depict what the owner has in mind in the form of a series of «bubbles», each bubble representing a room, its gross size, shape, spatial relationship, etc. (See Figure 1.)	Обратите внимание, что каждый вопрос служит для установления ограничения (размер участка) или определения требования (количество спален), чтобы установить «приблизительный» или приблизительные условия, в которых будет осуществляться любое проектирование. Из приведённого выше диалога архитектор может изобразить то, что имеет в виду владелец, в виде серии «кружков», каждый из которых представляет комнату, её общий размер, форму, пространственные отношения и т.д. (см. Рисунок 1).
The architect’s drawings are a transcription of the owner’s perceptual requirements.	Архитектурные эскизы – это расшифровка восприятия требований владельца.

The architect prepares this bubble chart for two reasons. First, the prospective owner must express what he or she has in mind that will serve as a foundation or basis for the architect’s actual design work. Second, the architect must convince the owner that the owner’s desires are understood well enough so that the owner will pay for the creative work to follow, and in effect, initiate the project.	Архитектор готовит эту схему с кружками и стрелками по двум причинам. Во-первых, потенциальный владелец должен выразить то, что он или она имеет в виду, что послужит фундаментом или базисом для фактической проектной работы архитектора. Во-вторых, архитектор должен убедить владельца в том, что желания владельца поняты достаточно хорошо, чтобы владелец заплатил за последующую творческую работу и, по сути, инициировал проект.
Having established a basic understanding with the prospective owner, the architect produces the next set of architectural deliverables, which are called architect’s drawings.	Установив базовое взаимопонимание с потенциальным владельцем, архитектор создаёт следующий набор архитектурных результатов, которые называются архитектурными эскизами.
Architect’s drawings. The architect’s drawings are a transcription of the owner’s perceptual requirements, a depiction of the final product from the owner’s perspective.	Архитектурные эскизы. Эскизы архитектора – это расшифровка восприятия требований владельца, описание конечного продукта как ви́денье владельца.
The drawings include horizontal sections (floor plans), vertical sections (cutaways), and pictorial representations depicting the artistic motif of the final structure. The purpose of these drawings is to enable the owner to relate to them and to agree or disagree: «That is exactly what I had in mind!» or «Make the following modifications».	Эскизы включают горизонтальные разрезы (поэтажные планы), вертикальные разрезы (вырезы) и графические изображения, изображающие художественный мотив окончательной конструкции. Цель этих рисунков – дать возможность владельцу ознакомиться с ними и согласиться или не согласиться: «Это именно то, что я имел в виду!» или «Внесите следующие изменения».
The drawings can be very detailed; however, they are normally developed only to the level of detail required for the prospective owner to understand and approve the design.	Эскизы могут быть очень подробными; однако обычно они разрабатываются только до уровня детализации, необходимого для того, чтобы потенциальный владелец мог понять и одобрить проект.
Once the owner agrees that the architect has captured what he or she has in mind, and further agrees to pay the price for continuing the project, the architect produces the next set of architectural deliverables, which are called the architect’s plans.	Как только владелец соглашается с тем, что архитектор уловил то, что он или она имеет в виду, и далее соглашается заплатить цену за продолжение проекта, архитектор создаёт следующий набор архитектурных результатов, которые называются архитектурным проектом.
Architect’s plans. The architect’s plans are the translation of the owner’s perceptions/requirements into a product. The plans are a designer’s representation of the final product (as opposed to an owner’s representation, which is embodied in the drawings). The designer’s representation (plans) puts an explicit specification around the material composition of the final product. The plans are composed of 16 categories of detailed representations, including site-work, electrical system, masonry, wood structure, etc. They describe material relationships in the form of diagrams (drawings) as well as bills-of-materials. These plans are the final deliverables prepared by the architect and ultimately become the official «record» of the finished structure.	Архитектурный проект. Архитектурный проект – это воплощение представлений / требований владельца в продукт. Проекты представляют собой представление проектировщика о конечном продукте (в отличие от представления владельца, которое воплощено в эскизах). Представление проектировщика (проект) содержит чёткую спецификацию материального состава конечного продукта. Проекты состоят из 16 категорий подробных представлений, включая строительные работы, электрическую систему, каменную кладку, деревянную конструкцию и т.д. Они описывают материальные взаимосвязи в виде диаграмм (чертежей), а также спецификаций. Эти планы являются окончательными результатами, подготовленными архитектором, и в конечном итоге становятся официальной «записью» готовой конструкции.
The architect’s plans are prepared to serve as a basis for negotiation with a general contractor. The owner takes the plans to a contractor and says, «Build me one of these». If the contractor builds «one of these», which is represented in the architect’s plans, the owner knows that there is a high probability of getting the desired product, as depicted in the architect’s drawings.	Архитектурные проекты подготовлены для того, чтобы послужить основой для переговоров с генеральным подрядчиком. Владелец относит проекты подрядчику и говорит: «Построй мне один из этих». Если подрядчик строит «один из этих», который представлен в архитектурных проектах, владелец знает, что существует высокая вероятность получения желаемого продукта, как показано на архитектурных эскизах.
As a result of the negotiations between the owner and general contractor, the plans may be modified because of cost/price and other considerations, but they finally serve to represent what is committed to construction.	В результате переговоров между владельцем и генеральным подрядчиком планы могут быть изменены из-за соотношения затрат и цен, и других соображений, но в конечном итоге они служат для представления того, что предполагается построить.
Contractor’s plans. At this point, the contractor redraws the architect’s plans to produce the contractor’s plans representing the builder’s perspective. Such plans are prepared because complex engineering products are not normally built in a day. Some phased approach is required which, in the case of a building, may comprise first some site work; next the foundation; then the first floor, and so on, until the building is completed. Furthermore, the contractor may have technology constraints. Either the tool technology or the process technology may constrain his ability to produce precisely what the architect has designed. In either case, the contractor will have to design a reasonable facsimile which can be produced and yet satisfies the requirements. These technology constraints, plus the natural constraints requiring phased construction, are reflected in the contractor’s plans, which serve to direct the actual construction activity.	Планы подрядчика. На этом этапе подрядчик перерисовывает архитектурные проекты, чтобы создать планы подрядчика, отражающие ви́денье строителя. Такие планы составляются потому, что сложные инженерные изделия обычно не создаются за один день. Требуется некоторый поэтапный подход, который, в случае здания, может включать в себя сначала некоторые работы на площадке; затем фундамент; затем первый этаж и так далее, пока здание не будет завершено. Кроме того, у подрядчика могут быть технологические ограничения. Либо технология инструмента, либо технология процесса могут ограничить его способность производить именно то, что спроектировал архитектор. В любом случае подрядчик должен будет разработать приемлемую копию, которая может быть изготовлена и в то же время удовлетворяет требованиям. Эти технологические ограничения, а также естественные ограничения, требующие поэтапного строительства, отражены в планах подрядчика, которые служат для руководства фактической строительной деятельностью.
Shop plans. Other representations, short of the final structure itself, are prepared by subcontractors. These representations are called shop plans and are drawings of parts or subsections which are an out-of-context specification of what actually will be fabricated or assembled. The drawings, architect’s plans, and contractor’s plans are in-context because the owner, architect, and contractor are all concerned with the entirety of the structure, whereas the subcontractors’ representations are concerned with components or parts of the total structure. These shop plans might even serve as patterns for a quantity of identical parts to be fabricated for the project.	Цеховые планы. Другие представления, за исключением самой окончательной структуры, готовятся субподрядчиками. Эти представления называются планами цеха и представляют собой чертежи деталей или секций, которые представляют собой вырванную из контекста спецификацию того, что на самом деле будет изготовлено или собрано. Эскизы, архитектурные проекты и планы подрядчика находятся в контексте, потому что владелец, архитектор и подрядчик имеют отношение ко всей конструкции, в то время как представления субподрядчиков касаются компонентов или частей общей конструкции. Эти планы цеха могут даже служить образцами для количества идентичных деталей, которые будут изготовлены для проекта.
The building. In the case of producing a building, the final representation is the physical building itself. In summary, there is a set of «architectural» representations that are produced during the process of constructing a building. The set is given in Table 1.	Здание. В случае создания здания конечным представлением является само физическое здание. Таким образом, существует набор «архитектурных» представлений, которые создаются в процессе строительства здания. Набор приведён в таблице 1.

A generic set of architectural representations	Общий набор архитектурных представлений
Now that we have specified the set of architectural representations produced during the process of constructing a building, it becomes apparent that this set of «architectures» may be generic to the process of building any complex engineering product. A cursory examination of military airframe manufacturing appears to validate this hypothesis as follows:	Теперь, когда мы определили набор архитектурных представлений, созданных в процессе строительства здания, становится очевидным, что этот набор «архитектур» может быть общим для процесса создания любого сложного инженерного продукта. Беглый анализ производства военных самолётов, по-видимому, подтверждает эту гипотезу следующим образом:
a. Concepts equals «bubble charts» (ballpark view). The airframe manufacturers begin with some «concepts», which are specifications for the «ballpark» in which they intend to manufacture. For example, concepts for the final product indicating that it will fly so high, so fast, so far, for such and such purpose, with so many people, etc. are formulated to establish its gross size, shape, and performance.	Та же концепция «схем с кружками и стрелками» (приблизительный вид). Производители самолётов начинают с некоторых «концепций», которые являются спецификациями для «площадки», на которой они намерены производить. Например, концепции конечного продукта, указывающие, что он будет летать так высоко, так быстро, так далеко, для такой-то цели, с таким-то количеством людей и т.д., формулируются для определения его общего размера, формы и производительности.
b. Work breakdown structure equals architect’s drawings (owner’s view). The work breakdown structure is the «owner’s perspective». The government requires that the manufacturer specify the work to be accomplished in terms of the components/systems against which costs are accrued and schedules are managed. In this fashion, the government controls the manufacturer in the production of the product.	WBS соответствует архитектурным эскизам (взгляд владельца). WBS – это «ви́денье владельца». Правительство требует, чтобы производитель указывал работу, которую необходимо выполнить, с точки зрения компонентов/систем, в отношении которых начисляются затраты и управляются графики. Таким образом, правительство контролирует производителя при производстве продукта.
c. Engineering design equals architect’s plans (designer’s view). Engineering, the designer, translates the work breakdown structure into a physical product. The resultant «engineering design» is composed of drawings and bills-of-material.	Инженерный проект равен архитектурному проекту (взгляд проектировщика). Инженер, проектировщик, преобразует WBS в физический продукт. Результирующий “инженерный проект” состоит из чертежей и спецификаций.
d. Manufacturing engineering bill-of-materials equals contractor’s plans (builder’s view). Manufacturing engineering, the builder, applies the laws of nature and technology constraints to the engineering design to describe how to build the product (i.e., inside-out, bottom-up) and to ensure that everything designed is actually producible.	Техническая спецификация производства равна планам подрядчика (взгляд строителя). Техническая спецификация, разработчик, применяет законы природы и технологические ограничения к инженерному проекту, чтобы описать, как создавать продукт (т.е. изнутри наружу, снизу вверх), и гарантировать, что все спроектированное действительно пригодно для производства.
e. Assembly and fabrication drawings equals shop plans (detail view). Assembly and fabrication drawings are the instructions to the shop floor personnel on how they are to assemble/fabricate the pieces or parts as stand-alone entities.	Чертежи сборки и изготовления равны планам цеха (детальный вид). Чертежи сборки и изготовления – это инструкции для персонала цеха о том, как они должны собирать / изготавливать части или детали как самостоятельные объекты.
An analogous set of architectural representations is likely to be produced in building any complex product.	Аналогичный набор архитектурных представлений, вероятно, будет создан при создании любого сложного продукта.
f. Machine tool representation (machine view). Because manufacturing uses computer-controlled equipment to produce some parts, they insert an additional representation of the final piece or part, short of the physical part itself. This representation is a «program» (i.e., «numerical code program») that is a machine language representation.	Представление машины (технический вид). Поскольку в производстве для изготовления некоторых деталей используется оборудование с компьютерным управлением, они вставляют дополнительное представление конечного изделия или детали, за исключением самой физической детали. Это представление представляет собой «программу» (т.е. «программу с числовым кодом»), которая представляет собой представление на машинном языке.
g. Airplane equals building (finished product). The final representation is the actual, physical item itself.	Самолёт равен зданию (готовому продукту). Конечное представление – это сам фактический, физический элемент.
In any case, there appear to be conceptual equivalents in the manufacturing industry for the architectural representations of the construction industry. This equivalency would strengthen the argument that an analogous set of architectural representations is likely to be produced during the process of building any complex engineering product, including an information system.	В любом случае, в обрабатывающей промышленности, по-видимому, существуют концептуальные эквиваленты архитектурных представлений строительной отрасли. Эта эквивалентность усилила бы аргумент о том, что аналогичный набор архитектурных представлений, вероятно, будет создан в процессе создания любого сложного инженерного продукта, включая информационную систему.
Before identifying the information systems analogs, it is useful to make some general observations regarding architecture.	Прежде чем определить аналоги информационных систем, полезно сделать некоторые общие замечания относительно архитектуры.
First, there appear to be three fundamental architectural representations, one for each «player in the game», that is, the owner, the designer, and the builder. The owner has in mind a product that will serve some purpose. The architect transcribes this perception of a product into the owner’s perspective. Next the architect translates this representation into a physical product, the designer’s perspective. The builder then applies the constraints of the laws of nature and available technology to make the product producible, which is the builder’s perspective.	Во-первых, по-видимому, существует три фундаментальных архитектурных представления, по одному для каждого «игрока в игре», то есть владельца, проектировщика и строителя. Владелец имеет в виду продукт, который будет служить какой-то цели. Архитектор переводит это восприятие продукта в ви́денье владельца. Затем архитектор переводит это представление в физический продукт, ви́денье проектировщика. Затем разработчик применяет ограничения законов природы и доступных технологий, чтобы сделать продукт производимым, что является ви́деньем разработчика.
Preceding these three fundamental representations, a gross representation of size, shape, and scope is created to establish the «ballpark» within which all of the ensuing architectural activities will take place.	Предшествуя этим трём фундаментальным представлениям, создаётся общее представление о размере, форме и объёме, чтобы установить «примерное поле», в пределах которого будут происходить все последующие архитектурные действия.
Succeeding the three fundamental representations are the detailed, out-of-context representations which technically could be considered architectures because they are representations short of being the final physical product. However, they are somewhat less interesting «architecturally», since they do not depict the final product in total and are more oriented to the actual implementation activities. Nonetheless, they are included in this discussion for the purpose of ensuring a comprehensive framework.	За тремя фундаментальными представлениями следуют подробные, вырванные из контекста представления, которые технически можно было бы считать архитектурами, поскольку они являются представлениями, не являющимися конечным физическим продуктом. Однако они несколько менее интересны «архитектурно», поскольку не отображают конечный продукт в целом и больше ориентированы на фактическую деятельность по внедрению. Тем не менее, они включены в это обсуждение с целью обеспечения всеобъемлющей основы.
A significant observation regarding these architectural representations is that each has a different nature from the others. They are not merely a set of representations, each of which displays a level of detail greater than the previous one. Level of detail is an independent variable, varying within any one architectural representation. For example, the designer’s representation (i.e., architect’s plans) is not merely a succeeding, increasing level of detail of the owner’s representation (i.e., architect’s drawings). It is different in nature, in content, in semantics, and so on, representing a different perspective. The level of detail of the designer’s representation (i.e., plans) is variable, and quite independent of the level of detail of the owner’s representation (i.e., drawings).	Важным замечанием, касающимся этих архитектурных представлений, является то, что каждое из них отличается по своей природе от других. Они представляют собой не просто набор представлений, каждое из которых отображает уровень детализации, превышающий предыдущий. Уровень детализации — это независимая переменная, изменяющаяся в пределах любого архитектурного представления. Например, представление проектировщика (т.е. архитектурный проект) – это не просто последовательный, увеличивающийся уровень детализации представления владельца (т.е. архитектурные эскизы). Он отличается по своей природе, по содержанию, по семантике и так далее, представляя другое ви́денье. Уровень детализации представления проектировщика (т.е. проектов) является переменным и совершенно не зависит от уровня детализации представления владельца (т.е. эскизов).
In the same fashion, each of the architectural representations differs from the others in essence, not merely in level of detail.	Точно так же каждое из архитектурных изображений отличается от других, по сути, а не только по уровню детализации.
Given this description of the perspectives (i.e., owner’s perspective, designer’s perspective, builder’s perspective, etc.) of architectural representation produced over the process of building a complex engineering product, it is relatively straightforward to identify the analogs in the information systems area, since information systems are also «complex engineering products». Table 2 identifies those information systems analogs along with the building and airplane equivalents.	Учитывая это описание ви́денья (т.е. ви́денье владельца, ви́денье проектировщика, ви́денье строителя и т.д.) архитектурного представления, созданного в процессе создания сложного инженерного продукта, относительно просто идентифицировать аналоги в области информационных систем, поскольку информационные системы также являются «сложными инженерными продуктами». В таблице 2 указаны аналоги этих информационных систем, а также эквиваленты зданий и самолётов.

Different types of descriptions for the same product.

Разные типы описаний для одного и того же продукта.

Before the idea regarding the different perspectives (and therefore the different architectural representations produced over the process of building complex engineering products) is developed further, it is necessary to introduce a second, entirely different idea. Specifically, there exist different types of descriptions oriented to different aspects of the object being described. Table 3 characterizes three such types of descriptions, one of which is oriented to the material of the product, another to its function, and the third to the relative location of its components.

Прежде чем идея, касающаяся различных ви́дений (и, следовательно, различных архитектурных представлений, создаваемых в процессе создания сложных инженерных продуктов), получит дальнейшее развитие, необходимо представить вторую, совершенно иную идею. В частности, существуют различные типы описаний, ориентированных на различные аспекты описываемого объекта. Таблица 3 характеризует три таких типа описаний, одно из которых ориентировано на материал изделия, другое – на его функцию, а третье – на взаимное расположение его компонентов.

In spite of the fact that each of the descriptions may be describing the same product, each of them is unique and stands alone because each serves quite different purposes. Furthermore, none of the descriptions explicitly says anything about any of the other descriptions. Only assumptions can be made from one about the contents of another. For example, a bill-of-materials exists independently of, and is clearly different from, functional specifications or drawings. Looking at a bill-of-materials tells nothing about functional specifications or drawings (relative locations of components). Only assumptions can be made about function or location, depending upon how descriptively named the parts are in the bill-of-materials. Similarly, the functional specifications say nothing explicit about the bill-of-materials or the drawings, and the drawings say nothing explicit about the bill-of-materials or functional specifications.	Несмотря на то, что каждое из описаний может описывать один и тот же продукт, каждое из них уникально и стоит особняком, потому что каждое служит совершенно разным целям. Кроме того, ни в одном из описаний явно ничего не говорится ни о каком из других описаний. Из одного можно сделать только предположения о содержании другого. Например, Спецификация материалов существует независимо от Функциональных спецификаций или Чертежей и явно отличается от них. Просмотр Спецификации материалов ничего не говорит о Функциональных спецификациях или Чертежах (относительное расположение компонентов). Относительно функции или местоположения можно делать только предположения, в зависимости от того, как описательно названы детали в спецификации. Аналогичным образом, в Функциональных спецификациях ничего не говорится о Спецификации материалов или Чертежах, а в Чертежах ничего не говорится о Спецификации материалов или Функциональных спецификациях.
In short, each of the different descriptions has been prepared for a different reason, each stands alone, and each is different from the others, even though all the descriptions may pertain to the same object and therefore are inextricably related to one another.	Короче говоря, каждое из различных описаний было подготовлено по другой причине, каждое стоит особняком, и каждое отличается от других, даже несмотря на то, что все описания могут относиться к одному и тому же объекту и, следовательно, неразрывно связаны друг с другом.
The «description» row of Table 3 suggests that there likely are additional descriptions not characterized in the table as the material description addresses «what», the functional description addresses «how», and the location description addresses «where». The implications are that there must be at least «who», «when», and «why» descriptions as well. Discussion of these additional types of descriptions is reserved for the future, since using only three different descriptions introduces considerable complexity into the subject of information systems architecture at this time. Therefore, the remainder of this paper will be limited to the three types of descriptions contained in Table 3. For future reference, Appendix A is included and contains a preliminary, Table 3-like characterization of the additional descriptive types related to people (who), time (when), and motivation (why).	Строка «описание» таблицы 3 предполагает, что, вероятно, существуют дополнительные описания, не описанные в таблице, поскольку в описании материала указано «что», в функциональном описании указано «как», а в описании местоположения указано «где». Отсюда следует, что также должны быть, по крайней мере, описания «кто», «когда» и «почему». Обсуждение этих дополнительных типов описаний отложено на будущее, поскольку использование только трёх различных описаний вносит значительную сложность в предмет архитектуры информационных систем в настоящее время. Поэтому оставшаяся часть этого документа будет ограничена тремя типами описаний, содержащихся в таблице 3. Для дальнейшего использования включено Приложение А, содержащее предварительную, подобную таблице 3 характеристику дополнительных описательных типов, связанных с людьми (кто), временем (когда) и мотивацией (почему).
As was the case with the earlier idea regarding the different perspectives of the different participants in the architecture process, once again it is straightforward to identify the information systems analogs for the elements of the second idea, that is, the different types of descriptions for the same object, as follows:	Как и в случае с предыдущей идеей, касающейся различных ви́дений различных участников процесса архитектуры, снова легко идентифицировать аналоги информационных систем для элементов второй идеи, то есть различных типов описаний для одного и того же объекта, следующим образом:
a. Functional description – in information systems terms this would likely be called a process (or a functional) model, and the descriptive representation would be called the same as the general case, «input-process-output».	Функциональное описание – в терминах информационных систем это, вероятно, будет называться моделью процесса (или функциональной), а описательное представление будет называться так же, как и в общем случае, «вход-процесс-выход».
b. Material description – generally speaking, the material description describes the «stuff the thing is made of», which in the case of information systems is data. Therefore, in information systems terms, the analog for the material description would be a data model, and in the data vernacular, «part-relationship-part» would become «entity-relationship-entity». The data model is the equivalent of the bill-of-materials for the information systems product.	Описание материала – вообще говоря, описание материала описывает «материал, из которого сделана вещь», который в случае информационных систем является данными. Следовательно, в терминах информационных систем аналогом описания материала будет модель данных, а на языке данных «часть-взаимосвязь-часть» станет «сущность-связь-сущность». Модель данных является эквивалентом спецификаций материалов для продукта информационных систем.
c. Location description – in information systems, this would likely be called the network model, in which the focus is on the flows (connections) between the various components. In the information systems network vernacular, «site-link-site» would become «node-line-node».	Описание местоположения – в информационных системах это, вероятно, будет называться сетевой моделью, в которой основное внимание уделяется потокам (соединениям) между различными компонентами. На просторечии сети информационных систем «местоположение-соединение-местоположение» превратился бы в «узел-линия-узел».

Therefore, the rows of Table 4, which constitute the analogs in information systems for the more generic types of descriptions, could be added to Table 3.	Следовательно, строки таблицы 4, которые представляют собой аналоги в информационных системах для более общих типов описаний, могут быть добавлены в таблицу 3.
The framework. Two ideas have been discussed thus far:	Структура. До сих пор обсуждались две идеи:
a. There is a set of architectural representations produced over the process of building a complex engineering product representing the different perspectives of the different participants.	а. Существует набор архитектурных представлений, созданных в процессе создания сложного инженерного продукта, представляющих различные ви́денья разных участников.
b. The same product can be described, for different purposes, in different ways, resulting in different types of descriptions.	б. Один и тот же продукт может быть описан для разных целей по-разному, что приводит к различным типам описаний.
The combination of the two ideas suggests that for every different type of description, there are different perspectives (and actually different representations) for each of the different participants. For example, for the material (or data) description, there are the owner’s representation, the designer’s representation, the builder’s representation, etc. For the functional (or process) description, there are the owner’s representation, the designer’s representation, the builder’s representation, etc. For the location (or geographic) description, there are also the owner’s representation, the designer’s representation, the builder’s representation, etc.	Сочетание этих двух идей предполагает, что для каждого различного типа описания существуют разные ви́денья (и фактически разные представления) для каждого из разных участников. Например, для описания материала (или данных) есть представление владельца, представление проектировщика, представление разработчика и т.д. Для описания функционала (или процесса) существует представление владельца, представление проектировщика, представление разработчика и т.д. Для описания местоположения (или географического) также есть представление владельца, представление проектировщика, представление разработчика и т.д.
Figure 2 illustrates the total set of different perspectives for each type of description. Note that because the intent is to depict a framework for information systems architecture, all the information systems analog names from Tables 2, 3, and 4 have been used in Figure 2 in place of the more generic manufacturing or construction names. Also, the machine language perspective in Table 2 has been omitted, merely because it is not as interesting as the others from an «architectural» point of view.	На Рисунке 2 показан общий набор различных ви́дений для каждого типа описания. Обратите внимание, что, поскольку цель состоит в том, чтобы изобразить структуру архитектуры информационных систем, все аналоги названий информационных систем из таблиц 2, 3 и 4 были использованы на Рисунке 2 вместо более общих названий производства или конструкции. Кроме того, ви́денье машинного языка в таблице 2 было опущен просто потому, что она не так интересна, как другие, с «архитектурной» точки зрения.

Рис.2

The one single factor that makes this framework extremely interesting is the fact that each element on either axis of the matrix is explicitly differentiable from all other elements on that one axis. That is, the model of the business (owner’s perspective) is different from the model of the information system (designer’s perspective), and so on. (Remember from earlier discussions that these representations are not merely successive levels of increasing detail but are actually different representations—different in content, in meaning, in motivation, in use, etc.) Also, the data description column (entity-relationship-entity) is different from the process description column (input-process-output), and so on. Because each of the elements on either axis is explicitly different from the others, it is possible to define precisely what belongs in each cell, and further, each cell in the matrix will be explicitly different from all the other cells.	Единственным фактором, который делает эту структуру чрезвычайно интересной, является тот факт, что каждый элемент на любой оси матрицы явно отличается от всех других элементов на этой оси. То есть модель бизнеса (ви́денье владельца) отличается от модели информационной системы (ви́денье проектировщика) и так далее. (Помните из предыдущих обсуждений, что эти представления представляют собой не просто последовательные уровни возрастающей детализации, а на самом деле разные представления — разные по содержанию, значению, мотивации, использованию и т.д.). Кроме того, столбец описания данных (сущность-связь-сущность) отличается от столбца описания процесса (вход-процесс-выход) и так далее. Поскольку каждый из элементов на любой оси явно отличается от других, можно точно определить, что принадлежит каждой ячейке, и, кроме того, каждая ячейка в матрице будет явно отличаться от всех остальных ячеек.
Architectural representations for describing data	Архитектурные представления для описания данных
To illustrate how each cell differs from all of the others, examine the data description column of Figure 2. Even though every cell in the column is descriptive type I relating to data, and the descriptive model is «entity-relationship-entity», the meanings of «entity» and «relationship» change with the different perspectives of the participants in the architecture process. The only exception is the scope description (ballpark) cell, in which entity is defined the same as entity in the model of the business cell. This ballpark perspective is merely a very high level of aggregation which is being used like the architect’s «bubble charts» to establish the gross size and scope of the data strategy, leading to the decision regarding investment of data processing resources in managing data.	Чтобы проиллюстрировать, чем каждая ячейка отличается от всех остальных, изучите столбец описания данных на Рисунке 2. Несмотря на то, что каждая ячейка в столбце относится к описательному типу I, относящемуся к данным, а описательная модель представляет собой «сущность-связь-сущность», значения «сущности» и «отношение» меняются с различными ви́деньями участников процесса архитектуры. Единственным исключением является ячейка описания области применения (приблизительно), в которой сущность определяется так же, как сущность в модели бизнес-ячейки. Это приблизительное ви́денье представляет собой просто очень высокий уровень агрегирования, который используется подобно «схем с кружками и стрелками» архитектора для определения общего размера и масштаба стратегии обработки данных, что приводит к принятию решения относительно инвестирования ресурсов обработки данных в управление данными.
Scope/description (ballpark perspective) – data column. The scope description cell in the data description column of Figure 2 could be expected to be a list of all the things that are important to the business, and therefore, that the business manages. [2]	Область применения / описание (приблизительное ви́денье) – столбец данных. Можно ожидать, что ячейка описания области применения в столбце описания данных на Рисунке 2 будет представлять собой список всех вещей, которые важны для бизнеса и, следовательно, которыми управляет бизнес. [2]
Table 5 [3] is an example of an architectural representation in the data description column from the scope description perspective.	Таблица 5 [3] представляет собой пример архитектурного представления в столбце описание данных с точки зрения описания области применения.

This representation would be a list of things (i.e., material – grammatically, nouns) as opposed to a list of actions (i.e., processes – grammatically, verbs). A list of actions (verbs) could be expected in the next column, process description. The list of things (material) in the data description column would be called «entities» in data vernacular.	Это представление было бы списком вещей (т.е. материалов – грамматически, существительных), в отличие от списка действий (т.е. процессов – грамматически, глаголов). Список действий (глаголов) можно было бы ожидать в следующем столбце, описание процесса. Список вещей (материалов) в столбце описания данных будет называться «сущностями» на языке данных.
Since this architectural representation is at the scope description row, one could also expect that the entities (things) would likely be entity «classes», that is, higher levels of aggregation, because the decision being made as a result of this representation would be one of scope, not one of design. A selection would be being made of the entity class or classes in which to invest actual information system (I/S) resources for data «inventory» management purposes.	Поскольку это архитектурное представление находится в строке описания области применения, можно также ожидать, что сущности (вещи), скорее всего, будут «классами» сущностей, то есть более высокими уровнями агрегации, поскольку решение, принимаемое в результате этого представления, будет зависеть от области применения, а не от проекта. Будет сделан выбор класса или классов объектов, в которые следует инвестировать фактические ресурсы информационной системы (I/S) для целей управления «инвентаризацией» данных.
Further, in this cell, one might not expect to be definitive about the relationship between entities. The scope decision would constitute overlaying the business values on the total range of possibilities to identify a subset of entity classes for implementation which is consistent with the resources available for investing in information systems—specifically, in this case, the management of the selected class (or classes) of data. Furthermore, it is useful to start with the total list of entities because, at times, the entities that are not selected are as significant as those that are selected.	Кроме того, в этой ячейке можно было бы не ожидать однозначности в отношении отношений между сущностями. Решение об области применения будет представлять собой наложение бизнес-ценностей на общий диапазон возможностей для определения подмножества классов сущностей для реализации, которое согласуется с ресурсами, доступными для инвестирования в информационные системы, в частности, в данном случае, для управления выбранным классом (или классами) данных. Кроме того, полезно начинать с общего списка объектов, потому что иногда объекты, которые не выбраны, столь же значимы, как и те, которые выбраны.
The strategy/resource investment decision is made by understanding the values/strategies of the business, which can be done by using various data-gathering/analytical techniques. The decision is made by overlaying the analytical conclusions on the total list of business entities in the scope description cell and thereby selecting the subset of business entities in which to actually invest data processing resources. Since this paper is intended to define architecture, not to describe strategy methodologies, nothing further will be said about strategic planning except to point out that similar kinds of decisions have to be made relative to every other scope description cell. That is, out of the total list of business processes, the business likely does not have enough data processing resources to automate all the processes. Therefore, a decision will have to be made to select a subset in which to invest data processing resources for actual automation. By the same token, out of the total list of locations in which the business operates, it probably does not have enough data processing resources to put hardware and software in every location. Again, decisions will have to be made in selecting a subset of locations in which to actually install hardware and software.	Решение об инвестициях в стратегию / ресурсы принимается на основе понимания ценностей / стратегий бизнеса, что может быть сделано с помощью различных методов сбора / анализа данных. Решение принимается путём наложения аналитических выводов на общий список бизнес-объектов в ячейке описания области применения и, таким образом, выбора подмножества бизнес-объектов, в которые фактически следует инвестировать ресурсы обработки данных. Поскольку этот документ предназначен для определения архитектуры, а не для описания стратегических методологий, больше ничего не будет сказано о стратегическом планировании, кроме как указать, что аналогичные решения должны приниматься относительно каждой другой ячейки описания области применения. То есть из общего списка бизнес-процессов у бизнеса, скорее всего, недостаточно ресурсов для обработки данных, чтобы автоматизировать все процессы. Следовательно, необходимо будет принять решение о выборе подмножества, в которое следует инвестировать ресурсы обработки данных для фактической автоматизации. По той же причине из общего списка местоположений, в которых работает бизнес, у него, вероятно, недостаточно ресурсов для обработки данных, чтобы разместить аппаратное и программное обеспечение в каждом местоположении. Опять же, необходимо будет принять решения при выборе подмножества местоположений, в которых фактически будет установлено оборудование и программное обеспечение.
These are the strategy/resource investment decisions that are supported by the scope description cells in the top row of Figure 2. Although they are inextricably related, the probability is that each decision will have to be addressed independently of the others. Discussion now continues on the framework, particularly the data description column of Figure 2.	Это решения об инвестициях в стратегию / ресурсы, которые поддерживаются ячейками описания области применения в верхнем ряду Рисунка 2. Хотя они неразрывно связаны, существует вероятность того, что каждое решение придётся принимать независимо от других. В настоящее время продолжается обсуждение структуры, в частности столбца описания данных на Рисунке 2.
Model of the business (owner’s perspective)—data description column. Since this model (or description) appears in the data description column, the descriptive model will be «entity-relationship-entity», and when owners (users) describe the business and say «entity», what they have in mind are business entities. [4]	Модель бизнеса (ви́денье владельца) – столбец описания данных. Поскольку эта модель (или описание) отображается в столбце описание данных, описательная модель будет «сущность-связь-сущность», и когда владельцы (пользователи) описывают бизнес и говорят «сущность», они имеют в виду бизнес-объекты. [4]
For example, when owners (users) specify an entity such as «employee», what they have in mind would be real beings, that is, flesh and blood employees who work for the business. That meaning of «employee» is entirely different from the one used in an information systems model (the designer’s perspective), in which «employee» would refer to a record on a machine, which also happens to be called «employee», however conceptually and entirely different it is. (This data entity, as opposed to business entity, would be found in the cell directly below.) Figure 3 is an example of a model of a business, oriented to data.	Например, когда владельцы (пользователи) указывают такую сущность, как «сотрудник», они имеют в виду реальных существ, то есть сотрудников из плоти и крови, которые работают на бизнес. Это значение «сотрудник» полностью отличается от того, которое используется в модели информационных систем (ви́денье проектировщика), в которой «сотрудник» будет относиться к записи на компьютере, которая также называется «сотрудник», как бы концептуально и совершенно иначе это ни было. (Этот объект данных, в отличие от бизнес-объекта, будет найден в ячейке непосредственно ниже.) На Рисунке 3 приведён пример модели бизнеса, ориентированного на данные.

Further, when owners, describing a business, specify a relationship between the entities, what they have in mind would be the business rule or strategy that relates one entity to another entity. [5] A business rule or strategy, for example, might be «in this business we ship this product from that warehouse only». An entirely different rule would be «in this business, we ship this product from any warehouse we have». These are business rules and not data relationships such as would be expected in the model of the information system (designer’s perspective) in the cell below the Model of the Business shown in Figure 2.	Кроме того, когда владельцы, описывая бизнес, указывают взаимосвязь между сущностями, они имеют в виду бизнес-правило или стратегию, которые связывают одну сущность с другой сущностью. [5] Бизнес-правило или стратегия, например, могут быть такими: «в этом бизнесе мы отправляем этот продукт только с этого склада». Совершенно другим правилом было бы «в этом бизнесе, мы отправляем этот товар с любого склада, который у нас есть». Это бизнес-правила, а не отношения между данными, которые можно было бы ожидать в модели информационной системы (ви́денье проектировщика) в ячейке под Моделью бизнеса, показанной на Рисунке 2.
Finding good «real-life» examples which crisply illustrate each of the architectural representations is difficult. There are two reasons for this difficulty. First, when the real-life representations were being developed, no framework existed to clearly define and differentiate one representation from the others. Therefore, many real-life illustrations are a mixture of representations, both conceptually (e.g., business entities and data entities get mixed together) and physically (e.g., entities and inputs/outputs, that is, user views from the process description column of Figure 2, get mixed together). Second, real-life examples are hard to understand because it is not always clear what model, or cell, the author had in mind when developing the representation.	Трудно найти хорошие «реальные» примеры, которые чётко иллюстрируют каждое из архитектурных представлений. У этой трудности есть две причины. Во-первых, когда разрабатывались реальные представления, не существовало никаких рамок для чёткого определения и дифференциации одного представления от других. Поэтому многие реальные иллюстрации представляют собой смесь представлений, как концептуально (например, бизнес-объекты и объекты данных смешиваются вместе), так и физически (например, объекты и входные / выходные данные, то есть представления пользователей из столбца описания процесса на Рисунке 2, смешиваются вместе). Во-вторых, примеры из реальной жизни трудно понять, потому что не всегда ясно, какую модель или ячейку имел в виду автор при разработке представления.
An illustration of this difficulty is found in Figure 3. It is clear that this model is describing data and not process, but the question is, did the author have in mind a description of a business or a description of an information system! In this case, it is likely that the description is of a business because of the existence of the «many-to-many» relationships. In real life, there are many «many-to-many» relationships, but the database management concepts that are popular today require that the «many-to-many» relationships be resolved in order to run on a machine. Therefore, «artificial» entities have to be created to resolve the «many-to-many» relationships, and the model in Figure 3 would have to be «normalized» before it could be a legitimate model of an information system. In any case, since the model in Figure 3 is not «normalized», by today’s standards at least, it is clearly a model of a business as opposed to a model of an information system.	Иллюстрация этой трудности приведена на Рисунке 3. Понятно, что эта модель описывает данные, а не процесс, но вопрос в том, имел ли автор в виду описание бизнеса или описание информационной системы! В этом случае, вероятно, описание относится к бизнесу из-за существования отношений «многие ко многим». В реальной жизни существует множество отношений «многие ко многим», но популярные сегодня концепции управления базами данных требуют, чтобы отношения «многие ко многим» были разрешены для запуска на компьютере. Следовательно, для разрешения отношений «многие ко многим» должны быть созданы «искусственные» сущности, и модель на Рисунке 3 должна быть «нормализована», прежде чем она сможет стать законной моделью информационной системы. В любом случае, поскольку модель на Рисунке 3 не является «нормализованной», по крайней мере, по сегодняшним стандартам, это явно модель бизнеса, а не модель информационной системы.
Model of an information system (designer’s perspective) – data description column. Once again, since the model of the information system is in the data description column of the framework, the descriptive model used is «entity-relationship-entity». But from the designer’s perspective, the meaning of «entity» would change to that of a record on a machine, and relationship would change to that of a data relationship. Clearly, the example in Figure 4 is a model of an information system and not a model of a business, because of the existence of «artificial» entities, specifically the «deptproj» entity (resulting from the concatenation of department and project), which is not a real-life item, but something in an information system, created in the process of translating the business description into an information systems «product». In the data design vernacular, this example of Figure 4 would likely be called a data model. [6], [7]	Модель информационной системы (ви́денье проектировщика) – столбец описания данных. Ещё раз, поскольку модель информационной системы находится в столбце описания данных фреймворка, используемая описательная модель – «сущность-связь-сущность». Но в ви́деньи проектировщика значение «сущности» изменилось бы на значение записи на компьютере, а отношение изменилось бы на отношение к данным. Очевидно, что пример на Рисунке 4 представляет собой модель информационной системы, а не модель бизнеса, из-за существования «искусственных» объектов, в частности объекта «deptproj» (являющегося результатом объединения department и project), который является не реальным элементом, а чем-то в информационной системе, созданной в процессе перевода бизнес-описания в «продукт» информационной системы. На языке проектирования данных этот пример на Рисунке 4, скорее всего, будет называться моделью данных. [6], [7]

Technology model (builder’s perspective) – data description column. As in the previously described cells, the descriptive model in the builder’s cell is «entity-relationship-entity», and what could be expected is the physical implementation or data design for the conceptual model of the information system.

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

In the technology model, the laws of nature and technology constraints are being applied. A decision is made to use Information Management System (IMS) or IBM Database 2 (DB2) or XYZ, and depending on the choice, the meaning of entity and relationship change. In the case of IMS, entity means «segment» and relationship means «pointer». In the case of DB2, entity means «row» and relationship means «key», etc. [5] Figure 5 is an example of an architectural representation of the technology model (builder’s perspective) in the data description column of the framework.

В технологической модели применяются законы природы и технологические ограничения. Принимается решение использовать Систему управления информацией (IMS) или IBM Database 2 (DB2) или XYZ, и в зависимости от выбора значение сущности и отношения меняются. В случае IMS сущность означает «сегмент», а отношение означает «указатель». В случае DB2 сущность означает «строка», а связь означает «ключ» и т.д. [5] На Рисунке 5 приведён пример архитектурного представления технологической модели (ви́денье разработчика) в столбце описания данных фреймворка.

Detailed description (out-of-context perspective) – data description column. The descriptive model is «entity-relationship-entity» in the detailed description cell. This cell is analogous to the subcontractors’ out-of-context descriptions. What could be expected is Data Definition Language. An example might be a DBDGEN in which the entities are specifications of the «fields», and relationships are specifications of the «addresses». [5] An example is shown in Figure 6.

Подробное описание (вне контекстная перспектива) – столбец описания данных. Описательная модель – это «сущность-связь-сущность» в ячейке подробного описания. Эта ячейка аналогична описаниям субподрядчиков вне контекста. Чего можно было бы ожидать, так это языка определения данных. Примером может быть DBDGEN, в котором сущности являются спецификациями «полей», а отношения – спецификациями «адресов». [5] Пример показан на Рисунке 6.

This description is «compiled» to produce the machine language representation (relative addressing— not shown in the figure), which is further «link-edited» to produce the actual physical data (absolute addressing) residing in the machine.	Это описание «компилируется» для получения представления на машинном языке (относительная адресация — не показана на рисунке), которое далее «редактируется по ссылке» для получения фактических физических данных (абсолютная адресация), находящихся в машине.
It is clear that real-life examples can be found to illustrate all of the architectural representations for the various viewpoints or perspectives that are created for the data (or material) description of the information system.	Очевидно, что можно найти примеры из реальной жизни, иллюстрирующие все архитектурные представления для различных точек зрения или ви́дений, которые создаются для описания данных (или материалов) информационной системы.
Real-life examples can be found to illustrate all of the architectural representations.	Можно найти примеры из реальной жизни, иллюстрирующие все архитектурные представления.
Although actual samples (figures) for each of the remaining cells are available, no attempt will be made to include them in this paper. Let it be sufficient merely to describe how the meanings of the descriptive model terms change in the remaining two columns as the representations shift from perspective to perspective.	Хотя фактические образцы (рисунки) для каждой из оставшихся ячеек доступны, не будет предпринято никаких попыток включить их в эту статью. Пусть будет достаточно просто описать, как меняются значения терминов описательной модели в оставшихся двух столбцах по мере того, как представления переходят от ви́денья к ви́денью.
Architectural representations for describing the process	Архитектурные представления для описания процесса
The descriptive model for describing the process is «input-process-output», and, as in the case of the data description column, each of the representations in the different cells in the process description column of Figure 2 have different meanings associated with «input», «process», and «output».	Описательной моделью для описания процесса является «вход-процесс-выход», и, как и в случае столбца описания данных, каждое из представлений в разных ячейках столбца описания процесса на Рисунке 2 имеет разные значения, связанные с «входом», «процессом» и «выходом».
At the scope description (ballpark perspective) cell, «process» would mean business process. It would likely be some process «class», a relatively high level of aggregation, as the decision being made from the scope description cell is the selection of some subset of the appropriate business processes in which to invest some finite amount of information systems resources for actual automation purposes. Further, in making the scope decision, it is unnecessary to be definitive about the input and output linkages between the functions by overlaying the business values against the total range of automation possibilities. Therefore, just a list of business processes would appropriately be expected in this cell representation.	В ячейке описания области применения (приблизительное ви́денье) «процесс» будет означать бизнес-процесс. Вероятно, это будет некоторый «класс» процесса, относительно высокий уровень агрегирования, поскольку решение, принимаемое из ячейки описания области применения, заключается в выборе некоторого подмножества соответствующих бизнес-процессов, в которые следует инвестировать некоторое конечное количество ресурсов информационных систем для фактических целей автоматизации. Кроме того, при принятии решения о области применения нет необходимости быть точным в отношении входных и выходных связей между функциями, накладывая бизнес-ценности на общий диапазон возможностей автоматизации. Следовательно, в этом представлении ячейки уместно было бы ожидать только список бизнес-процессов.
In the model of the business (owner’s perspective) in the process description column, an example might be a functional flow diagram [8], [9] in which «process» would be a business process (not an information systems process) and inputs and outputs would be business resources such as people, cash, material, product, etc.	В модели бизнеса (ви́денье владельца) в столбце описание процесса примером может быть функциональная блок-схема [8], [9], в которой «процесс» будет бизнес-процессом (а не процессом информационных систем), а входными и выходными данными будут бизнес-ресурсы, такие как люди, денежные средства, материалы, продукт и т.д.
In the model of the information system (designer’s perspective) for the process description column, an example would be a data flow diagram [8] – [10] in which processes are information systems (application) processes (not business processes) and the inputs/ outputs are «user views» – some aggregations of data elements that flow into and out of the application processes, connecting them in some sequential fashion. (Note that this does not preclude depicting manual functions that are introduced as part of the information system.)	В модели информационной системы (ви́денье проектировщика) для столбца описания процесса примером может служить диаграмма потока данных [8] – [10], в которой процессы являются процессами информационных систем (приложений) (а не бизнес – процессами), а входы / выходы являются «представлениями пользователя» – некоторые агрегации элементов данных, которые поступают в прикладные процессы и выходят из них, соединяя их некоторым последовательным образом. (Обратите внимание, что это не исключает отображения ручных функций, которые вводятся как часть информационной системы.)
Proceeding to the technology model (builder’s perspective) – process description column, we see that the meaning of «input-process-output» changes once again. In applying the physical constraints of the technology chosen for implementation, for example, IBM 3380 Direct Access Storage Devices versus IBM 3480 Magnetic Tape Subsystems (disks), IMS versus Customer Information Control System (CICS), cobol versus fortran; IBM 3270 terminal devices (video displays) versus IBM Personal Computers, etc., the builder’s perception of a process becomes a computer function, and inputs and outputs are device formats. The predictable example would be a structure chart [10], [11] and screen/device formats.	Разбирая технологическую модель (ви́денье разработчика) – описание процесса, мы видим, что значение «вход-процесс-выход» снова меняется. При применении физических ограничений технологии, выбранной для реализации, например, Устройства хранения данных IBM 3380 с прямым доступом по сравнению с подсистемами (дисками) IBM 3480 с магнитной лентой, IMS по сравнению с Системой управления информацией о клиентах (CICS), cobol по сравнению с fortran; терминальные устройства IBM 3270 (видеодисплеи) по сравнению с персональными компьютерами IBM и т.д. Восприятие процесса разработчиком становится компьютерной функцией, а входные и выходные данные – форматами устройств. Ожидаемым примером может быть структурная диаграмма [10], [11] и форматы экрана / устройства.
For the detailed description (out-of-context) cell, the example is a «program» in which «process» is a language statement and the inputs and outputs are control blocks. [11], [12]	Для ячейки подробного описания (вне контекста) примером является «программа», в которой «процесс» является оператором языка, а входы и выходы являются блоками управления. [11], [12]
The program is compiled to produce object code, the machine language representation (not shown in Figure 2) which, in turn, is assembled to produce running instructions for the actual, physical system.	Программа компилируется для создания объектного кода, представления на машинном языке (не показано на Рисунке 2), который, в свою очередь, собирается для создания инструкций выполнения для реальной физической системы.
Again, it is clear that examples can be found for every descriptive representation for the process description column, as well as for the data description column.	Опять же, ясно, что примеры можно найти для каждого описательного представления для столбца описания процесса, а также для столбца описания данных.
Architectural representation describing the network	Архитектурное представление, описывающее сеть
The descriptive model for the network set of architectural representations in the network description column of Figure 2 is «node-line-node».	Описательной моделью для набора архитектурных представлений сети в столбце описания сети на Рисунке 2 является «узел-линия-узел”.
From the scope description (ballpark) perspective, what could be expected is a list of locations in which the business operates. Therefore, «node» would mean business location, likely at a high level of aggregation, that is, showing little detail about the «contents» of the location. The locations might even be arranged on a map, a geographical construct. If lines were shown, they would probably merely indicate where there are communications or logistics connections between the locations. The purpose served, once again, is the strategy/resource investment decision in which the main decision is to select the subset of locations in which to actually locate technology (hardware/software).	С точки зрения описания области применения (приблизительного), чего можно было бы ожидать, так это списка местоположений, в которых работает бизнес. Следовательно, «узел» будет означать местоположение предприятия, вероятно, на высоком уровне агрегации, то есть с небольшим количеством подробностей о «содержимом» местоположения. Местоположения могут быть даже расположены на карте, географической конструкции. Если бы были показаны линии, они, вероятно, просто указывали бы, где есть коммуникации или логистические соединения между местоположениями. Цель, которой служит, опять же, – это решение об инвестициях в стратегию / ресурсы, в котором основное решение заключается в выборе подмножества местоположений, в которых фактически будет размещаться технология (оборудование / программное обеспечение).
The owner, in describing the business, that is, producing the model of the business as related to the network (or the connectivity characteristics of the business), would perceive the «nodes» to be business units, an aggregation of business resources (people, facilities, responsibilities, etc.) at some geographical location. The lines would represent logistics connections or flows, probably including communications linkages, but even more basically would represent the distribution structure or logistics network along which communications take place.	Владелец, описывая бизнес, то есть создавая модель бизнеса, связанную с сетью (или характеристиками подключения бизнеса), будет воспринимать «узлы» как бизнес-единицы, совокупность бизнес-ресурсов (людей, объектов, обязанностей и т.д.) на некотором уровне. географическое положение. Линии будут представлять логистические соединения или потоки, возможно, включая коммуникационные связи, но ещё более существенно будут представлять структуру распределения или логистическую сеть, по которой осуществляется связь.
In the model of the information system (the designer’s perspective) for the network description, the information system designer would perceive the node to be some i/s function, like a processor, storage unit, or access point. This would be a conceptual representation, independent of specific technology which would be introduced in the builder’s cell. The line, from a designer’s standpoint, would be a communication line at the conceptual level, such as a leased line, dial-up service, U.S. mail, etc. This cell would serve the purpose of making the «distributed systems» decisions, that is, specifying where the i/s facilities would be installed, which of them would be connected, and by what type of connection.	В модели информационной системы (ви́денье проектировщика) для описания сети проектировщик информационной системы будет воспринимать узел как некоторую функцию ввода-вывода, такую как процессор, блок хранения или точка доступа. Это было бы концептуальное представление, независимое от конкретной технологии, которая была бы введена в ячейку разработчика. Линия, с точки зрения проектировщика, была бы линией связи на концептуальном уровне, такой как выделенная линия, коммутируемая служба, почта США и т.д. Эта ячейка будет служить цели принятия решений о «распределённых системах», то есть определения того, где будут установлены средства ввода-вывода, какие из них будут подключены и с помощью какого типа соединения.
Technology constraints would be introduced in the technology model.	Технологические ограничения будут введены в технологическую модель.
The technology constraints would be introduced in the technology model (the builder’s perspective). This cell would depict physical hardware and software, for example, an IBM 3090 processor, 3270 display device, Personal Computer, Multiple Virtual Storage (MVS) operating system, Advanced Communications Function/Network Control Program (ACF/NCP), etc. at the nodes and Synchronous Data Link Control (SDLC), bisynchronous communications, 4800 baud, etc. for the lines.	Технологические ограничения будут введены в технологическую модель (ви́денье разработчика). Эта ячейка будет отображать физическое аппаратное и программное обеспечение, например, процессор IBM 3090, устройство отображения 3270, Персональный компьютер, операционную систему с несколькими виртуальными хранилищами (MVS), Расширенную функцию связи / Программу управления сетью (ACF/NCP) и т.д. на узлах и Управление синхронным каналом передачи данных (SDLC), бисинхронная связь, 4800 бод и т.д. для линий.
In the detailed description (out-of-context) cell, the nodes would be addresses, and the lines would be protocols. [13]	В ячейке с подробным описанием (вне контекста) узлы будут адресами, а строки – протоколами. [13]
In summary, although actual pictures have not been included in the paper, examples could be presented to illustrate every hypothetical architectural representation postulated by the relationship among the various architectural perspectives and the different types of descriptions.	Таким образом, хотя фактические рисунки не были включены в статью, можно было бы привести примеры, иллюстрирующие каждое гипотетическое архитектурное представление, постулируемое взаимосвязью между различными архитектурными ви́деньями и различными типами описаний.

Conclusions	Выводы
When the question is asked, «What is information systems architecture?» the answer is, «There is not an information systems architecture, but a set of them!» Architecture is relative. What you think architecture is depends on what you are doing. For an example, see Table 6.	Когда задаётся вопрос: «Что такое архитектура информационных систем?» ответ таков: «Существует не архитектура информационных систем, а их набор!» Архитектура относительна. То, что вы считаете архитектурой, зависит от того, что вы делаете. Пример приведён в таблице 6.
We are having difficulties communicating with one another about information systems architecture, because a set of architectural representations exists, instead of a single architecture. One is not right and another wrong. The architectures are different. They are additive and complementary. There are reasons for electing to expend the resources for developing each architectural representation. And there are risks associated with not developing any one of the architectural representations.	У нас возникают трудности в общении друг с другом по поводу архитектуры информационных систем, потому что вместо единой архитектуры существует набор архитектурных представлений. Одно неправильно, а другое неверно. Архитектуры разные. Они являются аддитивными и взаимодополняющими. Есть причины для того, чтобы потратить ресурсы на разработку каждого архитектурного представления. И существуют риски, связанные с отказом от разработки какого-либо одного из архитектурных представлений.
Research is being done to create more explicit definitions for each of the architectural representations in this framework, to understand the design issues, the reasons for developing each representation, the risks associated with not developing any one, and the «tool» implications of each cell.	Проводятся исследования для создания более чётких определений для каждого из архитектурных представлений в этой структуре, чтобы понять проблемы проектирования, причины разработки каждого представления, риски, связанные с отказом от разработки какого-либо из них, и «инструментальные» последствия каждой ячейки.
Summary	Резюме
In summary, by studying fields of endeavor external to the information systems community, specifically those professions involved in producing complex engineering products (e.g., architecture/construction, manufacturing, etc.), it is possible to hypothesize by analogy a set of architectural representations for information systems.	Таким образом, изучая области деятельности, внешние по отношению к сообществу информационных систем, в частности те профессии, которые связаны с производством сложных инженерных продуктов (например, архитектура / строительство, производство и т.д.), можно по аналогии выдвинуть гипотезу о наборе архитектурных представлений для информационных систем.
The resultant «framework for information systems architecture» could prove quite valuable for: Improving professional communications within the information systems community.Understanding the reasons for and risks of not developing any one architectural representation.Placing a wide variety of tools and/or methodologies in relation to one another.Developing improved approaches (including methodologies and tools) to produce each of the architectural representations, as well as possibly rethinking the nature of the classic «application development process» as we know it today.	Полученная в результате «структура архитектуры информационных систем» может оказаться весьма ценной для: • Улучшение профессиональных коммуникаций в сообществе информационных систем. • Понимание причин и рисков отказа от разработки какого-либо одного архитектурного представления. • Размещение широкого спектра инструментов и/или методологий по отношению друг к другу. • Разработка улучшенных подходов (включая методологии и инструменты) для создания каждого из архитектурных представлений, а также, возможно, переосмысление природы классического «процесса разработки приложений», каким мы его знаем сегодня.
Cited references
1. G. D. Larson, private communication, Gaede and Larson, Architects International Association, Pasadena, CA (1985). 2. Business Systems Planning—Information Systems Planning Guide, Application Manual GE20-0627, IBM Corporation; available through IBM branch offices. 3. Business Systems Planning, class material, IBM Corporation, Information Systems Management Institute, Los Angeles, CA. 4. D. S. Appleton, «Business rules: The missing link», Datamation 30, No. 16, 145-150 (October 15, 1984). 5. C. J. Date, An Introduction to Database Systems, Addison-Wesley Publishing Co., Reading, MA (1981). 6. ICAM Architecture Part ll, Volume V—Information Modeling Manual, (IDEF1) AFWAL-TR-81-4023, Air Force Wright Aeronautical Labs, Air Force Systems Command, Wright-Patterson Air Force Base, OH 45433 (June 1981). 7. P. P. Chen, Entity-Relationship Approach to Systems Analysis and Design, University of California at Los Angeles, Los Angeles, CA (December 1979).
8. T. DeMarco, Structured Analyses and System Specifications, Yourdon Press, Inc., New York (1978). 9. S. M. McMenamin and J. F. Palmer, Essential Systems Analysis, Yourdon Press, Inc., New York (1984). 10. HIPO—A Design Aid and Documentation Technique, GC20-1851, IBM Corporation; available through IBM branch offices. 11. J. K. Hughes and J. I. Michtom, A Structural Approach to Programming, Prentice-Hall, Inc., Englewood Cliffs, NJ (1977). 12. H. D. Leeds and G. M. Weinberg, Computer Programming Fundamentals, McGraw-Hill Book Co., Inc., New York (1961). 13. Systems Network Architecture—Technical Overview, Systems Manual GC3O-3O73, IBM Corporation; available through IBM branch offices.
John A. Zachman IBM South-West Marketing Division, Western Area, P.O. Box 60737, Los Angeles, California 90060. Currently the Business Systems Planning consultant for IBM’s Western Area, Mr. Zachman joined IBM in 1965 and has held various marketing-related positions in Chicago, New York, and Los Angeles, including one as National Account Manager for a major U.S. oil company. He has been involved with Strategic Information Systems Planning methodologies since 1970 and came to his present position in 1973. He travels worldwide, speaking and consulting on information systems planning, and has written a number of articles on the subject. His current responsibilities include working both internally with IBM and externally with IBM customers in addressing planning approaches to support management with information systems. Mr. Zachman holds a degree in chemistry from Northwestern University. Prior to joining IBM, he served for a number of years as a Line Officer in the U.S. Navy and is a retired Commander in the U.S. Naval Reserve.

Недостающие 3 столбца, которые были рассмотрены позднее в статье 1992 г.