The Missing Triangle – Framing the Transformation

One of my more astute readers has pointed out to me that all of the documents in the Library are referenced in a link from one of my posts except for one, the IT Transformation Triangle.

First, I’m flattered that anyone has read the blog that consistently and thoroughly to be able to notice that omission.

Second, I’m somewhat surprised to see that it is true. The materials in the Library are there to support the posts in some fashion. The post using the Transformation Triangle was edited a bit too severely and I ended up omitting the reference link. I’ll attempt to explain the use of the diagram outside of my originally intended reference.

To be successful, transformational programs of work must be defined along workstreams that are readily understood by, communicated to, and executed by IT folks. The triangle icon is the mechanism that I commonly use to help accomplish this.

Please note that it is far beyond the scope of this post to capture the entire body of work for an IT transformation. The intent of this post is to explain the Transformation Triangle and its use in framing, communicating and managing an IT transformation program.

The Transformation Triangle is comprised of four smaller triangles representing the various dimensions of the transformation: Process, Technology, Organization and Management Systems. The first three categories are for changes within IT. The fourth category is for changes that are external to IT and are done in cooperation with other staff departments, most commonly HR, Finance and Procurement.

The Process Triangle represents the changes to IT processes that will take place as part of the transformation. Presuming that the changes are to support a transformation to a services-based strategy, they are usually in the following IT functional or governance areas (in no particular order):

•    Portfolio & Demand Management
•    Solution Design & Delivery
•    Service Delivery & Support (Service Management)
•    Enterprise Architecture
•    Program/Project Management
•    Sourcing/Supply Management

Each of these areas will have a set of processes to be defined and matured within the overall transformation plan. Each of the work teams accountable for the definition and implementation of processes will have their work captured and reported in this category.

In a similar fashion, the Technology Triangle represents the changes to IT technology that will be needed to support the changes to process and architecture that will take place as part of the transformation. Initially these tend to be the implementation of software and support tools for program/project management and various service management functions (e.g. Service Desk). Later, they tend to be standardization efforts sponsored by Enterprise Architecture and additional tools for other areas as needed. Each of the work teams accountable for technology-related change will have their work captured and reported in this category.

The Organization Triangle represents the changes that will be made to the organization from staffing, skills, structure and sourcing dimensions during the transformation. These are discussed in BES-6. This category tends to be the one that is of most interest to the organization (as well as the one that causes the most angst) during this period. Each of the work teams (generally the IT leadership team) accountable for organization-related change will have their work captured and reported in this category.

The Management Systems Triangle represents the changes that will be made with the assistance of other staff functions to support the IT change agenda. For example, if there are new roles in IT that are defined by the transformation plan, HR will need to assist in the creation of  new job descriptions, slot the levels and define the compensation for these new roles. If a new service costing strategy is defined, Finance will need to assist in the modification of cost centers and create new mechanisms for assignment of cost to the new services. Each of the work teams accountable for changes to management support systems will have their work captured and reported in this category.

When embarking on an IT transformation journey, the Transformation Triangle is a great tool for the initial framing and ongoing communication and management of the IT Transformation for several reasons.

First, it provides a logical structure for categorizing the work that will be going on across the department, as well as other staff functions. It exposes the breadth and variety of the work on process, supporting technology and organizational elements of change needed to accomplish a successful transformation to the organization. This structure enables crisp, consistent communications to be developed during the transformation program.

Next, it fosters a common understanding and lexicon for the transformation program. As it becomes familiar and the transformation Vision is communicated, IT begins to see itself in a different way, as a service organization supported by process and technology, and is purpose-built for that mission.

Finally, the Transformation Triangle can be used to illustrate the continuous nature of change over time. It is an ongoing cycle that is responsive to the changing needs of the business and optimization of the IT function.

Cloud Computing Commentary

Please comment on Cloud Computing with GPU Intensive Apps (current state and future viability).

Admittedly, this topic isn’t my long suit. Cloud Computing is kind of the übercategory for delivery of IT capabilities over the Internet. Most of the business offerings in that category aren’t computationally intensive, particularly for graphics.

When thinking Internet-delivered capabilities, I’m presuming some sort of thin device on the client-side. That doesn’t generally mesh well with a heavy-duty GPU and the corresponding bandwidth requirements to feed it. Is this for Internet delivery of multimedia gaming or other real-time graphics applications?

Perhaps I’m just a troglodyte, but I don’t see this in the present Cloud Computing environment and would be somewhat apprehensive about opining a future without knowing more specifics. Reader comments are most welcome.

SaaS Commentary

Please comment on Software as a Service (current state and future viability).

At the risk of placing myself firmly in the pantheon of IT curmudgeons, I think that SaaS is another new name for an old concept. In 1993, we referred to this sort of thing as an outsourced or hosted application (admittedly not particularly sexy names).  IT lexicon purists may split hairs over the use of a common code base, but fundamentally it’s the same thing.

In my view, SaaS is simply another way to add a particular business capability. There are certain conditions where it makes sense to adopt this approach. For highly differentiated capabilities, it probably isn’t a good option. For more standardized capabilities, it is. Lower investment and speed of implementation are also generally considered as advantages for SaaS solutions.

There are other considerations as well that would be built into a scorecard that would be used to rate the suitability of a SaaS solution versus other options. Again, it’s all about what you are trying to accomplish and what that means about how you should do it.

Obviously, SaaS is and has been a viable option for provisioning capabilities. In the future, my opinion is that it will most likely be subsumed into the larger utility or cloud computing category.

SOA Commentary

Please comment on Services-Oriented Architecture (current state and future viability).

Services is one of the most overused and least commonly defined words in IT today (discussing Services in both SOA and Managed Services contexts at the same time makes for a challenging conversation). A close runner-up is Architecture.

Having them both in the name of an IT construct still somewhat frightens me.

My comments today on SOA will be brief. I believe that SOA is a new, fancy IT-ism for an older concept called Enterprise Architecture carried to its logical conclusion or goal.

Enterprise Architecture is all about common business services as instantiated in technology. That happens via an end-to-end EA process reaching back to the business. SOA simply articulates that differently. The technology behind them is the same.

I’m not sure if SOA has the staying power of EA. If pressed, I’d speculate that SOA would eventually diminish in the IT lexicon, as EA efforts are successful in reaching the same goal using processes in place now.