In a world where the business is increasingly performed using digital technologies and where the younger generation is IT literate, do we still need an IT department? That is actually an interesting question. It’s true that some industries have become driven by information technology. Think about the financial services industry or telecom. Most financial assets only exist as bits and bytes on computers. All communication is digital these days. That implies that every member of the organization is using information technology on a daily basis. So, why do we need a separate department to build, manage and evolve the environment and associated tools? And if we do, what functions should remain in that organization?
Remove the IT blaming factor
Many business teams complain that IT is always lagging behind and unable to deliver required services in time. If functionality developments are performed within the business teams, there is no place anymore to blame IT. The department has everything under control, manages the resources and funds the developments. So, they have it all under control, or at least they should.
On top of that, as the development teams are part of the business, the translation of the needs required for the IT department is no longer needed. If on top of that, the business uses agile development methodologies, the business owners are part of the scrum teams and can steer the development teams to deliver exactly what is needed by the business. This sounds like a great idea, isn’t it?
There is a third advantage of this approach and that is that, because the business directly pays for the developments, we can expect them to perform proper return on investment analysis and only fund developments that have true returns.
What if a development spans multiple departments?
There is a small issue though. Business Processes often are not limited to one department. They actually cover functionality performed by several ones. For example, an order entry function not only involves sales, but also finance, for credit check for example. If we go with the approach highlighted, we now have a development team in sales delivering the sales part of the functionality, while another team, part of finance, deliver the credit check and other financially oriented functionality. Sales and finance need to agree on the interface between both functionalities and funding.
You can argue they have to agree on the combined process anyway, so this is only an extension to something they already do, and you are right there. Coordination is happening directly at department level.
And what about managing the environment?
Up till now we have only talked about development. And it could make sense to have development handled directly by the departments. However, once the functionality is developed it has to be operated so the end-users can actually do their job. Does it makes sense, even in a fully cloud based approach, to have the management being performed on a department by department basis. I would say no. The reason is that such a departmentalized approach leads to trouble at the intersection between departments. Let’s take our order entry example. The sales team is managing the actual order entry functionality while finance is doing the same for the credit check one. If a problem occurs whose origin is not crystal clear, the blame game can start. We see this often when multiple suppliers are involved in delivering the management of an IT ecosystem, and often it is not pretty. So, it probably does not make sense to perform the management at departmental level. This leaves us with two options, either it is done by a third party, agreed upon enterprise wide, or by an internal department set-up to perform that function.
And security & compliance?
Security and compliance are two critical aspects that we need to keep in mind. The latest international news has demonstrated that hacking is truly on the rise. Every company has to remind itself that it is a potential target to hacking and that being a victim can make a lot of damage, not just financially but also to the brand. End-to-end security has to be taken seriously. This means an enterprise-wide team needs to be responsible for defining, analyzing and combat security breaches, there is no way without it.
Compliance is another one of these cross-enterprise topics. The new European privacy regulation for example is forcing to take a hard look at how data is treated throughout the enterprise. You could argue this is the responsibility of each department and that naming a responsible at department level can easily address that. However, here again, the cross departmental approach needs to be addressed. So, either you put a strong governance in place where the departmental responsible people work closely together or you name one person to drive an end-to-end approach.
And standardization in all that?
Performing the developments in the business teams may make sense, but two things have to be taken care off, first the ease of integration between the functions developed in different departments and second the ease of management. Both lead to the establishment of standards, both from a coding/development and technology perspective. One entity should decide which standards are used and should maintain the list to ensure consistency. This again leads to a proper governance as you do not want to kill creativity by being too rigid in the choices made, but at the same time put boundaries on what can be used.
If the organization decides to implement DevOps to speed-up the delivery of new functionality, the key processes, the tools used, even the installation scripts of middleware, database and other common elements needs to be standardized to optimize the IT ecosystem.
And then we have SAP
In many companies, the base system of record functionality is provided by a COTS (Commercial of the Shelf) package from companies such as SAP or Oracle. Those packages cover functionality in support of many of the back-office departments and sometimes even front-office ones. It rarely makes sense to split this functionality up by department and getting each entity manage their own piece. A common group looking at all the SAP or Oracle functionality makes sense. So, from that perspective, having a separate IT department seems a good idea. However, who is willing to take care of only these systems as their management might not be the funniest job in people’s mind.
Should IT become a governance body?
IT has moved a long way since the ENIAC programming days depicted in the picture illustrating this blog entry. With IT literate people in each of the business teams, it makes sense to have them developing the functionality they require, under an overall guidance from a standards, compliance and security perspective. Does that mean that the role of the IT department limits itself to define the standards and key processes required to take the functionality into production?
Yes, there is a need for central operations, but in an increasing amount of companies outsource those activities. That leaves the foundational applications such as SAP and Oracle, but those can also be outsourced, leaving IT as a governance entity to coordinate all information technology related activities across the entire company.
Things will not change in one day, but it is clear that the role of the IT department is due to change drastically over the coming years as business people increasingly take their IT requirements in their own hands. How far companies will go will have to be seen. If a separate IT department is retained it will look different and its responsibilities will evolve.
Do you agree with my assessment? How do you see IT evolve?