A simplification of IT architecture would have far-reaching impacts across the whole of IT.
Over the past weeks we have been considering a simpler IT architecture, made up of independent systems that encapsulate their technical implementation, and which are aligned with the responsibility structures of the organisation.
We need more debate about whether this simpler architecture is feasible, or desirable. This week I want to put that debate aside, and think about the implications if we can and do adopt this simpler architecture.
The most obvious change is that the new architecture would remove technical layers, such as databases and middleware. These capabilities would of course still exist, but they could be standardised and hidden inside the systems. They would not need so much management, and we would need fewer specialists.
The new architecture would mirror the business structure. There would be no need to map layers of technology to applications to business areas, and there would be no need for enterprise IT architecture.
Many of our current approaches to managing complexity would not be required. For example, we currently use business process management (BPM) tools to show a business process view across multiple systems. But if systems are aligned to responsibility structures, and interfaces represent real flows of business meaning, then there is little scope for adding value with BPM tools.
There would be impacts on projects. Because the IT structure reflects the business structure, the IT response to business change would be more focused, and there would be no IT-enforced impacts from sharing IT between business areas. IT projects would be smaller and more firmly linked to business change. It would also be easier to identify and justify the minor changes required to stop systems declining into legacy status.
There would be impacts on IT management. There would be fewer large IT projects. There would be less need for an IT work plan independent of a business work plan. There would be no need for IT-lead decisions on the value of IT.
Because the units of IT are smaller and simpler, development tasks would reduce. Analysis, programming and testing would be simpler, though there would be new requirements for explicit integration rather than implicit integration through data sharing, and for coping elegantly with data differences between independent systems. The architectural simplification may even allow a new generation of effective end-user development tools, possibly something like multi-user Excel on steroids, properly integrated to all the other business systems.
The impact on IT professionals could be profound. There would be less need for all types of IT staff: technical specialists, architects, project managers, development staff. IT departments may end up more like HR departments, giving specialist advice but leaving day-to-day management with the main business.
This is all just a hypothesis. But we must not reject the hypothesis just because we do not like the dismantling of traditional IT. We need to consider what other types of IT will grow in its place, which I will cover next week.