...that happened to 'IT' in the last decade.
Once upon a time...
the craft of software development was performed under the umbrella of data processing and those performing the tasks had titles like programmer, designer, analyst or something along that line. Some of them even came from "computer sciences" or "informatics" but: all of them acted on data or information.
Nowadays - I'd say since the late nineties of the last century - there seems to be a clear line between "business" on one side and "IT" on the other. That wouldn't need to be too bad, but since the "T" in "IT" stand for "Technology" it is.
The "Technology*" metaphor affects both sides. Developers, projects managers and even (software) analysts and designers just take the input - be it concepts or orders or functional descriptions - and try to implement it (or design the system) as good as they can. Business analysts - or who ever describes the content of the project - concentrate on their part of the story and ignore any technical implications.
Sounds fine - doesn't it?
Unfortunately it does! But this seemingly sound separation of concerns is in fact one of the main reasons for time-and-budget overruns, immense time to market durations and similar problems (aka "the new software crisis").
Lets have a slightly closer look at the problems arising from that separation.
Technology & method savvy people get confined to the "techno-space"
Putting all those people with systems design education and experience on the technological side of the imaginary "IT fence" leaves no-one with up-to-date knowledge on the business side of that "IT fence". Of course some business analyst are happily nudging away on the business side of the fence, but they are clearly in the minority.
Most businesses are un-precise by definition - so that is what the business people need to be
To be successful in business a certain degree of leeway is absolutely necessary - people (and most customers are people, even if some of them - namely some of those from the centralised purchasing departments - try to hide the fact) are extremely informal in their perception of the world and in order to generate business you'd better be flexible too.
Business problems don't have to be hard to be expensive - it's sufficient if they are based on "common knowledge"
In the early time of software development software simply was the only way to solve very complex but well defined problems. Finding the correct trajectory to shoot three people from florida to the moon would be one of those well defined but complex problems. Later on there came other types of problem: seemingly simple problems with ambiguos definitions - lets say tax collection. Although theses are 'not exactly rocket science' and you easily get along with the four basic calculation types there are volumes and volumes of law textbooks and interpretations even for one type of tax.
The problem gets worse when people try to describe - or even define - a process 'unambiguously' without proper knowledge. Just try to describe the behaviour of a lift without diagrams. Now add time-awareness and route optimization. And add a second lift, coupled with the first one.
Formal methods should be applied much earlier
Now if you thought of all those fancy diagrams from one of your favourite methods to describe the problem above your probably living rather close to the "T-fence". I personally cross the border very often - either from one assignment to the other or during one single assignment - and every time I introduce some little formal method to business people I am overwhelmed how fast and efficient these methods are applied. It's not that these business people are dumb or ignorant - the problem is just that they don't have a focus on formal methods and are often actively separated from them by the IT-departments.
Agile processes try to circumvent this problem but fail to consider typical german mindsets
It's not only that business and IT use different (formal) languages but also the distance a piece of information has to cover to get from people thinking "business" to people thinking "systems" and back. So the poor guy trying to implement something has not only got to figure out how to implement it but also "what did he/she think that he/she thought what he/she was thinking - and what the heck could be the business reason behind all of these interpretations?". These assumptions - made by the last poor guy in the line - are what eventually make the systems work.
In my opinion the agile processes are a very good way to bridge the distance from business thinkers to systems thinkers (e.g. by placing them very close together) but they unfortunately fail to take local (in this case German) mindsets and organisational patterns into account.
To effectively overcome this situation the "fixed price addiction" (as one of the more direct agile protagonists once put it) has to be overcome - but I'm afraid that will still take a while. In the meantime it could help offer more support to business people earlier.
"bring together, what belongs together"
On the other hand it might be a good idea to allow for more business awareness in the IT-Departments to become more of "systems thinking departments". Although most of the systems work in the end they could get there much faster if the implementing departments would be willing to think more business oriented.
Although this will probably not happen any time soon (at least in Germany) this is one of the occasions where a small step backwards might turn out to be a giant leap forward. So perhaps it's not only about insourcing ousourced IT-departments but about integration of IS knowledge.
Stop using the term IT, make it IS (Information Systems) or something even more appropriate.
Any suggestions?
* BTW: It is even worse with the german word "Technik" because that is often interpreted as "mechanics".
Powered by Qumana
