Як стандарт TOGAF обслуговує архітектуру підприємства

1. Ключові винесення TOGAF замінює необхідність органічно розвивати власну практику архітектури підприємства....
2. TOGAF Summary
3. Застосування стандарту
4. Адаптація до інших структур і методів
5. Приклад 1: Адаптація TOGAF до гнучкої методології
6. Приклад 2: Адаптація TOGAF до Рамки Захмана
7. Висновок
8. Про автора

Ключові винесення

• TOGAF замінює необхідність органічно розвивати власну практику архітектури підприємства. Ознайомлення зі стандартом замінює необхідність винаходити процеси, практики, структури та принципи ЕО.
• Для розуміння TOGAF всебічності процесу, змісту, керівних принципів, ролей, структур - вивчіть основні сім частин стандарту.
• Використовуйте методики TOGAF, щоб застосувати їх у своїй організації. Якщо необхідно, використовуйте методи адаптації, щоб вона співіснувала з іншими структурами.
• Відстежуйте свій успіх, оцінюючи досягнення у Вашій поставленій архітектурі.
• Поділіться перевагами прийняття стандартизованих рамок EA (наприклад, стандарту TOGAF) з іншими. Заохочуйте свою організацію не винаходити колесо, якщо він виявиться, створюючи звичайну практику EA.

Спроба документувати всю складність великих корпоративних систем може бути надзвичайною і важко знати, з чого почати. Крім того, розробка архітектур підприємства, що відповідають стратегіям бізнесу, але все ще мають хороші архітектурні якості, може бути складним завданням. Керівництво та структура, надані TOGAF, можуть допомогти. Це перевірена і перевірена основа, яка надає рекомендації з багатьох аспектів архітектури підприємства. Тут я хотів би поділитися з вами перевагами TOGAF, як розпочати і додатково поєднати їх з іншими методологіями.

Нещодавно я вирішив виконати сертифікацію TOGAF 9 з різними намірами. Після тривалого навчання і підготовки я склав іспит на дві частини. Але після завершення іспиту я закінчила, повернувшись до всеосяжності загального стандарту TOGAF, більш ніж очікувалося.

Щоб продемонструвати значення стандарту TOGAF, я спочатку надаю короткий опис стандарту. Потім я окреслю його внесок у архітектуру підприємства, нададуть рекомендації щодо його застосування у вашій організації та пояснить, як адаптувати його до інших методологій. Оскільки стандарт складається з семи детальних деталей, лише деякі з них будуть виділені для Вашої користі. Рекомендується переглянути повний стандарт для кращого розуміння. Цей підсумок заохочуватиме вас прийняти зрілий, глибокий стандарт, а не органічно вирощувати свій власний.

Щоб забезпечити контекст, за останні вісім років після 17-річної кар'єри в галузі техніки я більше зосереджувався на архітектурі програмного забезпечення, систем і рішень. До цього моменту я створив 36 проектів архітектури в межах областей застосування, інтеграції, хмари, інтерфейсу, мобільного і конвеєрного каналів. З них 25 були впроваджені і в даний час використовуються або в виробничому середовищі. Хоча я все ще виробляю різні типи технологічної архітектури, моя робота поступово перейшла на архітектуру підприємства.

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

У цій організації структура та діяльність комітету з огляду архітектури зростають і розвиваються протягом короткого періоду з моменту створення ради. Зі збільшенням участі в процесах, заходах та заходах архітектури підприємства я хотів формалізувати свій досвід роботи зі стандартом архітектури підприємства, який був визнаний галуззю. Моя мета отримання сертифікації TOGAF полягала у вивченні всебічної методології архітектури підприємства. Я хотів побудувати на своєму досвіді в цій галузі, вивчивши нову дисципліну. По-друге, я тепер сподіваюся заохочувати організації до створення та виконання комплексної практики архітектури підприємства.

Значення архітектури підприємства

Так чому ж важливим є стандарт TOGAF? А ще краще, чому архітектура підприємства (EA) важлива? Компанії процвітають від змін, щоб доставити нові продукти та послуги, щоб заробити дохід і залишатися актуальними. Але впродовж усього життя бізнесу створюються нові системи, злиття вимагають системної інтеграції або консолідації, нові технології приймаються для конкурентної переваги, і більше систем потребує інтеграції для обміну інформацією. Чітко визначена і керована практика ЕО є критично важливою на організаційному рівні, щоб протистояти, обробляти та керувати цими технологічними та обчислювальними складнощами. Без практики ЕО може існувати розрив між системами, неузгодженість рішень, невідповідність між продуктами та інженерними групами, дублювання інженерних зусиль та розмивання архітектури та якості рішення організації.

Дозвольте нам скористатися компанією для запуску продуктів як приклад. Цей стартап може зазнати зростаючого зростання, швидко просуваючись від народжуваного до виникнення. Бізнес та технології відчувають швидкі зміни. Без практики ЕО або, принаймні, деякого рівня керівництва архітектурою, запуск може швидко знайти свої системи в невідповідності і не може обмінюватися інформацією. Чим швидше зростання компанії, тим більшою є загроза.

Іншим класичним прикладом, що демонструє необхідність проведення EA, є злиття або придбання. Коли дві компанії об'єднуються, надлишкові системи повинні будуть обмінюватися інформацією або, можливо, буде потрібна консолідація. Наприклад, для співробітників можуть існувати декілька систем HR, які потребують інтегрування або об'єднання в один. Неправильна інтеграція призведе до неможливості обміну даними співробітників, помилок програмного забезпечення, нерозуміння, надмірної комунікації та додаткових ручних процесів для досягнення належної безперервності бізнесу з додатковими системами. Крім того, вам може знадобитися об'єднати або перетворити рамки EA на одну модель, таку як TOGAF.

Підсумовуючи, використання стандартів зрілої архітектури підприємства, таких як TOGAF, забезпечує більш ефективні та ефективні ІТ-операції. Вона пропонує кращу рентабельність інвестицій, зменшений ризик для майбутніх надлишкових витрат і швидше / дешевше закупівель. Всі ці переваги підтримують більш ефективні бізнес-операції.

TOGAF Summary

Архітектура Open Group Framework, або TOGAF Для короткого викладу - це стандарт корпоративного архітектури, створений Відкрита група організації. Стандарт - це методологія, яка включає в себе набір процесів, принципів, керівних принципів, найкращих практик, методів, ролей і артефактів. Він використовується для розробки та управління архітектурами підприємств для адекватного вирішення потреб бізнесу. Визначено чітке визначення в сертифікат навчального посібника :

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

Для досягнення цієї мети високого рівня, стандарт пропонує встановити декілька тактичних елементів, що підкріплюють це. Ці елементи включають наступні - керівні принципи, комплексний метод розробки архітектури (ADM), континуум живої архітектури, живий артефакт, сховище управління, структуру можливостей і бібліотеку еталонних моделей. Як ви можете бачити, деякі з цих аспектів є структурами, такими як континуум і сховище. Але інші аспекти - це процеси, такі як ітеративний метод розробки архітектури ADM.

Щоб краще зрозуміти компоненти рамки, нижче наведено структуру стандарту.

Частина 1: Вступ

• Визначає загальні терміни в контексті стандарту TOGAF. Приклади включають визначення структури підприємства, архітектури підприємства та архітектури.
• Надає огляд основних концепцій. Приклади включають ADM, типи виводу, континууми, сховища, можливості та використання TOGAF з іншими рамками архітектури.

Частина 2: Метод розробки архітектури (ADM)

(1) Розділ 5.2.2, стандарт TOGAF 9.1

• Фази включають визначені види діяльності / процеси, очікувані вклади та виходи.

• Фази можуть бути пристосовані до потреб організації. Вони можуть повторюватися як повний цикл, сусідньо або внутрішньо, як необхідно.

3 Частина 3: Керівництво та методи ADM

▪ Керівні принципи надають альтернативи для адаптації процесу ADM для вирішення різних сценаріїв використання. Наприклад, як застосувати параметри ітерації до ADM.

▪ Методика - це специфічна тактика підтримки завдань у циклі ADM. Приклади включають визначення та застосування принципів архітектури, використання структури архітектури, визначення бізнес-сценаріїв та виконання аналізу розривів.

4 Частина 4: Архівна структура контенту

• Визначає метамодель, що класифікує виходи з архітектурних зусиль. Приклади включають результати, артефакти та будівельні блоки.
• Розмежує результати, артефакти та багаторазові будівельні блоки. Надає конкретні приклади вмісту кожного.

5 Частина 5: Континуум підприємства та інструменти

• Забезпечує метод класифікації архітектури та активів рішення для забезпечення узгодженості та сприяння повторному використанню. Континуум підприємства складається з двох внутрішніх континуумів: континууму архітектури та континууму рішень.
• Внутрішній архітектурний континуум класифікує виходи (результати, артефакти, будівельні блоки) щодо правил, архітектурних проектів, уявлень і відносин. Цей аналіз може бути більш абстрактним або пов'язаним з принципами, які необхідно підтримувати рішенням. Континуум архітектури керує континуумом рішень.
• Внутрішній континуум рішень надає фактичні методи для реалізації активів в континуумі архітектури, використовуючи технології та рамки. Він підтримує континуум архітектури.
• Обидві класифікації континуумної архітектури розташовані горизонтально - переміщаються зліва (більш загальні або абстрактні) вправо (більш конкретні). У кожній з чотирьох категорій є Фонд, Спільні системи, Промисловість та Організаційна специфіка.

[Натисніть на зображення, щоб збільшити його]

(1) Розділ 39.3, стандарт TOGAF 9.1

: Частина 6: Довідкові моделі

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

7 Частина 7: Рамка для можливостей підприємства

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

Застосування стандарту

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

У TOGAF ці частини стандарту описують класифікацію ваших архітектур, використовуючи ітераційний метод доставки архітектури, підтримуючі організаційні конструкції, керівні принципи та методи, управління, принципи мотивації, еталонні моделі, сховища активів тощо. Існує немає необхідності винаходити їх на свій розсуд.

Але для досягнення успіху вам не потрібно все в стандарті. Потрібно бути в курсі того, що пропонується і як його ефективно застосовувати.

При введенні TOGAF (або будь-якої практики EA) рекомендується починати з малого. Наприклад, при здійсненні зусиль із впровадження, почніть з об'єднання фаз ADM з методологією проекту вашої організації. Для кожної застосовуваної фази визначте необхідні входи та ідеальні виходи. Виконувати процеси та заходи в рамках ADM фаз для досягнення результатів та очікуваних результатів. Наприклад, при створенні нової цільової архітектури, застосовуйте фази B, C і D (фази бізнес-систем, інформаційних систем і архітектури) для створення базової архітектури, а потім виконайте аналіз розривів для виявлення пасток. Інший приклад реалізації EA полягає в тому, щоб почати з компіляції існуючих і нових ресурсів архітектури в континуумі підприємства. Створіть структуру вмісту архітектури та почніть категоризувати ваші артефакти, результати та будівельні блоки.

Соціалізуйте концепції та термінологію з технічними, проектними та зацікавленими групами протягом усього часу. Викличте перемоги, які допоміг стандарт TOGAF. Пізніше і, коли це доречно, ви можете запровадити більш формальний процес. Запровадити організаційні аспекти, такі як рада з архітектури та практику управління, які повинні бути офіційно визнані. Повний список заходів і міркувань див розділ 46 (версія 9.1) стандарту TOGAF.

Адаптація до інших структур і методів

Нарешті, TOGAF визнає необхідність інтегрувати свої стандарти з іншими методами управління бізнесом, проектами або операціями. Кожен метод управління мотивується власними проблемами. TOGAF займається якісною архітектурою для задоволення бізнес-стратегії. Може виникнути потреба адаптувати його до інших архітектурних структур, таких як Zachman Framework. Подивіться на стандартні розділ 2.10 (версія 9.1) для керівництва змішуванням TOGAF з іншими рамками. Зазначені методи включають ідентифікацію результатів випуску з архітектурної діяльності, а потім визначення того, в якій діяльності або фазі повинні вироблятися виходи. Розглянемо два приклади.

Приклад 1: Адаптація TOGAF до гнучкої методології

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

Для порівняння, TOGAF ADM є більш зорієнтованим на архітектуру, щоб забезпечити, щоб цільова архітектура підтримувала проблеми зацікавлених сторін і що вона підтримує довгострокову бізнес-стратегію. ADM має використовуватися, коли потрібно доставити цільові архітектури. Не всі гнучкі проекти вимагають доставки нової архітектури (наприклад, зазвичай з меншими релізами / епосами) і, отже, не потрібно використовувати цикл ADM. Але все ж ADM також є ітеративним процесом. Вона гнучка - ви можете повторити всі вісім фаз; вибирати тільки відповідні фази для перебору; повторюються повторно навколо сусідніх фаз; або ітерація всередині однієї фази. Це найкращий варіант для створення надійної цільової архітектури. Пам'ятайте, що команда розробників залежить від того, чи доставить якісний продукт архітектури.

Як би ви використовували ADM як архітектор підприємства, спільно з гнучкою командою розробників? Давайте розглянемо приклад.

[Натисніть на зображення, щоб збільшити його]

Перш за все, час - це все. Велика частина Вашої вступної роботи на Попередньому етапі через Етап D повинна бути зроблена до того, як команда розробників отримає її для вирішення та впровадження. Це включає наступні етапи: попереднє, архітектурне бачення, бізнес-інформаційні системи / архітектура технологій. В ідеалі, поки архітектор підприємства працює над своїм аналізом, проектуванням і результатами, гнучка команда працює над завершенням попереднього випуску. Ідеальний вибір часу для надання останнього виходу архітектури підприємства у фазі D безпосередньо перед тим, як команда розробників почне своє рішення та впровадження, що входить до наступного гнучкого випуску. Потім, щоб виконати цю роботу, архітектор підприємства повинен забезпечити нагляд у фазі рішень, щоб визначити, чи потрібна архітектура переходу. Архітектор повинен виконувати завдання планування міграції (етап F) та завдання управління впровадженням (етап G) у фоновому режимі, тоді як гнучка команда розробляє рішення. Постачання гнучкої команди повинно підтримуватися завданнями ADM Phase H Architecture Change Management.

Приклад 2: Адаптація TOGAF до Рамки Захмана

Малоймовірно, щоб організація одночасно використовувала декілька структур архітектури підприємства, хоча один з можливих сценаріїв - коли відбувається злиття. Наприклад, дві об'єднані організації могли б використовувати різні рамки - стандарт TOGAF і Zachman Framework. У довгостроковій перспективі вони можуть бути зведені до однієї основи, однак, можливо, їм доведеться співіснувати, коли відбувається злиття.

Для уточнення, Zachman Framework не є методологією, це онтологія, що описує структуру підприємства, застосовну до архітектури. TOGAF - це методологія, яка має ADM як процес доставки архітектур підприємства, на додаток до кількох інших можливостей. Однак адаптація TOGAF до Zachman продемонструє гнучкість TOGAF. Окрім того, це допоможе організації перейти від Zachman до TOGAF, оскільки TOGAF надає більш комплексне рішення, ніж Zachman.

По-перше, оцініть розміри таблиці Zachman. Незважаючи на те, що він розвивався з плином часу, короткий опис є таким. Переходячи через стовпці таблиці, у вас є запитання, які ставлять питання для кожного, що, як, коли, хто, де і чому . Ви можете інтерпретувати це як підказки або підказки щодо того, що потрібно діяти або виконувати. Спускаючись по рядках таблиці, у вас є поняття фази для кожного контекстуального, концептуального, логічного, фізичного і докладного . Ви можете інтерпретувати їх як різні точки зору, що вимагають різних результатів. По суті, рамки залучають усіх учасників проекту і визначають, які результати вони повинні виробляти для створення задовольняє цільового рішення. Можна сперечатися, що Zachman Framework знаходиться за межами рамки архітектури і є скоріше рамкою проекту.

Підсумувавши Zachman Framework, ми тепер можемо адаптувати його до стандарту TOGAF. Давайте розглянемо приклад.

[Натисніть на зображення, щоб збільшити його]

Щоб почати, можна інтерпретувати концепції рядка таблиці Zachman (контекстні, концептуальні, логічні, фізичні, детальні) до етапів проекту, а не тільки перспективи. Контекстний рядок Zachman буде узгоджений з попередньою фазою ADM і фазою A - архітектурного бачення. Наступний рядок Zachman, концептуальний, мав би деяке перекриття в архітектурі ADM Vision (фаза А) і бізнес-архітектурі (фаза Б).

Висновок

Сподіваємося, тепер ви зрозумієте цінність стандарту TOGAF і як він обслуговує архітектуру підприємства. Дійсно, це поглиблений, все ж адаптивний метод застосування архітектури підприємства для задоволення потреб бізнесу. Будь ласка, не соромтеся надавати свої відгуки та досвід у коментарях.

Про автора

Уілл Стівенс є архітектором технології та консультантом, який має багаторічний досвід роботи в різних галузях архітектури, програмного забезпечення, хмари, інтерфейсу, мобільних пристроях. Має ступінь магістра комп'ютерної безпеки, ступінь бакалавра з комп'ютерних наук, кілька галузевих сертифікатів, надає незалежні консультації та самостійно запускає 2 саморобні вироби, Valloc.com і SocialIntuition.co .