In the first part of this series we discussed the dynamics of technology development, including IT projects in the context of a Global 2000 company.
There are a number of approaches that can be applied to carry out such projects. The range of approaches is bracketed by either a totally centralized approach, where development is directed by a single organization worldwide, or a totally decentralized approach with development centers scattered across the world that don’t talk to each other.
In a global company these two extremes are usually less than optimal in the sense that they don’t yield the best business results. There is usually a happy medium between the two bookends, not totally centralized, not totally decentralized, which we will call federated, hence the moniker FTD (federated technology development).
An FTD analysis is holistic in nature and is of particular relevance to CIOs trying to establish a meaningful role for their IT organizations in the face of budget cutting.
Historically, because of the complexities involved, most organizations veer toward their comfort zone and today manage these processes serially and in a centralized fashion.
The prescription under an FTD environment is toward the opposite: to manage these processes in an explicitly decentralized and autonomous fashion (but not totally).
A distributed approach allows increasing the level of concurrency in how business processes are carried out. Faster execution time increases business agility in terms of time needed to reach goals, or to shorten recovery after a contingency or re-plan.
A product of any kind is developed through a pipeline of business and engineering processes. If we look at a pipeline in isolation, the underlying processes—R&D, proof-of-concept, engineering, etc.—represent the steps necessary to develop a technology-based product.
If the organization carrying the development has been in business for a while, it is to be expected that any given pipeline will be hard to compress. That’s because these development cycles have been the focus of prior re-use and it is reasonable to assume that they are highly optimized already.
The pipeline consists of discrete elements. The details of each process are immaterial for the purposes of FTD. What matters is how each process interfaces with the prior and subsequent pipeline stages. Clean interfaces are attained through experience, or lately, aided by the emergence of open standards such as XML.
Parallel pipelines can be totally independent, or have more than one touch point where synchronization takes place between similar or identical processes in two geographies.
Multiple synchronization points are more likely when the parallel development is carried out by a subsidiary of the same company. One instance of a touch point could be the coordination of a marketing or advertising campaign.
While parallel development may not improve the time to first product shipment, products intended for international distribution can be brought to market much earlier, and even before they ship in the home country, as business conditions dictate.
In sum, an FTD analysis ensures that local requirements are applied locally, not globally where they would bring over-specification and unnecessary drag in the processes. This approach is especially applicable to companies deploying distributed, regional design centers.
An FTD approach encourages this type of internal discussion, enabling an organization to explicitly decide the level of autonomy most beneficial for the current and anticipated business conditions and how constituent regional organizations should collaborate, and to discuss desired global business outcomes.
Enrique Castro-Leon is currently an enterprise architect and technology strategist for Intel Solution Services with 22 years at Intel. He has taught at the Oregon Graduate Institute, Portland State University, and has authored over 30 papers. Castro-Leon holds Ph.D. and M.S. degrees in Electrical Engineering and Computer Science from Purdue University.