Object Oriented Management
It’s both surprising and not surprising at all just how alike software is with business structure in general. It’s surprising in that it’s not something someone not familiar with software would expect, and it’s not something someone familiar with software would think of. But it’s not surprising in that both modern software and business structure are systems built with interactions and behaviors defined for some purpose.
The benefit to this is that you can frequently see anti-patterns that normally would smell in software, out in the ‘wild’. Think of the committee who must approve everything?(Sounds like a ‘God-Object’ to me) or the fact that an Engineer might have to handle his own schedule reporting rather than deferring it to an expert.(Sounds like someone gave out responsibilities to objects wrong).
The fact that so many business policies are so convoluted and hard to follow in the first place smacks of spaghetti code. Business policies are nothing but a bunch of ‘patches’ on a flawed base, each policy oriented to solving one specific problem, while the foundation beneath is in sore need of a rewrite. And when this happens the same symptoms of a fragile, unmaintainable architecture arise – more managers(bodies) have to be thrown at it, more money has to be thrown at it, and ultimately bugs(and potential for fraud) creep in.
Hilariously enough, you can even see the same approaches to approaching ‘business engineering’. Who doesn’t know of that one guy who couldn’t write a for loop to save his life, yet marks up your code in peer reviews complaining about the names or style? The same thing happens when vice presidents earn their wings by simply changing around acronyms!
To build an efficient, easily understandable business system (and believe me, easily understandable is the best way to go. It saves you tons of money in training and maintenance (not as many middle managers) and its more transparent across the board, reducing the risk of fraud or negligence.) you need to use the same object-oriented techniques to create a clean design up front as possible, and upon any rework, be willing to ‘refactor’ your business to take on new responsibilities that you originally didn’t see before.
Here’s an open question, though, do other software techniques apply to the business world? I can easily see ‘Aspects’ having a role in business engineering. But functional style or procedural style really don’t seem to make sense. I might just not be thinking hard enough on that.
1 Comment »