Why Qualitative Enterprise Architecture Data Really Matters3 (1)

Why Qualitative Enterprise Architecture Data Really Matters

When market conditions are tough, management agendas typically switch from expansion to retrenchment, and cost-cutting is the order of the day. Faced with demands to reduce costs by rationalising their IT application portfolios, many organisations require their enterprise architects to produce a list showing which applications perform the same functions. The results are typically quantitative views of the application landscape: numbers that indicate the potential for rationalisation, but not the story behind those numbers.

Why Qualitative Enterprise Architecture Data Really Matters

We believe that taking actions based on the numbers alone – particularly when they are elegantly presented with the aid of modern visualisation tools – can be counter-productive or even dangerous.

Informed decisions need not just quantitative analysis, but also a qualitative analysis that reveals what underlies the bare statistics provided by the quantitative view. For example, two order processing applications that apparently perform the same high-level functions may have been selected or adapted to serve business units with completely different needs. Top business executives can often be led to take decisions on such issues while being unaware of the disruptive consequences.

Case Study 1

We know of one chemical company where the CFO persuaded the Board that a strategy of standardising processes and systems across all its business units would significantly reduce costs across the entire organisation. He further argued that common systems supplied by a reputable package vendor would improve overall control of the business by generating more reliable and timely accounting and reporting information. It was only when senior product managers fully appreciated the impact of this strategy on their own business units’ operating models that red flags were raised. Some managers pointed out that the recommended package solution would fail to meet their specific needs, while one business unit head claimed that it was far too sophisticated for his operations. His unit had a single plant designed to manufacture two bulk products in a continuous process lasting several days. “We simply make one product until the collection tank is full, then clean the pipes and switch over to the other product”, he explained. “Why would we need this complicated planning and stock allocation system just to manage that?”  To add insult to injury, the CFO proposed to allocate the costs of the new system to business units according to their sales volume, thus further penalising the bulk products business unit. By taking due account of the different business requirements, the happy outcome was an agreement to implement the package solution for common accounting and reporting, but to deploy it selectively for other business functions. This required a qualitative analysis of the needs.

Case Study 2

The superficially attractive case for one-size-fits-all solutions to generate savings in a diverse business environment is a very common trap. A classic example, now featuring as an academic case study, is the Australian State of Queensland’s Shared Services initiative. Launched in 2003 as part of a government efficiency drive, this initiative aimed to provide common, shared back-office services covering the State’s entire range of departments and agencies. The needs of the Human Resources function were to be addressed by standard processes and systems for all activities from “hire-to-retire”, with SAP’s HR module selected for payroll management.

The pilot implementation of the payroll system for the Department of Housing, a small agency with office-based staff, was completed in 2007, and there was a two-year plan to roll the system out to all other departments. To cut a long and tortuous story short, the Queensland Health Authority’s implementation of the payroll system for their 78,000 staff turned out to be a complete disaster. When the system went live, a very large number of employees were overpaid, underpaid or not paid at all. Unsurprisingly, this led to industrial action, loss of staff members to other employment, and the resignation of the Minister of Health. The failure of the system and of repeated attempts to fix it meant that the Health Authority had to hire a thousand clerical staff to make many thousands of manual adjustments to the fortnightly salary payments. So much for the promised efficiency savings. And all this despite the deep involvement over several years of a series of prestigious external consultancy and systems integration firms. Needless to say, the costs of the remedial action were eye-watering, exceeding a billion Australian dollars by 2013. A Government report on the project, commissioned in 2013, stated that “Its failure, attended by enormous cost, damage to government and impact on workforce, may the most spectacular example of all the unsuccessful attempts to impose a uniform solution on a highly complicated and individualised agency”.

All this misery could have been avoided if a qualitative view of the enterprise architecture aspects had been taken from the outset, and then acted upon. Such a view would have soon revealed the true mind-blowing complexity of the situation. This included 300 separate work sites, 18 different industrial agreements and awards, 205 separate allowances across these agreements and awards, 223 different calculation groups of employees, and 146 different calculation rules that could apply to each calculation group. Some of the highly paid external consultants engaged in this project must surely have realised that applying a standard HR package solution with a few tweaks to this morass of system requirements was ‘mission impossible’. Indeed, some of them may even have thought it a good idea to first launch a programme to simplify the number of payment options, and in parallel consider a range of IT solutions suitable for each payroll scheme.


Skilled enterprise architects understand the importance of marrying qualitative data with quantitative data. However, acting on the results of such a qualitative analysis would have been extremely challenging in a situation like this, given that so many peoples’ reputations were at stake. That would of course have required astute sensing and handling of the corporate politics: a vital Enterprise Architecture skill that is certainly not covered by a standard TOGAF course.

Useful Links:

Queensland Health Case study – Henrico Dolfing

The Role of Qualitative Data in Making Business Decisions – Chris Walden

Contact Us