Building IT Synergy

One of the key focuses you should have as an IT leader is to ensure that you are bringing about greater synergy capability within your IT organization for your enterprise. This can provide tremendous commercial advantage if executed well. In many IT shops, and some that I found when I first arrived at a company, the IT is ‘siloed’ or separate into different divisions, with typically each division supporting a different business line. Inevitability there are frustrations with this approach, and they are particularly acute when a customer is served by two or more lines of business. How should you approach this situation as a leader and what are the best steps to take to improve IT’s delivery?

I think it is best first to understand what are the drivers for variations in IT organizations under large corporations. With that understanding we can then work out the best IT organizational and structural models to serve them. There are two primary sets of business drivers:

  • those drivers that require IT to be closer to the business unit such as:
    • improving market and business knowledge,
    • achieving faster time-to-market (TTM),
    • and the ability to be closer in step and under control of the business leads of each division
  • those drivers that require IT to be more consolidated such as:
    • achieving greater efficiencies,
    • attaining a more holistic view of the customers,
    • delivering greater consistency and quality
    • providing greater scale and lower comprehensive risk

So, with these legitimate pushes, in two different directions, there is always a conflict in how IT should be organized. In some organizations, the history has been two or three years of being decentralized to enable IT to be more responsive to the business, and then, after costs are out of control, or risk is problematic, a new CFO, COO, or CEO comes in and  IT is re-centralized. This pendulum swing back and forth, is not conducive to a high performance team, as IT senior staff either hunker down to avoid conflict, or play politics to be on the next ‘winning’ side. Further, given that business organizations have a typical life span of 3 to 4 years (or less) before being re-organized again, corollary changes in IT to match the prevailing business organization then cause havoc with IT systems and structures that have 10 or 20 year life spans. Moreover, implementing a full business applications suite and supporting business processes takes at least 3 years for decent-sized business division, so if organizations change in the interim, then much valuable investment is lost.

So it is best to design an IT organization and systems approach that meets both sets of drivers and anticipates that business organizational change will happen. The best solution for meeting both sets of drivers is to organize IT as a ‘hybrid‘ organization. In other words, some portions of IT should be organized to deliver scale, efficiency, and high quality, while others should be organized to deliver time to market, and market feature and innovation.

The functions that should be consolidated and organized centrally to deliver scale, efficiency and quality should include:

  • Infrastructure areas, especially networks, data centers, servers and storage
  • Information security
  • Field support
  • Service desk
  • IT operations and IT production processes and tools

These functions should then be run as a ‘utility’ for the corporation. There should be allocation mechanisms in place to ensure proper usage and adequate investment in these key foundational elements. Every major service the utility delivers should be benchmarked at least every 18 months against industry to ensure delivery is at top quartile levels and best practices are adopted. And the utility teams should be relentlessly focused on continuous improvement with strong quality and risk practices in place.

The functions that should be aligned and organized along business lines to deliver time to market, market feature and innovation should include:

  • Application development areas
  • Internet and mobile applications
  • Data marts, data reporting, and data analysis

These functions should be held accountable for high quality delivery. Effective release cycles should be in place to enable high utilization of the ‘build factory’ as well as a continuous cycle of feature delivery. These functions should be compared and marked against each other to ensure best practices are adopted and performance is improved.

And those functions which can be organized flexibly in either mode would be:

  • Database
  • Middleware
  • Testing
  • Applications Maintenance
  • Data Warehousing
  • Project Management
  • Architecture

For these functions that can centralized or organized along business lines, it is possible to organize in a variety of ways. For example, systems integration testing could be centralized and unit test and system testing could be allocated by business line application team. Or, data base could have physical design and administration centralized and logical design and administration allocated by application team. There are some critical elements that should be singular or consolidated, including:

  • if architecture is not centralized, there must be architecture council reporting to the CIO with final design authority
  • there should be one set of project methodologies, tools, and process for all project managers
  • there should be one data architecture team
  • there should be one data warehouse physical design and infrastructure team

In essence, as the services are more commodity, or there is critical advantage to have a single solution (e.g. one view of the customer for the entire corporation) then you should establish a single team to be responsible for that service. And where you are looking for greater speed or better market knowledge, then organize IT into smaller teams closer to the business (but still with technical fiduciary accountabilities back to the CIO).

With this hybrid organization, as outlined in the diagram, you will be able to deliver the best of both worlds: outstanding utility services that provide cost and quality advantage and business-aligned services that provide TTM and market feature and innovation. .

As CIO, you should look to optimize your organization using the ‘hybrid’ structure. If you are currently entirely siloed, then start the journey by making the business case for the most commodity of functions: networks, service desks, and data centers. It will be less costly, and there will be more capability and lower risk if these are integrated. As you successfully complete integration of these area, you can move up the chain to IT Operations, storage, and servers. As these areas are pooled and consolidated you should be able to release excess capacity and overheads while providing more scale and better capabilities. Another area to start could be to deliver a complete view of the customer across the corporation. This requires a single data architecture, good data stewardship by the business, and a consolidated data warehouse approach. Again, as functions are successfully consolidated, the next layer up can be addressed.

Similarly, if you are highly centralized, it will be difficult to maintain pace with multiple business units. It is often better to divest some level of integration to achieve a faster TTM or better business unit support. Pilot an application or integration team in those business areas where innovation and TTM are most important or business complexity is highest. Maintain good oversight but also provide the freedom for the groups to perform in their new accountabilities.

And realize that you can dial up or down the level of integration within the hybrid model.  Obviously you would not want to decentralize commodity functions like the network or centralize all application work, but there is the opportunity to vary intermediate functions to meet the business needs. And by staying within the hybrid framework, you can deliver to the business needs without careening from a fully centralized to a decentralized model every three to five years and all the damage that such change causes to the IT team and systems.

There are additional variations that can be made to the model to accommodate organizational size and scope (e.g., global versus regional and local) that I have not covered here. What variations to the hybrid or other models have you used with success? Please do share.

Best, Jim

 

4 Responses to Building IT Synergy

  1. Rimantas says:

    Hello,
    first of all thank you for so interesting place of ideas, thoughts and…recipes. Definitely, will read them in the future. In this ‘recipe’ you were talking about ‘IT factory’ as a single ‘internal factory’ within a company. What about situation(s) if some of ‘factory’s functions are splitted between several companies, including local IT organization and outsource providers (I don’t have in mind services we’re getting from HW/SW vendors). What about more complicated situation when not 100% of service delivery responsibilities are dedicated to single outsource provider – for instance 50% local IT org responsibility and other 50% – some outsource company. Whan could be approach to handle IT operations smoothly when some services arrives from outside? What is your opinion when outsource itself is reasonable – could reasonability be measured in some number of infrastructure items or number of served users or number of services etc.. ?

    • Jim D says:

      Rimantas,

      I am glad you are finding the site useful. I do recommend reading the Spring Break recent post ( http://www.recipeforit.com/2012/03/11/just-about-time-for-spring-break/ ) as it has a good intro and several key posts to check out.

      Now, on to your questions… the first one where IT is not consolidated is a situation that is found when the business units are more federated – often in a conglomerate where there is not significant synergy between the BUs even to the point of different customer bases (GE comes to mind as an example). Here, I recommend that even with diverse needs, it is to the corporation’s advantage to leverage economies of scale and significant savings for:

      – the data center and network: if the company is of any significant size, regardless of how diverse the businesses or applications are, there will be synergies and advantages to a common network and set of data centers
      – information security and IT operations: this would be the next logical place to consolidate and leverage across an organization. Having these split up in to multiple groups typically renders them far less effective than a consolidated team.

      Now if the corporation has ventured down a path where every business unit has outsourced their IT infrastructure and other functions to multiple vendors (or 1 vendor per BU), then I would suggest that you are consuming the services in subscale quantities. Your network services will cost 20 or 30% more because you are buying and managing it in 6 smaller pieces rather than 1 piece, and you will have less flexibility and capacity within each business unit. Similarly for some of the other services. So I would recommend whether in house or outsourced, that the utility service be aggregated to provide economies of scale and synergy.

      As for when to outsource versus to do inhouse, usually, if your organization is smaller or below scale, you should consider outsourcing because it is likely to be a cost and capability advantage to do so. Also, even where you may have scale (e.g. field services supporting branches or stores), it may be cheaper and better to outsource to a vendor because they are supporting 5 – 10 companies your size and have much greater scale and better systems and capabilities. On the other hand, anywhere that technology is a critical portion of your product I would be reticent to outsource as you lose control, you lose IP, and you often lose innovation and higher quality by outsourcing.

      Let me know if you desire further insight or have specific examples in mind.

      Best, Jim

  2. Jamie says:

    Jim, the idea of a hybrid model is great and setting up the organization to be flexible in that hybrid manner is a good idea. With regards to application development and delivery, a growing aspect of all businesses, there are some unique issues associated with the hybrid or “heterogeneous” environment approach: Software developers are one of the few groups of stakeholders on a project who can produce the tools/systems they desire to get their work done. This leads to an ever changing landscape of tools (and processes) that are “today’s favorite”. If such favorites are not developed internally they are often found in open source communities. This autonomy is great for the local team, but can be a nightmare for other stakeholders and PMO for data sharing, reporting and understanding overall project status/health. On the other hand, if forced to use Vendor A’s tool suite because the organization has an ELA for the suite, individual teams will lose the best of breed capability of a different solution or be forced to use non-optimized processes. An organization who’s first focus of business isn’t software can still be easily sucked into creating its own tools, systems and integrations. Short term this might prove economically beneficial, but to borrow your phrase from the recent SaaS blog posting, it eventually “turns into an anchor”. The challenges/costs of maintaining a hybrid model in software development grows in a non-linear way as the application development, delivery & support demand grows in the organization.

    • Jim D says:

      Jamie, I think your observations are on the mark. I would suggest you touch on a few themes here: the pros and cons of using a single vendor’s or the ‘enterprise standard’ tool suite; and the decision to build versus buy – here applied to development tools. Generally speaking the bar for build versus buy has been rising over the past decade in development tools where it is not worth it or even feasible for shops to venture off on their own toolsets. Plus there is even a plethora of open tool suites that are very low cost. Here I think the solution is instead to buy 2 or 3 toolsets and make them standard. Generally, the IBM Rational and Microsoft should be in almost every shop so you can support both Java and .Net development. A third one might be either a mobile toolkit or an open toolkit. That should complete out the mix to enable your developers to handle traditional development as well as agile methodology on pretty much all key platforms.

      Best, Jim Ditmore

Leave a Reply

Your email address will not be published. Required fields are marked *