The organizational design of the IT department in most firms was based on the ‘not invented here’ syndrome: everything was designed, built, and supported by resources internal to the company. The needs of the business, the segment it operated in, or the proprietary business processes and knowledge built up over time meant that it needed specialized IT applications and infrastructure to meet its needs. These were built by purchasing basic infrastructure like servers, storage, network equipment and circuits, with all design, configuration and programming done in-house. Operating systems, middleware, databases and some tools would also be purchased, but the IT team would take pride in building everything else themselves.
This led to the organizational structure shown in Figure 1, with a lot of specialized functions in the IT department, all staffed internally.
The client or the consumer was serviced by the business which had business operations teams that used standardized processes to guide their work, but with enough flexibility in their thinking and communication skills to be able to work with the business and the end customer. These business operations teams were the interface to the IT department that built the applications that helped gather, process and store the information of the business, making the business processes easier and efficient.
IT had business relationship and product/service management teams that would perform the analytical activity of understanding what the business needed, choose what could be provisioned and communicate that to the extremely literal and detail-oriented teams of architects, developers and project managers. IT asset and financial management teams would control the contracts, suppliers, budgets and coordinate the work so the applications could be put into production without straying too far from the scope, schedule and budget. Operations and Infrastructure teams would build, monitor and fix the platforms used, as well as some services like telecom, circuits and the internet. Application Support teams provided specialized support for the application deployed, front-ended by the Service Desk that handled customer calls or requests.
In the diagram, the vertical blue arrow represents the flow of feature demand from the business as it is translated and implemented in the applications and supported for the customers. The horizontal arrow represents the shift that occurs as the fuzzy ‘what’ that is needed by the business is translated into the precise instructions that say ‘how’ they will be realized. Inside the IT department, as we move down the diagram, the work becomes more standardized, precise and detail oriented.
Initially, with the introduction of Commercial Off the Shelf Software (COTS), followed by the proliferation of Software-as-a-Service (SaaS) products, IT departments started buying some of the apps needed by the business while still building those that differentiated the business. They continued to provision the infrastructure used in their own data centers or co-location, i.e., the network, compute and storage needed to deliver the apps. The move away from proprietary applications meant that there was less demand on architects, developers and project management. Even application support could be sourced from Managed Service Providers (MSP). While outsourced support for proprietary applications has become popular, it cannot match the value optimization that a SaaS replacement can, due to economies of scale and automation. The transfer of knowledge and insight into the architecture and code needed to support a proprietary application means that the savings are limited. A SaaS application built to be supported at a lower cost and a lot of automation built-in provides unmatched value optimization.
Recent technology trends are changing how the IT department needs to be organized, moving the focus from hardcore technology skills to business and financial expertise. This is shown in the Figure 2 below.
First, the move from monolithic software applications to the use of micro-services as well as the concept of business process composition has meant that architects and developers need to look outward for services that provide what the business needs. The differentiation is in how these services are composed into business solutions, and how quickly they can be put to use making money for the business. Many application functions that used to be painstakingly coded can now be purchased from reliable vendors with performance guarantees. This requires the opposite of the ‘not invented here’ syndrome to be successful, as well as being open to using CTO-as-a-Service (CTOaaS) to quickly develop an outward view.
Second, internal applications are also built in the same way, exposing Application Programming Interfaces (APIs) so that other teams can integrate and use them more easily. The graphical user interface on the mobile or web device is not the only consumer of these APIs, but rather other services, orchestrators or even business partners and customers. This allows the business operations teams to become technologists who modify the digital implementation of business processes on their own without involving developers.
Third, the move to cloud-based infrastructure for compute, storage, network and telecom, as well as the proliferation of SaaS applications means that the IT department no longer needs as many 'build and operate' team members as it needed previously. As many of the cloud vendors also include/provide extensive middleware services such as databases and queues, the monitoring is built-in and operations are automated, thus deep technical knowledge is no longer needed in the IT department.
Finally, as the proprietary infrastructure and applications are replaced by standardized implementations from external vendors, it is easier to get MSPs to provide the support needed. With larger teams and the ability to leverage automation tools and follow-the-sun support, these vendors are able to promise and achieve service levels that small internal teams cannot.
As more of the IT department work is moved to vendors, the IT business and financial management teams gain in importance and need tools to perform their work effectively. New metrics that measure the vendor performance in combined dashboards that enable quick action in case of contractual slippages or misses, as well as easy movement between vendors to improve competitiveness. In order to quickly bring in the required expertise, use of CFO-as-a-Service (CFOaaS) or SaaS-based management tools needs to be considered.
The IT department also has to shift into agile and iterative methods to quickly deliver what the business needs, working with the business operations teams and coordinating multiple external partners. These replace the detailed requirements documents painstakingly gathered over long project cycles with quick proof-of-concept through to implementation. The speed of business transformation and dependency on information and data cannot wait for the traditional way. Yet application resiliency and quick handling of issues may require getting help from Site Reliability Engineering-as-a-Service (SREaaS), Service Desk Manager-as-a-Service (SDMaaS) or even a Help Desk-as-a-Service (HDaaS).
This also means that the traditional performance measurement techniques and promotion policies need to be adjusted. Many companies have guidelines around the minimum number of staff a Manager or Director must have on their team to be promoted to that position. However, if productivity and business effectiveness is being maintained through work done by partners, this measure needs to change to the importance of business operations supported.
Similarly, as the focus of the IT department shifts from ‘build’ to ‘buy’, the IT business and financial management team becomes more important than the deep technical teams that build software and maintain the infrastructure. The technical teams may no longer need the technical expertise which is now implicit in a SaaS or cloud offering, but rather architects skilled at composing micro-services into valuable business processes.
As each application or infrastructure service will need to transition at its own pace as part of a longer-term strategy, tools such as Paragon’s Atlas that use process maturity evaluation and prescribe the transition steps become important. Initially costs will rise as the new model is implemented without reducing the older structures of doing work. As the transition progresses, the investment will pay off and the new structure will slide into place. At each step, organizations will need to measure their progress using metrics embedded in balanced scorecards: the gains have to be measured by looking at the whole business, not just the IT department.
Once the new model is in place, continual improvement steps guided by metrics and feedback are needed to keep the IT department functioning in step with the business and its extended ecosystem.