Governance Under Federated Technology Development

Enrique Castro-Leon, Jackson He, Mark Chang

Intel Corporation, JF2-22 2111 NE 25th Avenue

Hillsboro, Oregon 97124

Abstract-This paper summarizes the concept of Federated Technology Development (FTD) and explores requirements for a governance structure necessary to make FTD work in an organization.

I. INTRODUCTION The concept of Federated Technology Development (FTD) was introduced and discussed in a previous paper and is deceptively simple: FTD attempts to answer the question of what is an optimal strategy to minimize the cost of building and delivering a product in the context of an organization spanning multiple geographic regions, or possible worldwide scope. We use product in a general sense: it applies to the development of a physical product, but can also apply to platform products comprising a family of physical products and usage and business models. It also applies to work products developed by a services or consulting organization. The FTD prescription is also equally simple: certain elements must be constant across the organizations, and certain elements need to be adjusted to the specific needs of the geographic regions. The exercise of what remains constant and what varies becomes an optimization exercise. The ensuing discussions of scope, different scenarios and the introduction of quantitative methods for the specific application domain will hopefully yield a strategy that maximizes the competitive position of the organization. This is where we believe the value proposition of FTD lies: it formalizes previously empirical, “tribal” knowledge and can be used as a predictive and prescriptive tool to formulate optimal development strategies. In this article we start exploring requirements for a governance structure necessary to make FTD work in an organization.

II. ABOUT FTD

For the purposes of context, let’s recap on some of the basic FTD concepts. For a more extensive treatment, please refer to the first article. [1] FTD is a pattern observed and already occurring in the [high-technology] industry. However, its application to date has been more the result of happy accidents than intentional application. In the spirit of Moore’s Law, our contribution in this investigation has been to call out this pattern and make it explicit. In particular, we’d like to explore how FTD can improve product and technology development processes and the governance infrastructure to make it happen. We believe the concept has predictive value, and can be used with advantage as a strategic framework leading to improved time-to-market and business agility.

A. History of FTD FTD represents the authors’ experience from building technology development and management strategies on behalf of a number of organizations. The concept of FTD was initially developed for the City of Xi’an Development Zone (XDZ), in the People’s Republic of China as part of an Intel ® Solution Services Enterprise Architecture engagement in early 2004. The concept was presented to XDZ executives in response to a request for a 10-year technology strategy and vision. We are describing an actual work product from an Intel® Solution Services client engagement.

B. What is FTD? In an abstract sense, FTD is a framework for managing technology development processes in a global economy.

0-7803-9139-X/05/$20.00 ©2005 IEEE. 529

FTD is applicable to most any global organization involved in product and technology development. A few examples include:

• Software development • Hardware development • Manufacturing processes • IT and business processes

The last aspect is particularly relevant to IT Enterprise Architecture because FTD would be applied to derive particular insight into building long term policies and strategies for a particular IT organization, and its application helps establish strong linkages between IT and corporate business objectives. 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, hence the moniker “federated”. The idea is to increase the level of concurrency. Faster execution time increases business agility in terms of time needed to reach goals, or to shorten recovery after a contingency or re-plan. These processes are illustrated graphically in Figure 1. If we look at Pipe #1 in isolation the processes represent the steps necessary to develop a technology-based product, the first block could represent R&D and the application of science

principles; the second block could represent the development of a proof-of-concept, followed by blocks sequentially representing engineering design, manufacturing, marketing, with the pipe ending at product launch. These pipelines are often represented by product road maps with a time scale of 2 to 5 years. This development model brings two challenges: first, mid-course corrections, for instance due to changes in requirements or business conditions are considered highly disruptive events, leading almost always to schedule slips and cost overruns. The trouble is that markets today rarely stay a course for that long. Second, this pipeline basically addresses one market, the US market in this example. Normally, addressing international markets requires starting another pipeline after the first product launch. It may not be as long as the original pipe, but it begs the question of whether the time to delivery could be expedited by shortening the pipelines somehow. 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. However, given sufficient development expertise in the target markets, instead of shortening the original pipeline, it might be possible to spin off a new pipeline in the target market. The goal here is to attain an earlier finish through an earlier start.

Figure 1: Block representation of abstract processes under Federated Technology Development. As implied in Figure 1, the pipeline consists of discrete elements. Each block represents an engineering or business process. 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.

0-7803-9139-X/05/$20.00 ©2005 IEEE. 530

The parallel pipelines can be totally independent as shown in the People’s Republic of China (PRC) pipeline, or have more than one touch point as indicated in the India pipeline, 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. The parallel pipelines are usually carried out local to the target geography. A successful example of this approach is the Toyota US Design Center in Ann Arbor, Michigan tasked to better design vehicles for American tastes. 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. At some level, blocks are treated as single, atomic logical entities. This does not prevent FTD from being applied recursively or hierarchically. At the top level pipes may represent workflows between international subsidiaries or different companies altogether, whereas blocks in a pipe represent business groups. Drilling down into a single block may reveal relationships across departments in within a business group. Single blocks can be monolithic as well. When this happens, under the FTD framework it may be a worthwhile exercise to determine whether further decomposition would lead to improved business outcomes.

III. GOVERNANCE From an intuitive perspective, FTD represents a business outcome optimization exercise along a single dimension as depicted in Figure 2. At one end of the spectrum, a local organization enjoys total freedom to make decisions. This is the equivalent of no coordination at all, and hence, synergies due to the coordinated action of multiple organizations are never realized.

Figure 2. FTD Optimization Process At the other end of the spectrum is a centralized organization where every subsidiary operates under uniform mandates and processes. This situation is less than optimal as well because it may lead to over-specification or red tape, i.e., processes that have no tangible business results carried out only because they have meaning in some other locality. Companies go through mergers or divestitures in attempts to optimize these outcomes. FTD is useful in providing insight into the underlying dynamics Because most companies started small and because of complexities in managing large organizations, there is a tendency to view regional variances as departures from the norm and hence most organizations exhibit a bias toward centralized approaches. For instance, corporate budgets might be managed from headquarters, in an environment where regional offices must secure approval from headquarters for any major program spending and headcount authorization. Data centers in an outsourcing arrangement constitute an example where forcing identical processes would lead to sub-optimal results. Because of higher cost of labor in the US pipe, data centers are designed to minimize this component with greater consideration to lights out operation, whereas the cost of equipment in India is relatively

0-7803-9139-X/05/$20.00 ©2005 IEEE. 531

higher, and hence asset management is probably a first consideration. It makes little sense to apply the same rules across the two geographies as long as the parties in an outsourcing arrangement abide by the contractual rules. In fact, an outsourcer implementing FTD would likely have a competitive advantage through lower capital and operational expenditures. The application of FTD in a specific organizational context and application domain involve discovery and a decision-making processes where the invariant elements are distinguished from the elements that are subject to geographic instantiation. By definition, the invariant elements in this organizational ecosystem define the basic “architectural” elements for that ecosystem. This definition of architecture is relative, and can be applied recursively: a major region, say Asia-Pacific may have a location-specific architecture. The number of levels is usually small, even for the largest organizations, perhaps two or three. The architectural elements can change, but do so very slowly and by exception. On the other hand, the business processes that are instantiations if this architecture are specifically designed to account for local circumstances and expected to have regional differences, and may change over time tracking changes in business conditions. The points of interaction amongst regional instantiations of an architecture must of necessity be limited keep complexity in check and enhance manageability. These points of interaction need to be results oriented, i.e., outcomes based, not process oriented to avoid micromanaging. Examples of outcomes based interface would be interactions between regions based on budgetary results. An IT organization would be governed by Service Level Agreements (SLAs), more so if the relationship is one of outsourcing. It must be noted that certain processes can become part of the architecture. The bar for these processes is set high. Normally these processes have become part of some industry standard. Examples are the IT Information Library (ITIL) for IT operations and Six Sigma processes. The role of standards in an FTD environment cannot be overemphasized. A standard reflects a common understanding within an industry, and in

particular for an organization operating within that industry. The standards can be used as building blocks for the FTD architecture of the organization. They are valuable because the arduous consensus building work has been done up front. In fact they are so valuable that in some cases the fiercest competitors are willing to sit at the same table to see them through. As an example of standards, Service Oriented Architectures or SOAs are being enabled by Web services technology. The unprecedented interoperability brought up by Web services is not necessarily because of a revolutionary technology. It’s because a common understanding has been reached in the information industry through standards work in the form of XML schema. XML is the data format used by applications communicating through Web services. Governance structures in federated environments tend to mimic the environment they govern, and are set up in a federated fashion themselves in a multi-level, geographically distributed structure. As an example, within global companies, Information Technology (IT) services are delivered to the company through a federated organization. In particular, Enterprise Architecture is a discipline in Information Technology to build guidelines for long term planning with general guidelines on the rules of engagements of IT with the company business units served, contractual policies and technology re-use and transitions. In this context, the IT function of a global company is also delivered by an IT organization that has all the characteristics of a global organization. The IT department at Intel, the Information Systems Technology Group, or ISTG comprises about 6000 people serving over 80,000 Intel employees. The Enterprise Architecture function within Intel ISTG is fulfilled by a three-level hierarchy: The highest level (“federal” level) is an Executive Steering Committee. The Steering Committee is the approval body for major architectural visions and sets makeup of the portfolio of services for the company, the charter for the programs put together to deliver these services and the funding decisions behind them. At the middle level (“state” level) are the Solution Review Groups staffed by Chief Architects responsible for the long term planning and architecture implementation for the programs chartered by the Steering Committee. At the lowest level (“city” level) are the Architecture

0-7803-9139-X/05/$20.00 ©2005 IEEE. 532

Standards and the Solution Review Groups addressing operational aspects and conformance to standards for individual projects. Professional organizations such as the IEEE follow these principles. The IEEE is governed by a Constitution describing the mission of the organization and a set of Bylaws describing how the mission is to be accomplished. The global organization is in turn divided into geographic regions (Region 1 through Region 9), and regions are divided into local chapters. Each level down adds geographical specificity. It must be noted that a federated governance infrastructure is not synonymous with “democratic” in the sense that the different geographic regions will have equal say at the highest organization echelons. A federated governance structure can still be very much top-down where headquarters determines the rules for regional variances without much input from the regions. For most organizations the actual setup is somewhere in-between, where for historical reasons the global governance bodies have a larger representation from the organization’s home country. Federations can be extremely loose without formal relationships between levels as it is the case with standards-making related work. Because of the need for consensus building it takes a long time to get a standard approved through a global organization such as the W3C or the IEEE. What happens in practice is that many standards are initiated by consortia. These consortia are populated by a small number of member companies driven by common interest. Examples of small consortia are the Liberty Alliance and the WS-I and OASIS that exhibit geographic specialization. Some standards are initiated by a single company, such as the C# language and the .Net CLR (Common Language Runtime) that became an ECMA standard. Single-company standards come to be as de-facto standards because of wide adoption. Well known standards of this flavor are the classic Hayes modem command set. In this context, we again see three functional levels with varying degrees of global/regional scope. The net effect of the informal dynamics amongst levels in the standards making bodies is an acceleration of time-to-market, a case in point for agility through federation. Running the whole process through a global organization would take

an inordinate amount of time, and the outcome might not necessarily be better.

IV. CONCLUSIONS The concept of Federated Technology Development captures organizational dynamics involved in the development of some form of technology, whether a product, service or a standard. The understanding of these dynamics increases agility in large organizations by facilitating the discovery of task parallelism and local decision making where global decision making would introduce drag. A federated approach allows variance in the processes used by an organization, and rather than treating it as an anomaly to be minimized. Standards can be implemented differently in different regions. Engineering and business process need not be identical across regions. They need to be interoperable. This relaxation may lead to cost reduction overall. The patterns of FTD are not unique; they have a long history and have been taking place in many countries. The contribution of this paper is to call out these patterns. In the spirit of Moore’s Law, once these patterns are understood, they can be useful for making predictions, for planning purposes and for formulating technology strategies and policies. FTD can be a useful tool for IT Enterprise Architecture given that the focus of EA is oftentimes global, and suggests that normalizing IT processes on a global basis may not always be the best alternative in terms of cost containment or organizational outcomes. Somewhat ironically, the relaxation of processes brought by FTD can take root only in the most advanced and disciplined global organizations, those that have managed to move to results orientation, not those still trying to get a grip on establishing predictable processes.

REFERENCES [1] Enrique Castro-Leon, Jackson He, Mark Chang, Introducing the Concept of Federated Technology Development, Proc. of The Open Group IT Architecture Practitioners Conference Europe 2005. Web: http://www.opengroup.org/conference-live/.

0-7803-9139-X/05/$20.00 ©2005 IEEE. 533