Most technologists are familiar with the concept of transclusion, but this is not necessarily the case for entrepreneurs.
It is another example of why innovation happens at the intersections of life or business.
- Cut across traditional boundaries and you will find places, people, products and processes that are often central to where or how new improvements are found.
- Tech startups founded by one or more geek entrepreneurs would have awareness of transclusion from their technology (usually software) training and naturally apply it to their business design.
Basically, to me (with my geek hat on), transclusion means avoid duplication or reuse existing code or apply use best practice PLUS be open to how these are employed or integrated.
- Why copy a piece of code from another place when you can refer to it (or call it in at run time or integrate it) and hence benefit in both places if the original source is improved.
- The downside is it introduces a new dependency into your software or business but usually it creates a new network effect or shared upside incentive to collaboration too.
As an entrepreneur however I think we can interpret transclusion to have other wider meanings, hence the reason for this article.
Why Apply Transclusion?
- Speed to market. Stop reinventing the wheel. Reuse an existing thing rather than rebuilding it.
- Confidence. Usually the original has been tested and used by others already.
- Best practice. You spend your time picking the best code (or service) to reuse rather than design, build and test your own.
- Open Innovation. We might have started talking about code here but in reality you should be looking at services (e.g. payments, reputation, social network connectors, analytics), communities and marketplaces (especially integrity and liquidity). Others are relying on and often improving these services so you get benefits.
- Focus on Outcomes. As above, you start looking at wider benefits (e.g. is it easier to login with social APIs like linked/facebook/twitter) not just code.
- Adaptability. If I reused an existing (e.g language translation) service rather than build my own, when I want to add another option/feature (e.g. new language to the list of supported translations) it is a standardised step that has been done many times before not a hardwired stove pipe built only for one set of situations.
How to Apply Transclusion?
- Example implementations out in the wild are extensive and go by many names such as include files, include scripts, application programming interfaces (API)s, service orientated architecture (SOA), service design, functional partitioning etc…
- The purists will comment below and point out to me the subtle (and sometimes dramatic) differences between each of the above technical terms, they are not lost on me technically (I did do comp. sc. at university) but today we are talking about transclusion in a entrepreneurial context and hence include business growth considerations more than pure technical definitions.
- The gist of all this to me is simply thinking about reuse from the outset so that your technology or business is architected to allow the use of open innovation ideas AND techniques including transclusion if the opportunity arises and more importantly you make sure your culture keeps it in mind each time you do something new, make the decision to allow a considered decision where you evaluate options rather than just diving into a particular path.
Why not use Transclusion?
- Risk. New dependencies you could otherwise avoid and might fail. (e.g our project management system we use in Sydney Australia was recently taken out by a hosting provider to one of our information management tools when New York City was hit by a hurricane but the productivity benefits of the tool outweigh the risks and longer term they will fix that issue for all current and future clients).
- Over Analysis. You could spend more time looking around than it takes you to build one or grab the first alternative that comes along. Usually people use this excuse. But often it is the area of greatest upside. e.g. Would you prefer to build you own card payments connector or reuse an API that give access to hundreds of millions of existing customers than not only can pay with it but are familiar with the user experience, you are getting additional trust and confidence in your customers mind – something that is very expensive and time consuming to build/acquire.
- Lots more but they are the main ones.
So how to decide?
- Which technology?
- Which service?
- Which vendor?
- Which options?
Often it is all just made a lot easier if you ask these questions –
- Is it my core business? ie is it one of the things you plan to differentiate on or is it a marginal side service that is needed but not core to our unique offering. Another way of looking at this is can I leave it out all together (focus) or can I change it easily (later if in the unlikely event our decision was wrong and creates a problem) or do our key stakeholders already have a certain expectations (e.g. email and phone as obvious contact methods with acceptable costs).
- Is it available and acceptable to all my stakeholders (i.e. can I buy it at the right price and service/risk level to keep customers, investors, team, regulators, community) all happy?
- Is it going to add other benefits? e.g. a network effect of other users that already know how to use that payments system or a cost reduction trend because leading cloud computing providers are dropping prices.
So next time you are considering a feature, think about transclusion.