Skip to main content

3. ЩО ТАКЕ КОРПОРАТИВНА АРХІТЕКТУРА?

Переклад​

3.1 Опис​

3.1.1 Корпоративна архітектура (Enterprise Architecture, EA) є способом формалізації питань (занепокоєнь, інтересу) зацікавлених сторін і подання їх у контексті підприємства.

Наприклад, EA може охоплювати як бізнесові, так і технічні концепції з метою підкреслення залежностей між ними. Такий підхід дає змогу здійснювати зміни з чіткішим розумінням точок дотику та проблемних зон. EA застосовує цілісний підхід для управління проблемами, пов'язаним з системою інтересу, з метою відображення взаємодії технологій і бізнес-процесів.

3.1.2 Призначенням EA є оптимізація в масштабах усього підприємства часто фрагментованої спадкової сукупності процесів (як ручних, так і автоматизованих) та систем шляхом їх інтеграції в єдине середовище, здатне реагувати на зміни та підтримувати реалізацію бізнес-стратегії. Призначенням EA не є моделювання всього підприємства.

3.1.3 EA має охоплювати процес визначення архітектури, як це описано в стандарті ISO/IEC/IEEE 15288-2015.

«Призначенням процесу визначення архітектури є формування альтернатив архітектури системи, вибір однієї або кількох альтернатив, що відображають питання зацікавлених сторін і відповідають вимогам до системи, а також подання цього у вигляді набору узгоджених подань.

Ітеративне застосування процесу визначення архітектури разом із процесами бізнес- або місійного аналізу, визначення вимог до системи, визначення проєктних рішень, а також визначення потреб і вимог зацікавлених сторін часто використовується з метою досягнення узгодженого розуміння проблеми, яку необхідно розв'язати, та ідентифікації задовільного рішення. Результати процесу визначення архітектури широко використовуються в процесах життєвого циклу. Визначення архітектури може застосовуватися на багатьох рівнях абстракції з акцентуванням відповідного рівня деталізації, необхідного для прийняття рішень на цьому рівні».

Примітки перекладача​

Загальна ідея​

Корпоративна архітектура це не схема ІТ-систем, це також не модель усього підприємства (це надскладна задача), а інженерний спосіб мислення і формалізації проблем, у якому фіксуються питання та інтереси зацікавлених сторін, показуються зв'язки між бізнесом і технологіями, створюється узгоджене підґрунтя для прийняття рішень про зміни.

Архітектор створюючи EA працює з підприємством через призму контексту, задачі, інтересів.

Фокус на запиті від зацікавлених сторін​

Архітектор не має занурюватись у системи та технологій. Він має починати свою робот з аналізу питань, проблем і очікувань зацікавлених сторін, працювати з викликами, занепокоєннями, глибоко розуміти сфери інтересів, працювати з ризиками та вимогами. Це підкреслює зв'язок бізнесу і технології.

Розуміння stakeholder concern​

В контексті Enterprise Architecture (EA), переклад "stakeholders concerns" має специфічне та фундаментальне значення. Найкращий варіант - Занепокоєння зацікавлених сторін.

Щодо терміну "concern" — це будь-який інтерес до системи, який є критичним для стейкхолдера (наприклад, безпека, продуктивність, вартість або масштабованість).

В щирокому сенсі Concern : занепокоєння, питання сфери інтересів, питання, ризик або вимога, що є важливими для стейкхолдера.

Також може бути опція коли підкреслюється важливість - Критичні питання / Ключові аспекти - наприклад в контексті прийняття архітектурних рішень, тобто це те, що архітектор має "адресувати" (address) у своєму проєкті.

Приклади:

  • Addressing stakeholder concerns: Усунення занепокоєнь зацікавлених сторін - шляхом створення відповідних архітектурних діаграм).
  • Concerns of the CFO: Питання, що хвилюють фінансового директора.
  • Cross-cutting concerns: Наскрізні аспекти/занепокоєння - питання, що стосуються всієї архітектури одночасно, наприклад, безпека чи журналювання.

Оригінальний текст​

3 WHAT IS AN ENTERPRISE ARCHITECTURE?

3.1 Description

3.1.1 An Enterprise Architecture (EA) is a way of formalizing stakeholder concerns and presenting them in the context of the enterprise.

For example EA can encompass both business and technical concepts to emphasize the dependencies between them. This approach enables change to proceed with a clearer understanding of the touch-points and problem areas. EA takes a holistic approach in order to manage problems associated with the system-of-interest to show the interaction of technology and business processes.

3.1.2 The purpose of EA is to optimize across the enterprise, the often fragmented legacy of processes (both manual and automated) and systems, into an integrated environment that is responsive to change and supports the delivery of the business strategy. The purpose of EA is not to model the entire enterprise.

3.1.3 An EA should encompass the architecture definition process as described by ISO/IEC/IEEE 15288-2015.

“The purpose of the Architecture Definition process is to generate system architecture alternatives, to select one or more alternative(s) that frame stakeholder concerns and meet system requirements, and to express this in a set of consistent views.

Iteration of the Architecture Definition process with the Business or Mission Analysis process, System Requirements Definition process, Design Definition process, and Stakeholder Needs and Requirements Definition process is often employed so that there is a negotiated understanding of the problem to be solved and a satisfactory solution is identified. The results of the Architecture Definition process are widely used across the life cycle processes. Architecture definition may be applied at many levels of abstraction, highlighting the relevant detail that is necessary for the decisions at that level.”