What is your business?

Should “the business” care about IT? Should an investment bank trader know anything about XML, or a marketeer know anything about SQL? Probably not. Even less so should they be talking to their IT colleagues of their requirements in these terms. The business should speak to IT in a language of value driven requirements rather than implementation detail. Yet in many organisations (where IT has historically had a track record of failure), the business has taken a greater interest in IT delivery. They start talking the language of the techie. When this starts to happen business operations no longer see the clarity of their business. They see systems. In an investment bank setting: the trade is booked in Zeus. Settlements are handled by Minotaur, payments by Socrates. Corporate actions are handled in Hades. Depending upon the geographic region, client management might be handled by Tomsys, Dicksys or Harrysys. You ask a business person what do they do and they talk in terms of systems. Getting down to the underlying requirements of what they actually want to do is hard. Innovation and creative thinking are hard because we always return to what the limitations of the current systems are. Why there is a requirement for a Reconciliation System rather than asking why there needs to be any reconciliation in the first place.

So here’s a suggestion. Act dumb. Forget everything you know about the way you do things and go back to first principles. How would things be if we were starting from scratch. How would you describe your business intent (not the what you do now, rather what would you do) if you had to explain it to a novice who was starting a competitive business to put your business out of business. I doubt the word system would come into the description.

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

1 Comment

  1. dancingmango » Code I understand · Tuesday, 19 June, 2007

    […] I enjoy the former, but I’ll confess the latter is usually gibberish to me. So what joy it is to read a blog that describes code, but is eminently understandable. Behaviour Driven Design that Dan talks about not only makes sense, it is also understandable to someone like me who is not a code polyglot. My last blog was critical about the Business finding themselves talking the same language as IT… how refreshing it is to see code talking the language of the Business. […]

Leave a Reply