Follow by Email

Thursday, June 30, 2011

In Search of the Ideal IT Organization Structure

Gartner Group and many others have recently been posting articles about the changing role and organization of IT within the modern business enterprise.  Gartner of course promotes their "Enterprise Architecture" but is pointing out that most enterprises are not embracing the concept. 

There are countless articles on the web about changing the structure of IT.  It move research, strategy, planning, and technology groups around but it appears to be a game of musical boxes on the org chart.  In most of the articles that I read, the fundamental assumption is that IT should continue to have the same basic functionality that it has for the past 20 plus years.  The fundamental issue is protecting the CIO's assets so to speak and his or her kingdom and multi-million dollar budget. 

There is a lot of lip service to corporate IT governance, but few organizations are stepping up to the plate.

In this old guys mind there is only one way to truly manage and control IT today and that is to move control out of IT to a team that reports directly to the CEO with dotted lines tot he board's IT Governance committee.  You can call this group Enterprise Architecture, Systems Planning, or even Corporate planning.  The bottom line is that it should be staffed with business analysts and project managers who have only the interest of the enterprise as their sole driving force. 

This new group should have no bias about building systems or maintaining them in-house, buying them from a third party, or outsourcing to a low cost but professional development firm.

The key to this organization is to always look at business problems and opportunities that can benefit from improved computer systems support, but has no historical bias towards any particular solution, hardware platform, or technology. 

I mentioned two key roles in this group:  business analyst, and project manager.

The business analyst's role should be to work with business unit leaders to define specific business requirements in such a manner that solutions can be crafted that address the specific needs of the business regardless of what technologies the solution might entail.

Project managers are required to manage computer systems projects as well as relationships with 3rd party vendors.  When people criticize the use of outsourcing vendors it is most often due to a failure to properly manage the vendor and insure that proper procedures are handled.  Professional project management is a key success factor in dealing with external vendors.

Note that in this scenario, an internal IT organization would be considered to be a vendor and treated the same as any other vendor.  This group would create a buffer between the IT organization and the business. 

Note that a big part of the role of this group would be the ongoing assessment of existing systems with recommendations to replace or eliminate old system that are too expensive to maintain or no longer meet business requirements. 

The people staffing this group should have excellent business and analytical skills.  Knowledge of current IT technology is desirable but should not be a factor in hiring or staffing positions in this group. 

Enterprise architecture should be a big part of the function of this group but not necessarily designing systems that are integrated enterprise systems, but rather insuring that there is sufficient integration between the various systems used within the enterprise.

Note: I have developed large scale systems for very large insurance companies and an insurance software house over the years and consider myself an expert and one of maybe 50 people who have built true enterprise systems over the years.  I still think the principles of enterprise architecture are commendable, but simply not practical in today's world of rapid change and globalization.

The key issue today IMHO is reducing the time from the identification of a requirement to delivery of a system to facilitate the requirement.  In my past I tried to design systems that would last "forever".  Today, if a system lasts 30 days and meets its business objective producing a return on its investment, then it is a success.  30 days might be a bit over the top, but a system that last a year would be reasonable. 

The key of this article is to get rid of traditional thinking about IT, refocus on business objectives and remove the dependency on multi-million dollar bureaucracies.