Last week, there was the news that the Federal Employment Office of Germany will claim for the return of excessive payments from potentially more than a million so called "Hartz 4" recipients. What appears to be of political and social relevance, is as well interesting for IT - because it's about the negative impact of archaic software architecture.
Let's start with the background. Hartz 4 stands for as well social welfare aid as unemployment aid, named after Peter Hartz, a former Volkswagen member of the board and advisor to the German government about how to change and optimize these aids and insurances. There is a significant number of Hartz 4 recipients. Many of them are either families or single parents. Starting Jan 1st 2010, the child allowance has been increased by 20 € per child and month. However, child allowance is charged against Hartz 4, thus Hartz 4 recipients with childrens shouldn't benefit from that increase - not that social, isn't it?
Now the problem arises: Many have received the 20 € (or x times 20 €, depending on the number of children) increase - and now that shall be reclaimed. The Federal Employment Office came up with the explanation that this has been because the short period of time between deciding about the increase of child allowance and the due date. However, there were some weeks in between. Regardless of whether the money will be reclaimed or not (there are interesting legal discussions about), that clearly shows, together with other explanations, that there is an IT issue behind.
That issue is a software where such a change obviously has been to complex to perform in time, in a planned, structured manner. That is, looking at topics like "Software Architecture", "GRC", and "Externalization of Security", pretty interesting - especially from the GRC view on software architecture. Obviously, a change of a business policy couldn't be transferred to the software just in time. That is a typical GRC issue: Business Policies which lead to complex change process in IT, when code has to be adopted to these changes. That leads to issues like time-to-market or, in that case, has a significant social impact. From a GRC perspective, that is an issue - a governance issue IT management has to deal with. IT is a software architecture issue, because such problems occur only due to a non-policy-aware software architecture and due to hard-coding things which shouldn't be hardcoded. Think about a policy-controlled software and defined request/approval workflows for such fundamental changes. That isn't hard to architect, it should just be good practice. It would lead to applications which are acceptable from a GRC point of view (with GRC being much more than security...). It were secure. And, most presumably such a software would rely on policies and thus externalization as well for security, especially access controls.
There is little reason to assume that the Federal Employment Office has a software in place that meets these fundamentals of good software architecture. The real bad thing, besides all the unnecessary costs associated with such archaic software, is the negative social impact of that.