EN
как захотите так и нарежете
Size: a a a
2020 April 16
AG
Мне нравится подход TOGAF: на верхнем уровне выделить Foundation solutions, common solutions, industry solutions, organisation-specific
EN
это не классификация ПО)
AG
Почему? Дальше классы, например СУБД попадут в Foundation
AG
А CRM в common
EN
солюшен=по?
AG
Да, программные продукты
EN
в частном случае солюшен конечно может состоять из 1 программного продукта
EN
но солюшен на то и солюшен, что там смесь
AG
Каждый отдельный продукт - тоже солюшн. Для тех задач, под которых его проектировали. Под что не проектировали - там интегрированные и кастомизированные решения.
EN
разве может быть солюшен без привязки к конкретному внедрению?
EN
вот я сделал что-то, коробочку красивую, написал доки, установил цену. но пока оно не развернуто его не существует)
VU
разве может быть солюшен без привязки к конкретному внедрению?
А если не рассматривать продуктовую изолированную разработку?
VU
вот я сделал что-то, коробочку красивую, написал доки, установил цену. но пока оно не развернуто его не существует)
Можно выше абстрагироваться
VU
Вы архитектор?
EN
Я и не рассматриваю, я хотел сказать, что солюшен - сугубо практическое понятие, которое развернуто и работает. Мб я не в ту сторону думаю? Для меня ПО и солюшен были до сего дня разными понятиями)
VU
Я и не рассматриваю, я хотел сказать, что солюшен - сугубо практическое понятие, которое развернуто и работает. Мб я не в ту сторону думаю? Для меня ПО и солюшен были до сего дня разными понятиями)
ИМХО Не в ту, солюшн оперирует окружением и потребностями бизнеса, в идеале помогает построить бизнес-решение
VU
Т. е. не в пределах одной проблемы
EN
я не про архитектора-солюшена говорю, а про солюшн в смысле решение архитектурное
EN
короче, разговор о терминах бессмысленен