Produkt, usługa, zasób – dlaczego ważne jest, aby je oddzielić?

Enxoo Q&A – #APIfication channel, episode #06, PSR Model

🔍 In this video, which is a follow-up to previous episode 05, our expert explains why it is important to follow the PSR model and keep concepts like Product, Service, and Resource separated from each other.

Read full transcript below

Transcript

Hi Everyone,

Welcome to the next episode of our Q&A series. My name is Maciek, I’m one of the leaders of Enxoo Comms Industry Practice and in this series of videos, I’m presenting my point-of-view on some topics related to the Comms industry API-fication.

In the previous episode I tried to explain the PSR Model and the subtle difference between Product, Service and Resource, and judging from all the comments I have received – it made at least some sense to some of you.

Now the question why it’s actually so important to keep these concepts separated one from another.

Let me try to explain that in brief.

About modelling abstract constructs

The world is a chaos. It’s complex and unstructured. And by the way – the communications industry is a great example of that. Now what we engineers, software developers and architects are trying to do, we’re trying to organize that chaos and bring it into the order. And we’re doing that by defining abstract concepts which are approximation modeling the reality surrounding us. 

Now… that was a bit philosophical. But let me give you an example. The Alfa Romeo car I brought up in the previous episode, it is a very real thing. You can go to the nearest Alfa Romeo dealership to see it, touch it, drive it, open the hood to see all the different parts. 

But when you come back home and try to describe it to your family – based on your story they will try to visualise an Alfa Romeo in their head. Their brains will create abstract images of what you have described. Now you can make your family sit on the couch and make them listen a very long and detailed story covering all the aspects of your dealership visit and I can tell you – each of them will imagine what you described in a completely different way. But equally – you can tell three different stories, separate one to your partner who all that might care is that glossy red colour maching the outfit, separate to your older kid, a petrolhead car maniac, separate to the younger kid, an aspiring mechanical engineer interested in all the nuts and bolts, and finally separate to yourself in a desperate search to defend a business case for this mid-life crisis investment.     

Context Matters

I know, I don’t make it easy. But to the point – how does this story relate to our Product, Service, Resource question. As I said – what we engineers do, we’re defining abstract constructs modelling reality around us. PSR Model is all about modelling. And from the previous episode we know that Product, Service and Resource represent three different contexts – Product – what you buy, Service – what you operate, Resource – how you assemble. So when you try to combine all these three contexts into one – you as an architect need to end up with an abstract construct that need to be capacious enough for that construct to be useful in all three contexts.

But instead if you define three different abstract constructs, each tied to the specific context – they become much smaller and easier to comprehend.

What I’m trying to explain here is deeply rooted in the software development, and if you’re into Software Architecture and building complex business applications – modeling these abstract constructs or so called “aggregates” is more of an art than the science and it’s an underpin of an approach called Domain-Driven Design, described first by Eric Evans, where the importance of defining clear boundaries, or so-called bounded-contexts in the software promises better clarity and simplicity, avoiding spaghetti-style applications where everything is connected with everything else.

Benefits

Context is important and it defines application boundaries. And our three contexts easily map to application architectures commonly used in the Comms industry – Products in the “what you buy context”, belonging to so called Business Support Systems (BSS) layer, Services in the “what you operate context” to OSS – Operational Support Systems layer and Resources in the “how you assemble context” to Network Management Systems layer. Benefit of separating the three is called separation of concerns, and thanks to that our software becomes clearer, simpler to comprehend and easier to maintain in the long run.

But that’s not the only benefit – contexts are dynamic, they coexist and transition one to another. So our Product, Service and Resource don’t live in isolation, they need to interact. And for that purpose – we have interfaces – a set of methods each context “exposes” to the external world to interact with it. These methods “encapsulate” our contexts exposing everything that is needed to the external world and hiding everything that is internal, and not relevant.

This is where another benefit arises. Because we’ve separated Product, Service and Resource constructs and we have only coupled them at their boundaries – at the interface level – we achive something that is called “loose coupling”. So it is easier for us to make changes within boundaries of the context, while keeping other contexts untouched. Let’s make it practical, let’s say you have invested millions of dollars to build an orchestration platform enabling you to spin up on-demand IP Services in the matter of seconds – most likely you’d want to avoid needing to rebuild that in case your marketing team comes up with another great idea of repackaging Internet Product offerings. And the same you’d want to avoid needing to change that if your technology team suddenly decides to use screws and bolts from Company X instead of Company Y.

Summary

PSR Model and the separation of Product, Service, Resource is a common concept in the Comms Industry and originates from original TeleManagement Forum frameworks. And if you take a closer look at the architecture diagram outlining the MEF LSO framework – it is also visible there – this picture can easily be mapped to our Product, Service and Resource constructs.

That’s it for Today, I hope you liked these a bit philosophical considerations. Again a longer episode, but these are not so easy things to explain. Let me know what you think about the topic in the comments, and if you have any topics you’d like me to cover in the next episodes – let us know.

Cheers!