packaged business capabilities что это
What are Packaged Business Capabilities?
According to Gartner: Packaged business capabilities (PBCs) are software components representing a well-defined business capability, functionally recognizable as such by a business user.
In a previous article, we discussed what Composable Commerce is and why it is essential for businesses to adopt. In short, brands that prioritize infusing digital throughout their entire strategy need a commerce framework that empowers them to build, deploy, and optimize experiences seamlessly.
Packaged Business Capabilities are a part of Composable Commerce and are used to create a best of breed solution. But having talked to prospects and customers, it became clear that there is a lot of confusion. Most industry folks are on-board with the microservices concept, but now there is a new kid on the block, which raises many questions. What are Packaged Business Capabilities? Are they different from microservices? How Packaged Business Capabilities relate to microservices or other architecture patterns?
This article provides answers to those questions, and places Packaged Business Capabilities among the modern architecture terminology.
Definitions
According to Gartner: Packaged business capabilities (PBCs) are software components representing a well-defined business capability, functionally recognizable as such by a business user. Technically, a PBC is a bounded collection of a data schema and a set of services, APIs, and event channels. The well-implemented PBCs are functionally complete to ensure autonomy (no critical external dependencies, no need for direct external access to its data). PBCs are meant to be used as building blocks for application product suites and custom-assembled application experiences.
Microservices have many definitions. We will take the one by Sam Newman: microservices are small, autonomous services that work together. A straightforward explanation, but several characteristics in the image below compliment it.
As you can see, there are a lot of similarities: modeled around the business domain, decentralized, isolated. Because there is no defined size for microservices and Gartner says that PBCs can also vary in size, it can become confusing.
Deliver unique customer experiences
Get a custom demo to see how Elastic Path will help you deliver the unique customer experience you’ve always imagined.
PBCs and Microservices
The key to establishing a relation between the two terms is to understand that microservices are an architectural style that defines how you break down the application into «services» – a well-defined software term. While PBCs are defined as building blocks for applications or suites. From this perspective, they are complimentary, and PBCs can be considered aggregations of microservices. The number of microservices can be one or more, as depicted in the image below. Now all the similarities in definitions make sense.
PBCs value
At this point, you might be asking questions: «why do I need PBCs? What is the point? Where is the value?».
Theoretically, in the microservices world, you can create a best of breed solution consisting of 50 microservices, each being from a different vendor. But nobody does it because the integration costs will be sky high and it will outweigh any benefits. Imagine your business users having to deal with 10 UIs from different vendors within a single commerce application. It sounds like a nightmare because it is. This is why businesses usually consume applications in larger pieces.
Consumption includes multiple aspects, including:
Reduced Complexity for the business
With PBCs, a business has to deal with a smaller number of building blocks. Think of it as the same way people group animals into six primary animal groups: amphibians, birds, fish, invertebrates, mammals, and reptiles. It is just easier to deal with it this way. Overall it makes it easier to understand the value provided by the application, create a best of breed solution that fits their needs, deploy it, and train their personnel.
Streamlined go-to-market for the vendor
While the business application’s core capabilities and value won’t often change, how it is broken down into microservices will be changing over time. New microservices might appear, and the older ones may be altered to accommodate new technologies and frameworks. In the SaaS environment, the underlying architecture is not exposed to the customer as they consume the APIs. Because of this, PBCs allows the business to maintain their customer-facing
What is the right size for PBC?
PBC size will differ from application to application, and the vendor should define PBCs based on how their customers consume their application, but I will provide some considerations:
Can a monolith application be a PBC?
The simple answer is – yes. Suppose the application’s scope is small enough that it is always consumed as a whole and is virtually indivisible by a business user. In that case, the whole application can be considered a PBC. And of course, the application should satisfy the requirements provided by Gartner. Example: a payment gateway with APIs is a PBC.
If you want to learn more about PBCs and Composable Commerce – check here.
Повышаем степень клиентоориентированности с помощью корпоративной архитектуры на основе TOGAF®
Привет, Хабр. В рамках набора учащихся на курс «Enterprise Architect» подготовили перевод материала.
Также у всех желающих есть возможность посетить открытый демо-урок «Обоснованные структурные изменения организации в быстро меняющихся условиях». На этом вебинаре вместе пройдёмся по процессу исследования, оценки, планирования и контроля изменений в организации. Увидим, как применяются методы архитектуры предприятия — это доступный многим инструмент. Вопреки расхожему мнению, он не требует глубоких технических знаний, зато сфокусирован на понимании предметной области и эффективных коммуникациях.
Область бизнес-архитектуры в рамках Enterprise Architecture (Архитектура предприятия) — это не только бизнес-возможности и бизнес-процессы. В первую очередь это касается оптимизации ценности (value) для ваших клиентов и усилий в построении организации, в большей степени ориентированной на них.
Важность ценности в Enterprise Architecture
Традиционно в Enterprise Architecture бизнес-процессы (business processes) являются основным средством взаимодействия с заинтересованными сторонами. Что касается понятия бизнес-возможностей (business capabilities), то это более новая концепция, также часто используемая в Enterprise Architecture. Бизнес-возможности позволяют лучше понять, как программные приложения поддерживают бизнес, что очень хорошо объясняется в этом видео — «Бизнес-архитектура TOGAF®: Руководство по бизнес-возможностям»:
Часто бывает, что для одних (новых) бизнес-возможностей поддерживающих приложений нет, в то время как для других (старых) возможностей их слишком много. Обе концепции сами по себе не отражают ценность, которую гибкая клиентоориентированная организация должна обеспечить для сохранения и увеличения своей доли рынка за счет все более быстрых и непрерывных инновационных изменений и более информированных клиентов, которые вынуждают их иметь более гибкие бизнес-стратегии.
Корпоративные архитекторы должны осваивать и использовать концепцию ценности на клиентоориентированном предприятии, как показано на изображении выше. Организация обычно предоставляет несколько ценностных предложений (value propositions) различным сегментам своих клиентов (или персонам) и партнерам, которые доставляются потоками создания ценности (value streams), состоящими из нескольких этапов создания ценности (value stages). На этапах создания ценности участвуют внутренние заинтересованные стороны (stakeholders), внешние заинтересованные стороны и очень часто потребители. Этапы создания ценности создают условия для этапов клиентских путей (customer journey steps), опираются на возможности и вводятся в действие процессами (обычно уровень 2 или 3). Видео Бизнес-архитектура TOGAF® :Значение Guide Поток дает очень четкое и простое объяснение, если вы хотите узнать об этом побольше. Клиентские пути, строго говоря, не является частью бизнес-архитектуры, но, тем не менее, очень полезно для взаимодействия с заинтересованными сторонами.
Эти потоки/этапы создания ценности не могут быть реализованы на пустом месте. Организация должна иметь возможность достичь определенной цели, которая заключается в предоставлении ценности инициирующим заинтересованным сторонам, в частности — клиентам. Эта способность является решающей бизнес-возможностью. Без этой возможности организация не может предоставить ценность для инициирующих заинтересованных сторон (клиентов). Она делает возможным этап создания ценности и реализуется бизнес-процессом. Она также принадлежит одной бизнес-подразделению или филиалу внутри организации и используется одним или несколькими бизнес-подразделениями или филиалами. Как правило, возможность должна поддерживаться по крайней мере одним приложением, системой или IT-службой.
Фактически, ценностные предложения, потоки и этапы создания ценности — это «Почему» инициатива или проект должны быть реализованы. Заинтересованная сторона — это «Кто» должен участвовать для создания ценности. Бизнес-процесс — это «Как» организация может создавать ценность. Наконец, бизнес-возможности — это то, «Что» организация должна контролировать или должна делать для создания ценности.
Важные определения
Ссылаясь на стандартные определения TOGAF, каждый элемент, упомянутый на рисунке выше, должен быть определен следующим образом:
Бизнес-процесс (Business Process). Бизнес-процесс — это группа связанных и структурированных действий, выполняемых отдельными лицами или оборудованием, которые в определенной последовательности производят услугу или продукт (или служат бизнес-цели или задаче).
Бизнес-возможность (Business Capability). Бизнес-возможности — это особые способности, которыми предприятие может обладать или обменивать для достижения определенной цели. Бизнес-возможности должны поддерживаться приложениями, системами и/или IT-сервисами.
Клиент (Customer). Тот, кто покупает товар или услугу.
Клиентский путь (Customer Journey). Клиентский путь описывает полный опыт, который проходят клиенты при взаимодействии с организацией в виде пути из последовательных шагов до и после покупки продукта или услуги. Вместо того, чтобы рассматривать только часть транзакции или опыта, клиентский путь документирует полный опыт работы с клиентом. Клиентский путь состоит из нескольких этапов.
Продукт (Product). Продукт, предлагаемый организацией, — это товар, идея, метод, информация, объект или услуга, задуманные как результат процесса, удовлетворяющие потребности или желания покупателя. Продукт обычно является частью ценностного предложения.
Заинтересованная сторона (Stakeholder). Человек, команда, организация или комбинация вышеперечисленного, заинтересованные в системе.
Услуга (Service). Повторяющееся действие — дискретное поведение, которое может быть запрошено или инициировано каким-либо иным образом. Услуга обычно является частью ценностного предложения.
Ценностное предложение (Value Proposition). Ценностное предложение — это обязательство предоставить ценность инициирующей заинтересованной стороне (обычно клиенту), которая убежден, что после покупки будет получена выгода. Ценностное предложение состоит из одного или нескольких продуктов или услуг.
Поток создания ценности (Value Stream). Представление непрерывного набора действий, добавляющих ценность, которые создают общий результат для клиента, заинтересованного лица или конечного пользователя. Поток состоит из нескольких этапов создания ценности, в которых участвует по крайней мере одна идентифицируемая заинтересованная сторона.
Поток создания ценности бизнес-архитектуры и связанные с ним возможности обеспечивают ценностно-ориентированную перспективу возможностей, необходимых для ведения бизнеса любого типа (например, любой гостиницы), без учета организационной структуры, местоположения, вариантов продукта, конкретных процедур или других операционных характеристик, которые отличают конкретный бизнес или цепочку предприятий. Напротив, ценностно-ориентированный бизнес-процесс и его разложение на виды деятельности и потоки, обеспечивает ценностно-ориентированную перспективу потока товаров, информации и достижения результатов посредством деятельности (потенциально общего) бизнеса.
Enterprise Architecture и 5 этапов исполнения гибкой стратегии
Теперь давайте расположим каждый элемент, указанный на рисунке выше, как показано на рисунке ниже, чтобы определить 5 шагов в организации реализации гибкой стратегии. Эти этапы подробно описаны в книге «Практическое руководство по реализации гибкой стратегии: проектирование, архитектура, расстановка приоритетов и успешное достижение корпоративного будущего».
Клиенты (сегменты и/или персоны) и партнеры участвуют на всех пяти этапах реализации гибкой стратегии организации. Заинтересованные стороны бизнеса участвуют во всех этапах, кроме четвертого, который представляет собой этап гибкой доставки и выполнения. Что касается заинтересованных сторон в области IT, они в основном участвуют в планировании инициативы (шаг 3) и гибкой доставке и реализации (шаг 4).
Ценностные предложения, продукты, услуги в основном разрабатываются на этапе бизнес-дизайна и стратегии (шаг 1) для достижения конкретных стратегий и целей. Клиентские пути, потоки и этапы создания ценности обычно изучаются в начале проектировании трансформаций (шаг 2). Бизнес-возможности исследуются как при проектировании трансформаций, так и при планировании инициатив (шаги 2 и 3). Что касается бизнес-процессов, о них в основном заботятся на этапе гибкой доставки и реализации (шаг 4) на оперативном и тактическом уровне, когда экспертам по бизнес-процессам и agile-экспертам необходимо достичь четких целей в оценке тактике.
Чтобы обеспечить дополнительную ценность для своей организации, архитекторам предприятия необходимо понимать, что бизнес-архитектура — это не только бизнес-возможности и бизнес-процессы. Архитекторам предприятий не следует ограничивать свои возможности только проектированием трансформаций и инициативным планированием своей организации. Корпоративные архитекторы также могут внести свой вклад в оптимизацию ценности для клиентов и партнеров своей организации. Включение всех аспектов бизнес-архитектуры в практику вашей enterprise architecture сделает вашу команду гораздо более ценной для заинтересованных сторон на начальном этапе бизнес-дизайна и выработки стратегии и для заинтересованных сторон в IT на этапе гибкой доставки и реализации.
The business value of Packaged Business Capabilities
In the previous article, we have discussed the relation between Packaged Business Capabilities (PBCs) and Microservices on the technical level. Still, for business users, most likely, this was not very relevant. It is not evident why anyone, besides enterprise architects, should care about Packaged Business Capabilities. This article addresses this question and explains how Packaged Business Capabilities can create value for your business users.
The business value starts with the business problem that needs to be addressed. Of course, every business will have its challenges, but we will list some of the potential ones:
These business problems can be solved with the existing software in some cases, but you will have to acquire a new solution in others. And most likely, your solution will be used by multiple business users with different roles and business requirements:
All those roles have different needs, so you want to ensure all their needs are addressed when you select a solution. Sometimes, a single commerce software application can handle all the requirements, but often this is not the case. If possible, you would want to create a solution from multiple software applications in this situation, a so-called “best of breed” solution.
But how do you do this? All the software applications on the market are different. Which pieces do you take, and which you don’t?
Packaged Business Capabilities to the rescue
PBCs are independent building blocks that you can combine to create your “best of breed” solution. Each of the PBCs has the following characteristics:
To understand the PBCs value, imagine you plan to have lunch with a large group of friends (users of your solution) who have different food tastes (different roles and requirements). You have several options:
You could argue that a restaurant is not a bad choice, but if you have to stick with it for several years – the food court can become a much more attractive alternative.
PBCs Benefits
As always, Packaged Business Capabilities are not a silver bullet for every business context, but they can help your business to create a solution addressing your unique business needs without sacrificing speed:
Introduction to Packaged Business Capabilities
In the digital commerce space, there are a lot of movements around the PBC concept, as well as countless speculations about what it is and what it isn’t.
In the digital commerce space, there are a lot of movements around the Packaged Business Capabilities (PBC) concept, as well as countless speculations about what it is and what it isn’t. For that reason, I would like to give an overview of this software organization pattern and also shed some light on how it aids flexibility and agility within a composable enterprise.
When Gartner published an article giving a name to a concept that we had been working on at Spryker in the last few years, we immediately recognized that the problems Gartner was trying to address were not unique to Spryker customers alone. As a matter of fact, they were a set of well-known but yet-to-be addressed industry problems surrounding upgradability, best-of-breed vs “off-the-shelf” selection, customizability, and implementation speed. But let’s start from the beginning.
From the very beginning, Spryker followed a modular architecture approach, even when it was only a single PHP-based framework. In growing the number of frameworks like the back end, front end, data distribution, and API into the Spryker OS, we recognized a huge demand for addressing typical software problems in digital commerce. Some of these problems include:
There are many best practices addressing these problems; one of them is the microservice architecture pattern which tries to solve the problem by decoupling services into independent deployables.
Can microservices alone address these issues?
A few years ago there were many prospects requesting microservices as a must-have for customizing their projects and looking for a silver bullet that would immediately solve all of the organizational, technical, and process issues. Many commerce vendors started offering that desired architecture as a set of distributed services or as an API gateway, while hiding the actual implementation.
One group of vendors broke down their systems according to the microservice approach, leaving their composition, connectivity and ops up to the different client projects decisions. In the beginning of the project, everything looked really nice: clean decoupling and full independence. What no engineer likes to see is dozens of services running and thousands of messages being transferred back and forth on an operator dashboard. There are 3 things people can watch forever: fire burning, water falling and messages flying from one service to another. 🙂
After 2-3 years of project development, when the basic commerce commodity was implemented and teams started working on more complex business requirements, it became clear that Microservices did not solve the issues, but rather moved them to infrastructure and operations while increasing complexity. Businesses that wanted to differentiate in their market could not have a small Devops team managing the project, thus, they had to hire a fleet of highly qualified Devops engineers in order to address operational risks and complexities.
Utilizing a microservice approach from day one creates a bunch of complex problems for a technical leader. It could cause a control vs responsibility problem. For instance, having full control over a service such as checkout doesn’t mean you aren’t equally responsible for missing prices on the check out page (which is typically controlled by another team).
Or consider a service communication problem when debugging becomes a cross-team nightmare. Communication can easily get out of hand when multiple teams are involved, and sizing of a service is addressing purely technical issues, such as performance, scalability or security. It happens that an individual deployable service becomes more performant, scalable and secure, while overall system characteristics degrade exponentially as the result of an increasing number of negative contributors and communications between them. In the worst cases this tendency ends up in building a “Death Star”, which is no good until you wear a dark side helmet and driving an Imperial spaceship for living.
“Death Stars” from Amazon and Netflix
Other software vendors hid microservices behind monolithic API gateways, providing to customers the same monolith-like experience as before (“Shelfware” and overprovisioning) but leaving a UI up to the project. While promising the new age of digital commerce, customers of these systems couldn’t fully leverage or even access the microservice architecture itself.
Microservices became more of a developer tool and an exciting playground structured around technical constraints with no standards or expectations to API delivery or events.
Of course it’s not the microservices themselves, an architecture pattern, to blame, but us, people who are in search of said silver bullet to solve all their problems. Sometimes I can also find myself searching for the all-encompassing answer, and it requires discipline to avoid this bias.
Headless, is it really so?
When talking about headless systems, it is easy to lose one’s head – in other words, forget about the initial intention of introducing multiple “heads” and user touchpoints. Projects tend to take months, and millions of euros are often spent in order to launch the first “head” before a go-live date. A brand new, built from scratch front-end, based on a standard commerce API of a SaaS product, only makes the front-end team busy with building a commerce front-end commodity over and over again. Headless commerce APIs that can’t be used in different contexts (such as storefronts, back offices, POS or IoT devices) blur the focus and stagnate businesses.
The Rise of PBCs
In order to address these newly presented operational issues, it is advisable to not only structure services in a standardized way, but to also address connectivity problems between services on a platform level. This is where Packaged Business Capabilities or PBCs come in.
“A service is no longer a developer’s playground, but a tool for business leaders to define value and market differentiation by composing a commerce system.”
With capability size and communication standardization we can address connectivity, discovery and operational concerns through an underlying platform – the composition platform. We will take a closer look on what opportunities are opening for Composition Platforms in another article. Today let’s look inside a single PBC component.
Inside of a Packaged Business Capability
At Spryker, a modular OS with strict HTTP-native communication between modules, we offered the DIY application – the “ D efine I t Y ourself” application. Think of modules as Lego blocks – taking one set of modules you get a B2C, taking another B2B, adding some other will give you a B2C / B2B Marketplace – all in a single installation.
A modular approach also allows to combine these modules into independent capabilities, communicating over HTTP.
How Packaged Business Capabilities are realized in Spryker’s modular architecture, their domain decoupling, and other technical insights will be discussed in our next article.