In the software business, there are several unforgivable curses which deserve a one way ticket to Azkaban. These include "What backup?", "What version control?" and "What testing environment?". Fortunately, the days when you might have heard such words are long gone as we all have learnt the folly of the dim distant past.
However, we are always living with our future curses, e.g. the naive and foolhardy things we do today which we will laugh at tomorrow. So, I've decided to pick out a couple of candidates for future curses.
What model?
The purpose of business process modelling (BPM) is not just to provide a view of what we do as an organisation but also to enable an architecture to be built to support our current and future activities. Obviously we cannot model innovations with any certainty, they are constantly changing. However commonly repeated activities can be modelled and subsequently used to create a supporting infrastructure. I was under the misguided impression that companies embarked on a Service Orientated Architecture (SOA) after first having examined what they do by Business Process Modelling (BPM). Apparently this is not the case, some companies start building without actually knowing what it is they do. There is always a balance to be struck between the two morals of "an imperfect plan executed today is better than a perfect plan executed tomorrow" and "proper planning prevents poor performance". I'm not sure that this novel approach achieves this.
What lifecycle?
Whilst BPM will give you an overview of what you actually do and help in the design of an architecture, it doesn't actually tell you how you should manage an activity or process. As I've mentioned before, I tend to "colour-in" my models to identify activities at different stages of their life-cycle. This provides me with information on how to deal with an activity, for example :-
- whether an activity is ripe for outsourcing or SaaS (assuming a suitable external ecosystem of providers exists).
- how I should manage a particular activity (for example more agile or more defined processes e.g. SCRUM or Prince 2).
- how I should measure it.
I'm fully aware that this runs contrary to our desire for simple measures; however even a simple measure such as ROI (return on investment) is only valid for particularly stages of the life cycle. For innovations, you need to work on a worth based mechanism whilst cost is your only ally with CODB (cost of doing business) activities.
Arthur C. Clarke said that "any sufficiently advanced technology is indistinguishable from magic". We shouldn't forget that we are all just underage magicians and tomorrow will look back at much that we thought was "magic" and just cringe.
Additions
I couldn't resist but add a few more unforgivable curses.
We only release once per month
Commodity like activities should be released or updated as little as possible, once per year is probably once too often. Innovations need a completely different timescale, once a week is possibly too slow. The one size fits all idea is instead one size doesn't fit anyone.
