Technology Change Management: An Activity of the Enterprise Architect

As I see it, Enterprise Architects have three responsibilities, key to the success of the organization.  They are:

1. Mission Alignment
2. Governance and Policy Management and
3. Technology Change Management.

I discussed the first two, Mission Alignment and Governance and Policy Management in my post A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture.  In this post I will discuss the third, Technology Change Management (TCM).

The Mission of Technology Change Management

The Mission of TCM is to insert new technology or replace existing technology, to increase the process effectiveness, increase the cost efficiency, while minimizing the impact on the organization of the technology change transformation process.  While that is a mouthful, it does identify the three key strategies of all TCM and in the following priority order:

• First, increase the organization's process effectiveness--this is the only reason for having tools
• Second, increase the cost efficiency of the tools--i.e., reduce the Total Lifecycle Cost (TCO) of the tooling while maintaining the process effectiveness
• Third,  transform the tool set while maintaining the process effectiveness--while this is third in priority, it is a strategy that the Enterprise Architect must keep in mind, especially when upgrading a current system to new technology.

The TCM Process and Its Activities

To meet the strategies, above the TCM process should have three high-level activities:

• Technology Evaluation
• Supplier Technology Roadmapping
• Internal Technology Roadmapping

Technology Evaluation

There are two very different types of Technology Evaluation, those evaluating the potential of upgrades of current products and those that evaluate the potential of immature versions of potentially disruptive technologies.  Additionally, Technology Evaluation activity enables and supports the evaluation of two distinctly different reasons for TCM, those that enable and support a product for sale and those that have the potential to disrupt the organization's current, strategies, processes, the current systems, or any and all of those.  This is the source of a significant conflict, which is currently an unidentified issue within many organizations.

TCM and the CTO versus the Enterprise Architect (or Chief Architect)

The source of the conflict is over whether the technology is a Product or a support for Process.  If it is a product the organization is producing for sale (in its many forms) then it is a product.  Product include computer and networking hardware, and software for sale or rental/leasing.  The CTO is definitely responsible for new products or new functions and components within current products.  The CTO organization should also evaluate the product's production readiness, even for internal systems.

However, if  the technology enables and supports an internal process or the processes supporting tools, the Chief Process Officer (CPO) or Enterprise Architect should evaluate the technology with respect to its applicability to supporting the ongoing or radically altered strategies and  processes.  This is especially true if the organization is a "service providing" firm, like those in the financial industry, IT systems integration, or legal and governmental organizations.  In fact, I really wonder why that for those industries that use a "unique" process to sell as a service to other organizations, that there is never a CPO that is on the same level as the CFO, with the CTO and CIO as direct subordinates.  The reason that I wonder this is that if the process is the value producer for the organization, then if should be of the highest importance and responsibility in the organization (without it the responsibilities of the CFO are non-value added, because the support the organization's value producing engine).

New releases of current technology

Since one of the TCM strategies is to insert the technology into the organization's tooling with as little disruption as possible, the Enterprise Architect, together with the Subject Matter Experts (SMEs) will perform the evaluation activities.  In fact, large organizations may want to have a specific SME designated for the main products supporting their processes.  These people must be evaluators, rather than product advocates, which many of them turn into.  In fact, when I held a position as a technical leader in one major organization, I got into serious political trouble because I accurately identified the shortcomings of a product to the supplier, rather than lauding it.  The supplier reps reported my evaluation to my boss (who reported to the corporate CIO) and this is one of the real reasons he eventually figured out that he did not have budget for all the Enterprise Architects and so removed me.  Still, there is some Pyrrhic justice.  When a new CIO replaced the prior one, the product in question was replaced as quickly as was possible, given the size of the effort.  Further, the supplier that apparently "listened with his mouth", has been steadily loosing market share.

Disruptive Technology

Another reason that the Enterprise Architects and  product SMEs must be evaluators, rather than Evangelists, is that from time to time disruptive technologies change everything--that's why they are called disruptive (e.g., one of my forbearers was a major manufacturer of buggy harnesses in the 1880s, just as something called the automobile was being innovated into a practical and affordable product...).  Therefore, the organization must maintain membership on standards bodies, and so on, where there may be early warning that that suppliers and research organizations are creating these technologies, then bringing the technologies in for evaluation as early as possible--to evaluate the new function or functional group, and its production readiness.

Supplier Technology Roadmapping

While Mission Alignment and Governance and Policy Management are short-term, short-cycle activities, Technology Change Management has a much longer time horizon, since supplier technology plan data and information is available, though semi-fugitive, for two to three years out.  Many suppliers will release their plans under nondisclosure agreements.  Additionally, as suppliers and entrepreneurs get ready to release potentially disruptive technologies, they tend to publicize it.  Therefore, the Enterprise Architect has some significant ability to identify, track, and evaluate (for use in his or her organization) new tooling and plan for its introduction into the organization.  These plans are called supplier technology roadmaps.

Organizational Technology Implementation Roadmapping

Once the organization understands when new versions of a product, either a new release or a disruptive technology is be production ready, the organization will require a second type of roadmap, an organizational technology implementation roadmap.  This roadmap is one process instantiating the third Strategy of TCM, minimizing the impact of transformation.  One reason for needing this roadmap is that the Enterprise Architect and SME team needs time to evaluate the new release within the organization's systems and nfrastructure.  Many times, new releases of software require new releases of operating systems, databases and other software components to operate or operate properly.  I have found this a key consideration.  Therefore, the organizational technology implementation roadmap must account for the migration of all hardware and software within the organization, not just the single product.

Further, the roadmap must account for exceptions.  For example, if most of an organization's customers (or clients) are on past release of software and there is a need to share data or information, then it may be a contractual obligation (or simply make sense) to stay at the same release until completion of the work, even if the rest of the organization is migrating to a new release.  If the software supplier is sunsetting a release of software (i.e., no longer supporting it) within the next 3 months, then it would make sense to change the organization's standard for that software to disallow any installations of that release and mandate a migration to the next release or the latest release, while waviering any migration for those projects or efforts with contractual obligations.

Finally, the leadership of the organization will use the organizational technology implementation roadmap as one of the criteria to determine which Architectural Blueprints to fund in a particular cycle of the Mission Alignment/Mission Implementation process.