IT is Undergoing a Fundamental Change and We're Not Looking

Author by Randy Steinberg

IT is undergoing a fundamental change in how it manages and operates itself.

Without our realizing it, the primary role of IT as an engineering organization has been shifting to one of service integration. The practice of understanding business requirements and designing, building and deploying IT solutions is giving way to integrating pieces, parts and services to meet those same business requirements. IT executives who don't understand this shift will face severe challenges in meeting business needs at cost and availability levels that are acceptable to the business.

Worse yet, many IT organizations are still organized and operated as engineering delivery and capability organizations. If the organization chart looks like the schema for a configuration database (application unit, network unit, server unit, etc.) then that organization may be in trouble. The ranks of outside suppliers ready to provide hardware, applications, and network and support solutions quickly and at lower price points is growing rapidly. IT will need to assemble services and solutions from many providers, integrating these in the optimum manner to meet business needs.

To deal with this shift, several things have to happen within the IT organization:

IT will need to organize itself as a service provider organization. While there is still a solid need for IT technical skills to understand networking, hardware, software and operations, it should be recognized that these are no longer the primary focus of the organization. Operating roles such as Service Owner, Service Manager, Service Architect, Business Relationship Manager, Process and Supplier Manager are becoming more critical. Stronger skill sets in customer relations, negotiation, service integration, product management and supplier management will be key.

A 'service bridge' needs to exist that masks the complexities of IT from the business. This bridge serves to abstract IT assets such as servers, networks, processes and applications into services that are consumable by business users. If email doesn't work, then it doesn't work. The business shouldn't have to get involved with the complexities of directory software, mailbox architecture, and access issues. If there are application issues, a single source is accountable for making sure that the business unit gets back into operation and people get back to work.

             Service Bridge diagram

Trying to shoehorn this service bridge into an existing IT organization that is made up of technical silos is fraught with issues. The need for the service bridge always exists. Therefore, failing to organize it will result in IT senior executives taking on this role, whether they realize it or not. Many a CIO wonders why they have to make so many phone calls to get things taken care of, why their people can't be more proactive, and why it takes so long to get things done. When IT leadership fails in this regard, the business units are left to handle the service bridge, taking on IT issues directly, issuing numerous complaints to IT leadership and support staff, or implementing their own IT support organizations to deal with the issues.

The solution focus needs to shift from applications to services. Historically, IT has laid a huge emphasis on applications when looking at solutions, often ignoring the ongoing needs for support and operations. Behind every app is an infrastructure that needs to be managed and controlled at acceptable costs to the business. Ignoring this, or shifting responsibilities to unprepared support units, will result in outages, delays and unexpected costs. While the DevOps discussions are an attempt to address this, there needs to be a much stronger shift to integrating ongoing operations requirements into the development lifecycle, such that the solution and its operating infrastructure are built together.

The IT organization must be able to articulate its services, costs and demand. Without this, IT is operating blindly, overspending, and can only react to changing business needs. Without this, IT will always be seen as an overhead, too expensive and fraught with issues. Without this, IT is essentially telling the business that it isn't completely sure what it is delivering (other than engineering capabilities), how money is being spent or how customers are consuming whatever it is that it delivers. Even a non-technical businessperson understands that this is a recipe for disaster.

Stay tuned.

 

 

 

Author

Randy Steinberg

ITSM Process Architect