В OMG Essence (системная схема проекта) слово opportunity, "возможность". Я когда-то перевёл даже множественным числом: "ищут разные возможности", а не "ищут конкретную возможность". Вот цитата из стандарта 1.1 (http://www.omg.org/spec/Essence/), и помним, что в стандарте намеренно приведены мутные формулировки, дабы поощрить их обсуждение командой проекта:
Opportunity: The set of circumstances that makes it appropriate to develop or change a software system. The opportunity articulates the reason for the creation of the new, or changed, software system. It represents the team’s
shared understanding of the stakeholders’ needs, and helps shape the requirements for the new software system by
providing justification for its development.
States
- Identified (определена) -- A commercial, social, or business opportunity has been identified that could be addressed by a software-based solution.
- Solution Needed (нужно решение) -- The need for a software-based solution has been confirmed.
- Value Established (польза установлена) -- The value of a successful solution has been established.
- Viable (жизнеспособна) -- It is agreed that a solution can be produced quickly and cheaply enough to successfully address the opportunity.
- Addressed (использована) -- A solution has been produced that demonstrably addresses the opportunity.
- Benefit Accrued (извлекается выгода) -- The operational use or sale of the solution is creating tangible benefits.
Я "возможность" понимаю как двери в поезде метро: в какой-то момент поезд с вашей командой останавливается на станции, двери открываются -- и на станции стоит толпа стейкхолдеров, которые что-то хотят. А у вас есть, что им предложить по сходной цене. Это означает, что есть возможность сделать проект. Но бывает, что толпа стейкхолдеров стоит, а вам предложить нечего. Или вы предлагаете, а толпа стейкхолдеров ожидает чего-то другого. Тогда возможностей сделать проект нет, через пару минут дверь закрывается, "окно возможностей" захлопывается. То есть несмотря на то, что в OMG Essence подчёркивается внешняя сторона "возможности" (нужна ли наша система внешним стейкхолдерам), есть и внутренняя (нужно ли выполнять этот проект внутренним стейкхолдерам -- нашей команде). Стандарт это не акцентирует, но всё-таки поминает: It is important that the team understands the current state of the opportunity so that they can ensure that an appropriate software system is developed, one that will satisfy the stakeholders and result in a tangible benefit being accrued.
У "возможности" в Essence есть предписанная стандартом подальфа -- это need. A lack of something necessary, desirable or useful, requiring supply or relief. Need exists within the customer, and will be considered by product or portfolio managers who analyze whether there will be value generated by addressing the Need, and pursuing the identified opportunities.
Need -- это про использующую систему, в отличие от requirements, которые про целевую систему. В любом случае, не любые needs нужно удовлетворять, а только те, которые команде проекта удовлетворять выгодно. В убыток работать нельзя.
Поэтому я предлагаю подальфами возможности считать маржинальный бюджет (не "себестоимость"! читайте Голдратта для подробного разбора), а ещё новые технологии -- ибо со старыми технологиями обычно сделать проект не удаётся. Новые технологии это подальфа технологий. Подальфы легко могут быть подальфами двух альф сразу: новые технологии, если их осваивать, продвигают альфу возможностей и одновременно продвигают технологии. Можно также говорить и о skills команды как такой же "двойной" подальфе. С моделированием практик тяжело: "практика = дисциплина + технология", но дисциплина обычно в голове команды, поэтому альфу way of working я перевёл как "технологии", а вот "дисциплину" оставил для команды. Всё сложно, счастья нет.
И вот в этот момент появляется вопрос о capability -- переводить можно либо "функциональные возможности", либо "потенциал". Это как раз "возможность команды сделать быстро и задёшево, но чтобы получить прибыль". Это, конечно, внутренняя сторона возможностей. В OMG Essence не обсуждается capability. Если добавлять для группировки подальф skills, новых технологий, бюджета на марже -- сразу появляется лишний подуровень. Поэтому я выбрал не умножать число сущностей без надобности.
В ArchiMate 3.0, наоборот, нет возможностей/opportunity, но есть возможности/capability (http://pubs.opengroup.org/architecture/archimate3-doc/chap07.html#_Toc489946034) -- A capability represents an ability that an active structure element, such as an organization, person, or system, possesses.
In the field of business, strategic thinking and planning delivers strategies and high-level goals that are often not directly implementable in the architecture of an organization. These long-term or generic plans need to be specified and made actionable in a way that both business leaders and Enterprise Architects can relate to, and at a relatively high abstraction level.
Capabilities help to reduce this gap by focusing on business outcomes. On the one hand, they provide a high-level view of the current and desired abilities of an organization, in relation to its strategy and its environment. On the other hand, they are realized by various elements (people, processes, systems, and so on) that can be described, designed, and implemented using Enterprise Architecture approaches. Capabilities may also have serving relationships; for example, to denote that one capability contributes to another.
Capabilities are expressed in general and high-level terms and are typically realized by a combination of organization, people, processes, information, and technology. For example, marketing, customer contact, or outbound telemarketing.
Напомню, что ArchiMate тоже намеренно сделан невнятным, чтобы не потерять возможность моделировать самые разные ситуации. Так что тут тоже возможности трактовки довольно широки -- но это "внутренние возможности", "функциональные возможности", "потенциал", от которых мы только что отказались как от отдельной сущности в Essence. А любителям перевести что-то на русский можно посоветовать насладиться определением, где по сути заявлено "capability = ability".
А как мы себя будем вести в ArchiEssence? А по ситуации, я бы пока не предписывал какого-то поведения по моделированию capability -- особенно если учитывать, что Essence не работает с corporate governance, а сосредотачивается на уровне одного проекта/предпринятия, а ArchiMate как раз пытается акцентировать в стратегических и целеполаганческих своих расширениях именно понятия corporate governance. Но ежели приглядеться, то capabilities в Архимейте очень похожи на развёрнутые практики, practices -- которые полноценно поддержаны загруженными уже в чьи-то головы дисциплинами и развёрнутыми в предприятии технологиями. Capability -- это практика, которая освоена и ресурсно поддержана.
Так что я бы просто не считал пока, что в архимейт-моделировании обязательно использовать все-все имеющиеся там значки. Нет, я бы пытался не умножать число задействованных архимейт-сущностей без надобности. А там посмотрим: в каждом проекте будут свои любители Essence, свои любители ArchiMate, свои любители подходов неведомых нам сейчас школ бизнеса, свои стратеги и развиватели бизнеса со своими птичьими языками. И дальше уж как все эти стейкхолдеры договорятся.
Это я по следам дискуссии по поводу "возможности" в системной схеме мышления в https://www.facebook.com/alex.turkhanov/posts/10213618970925657.
Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10211052463961572
По итогам всех дискуссий: capability -- это поставленная практика, возможность осуществления функции (т.е. готовность предоставления сервиса какими-то модулями, поддерживающими практику).