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

Как ни парадоксально, несмотря на постепенное вызревание соответствующей дисциплины, мы пока не можем дать краткий и ясный ответ на простой вопрос: что такое программная архитектура? Общепринятых дефиниций не существует. На сайте Института программной инженерии (Software Engineering Institute, SEI), посвященном практическим аспектам архитектуры, Пол Клементс приводит несколько определений. И хотя отсутствие согласия относительно такого определения не стало существенным препятствием к развитию самой дисциплины, его достижение оказалось весьма трудной задачей при создании стандарта IEEE [1].

Область программной архитектуры делится на несколько подобластей. Рабочая группа IFIP 2.10 (International Federation of Information Processing — Международная федерация по обработке информации) определяет следующие пять.

Архитектурный проект: как мы создаем архитектуру?

Анализ: как мы на основе архитектуры отвечаем на вопросы о свойствах конечного продукта?

Реализация: как мы создаем систему на базе архитектурного описания?

Представление: как мы создаем надежные артефакты, чтобы «донести» архитектуру до людей и машин?

Экономика: какие архитектурные проблемы влияют на бизнес-решения?

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

Взгляд в прошлое поможет определить текущее состояние программной архитектуры и направления ее будущего развития. Мы также приведем ссылки на книги, статьи, конференции и Web-сайты.

До 1995 года

Ян Шарп произнес эти слова в 1969 году на конференции NATO Conference on Software Engineering Techniques (B. Randell, J.N. Buxton eds., Software Engineering Techniques: Report of a Conference Sponsored by the NATO Science Committee. Scientific Affairs Division NATO, 1970). Сегодня, 37 лет спустя, они все еще не потеряли актуальности.

Есть некое дополнение к программированию, и его надо вытащить на свет. Это программная архитектура. Архитектура и проектирование — не одно и то же. В качестве примера рассмотрим ОС/360. Части ОС/360 запрограммированы чрезвычайно хорошо, в них использовано множество удачных идей и методов. Причина, по которой операционная система оказалась бесформенной кучей программ, состоит в том, что у нее не было архитектора. Ее проектирование было поручено нескольким группам инженеров, каждому из которых приходилось изобретать собственную архитектуру. И когда все части соединили, они не превратились в целое.

Многое из того, что мы истолковываем как теорию и практику, на деле является архитектурой и проектированием. Теоретиками и практиками могут быть как инженеры, так и архитекторы. Например, я не считаю, что Дейкстра занимается в основном теорией: вероятно, через некоторое время мы будем говорить об архитектурной школе Дейкстры.

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

Вероятно, многие знакомы с хорошими программами. Задумавшись, почему та или иная программа хороша, вы поймете: разработчик полностью осознавал, чего хочет добиться, и прежде всего создавал форму. Некоторые из тех, кто способны создать форму, не в силах ее реализовать, и наоборот. Беда в том, что в отрасли, особенно в больших промышленных империях, почти не уделяется внимания архитектуре. На этой конференции присутствовали некоторые из первопроходцев в этой области, в том числе Тони Хоар, Эдсгер Дейкстра, Алан Перлис, Пер Бринч Хансен, Фридрих Бауэр и Никлаус Вирт. С тех пор и до конца 80-х слово «архитектура» использовалось преимущественно для обозначения системной архитектуры, т. е. физической структуры компьютерной системы, а иногда — системы команд семейства компьютеров. Ключевые положения, связанные с организацией программных систем, изложены в работах Фреда Брукса [2], Батлера Лампсона [3], Дэвида Парнаса [4-7] и Джона Миллса [8]. Правда, статья Миллса относилась скорее к процессам и прагматике программной архитектуры.

Концепция программной архитектуры как отдельной дисциплины зародилась в 1990 году (см. рисунок). Отец и сын Уинстон и Уолкер Ройсы в статье [9], вышедшей в 1991 году, впервые позиционировали программную архитектуру как связующее звено между технологиями и процессами. Эбергард Речтин посвятил программному обеспечению несколько разделов своей книги [10]. А Филипп Крачтен написал статью, связывающую итеративную разработку с архитектурой, и определил несколько представлений для использования в крупной командно-административной системе [11].

 

Ретроспектива программных архитектур

Дюэйн Перри и Александр Уолф опубликовали основополагающую статью [12]. В ней была предложена знаменитая формула «{элементы, формы, объяснения} = программная архитектура», к которой Барри Боэм вскоре добавил «ограничения». Для многих исследователей «элементы» в этой формуле означали «компоненты и соединители», которые и стали основой множества языков описания архитектуры (architecture description language, ADL), в том числе C2, Rapide, Darwin, Wright, ACME и Unicon. К сожалению, они не слишком прижились. В 1994 году вышла первая книга по программной архитектуре, написанная бывшими сотрудниками IBM Бернардом Виттом, Терри Бейкером и Эвереттом Мерритом [13].

1995-1998 годы

В 1995-м начался настоящий бум программной архитектуры. События ускорились за счет многочисленных «вкладов» отраслевой и академической науки. Заметными явлениями стали метод анализа программной архитектуры SAAM (Software Architecture Analysis Method — первый из серии методов, предложенных SEI [14]), подходы на базе нескольких представлений (такие как модель представления «4+1» компании Rational [15] и четыре представления Siemens [16]), а также специальные шаблоны для разработки программной архитектуры [17]. Корпорации Siemens [18], Nokia [19], Philips [20], Nortel, Lockheed Martin, IBM и другие крупные разработчики программного обеспечения (преимущественно для областей сложных систем, авиации, космонавтики и телекоммуникаций) начали уделять внимание программной архитектуре. Они кооперировались в рамках исследований архитектуры продуктовых линеек программных продуктов [21]. Еще одна книга Речтина и Марка Майера [22] удачно заполнила брешь между оборудованием и программным обеспечением.

1999-2005 годы

В 1999 году состоялась первая конференция по программной архитектуре [23], были основаны рабочая группа IFIP Working Group 2.10 и институт Worldwide Institute of Software Architects. Множество специалистов энергично принялись за разработку передовых методов [24-27]. В надежде повысить практическую ценность описания архитектуры группа Open Group на базе XML создала язык Architecture Description Markup Language, который обеспечил совместное использование архитектурных моделей. Объединенные усилия сообществ сторонников многократного использования кода привели к появлению специальных продуктовых линеек и методов, которые привлекли внимание крупных промышленных компаний. Так, например, появились и сформировались методы SAAM, BAPO и ATAM [14, 28, 29], а к уже имевшемуся общему стандарту архитектуры RM-ODP [30, 31] добавился IEEE 1471 [1]. Одновременно в SEI продолжали выпускать книгу за книгой [29, 32-34].

Cегодня

В крупных компаниях наподобие Microsoft есть собственные главные архитекторы, причем наблюдается некоторое превосходство программного архитектора над разработчиком. Первый решает очень разные вопросы, несмотря на призыв Мэри Шоу не называть архитектурой все, что попадается на глаза. Появилось немало выразительных языков описания архитектуры ADL, но на практике используются лишь немногие из них. Исключением, пожалуй, являются Koala [35] и UML (если воспринимать его как ADL, но многие пуристы считают иначе).

Для некоторых предметных областей имеются готовые архитектуры в виде платформ — например, J2EE, .Net, Symbian/Series 60 и Websphere. Стандарты обмена данными на уровне приложений, такие как XML и SOAP, оказали на них значительное влияние. Языки сценариев, скажем Python и Perl, изменили привычные способы конструирования систем. Архитекторы больше не могут начинать «с чистого листа»: они строят системы на основе своих представлений о возможностях этих платформ. Программное обеспечение с открытым кодом также сильно влияет на архитектурную практику.

Сумма знаний об программной архитектуре изложена более чем в 25 монографиях (см. врезку «Библиотека по программной архитектуре») и многочисленных научных статьях (см. врезку «Первоисточники по программной архитектуре»). Сформировалось активное сообщество специалистов, десятки университетов по всему миру преподают программную архитектуру, множество организаций предлагают курсы подготовки архитекторов. Одним словом, дисциплина родилась. n

Литература

  1. IEEE 1471:2000. Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Press, 2000.
  2. F. Brooks, The Mythical Man-Month. Addison-Wesley, 1975.
  3. B. Lampson, Hints for Computer System Design. Operating Systems Rev., 1983, vol. 15, no. 5.
  4. D. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules. Comm. ACM, 1972, vol. 15, no. 12.
  5. D. Parnas, On the Design and Development of Program Families. IEEE Trans. Software Eng., 1976, vol. 2, no. 1.
  6. D. Parnas, P. Clements, A Rational Design Process: How and Why to Fake It. IEEE Trans. Software Eng., 1986, vol. 12, no. 2.
  7. D. Parnas, P. Clements, D. Weiss, The Modular Structure of Complex Systems. IEEE Trans. Software Eng., 1985, vol. 11, no. 3.
  8. J. Mills, A Pragmatic View of the System Architect. Comm. ACM., 1985, vol. 28, no. 7.
  9. W.E. Royce, W. Royce, Software Architecture: Integrating Process and Technology. TRW Quest., 1991, vol. 14, no. 1.
  10. E. Rechtin, Systems Architecting: Creating and Building Complex Systems. Prentice Hall, 1991.
  11. P. Kruchten, Un Processus de Developpement de Logiciel Iteratif et Centre sur l?Architecture [An Iterative Software Development Process Centered on Architecture]. Proc. 4?eme Congres de Genie Logiciel, EC2, 1991.
  12. D. Perry, A. Wolf, Foundations for the Study of Software Architecture. ACM Software Eng. Notes., 1992, vol. 17, no. 4.
  13. B. Witt, F. Baker, E. Merritt, Software Architecture and Design: Principles, Models and Methods. Van Nostrand Reinhold, 1994.
  14. R. Kazman et al, SAAM: A Method for Analyzing the Properties of Software Architectures. Proc. 16th Int?l Conf. Software Eng. (ICSE 94), IEEE CS Press, 1994.
  15. P. Kruchten, The 4+1 View Model of Architecture. IEEE Software, 1995, vol. 12, no. 6.
  16. D. Soni, R. Nord, С Hofmeister, Software Architecture in Industrial Applications. Proc. 17th Int?l Conf. Software Eng. (ICSE-17), ACM Press, 1995.
  17. E Buschmann et al, Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996.
  18. C. Hofmeister, R. Nord, D. Soni, Applied Software Architecture. Addison-Wesley, 1999.
  19. A. Ran, ARES Conceptual Framework for Software Architecture. Software Architecture for Product Families: Principles and Practice, M. Jazayeri, A. Ran and E van der Linden, eds., Addison-Wesley, 2000.
  20. J. Miiller, Integrating Architectural Design into the Development Process. Proc. 1995 Int?l Symp. and Workshop Systems Eng. of Computer-Based Systems, IEEE Press, 1995.
  21. I. Jacobson, K. Palmkvist, S. Dyrhage, Systems of Interconnected Systems. Report on Object-Oriented Analysis and Design (ROAD), May-June 1995, vol. 2, no. 1.
  22. E. Rechtin, M. Maier, The Art of Systems Architecting. CRC Books, 1997.
  23. P. Donohue, ed. Software Architecture-1st IFIP Conf. Software Architecture (Wicsa 1).— Kluwer Academic Publishers.— 1999.
  24. R.C. Malveau and T.J. Mowbray. Software Architect Bootcamp, 2nd ed., Prentice Hall, 2000.
  25. D.M. Dikel, D. Kane and J.R. Wilson. Software Architecture: Organizational Principles and Patterns.— Prentice Hall.— 2001.
  26. H. Obbink et al., Report on Software Architecture Review and Assessment (SARA). V1.0, Feb. 2002.
  27. P. Kruchten, The Rational Unified Process-An Introduction, Addison-Wesley, 1998.
  28. H. Obbink et al, COPA: A Component-Oriented Platform Architecting Method for Families of Software-Intensive Electronic Products (Tutorial). Proc. 1st Software Product Line Conf. (SPLC1), 2000.
  29. P. Clements, R. Kazman, M. Klein, Evaluating Software Architecture. Addison-Wesley, 2002.
  30. ISO/IEC 10746:1995, Reference Model of Open Distributed Processing (RM-ODP). ITU Rec. X901, 1995.
  31. J. Putman, Architecting with RM-ODP. Prentice Hall, 2000.
  32. L. Bass, P. Clements, R. Kazman, Software Architecture in Practice. Addison-Wesley, 1998.
  33. P. Clements et al., Documenting Software Architectures: Views and Beyond, Addison-Wesley, 2002.
  34. P. Clements, L. Northrop, Software Product Lines: Practice and Patterns. Addison-Wesley, 2002.
  35. R. van Ommering et al., The Koala Component Model for Consumer Electronics. IEEE Trans. Computers, 2000, vol. 33, no. 3.
  36. M. Shaw, The Coming-of-Age of Software Architecture Research. Proc. 23rd Int?l Conf. Software Eng. (ICSE 01), IEEE CS Press, 2001.
  37. B. Selic, The Pragmatics of Model-Driven Development. IEEE Software, 2004, vol. 20, no. 5.
  38. R. Soley, Model-Driven Architecture. Object Management Group, 2000.
  39. J. Bosch, Software Architecture: The Next Step, Proc. 1st European Workshop Software Architecture (EWSA 04), Springer, 2004.

Филипп Крачтен (kruchten@ieee.org)— профессор Университета Британской Колумбии, Хенк Оббинк (henk.obbink@philips.com)— ведущий научный сотрудник лаборатории Philips Research Laboratories в Эйндховене, Джудит Стаффорд (jas@cs.tufts.edu)— приглашенный исследователь в Институте программной инженерии Университета Карнеги—Меллона. 

Philippe Kruchten, Henk Obbink, Judith Stafford. The Past, Present, and Future for Software Architecture. IEEE Software, March/April 2006. IEEE Computer Society, 2006, All rights reserved. Reprinted with permission.

Библиотека по программной архитектуре

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

Первая книга

M. Shaw, D. Garlan, Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, 1996. Эта книга помещает программную архитектуру на достойное место в общей картине мира, расценивая ее как дисциплину, отличную от программирования. Авторы попытались дать определение программной архитектуры, что является довольно трудной задачей. Десять лет спустя мы все еще не пришли к общему мнению. Большая часть книги посвящена концепции архитектурных стилей, в ней также есть глава о подготовке программных архитекторов.

Трилогия SEI

L. Bass, P. Clements, R. Kazman, Software Architecture in Practice. 2nd ed. Addison-Wesley, 2003. В этой книге, впервые опубликованной в 1998 году, подробно освещен ряд аспектов программной архитектуры: процессы и методы, представление, технические приемы, инструменты и влияние на бизнес. В ней предлагается хорошее введение в несколько архитектурных методов SEI.

P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J. Stafford, Documenting Software Architectures: Views and Beyond. Addison-Wesley, 2002. Посвященная исключительно представлению и документированию программной архитектуры, эта книга де-факто стала практическим руководством по довольно абстрактному стандарту IEEE Standard 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems.

P. Clements, R. Kazman, M. Klein, Evaluating Software Architecture. How good is this architecture? Addison-Wesley, 2002. Третья книга трилогии SEI (плодовитая группа ее авторов написала значительно больше книг) фокусируется на рассмотрении и оценке разных аспектов качества архитектуры, существующей или создаваемой вновь. Хорошее дополнение к отчету Software Architecture Review and Assessment (SARA) Report (SARA Working Group, 2002).

Боеприпасы для архитекторов

C. Hofmeister, R. Nord, D. Soni, Applied Software Architecture. Addison-Wesley, 1999. Опираясь на опыт работы в исследовательском центре Siemens, авторы предлагают систематический, детальный метод проектирования и представления программной архитектуры.

I. Jacobson, M. Griss, P. Jonsson, Software Reuse: Architecture. Process and Organization for Business Success. Addison-Wesley, 1997. Эта книга объединяет сообщество специалистов по многократному использованию программного обеспечения (которое прежде процветало, но стало слегка выдыхаться в середине 90-х) с сообществом архитекторов, показывает пути к их взаимному обогащению. В ней представлены элементы архитектурного метода, воплощенного в процессе RUP (Rational Unified Process).

F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996. Опираясь на работы «Банды четырех» (Gang of Four, GoF — это неформальное прозвище авторского коллектива в составе Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса. — Прим. пер.), посвященные шаблонам проектирования архитектуры, эта «Банда пятерых» собрала полезный каталог таких шаблонов. К сожалению, их работа, столь хорошо начавшаяся, не получила продолжения.

Прагматика

R. Malveau, T. Mowbray, Software Architect Bootcamp, 2nd ed. Prentice Hall, 2000. Начальное руководство для практиков.

D.M. Dikel, D. Kane, J. Wilson, Software Architecture: Organizational Principles and Patterns. Prentice Hall, 2001. В своей модели VRAPS (vision, rhythm, anticipation, partnering and simplification) авторы отразили динамику взаимоотношений в группе программных архитекторов.

E. Rechtin, M. Maier, The Art of Systems Architecting. CRC Books, 1997. Первая книга Речтина, вышедшая в 1991 году, была посвящена скорее аппаратному, чем программному обеспечению. Однако программные архитекторы могли с пользой применить многие из представленных в ней принципов. Объединенными усилиями Майер и Речтин смогли точнее и глубже осветить вопросы, связанные с программным обеспечением. Новичкам эта книга может показаться слишком сложной, так что им следует начать с первых двух книг, указанных в этом же разделе нашей «библиотеки».

Линейки программных продуктов

J. Bosch, Design and Use of Software Architecture: Adopting and Evolving a Product-Line Approach. Addison-Wesley, 2000. Эта и следующая книги описывают программную архитектуру в применении к линейкам программных продуктов.

M. Jazayeri, A. Ran, F. van der Linden, P. van der Linden, Software Architecture for Product Families: Principles and Practice. Addison-Wesley, 2000.

Первоисточники по программной архитектуре

Основы

D. Perry, A. Wolf, Foundations for the Study of Software Architecture. ACM Software Eng. Notes, 1992, vol. 17, no. 4. Эту основополагающую работу всегда будут помнить благодаря предложенной в ней чеканной формуле {элементы, формы, объяснения} = программная архитектура.

Предтечи

D. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules. Comm. ACM, 1972, vol. 15, no. 12. Программная архитектура, зародившаяся в начале 90-х, возникла не на пустом месте. Хотя Дэвид Парнас и не использовал термин «архитектура», большинство основообразующих идей и концепций многим обязаны его работам. Эта и две следующие статьи являются наиболее важными.

D. Parnas, On the Design and Development of Program Families. IEEE Trans. Software Eng., 1976, vol. 2, no. 1.

D. Parnas, P. Clements, D. Weiss, The Modular Structure of Complex Systems. IEEE Trans. Software Eng., 1985, vol. 11, №. 3.

F. DeRemer, H. Kron, Programming-in-the-Large versus Programming-in-the-Small. Proc. Int?l Conf. Reliable Software, ACM Press, 1975. Предложенный авторами язык MIL 75 (Module Interconnection Language) фактически является предшественником всех языков ADL, а его цели проектирования сохраняют силу и сегодня. Авторы имели ясное представление об архитектуре. Они отличали ее не только от проектирования и программирования на уровне модулей, но и от более абстрактного высокоуровневого проектирования.

Представления архитектуры

D. Soni, R. Nord, C. Hofmeister, Software Architecture in Industrial Applications. Proc. 17th Int?l Conf. Software Eng. (ICSE 95), ACM Press, 1995. В статье представлена модель пяти представлений Siemens, которую авторы детализировали в книге Applied Software Architecture.

P. Kruchten, The 4+1 View Model of Architecture. IEEE Software, 1995, vol. 12, no. 6. Описана часть подхода, сегодня известного как Rational Unified Process. Многие консультанты Rational использовали в крупных промышленных проектах именно этот набор представлений. Своими корнями он уходит в работу, выполненную Alcatel и Philips в конце 80-х.

Процесс и прагматика

B. Lampson, Hints for Computer System Design. Operating Systems Rev., 1983, vol. 15, no. 5. Эта и следующая статьи стали источниками вдохновения для Крачтена, в то время подающего надежды программного архитектора. Они нисколько не устарели, и сегодня по-прежнему остаются актуальными.

J. Mills, A Pragmatic View of the System Architect. Comm. ACM, 1985, vol. 28, no. 7.

W.E. Royce, W. Royce, Software Architecture: Integrating Process and Technology. TRW Quest, 1991, vol. 14, no. 1. В этой статье четко сформулирована связь между архитектурой и процессом. В частности, говорится о необходимости итеративного процесса, в рамках которого на ранних итерациях строится и проверяется архитектура.

Еще две на посошок

Нам хотелось бы упомянуть еще множество статей о таких языках ADL, как Rapide, Wright и C2, а также об архитектуре, опирающейся на модели. Но пора остановиться, поэтому мы добавим только две.

M. Shaw, P. Clements, A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems. Proc. 21 st Int?l Computer Software and Applications Conf. (COMPSAC 97), IEEE CS Press, 1997.

M. Shaw, The Coming-of-Age of Software Architecture Research. Proc. 23rd Int?l Conf. Software Eng. (ICSE 01), IEEE CS Press, 2001.

Сообщество программных архитекторов

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

Ресурсы

  • Сайт Software Architecture for Software-Intensive Systems Института программной инженерии (www.sei.cmu.edu/architecture) содержит множество определений, статей о методах SEI и дополнительных ссылок. Сайт поддерживает группа архитектурной практики SEI.
  • Web-страница Gaudi System Architecting, названная в честь известного испанского архитектора, посвящена системной архитектуре. Страницу ведет Геррит Миллер, сотрудник Philips Research.
  • Архитектурный портал Software Architecture, Architects and Architecting ведут Дана Бредемейер и Руфь Малан. Портал содержит не только их работы, но и хорошо организованное собрание других ресурсов и ссылок.
  • Web-страница Software Product Lines посвящена продуктовым линейкам и многократному использованию кода.
  • SoftwareArchitectures.com — еще один портал, открывающий путь к архитектурным ресурсам.
  • Гради Буч из IBM возглавляет разработку справочника для программных архитекторов, создает репозитарий архитектурных образцов и практических примеров.

Конференции

  • Конференции Working IEEE/IFIP Conferences on Software Architecture. С 1999 года привлекают множество представителей отраслевой и академической науки, становятся местом возникновения интересных дебатов и плодотворных обсуждений. Конференции проводятся как в Северной Америке, так и в Европе. Были частью международных семинаров International Software Architecture Workshop, которые проводились с 1995-го по 2000 год.
  • Европейский семинар European Workshop on Software Architecture. Учрежденный в 2004 году семинар развивается главным образом силами участников европейского проекта ArchWare — Architecting Evolvable Software.
  • Конференция Software Product Line Conference (softwareproductlines.com). Встречи этого сообщества архитекторов проводятся с 2000 года. Эти конференции являются составной частью серии европейских конференций Product Family Engineering.
  • Конференция по качеству архитектуры Quality of Software Architectures (QOSA, se.informatik.uni-oldenburg.de/qosa) впервые проведена в 2005 году.
  • Обсуждения программной архитектуры также проводятся (зачастую как специальные сессии или направления) на конференциях ICSE, ECOOP (European Conference on Object-Oriented Programming), OOPSLA (Object-Oriented Programming Systems, Languages, and Applications), FSE (Foundation of Software Engineering), APSEC (Asia-Pacific Software Engineering Conference), а теперь и на MODELS (ACM/IEEE International Conference on Model-Driven Engineering Languages and Systems), которая входит в серию конференций по UML.

Ассоциации и рабочие группы

  • Рабочая группа IFIP WG 2.10 Software Architecture. Она основана на первой конференции WICSA в 1999 году. Тринадцать ее членов собираются дважды в год, а несколько раз в год проводят обсуждения через Internet. Они являются движущей силой конференций WICSA, специального выпуска IEEE Software и ведут портал Software Architecture Portal.
  • Всемирный институт программных архитекторов (Worldwide Institute of Software Architects, WWISA; www.wwisa.org). Основан Марком и Лаурой Сюелл в 1999 году.
  • Международная ассоциация программных архитекторов (International Association of Software Architects, IASA; www.iasarchitects.org). Занимается организацией социальных сетей, пропагандой прогрессивных идей, вопросами этики и совместного использования знаний.
  • Рабочая группа IEEE Standards Association WG 1471 (standards.ieee.org). Создала стандарт IEEE 1471-2000, а теперь возрождается, чтобы заняться его пересмотром.
  • Software Architecture Review and Assessment. Эта неофициальная группа архитекторов из компаний Philips, Siemens, Rational, Nokia, IBM и Lockheed Martin регулярно собиралась с 1998-го по 2001 год для обсуждения методов оценки программного обеспечения. В 2001 году выпустила отчет, расположенный на www.philippe.kruchten.com/architecture/ SARAv1.pdf .
  • Многие преподаватели и исследователи ведут страницы со ссылками на свои исследования и другие ресурсы. Ограничимся лишь двумя примерами: Ненад Медвидовиц (Университет Южной Калифорнии, sunset.usc.edu/research/ software_architecture/index.html) и Герт Флориджин (Исследовательский центр программирования в Голландии, www.serc.nl/people/florijn/interests/arch.html).