Notes from the Consultant’s Jungle

We’ve become fairly comfortable with the structure of our IT organizations, but new trends in technology product development are increasingly challenging these traditional models.

In the traditional (i.e., over the past 10 years or so) IT organization we have roughly aligned the organizational chart with a logical stack corresponding to our data processing footprint. We have Network Engineering, which is roughly focused on layers one through four of the OSI Stack. Systems Engineering, focuses on the servers and the O/S instances running on them. The business applications are sometimes served by a general development/QA/Test team or may be aligned vertically with the business units served by the applications. Data is often managed by business-aligned “data owners” and administered by one of the engineering teams. A Security team cuts across stack layers, accounting for access control as well as the broad array of IS Security concerns throughout the stack. An IT Operations team is accountable for Technical Operations processes and procedures and the general availability and integrity of the data processing footprint. The Telecom team is often bolted onto the IT organizational chart in some fashion, and frequently has a historical lineage outside of the IT department. It’s important also to include IT Facilities in this mix, as it is the foundation for the successful operation of the stack.

This model is under attack though, as new technology introductions are having a significant impact on our approach to casting the roles and hierarchy in our IT organizations.

VoIP is a simple example of this. As discussed in my other posts and external articles, the introduction of VoIP marks the end of the traditional Telecom group for most IT organizations. It is quite often absorbed into the Network Engineering organization, and voice MACD activity melded into Technical Operations change control processes. For those that have gone through this organizational transformation, it’s well understood how challenging this can be.

Be aware though, that more significant changes in this regard are on the horizon. Manufacturers are creating new products based upon utility and IT service virtualization models. These products address the growing asset and services management problems driven by increasing density of the data processing footprint.

Consider for example, a data center technology that allows the specification of a template of rules to describe the server, storage, network, firewall, load balancer, IP address ranges, failover, and security policies, …based upon point-in-time business demand whether Time-of-Day, Customer behavior, or activity prioritization. What is suggested here is the opening of the entire data processing stack of services to be virtualized and pooled based on attributes such as performance demand, capacity, and availability. This is a level of automation that projects the logical and holistic orchestration of IT resources serving business applications onto a consolidated technology product. This product capability exists today. An example is Cisco’s Vframe DC product line.

If one deploys such a technology into the enterprise there is a likely impact to the IT organization. This level of services virtualization cuts broadly across all of the traditional technology subject matter silos, shoots through IS Security, and is firmly rooted in IT Operations, all at the same time. Who is the “owner” of such a service in the IT organization? In one respect, this technology concept begs a new IT role by applying a hands-on engineering aspect to senior management level of oversight in infrastructure and operations. How in the world does one accomplish that?

What I’m offering here as food for thought (beginning with a familiar example of organizational disruption from VoIP implementation and extending that with a less familiar example of extensive services virtualization across the entire IT stack) is that new technologies are going to significantly impact the role definitions comprising the traditional IT organization. They may even impact engineering processes in a fundamental way. The dividing lines between layers of the logical stack are blurring. Systems are being programmed at the business logic and operational logic levels.

As the definition of roles in the IT organization change to maintain alignment with contemporary approaches to systems design and management, it’s possible that a new dimension of “Policy Engineering” will emerge to accommodate the cross-functional reach that characterizes these new roles.

I would appreciate hearing from those who have addressed these challenges with new roles definitions, new organizational structures, or other creative solutions to evolving the organization to keep pace with technology.