People often ask me why, as an IT Architect, I have an interest and expertise in co-creation. When I tell them it is because it is a technical subject they are often sceptical. I should say here that I mean co-creation in the business-to-business sense of jointly created solutions. I also work in IT for an IT company so most things I do, including co-creation, are inherently technical. I explained my take on co-creation, and my interest in it here.
When you start to look at any IT solution regardless of the number of parties involved there is, of course, a technical dimension. But this is not what I mean. When you introduce two parties working to co-create a solution you get some situations and technical challenges you don’t see when working within a single organisation. You also get lots of other challenges that can inhibit co-creation like worries about IP ownership, cultural clashes and mis-trust but those are subjects for another post.
Technical challenges occur especially when two IT companies come together with their unique expertise. This is especially true where there are solution elements that are needed to enable the main co-creation offering that either party could provide. Solutioning your way through two IT companies worth of technical enablers is a technical challenge. Patterns can help with this so you can have a jointly held definition of which components are going where but it is still a technical subject.
When you start to look at any IT solution regardless of the number of parties involved there is, of course, a technical dimension. But this is not what I mean. When you introduce two parties working to co-create a solution you get some situations and technical challenges you don’t see when working within a single organisation. You also get lots of other challenges that can inhibit co-creation like worries about IP ownership, cultural clashes and mis-trust but those are subjects for another post.
Technical challenges occur especially when two IT companies come together with their unique expertise. This is especially true where there are solution elements that are needed to enable the main co-creation offering that either party could provide. Solutioning your way through two IT companies worth of technical enablers is a technical challenge. Patterns can help with this so you can have a jointly held definition of which components are going where but it is still a technical subject.
Even when only one of the parties is in the IT game it is not simple and there are still technical challenges to overcome. Imagine a co-creation situation where there is a domain-player who has some data that the IT partner is going to enable via APIs and then offer as a service to third-parties. Here again there are IT challenges. How are you going to share the information you need to enable your revenue-sharing? What is the technical solution your support teams are using to collaborate? How do you refresh the data from the domain expert to the IT organisation?
On top of this I also consider the delivery method to develop the co-created solution a technical subject. Working with another party to co-create a solution is different to doing it all in-house. You need to focus more on upfront agreements, you can’t assume everyone knows your solution lexicon and in short you need to adapt you delivery method to include your co-creation partner.
So, yes, I think co-creation is a technical subject.
Images: Nestor Rizhniak/Shutterstock.com and sabrisy/Shutterstock.com