One longer-term objective of Upstarta has been to bring out a book. Having done previous analysis of the publishing industry and its effective benefits to authors (or the lack thereof – I might do a post on that some time!) I decided to self-publish. After all, shelf space is rare anyway but you can get your Lulu book to Amazon without hassle. What an expiring writer also needs is some project management to keep an eye on time, progress and structure: in summary, a good editor!
In April I had a rare opportunity to meet face-to-face with an editor-friend (we literally live on opposite sides of the planet), and while reviewing content is easy to do online, discussing structure is much easier in-person. We came up with this rough section layout:
This looked entirely sensible. But then somehow I got stuck fitting the content in to there, and worked out only months later that the above had something to do with it. This is not how disruptive non-funded businesses start! Instead it follows the flow of traditional businesses; and it’s exactly that process causing problems which Upstarta addresses…
The actual Upstarta process is not quite linear, but it can be described in chunks and some concepts should be dealt with before others. So while I love my wiki (it’s the visual-spatial thinker in me), it can be molded into a book.
The lesson is that it’s very easy to fall back in to “classic” thinking patterns, and you may not realise for quite a while that you actually did – meanwhile several layers of decisions get built on top. It can really mess with things, and in essence waste valuable time and often also money. In some cases, it might not even be fixable any more. The “getting stuck” was a pattern I should have questioned in more detail straight when it occurred. In this case it’ll be ok, just cost some time.
Modularity is about business processes as well as software or system design. The Innovator’s Solution (Clayton Christensen, Harvard Business School Press) analyses this very well, identifying modularity as a phase, or more accurately, a state in the going development cycle.
Choosing modularity as a core objective, as many appear to do these days, does not appear to be effective. Trying to make something modular when the subject is not fully understood and the interfaces not clearly defined and predictable can be fatal.
When, in order to make a product or process good enough in the current state of its market, it needs to be tightly integrated… then that’s the way to go. The system will evolve to a point where modularity at that point makes sense (for a period of time), with tightly bound sub-systems.
Looking at products (including software), consider the business processes in the market. For instance, the packaging (not necessarily physical, but documentation, support and other services) and other logistics are also part of the whole, and may well be suited to modularity (e.g., one company offering support for a product that’s built by another) even if the product itself is tightly integrated at that point in time.
In summary, modularity is not better or worse than integration. Each has its place, depending on the state of the market/ecosystem where the process/product/service operates. Part of a system can be in a modular phase, where another part of the same system needs integration.
At a user group meeting last week I got talking with someone who was working on an interesting PhD project. It was not IT related, but as part of the PhD he was developing a website offering a really useful service to people. When I asked “so when will the website go live?” he answered “mid next year”: PhDs are a three-year thing and he needs to span the time.
What a pity. That site should go live as soon as possible! Also, there might be some business in it, but with a longer time-to-market you run a serious risk of “entering obsolete” or at the very least encountering seriously changed market conditions. The world moves faster these days.
And think about it… once online, there’ll be data to collect and analyse that’ll also contribute to the thesis, that in itself will take considerable time. You’d want to get the site up as early as possible, for this reason and to have more time to learn from the real world and fine-tune the service.