Agile IT Departments – Concepts, Frameworks, Feasibility (Part 1)

Introduction

The idea of an IT department transforming into a service broker has been largely overlooked by academia. The business world is certain that the future of the IT department will consist of a mosaic of services with only a basic IT infrastructure in-house. Further, the main focus of the IT department will be on innovation to enable development of new products and services with the business side. Little research investigated the idea of the conditions necessary to enable an IT department to act as a service broker. This paper explores the concept of agility as a basic level of organisation. For many years the focus of agility has been on supply chains and manufacturing. If the IT department acts as a service broker, however, the way they provide services to other business units changes, and could look similar to concepts used for supply chains and manufacturing. Concepts from these two areas could be applicable for the new structure of the IT department. When the IT department consists of a mosaic of services it inevitably sources services and infrastructure from outside (e.g. cloud computing). The IT department then enables the use of these services for other business units. From this point of view the IT department faces the same challenges as supply chains because they pursue the same goal: to provide the right product, at the right time and price. Agile manufacturing, on the other hand, focuses on competitiveness, fast changing customer demands and performance. The IT department already faces the same challenges. Especially through the increasing developments of new technologies customer requirements change faster than a few years ago. In addition, the IT department might soon face competition from outside providers, if business units simply ‘order’ cloud computing services, for example, without consulting the IT department first.

Since the 1990’s the concept of ‘agility’ has been used in many different areas, e.g. agile supply chains, agile manufacturing or agile workforce [3, 23]. Since the Millennium this concept has also appeared in IT., e.g. agile software engineering and agile project management [5]. However, research has shown that neither a widely accepted definition nor commonly used frameworks or concepts exist. One possible reason for the high number of different definitions might be the application of agility itself. Especially within IT, e.g. in the IT department, agility is demanded but different concepts demand different types of agility, e.g. agile service provisioning [45], agile infrastructure [6], agile IT [44]. This suggests that the meaning of agility is context dependent. This suggestion is consistent with the findings by [8] who points out that poorly defined agility can lead to confusion.

The opinions on agility in connection with IT are very different. Some say the IT can hinder agility [1], others say without IT agility is not possible [9]. However, until now agility has always been viewed from a business perspective, focusing on how the IT department can support the agility of a business, e.g. through cloud computing which enables more flexible demand in resources without economic rent.

This paper focuses on how an IT department can become agile using emerging technologies, as a first step towards transforming the IT department into a service broker. Therefore, the rest of the paper is structured as follows. The next section will explain what agility means with the focus on finding a definition that supports the idea of IT departments as a service broker. The third section will explain what agility means for other departments. It aims to explain different concepts, frameworks, and specific angles of agility, e.g. agile supply chains, which could inform the transition of the IT department into a service broker. The fourth section explains how IT departments can become more agile.

Defining business agility

The concept of business agility or agile management first appeared in 1991 [10] and since then there has been much discussion of agility involving the creation of new definitions. Therefore, the focus will be on understanding why many definitions exist and what this means for the IT department.

Agility is often perceived from different angles. On the one hand, people think of agility as a concept to cope with change, [e.g. 4, 11, 12]; on the other hand, people think of agility as a concept to exploit opportunities, [e.g. 8, 13]. This difference in the basic understanding of agility defines how concepts and frameworks are developed. On the one hand, agility is used to react and on the other hand to act. This partly explains why many different definitions exist.

In the area of reacting, agility is often confused with uncertainty [3, 8, 14]. Companies emphasise agility because they face uncertain, unreliable and exceptional circumstances [8]. For this paper reacting means that the company responds to change after they know what the change will look like, whereas acting means that the company will anticipate the change and initiate appropriate actions. In other words, reacting is past-oriented and acting future-oriented.

In the area of acting agility is understood as a framework for decision-making [8]. As the IT department is facing ever more and faster change in the future it seems reasonable to act rather than react to achieve a competitive advantage. If the IT department only reacts, they are always one step behind. On the other hand, if they act they are more likely to take full advantage of opportunities and achieve strategic goals [11].

The meaning of agility is context dependent and is often related to the role in a company. For example, the demand for agile companies as expressed in [2], is likely to be associated with senior management. Agile software engineering, however, is not a priority for senior management but more for the software engineering department. Therefore, [8] suggests to ask “agility for whom”.

Agility is often confused or mixed up with flexibility, and dynamic abilities. The definition of flexibility is “the ability to adapt to change” [4]. The understanding is similar as to agility, however, there is a fundamental difference: flexibility refers to one off changes [4] and agility is a concept for continual change [15]. For flexibility and dynamic abilities the main measure is time [16, 17]. Therefore, it can be concluded that flexibility and dynamic abilities are only components of agility [4, 12, 18, 19].

For the purpose of this paper the definition of agility by [19] will be adopted and rephrased: Agility is the ability to anticipate change, exploit opportunities and detect threats by reconfiguring resources, processes and services to achieve strategic goals. This definition can be applied to IT departments that transform into a service broker. The concept of acting instead of reacting was adopted. Changes, opportunities and threats can come from technological developments, competitors and service providers (e.g. cloud provider). In addition, the mosaic of services can be altered by reconfiguring resources, processes and services. Lastly, the focus on innovation is reflected in the achievement of strategic goals.

Agility in other business units

Many people emphasize agility but it is important to point out two constraints. Some processes or systems are not made to be agile (e.g. ERP systems [8]). In addition, agile systems are not enough. The execution also needs to be designed in an agile way [43].

Why do companies want to be agile? As with the definition for agility, the answer to this question is also very different depending on the area. However, some major advantages can be identified that are pursued by many companies. Through agility a company can

  • React quickly and efficiently to changing market requests [27]
  • Customise products and services more feasibly [13]
  • Deliver new products in a cost-efficient manner [13]
  • Decrease manufacturing costs [13, 11]
  • Increase customer satisfaction [13, 3]
  • Increase competitiveness [20, 21]

But what is necessary for a company to become agile? Many frameworks and concepts exist but none seems to be widely accepted but some common parts can be identified. In order to achieve agility companies need agility drivers, capabilities and providers [11, 12, 14, 22, 23]. Agility drivers form the external business environment, capabilities are attributes of an agile company and they are achieved through agility providers [23]. The problem with this concept is the understanding of the terms that are as diverse as the definition of agility itself. The attributes of drivers, capabilities and providers are sometimes confused. E.g. sometimes ‘integration’ is part of drivers [e.g. 12] but other times it is part of capabilities [14]. Therefore, the conceptual model for agile manufacturing by [24] will be adopted (see Figure 1). This model pays attention to important drivers of the company (organisation, technology, people, and innovation) and incorporates the most common capabilities (responsiveness, competency, flexibility and speed). In addition, it is simple and abstract which makes it a candidate to inform the development of agile IT departments. Although it was developed for manufacturing it can be applied in other areas [23]. Other models are either highly specific to their application area [e.g. 12] or are too abstract to make them helpful in informing the development of agile IT departments [e.g. 4, 7].

Conceptual model for agile manufacturing by [24]

Figure 1 – Conceptual model for agile manufacturing by [24]

Two areas can be identified as supporting the transition of the IT department: supply chain agility and agile manufacturing. The two areas face the same challenges as, and pursue similar goals to the IT department. [3] points out that having a “truly agile” supply chain requires four attributes:

  • Market sensitivity
  • Virtuality
  • Network-based
  • Process integration

Market sensitivity means being closely connected to end-users and their trends [3]. This is an important attribute for the IT department in order to provide the right services/products at the right time and price. Virtual means that information can be shared across all members of the supply chain [3]. For the IT department this is essential in order to gain insights into the demands of the business units and possibilities by the providers. Network-based means that for specific tasks specialist providers will be used [3]. This aims to get the best result for every sub-task or sub-product. For the IT it means that they know which provider offers what in order to advice business units what services to buy where. In addition, having a network and therefore a mosaic of services is the essential idea of the IT department as a service broker. Lastly, process integration, means having a “high degree of process interconnectivity between the network members” [3]. This informs the idea of a mosaic of services and can be seen as a combination of the former attributes: only by having the right customer data (market sensitive) prioritised information (virtual) can be shared with the right providers (network-based) to feasibly purchase, create, alter or provide services from/through this network.

[13] formulate more detailed attributes than [3]:

  • Customer satisfaction
  • Quality improvement
  • Cost minimisation
  • Delivery speed
  • New product introduction
  • Service level improvement
  • Lead-time reduction

If these factors are not met the supply chain will eventually break apart [13]. They are also important for the IT department. Especially when considering the competition for services with outside providers. If business units are not satisfied they might bypass the IT department and buy services themselves. The same is true for poor quality, poor service levels, poor delivery speed. In addition, the IT department is facing the challenge to minimise costs. The concept to act as a service broker might help to minimise fixed costs as only a basic IT infrastructure will be kept in-house and the major share of costs can be passed on directly to business units. The IT department in return will be able to use the money for innovation activities. By using specialised service providers their knowledge can be used in addition to their existing infrastructure to, eventually, reduce the lead-time for new service introduction.

One commonly used concept for production lines in agile supply chains is postponement [3]. It is part of a broader concept called “De-coupling” [3, 25]. The idea is to find the optimal order penetration point. This means making the real demand visible as far downstream of the production line as possible. The basic problem of supply chains, which can also be applied to the IT department, is that orders are aggregations of demand. [25, 26] points out that these are often delayed and distorted through the parties involved. This makes it difficult to assess the real demand for single components of a product used. Finding the order penetration point means that the demand should “penetrate until the point of assembly” [3]. The concept of postponement supports companies in that matter. Its main idea is to “carry the inventory in a generic form” in order to use the inventory for several products [3, 25]. To support this concept common platforms and modules should be used (modular service/product design). The final assembly happens when the market destination and/or customer requirement and demand is known [3]. When designing a supply chain two de-coupling points need to be integrated: material de-coupling point and information de-coupling point. The material de-coupling point should be as far downstream as possible in order to delay final assembly until the real demand is visible [3, 25]. The information de-coupling point should be as far upstream as possible in order to make the real demand visible early [3, 25].

Because of the lack of a clear definition and factors ways to evaluate agility are difficult to find, i.e. evaluation is also context dependent. In addition, the factors involved often do not correspond with physical characteristics of a company [28]. Therefore, the measurement of agility should depend on the definition. For considering agility as a concept to act no evaluation methods could be found in academic literature. However, when the IT department is transforming towards a service broker evaluation is important to track progress in becoming agile and reconsider options available.

Eight different frameworks for evaluating agility could be identified [4, 7, 11, 23, 28, 29 30]. Four of these frameworks are similar, straightforward, easy to measure and abstract in a way that it could be applied to the IT department. These frameworks define a “lean/agile coefficient” [11]. A company pursuing agility can be in four stages: informal, efficient, reactive or responsive. When a company is informal and facing change it requires a lot of effort from many different resources (people, information, etc.). In this case companies often have no clearly defined business processes and the period of change is marked by instability and uncoordinated actions. Efficient companies have clearly defined internal processes but none with external partners. No pre-defined approach has been defined to address change and for every change new agreements have to be found with external partners. Reactive companies have efficient operations but they are not anticipating change or being pro-active. As well as efficient companies they have to find agreements for change with their external partners. Reactive companies have clearly defined their business processes across their entire eco-system and in addition they anticipate change and act pro-actively. In order to decide which actions to take they are using scenario planning [11].

Agility in IT departments

Customers, no matter if supply chain or IT department, demand highly customisable products that are delivered fast, at low cost [e.g. 3, 31]. Two ways exist to apply agility to IT departments. One is considering the IT as an enabler for the company to become agile, the other is trying to make the IT department itself agile. The first one has been examined extensively [32, 33, 34]. In many cases the two viewpoints are even connected [1, 7, 18, 29]. However, the focus of this section will be on making the IT department itself agile which has not received much attention. Research focuses much on prerequisites or properties of these departments but less on the actual transformation or management. Especially when incorporating the latest developments in IT (e.g. cloud computing, big data, etc.). As a first step the concepts for agile supply chains will be applied to the IT department.

Knowledge- and process-orientated IT departments

According to [19] agility in IT departments is achieved through dynamic capabilities which are, in turn, enabled through absorptive capacities. Originally this concept comes from supply chain agility. Dynamic capabilities support the IT in integrating, building and reconfiguring competencies, which can be internal as well as external, to address changes in the environment [19]. [7] refer to this as “process-oriented IT” which can be described through process reach (internally and externally) and process richness (timely, accurately, etc.) of the IT. Absorptive capacities enable the IT department to recognise valuable new knowledge, process and use it [19, 28]. [7] refer to this as “knowledge-oriented IT” which can be described through knowledge reach (comprehensiveness and accessibility of knowledge) and knowledge richness (timely, accurate, etc.) of the IT.

Applying postponement to IT departments

The IT department faces increasing uncertainty, a loss of control over their IT and the challenge of “open” socio-technical systems (or open companies). The concept of postponement was developed to deal with high uncertainties in supply chains and marketing [35, 36]. It doesn’t try to eliminate uncertainty but to push it as far downstream as possible. In addition, it was designed to deal with shortening product lifecycles and technological developments [36, 37]. Currently, one could describe the IT department as applying a push-approach. This means it is forecasting future demands based on the current ones [38]. The IT department orders generic infrastructure and software based on the demands expressed by the business units. But often, the actual demand by the end users is not visible. Instead, customer requirements should affect product design by applying a pull-approach. In this case, end user demand and requirements could be merged. By finding out which users need what and providing more specialised services the IT department can reduce costs from hard- and software purchases because they will only purchase what is really needed. By looking at emphasised drivers for the use of postponement it is possible to see how this can help achieve a pull-approach. Postponement is often used when one or more of the following conditions can be achieved [31, 37, 39]:

  • Demand for customisation
  • Modularity in construction
  • High product value
  • Short product life cycle
  • Reduced marketing risk

These factors can be applied to the IT department as

  • the need for specialised services for the business units is increasing,
  • the IT department tries to save costs through modularisation,
  • the value of hard- and software is high,
  • product life cycles become ever shorter and
  • the IT department is likely to compete for business units with other providers

However, postponement does not always work. [40] developed a framework to decide if a company should use postponement or anticipation (push- or pull-approach, respectively) [41 developed a similar model]. It was developed for supply chains but the following section will show that it can be applied to modern IT (e.g. cloud computing). The framework consist of eight steps:

  1. Define the market
    The market needs to be defined in terms of the number of destination points, plants, warehouses, etc. For the IT this means defining e.g. the number and locations of data centres (for infrastructure and data transfer) and end-user locations.
  2. Define the analysis period for postponement decision-making
    The period of static analysis must be defined to define which numbers to include and estimation of costs. For the IT this could be e.g. the amortisation period of hardware.
  3. Define products for market and period
    The products that will be distributed in the analysis period. For these products the outcome will be decided: postpone or anticipate. For the IT the products can be e.g. end-user hardware, office software, ERP-systems, etc.
  4. Define customer service level
    Varying levels of customer service correspond to different levels of physical distribution costs. They are usually measured in the cost of lost sales. For the IT this step is typically reflected in Service Level Agreements (SLAs).
  5. Determine status quo distribution costs
    This is the direct cost of distribution per period for every product under the assumption that the demand will be anticipated (push-approach).
  6. Estimate direct costs of postponement
    This is the cost of postponement per product, per period. [40] point out that this step is directly related to step four. In their model a postponement has to be chosen in order to estimate the costs (e.g. assembly, where products can either be fully assembled at the production site or wholesaler). For the IT postponement methods could be related to the transfer of date, hardware or time.
  7. Calculate direct product costs
    Direct production costs per product are the result of the subtraction of step five from step six.
  8. Decision: Postpone or Anticipate

As explained in step six the costs of postponement are closely related to the postponement method chosen. Different types of postponements have different cost consequences (i.e. [40] shows a list). Taking assembly postponement, for example, transportation costs can be reduced as unassembled products have better density ratios but production costs are increased because every wholesaler needs equipment to assemble the product [40]. Therefore, the benefits of postponement depend on the existing structure of the IT, the software they already possess (e.g. licensing contracts), and type of uses (generic or specialised). This supports the argument expressed above, that the IT departments needs to find the right balance between anticipation (push-approach) and postponement (pull-approach) as not every service or product is equally suitable.

The definition for agility emphasised in this paper needs methods for anticipation, exploitation, and detection to be realised. The areas or items of a company that can be changed are resources, processes, and services. Based on existing methods developed for the concept of postponement, three could be identified that seem to be a good starting point. Knowledge and/or process orientation can be used to anticipate change. De-coupling and modular service/product design can be used for exploitation. Based on research in other areas scenario planning could be a method to detect threats. However, this area needs further research before a complete framework can be developed.

In conclusion, the concept of postponement is a good approach for the IT department if hardware is involved (either eliminating or buying). This is consistent with findings from other studies on postponement where methods used were often related to time, transport or assembly. These methods don’t have implications for the IT in most of the cases where hardware isn’t involved because transport and assembly of information can happen in almost no time with low configuration costs.

Conclusion

This paper explored the idea of using agility as a first step to transform the IT department towards a service broker. The concept of postponement was used to build agility within the IT department. However, postponement can support IT departments in dealing with uncertainty but not other challenges identified in my previous paper (loss of control over IT, “open” socio-technical systems). This paper focused on concepts from supply chains. In the next step I will take a similar look at agile software engineering and agile project management to explore whether concepts from these area can be applied to IT departments as a whole.

In summary, company-level IT planning, implementation and maintenance are important for agile IT [33, 42]. IT governance is important for companies who find themselves in markets of constant change [18]. Exploring the subject of IT governance in relation to agile IT departments will be part of further research. In addition, the extensive use of postponement can result in a loss of control over the production line [35]. The questions that need investigation are, whether this is also true for the IT department, and whether postponement would still be a viable candidate to transform the IT department into a service broker. In this context, it also needs to be investigated if the concept of postponement is applicable to every size of company, e.g. small or medium enterprises (SMEs).

This article was written as part of my PhD progress with the School of Computer Science at the University of St Andrews.

References

[1]      J. S. Brown and J. I. I. I. Hagel, “Flexible IT, better strategy,” McKinsey Quarterly, pp. 51–59, 2003.

[2]      J. Bughin and M. Chui, “The rise of the networked enterprise: Web 2.0 finds its payday,” McKinsey Quarterly, no. December, pp. 1–9, 2010.

[3]      M. Christopher, “The Agile Supply Chain: Competing in Volatile Markets.,” Industrial Marketing Management, vol. 29, no. 1, pp. 37–44, 2008.

[4]      K. Conboy and B. Fitzgerald, “Toward a Conceptual Framework of Agile Methods : A Study of Agility in Different Disciplines,” Management, pp. 37–44, 2004.

[5]      P. Abrahamsson, J. Warsta, M. T. Siponen, and J. Ronkainen, “New directions on agile methods: a comparative analysis,” 25th International Conference on Software Engineering 2003 Proceedings, vol. 6, no. Proceedings of the 25th International Conference on Software Engineering (ICSE’03), pp. 244–254, 2003.

[6]      D. Reeves, “Cloud Computing: Transforming IT.” pp. 1–51, 2009.

[7]      E. Overby, A. Bharadwaj, and V. Sambamurthy, “Enterprise agility and the enabling role of information technology,” European Journal of Information Systems, vol. 15, no. 2, pp. 120–131, 2006.

[8]      M. Schrage, “The Struggle to Define Agility,” CIO, pp. 40–42, 2004.

[9]      C. Huang, J. A. Ceroni, and S. Y. Nof, “Agility of networked enterprises — parallelism, error recovery and conflict resolution,” Computers in Industry, vol. 42, no. 2–3, pp. 275–287, 2000.

[10]    R. N. Nagel, “21st Century Manufacturing Enterprise Strategy,” 1992.

[11]    C. Verstraete, “Planning for the unexpected,” Learning, vol. 83, no. 3, pp. 18–21, 2004.

[12]    Y. Y. Yusuf, M. Sarhadi, and A. Gunasekaran, “Agile manufacturing: The drivers, concepts and attributes,” International Journal of Production Economics, vol. 62, no. 1–2, pp. 33–43, 1999.

[13]    A. Agarwal, R. Shankar, and M. Tiwari, “Modeling agility of supply chain,” Industrial Marketing Management, vol. 36, no. 4, pp. 443–457, 2007.

[14]    Y.-H. Tseng and C.-T. Lin, “Enhancing enterprise agility by deploying agile drivers, capabilities and providers,” Information Sciences, vol. 181, no. 17, pp. 3693–3708, 2011.

[15]    S. L. Goldman and K. Preiss, Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer (Industrial Engineering). Wiley, 1994, p. 414.

[16]    D. Eppink, Managing the Unforeseen: A Study of Flexibility. Vrije Universiteit.: Amsterdam, 1978.

[17]    S. O. Gustavsson, “Flexibility and productivity in complex production processes,” Manufacturing Research and Technology, vol. 22, no. 5, pp. 85–93, 1984.

[18]    P. P. Tallon, “Inside the adaptive enterprise: an information technology capabilities perspective on business process agility,” Information Technology and Management, vol. 9, no. 1, pp. 21–36, 2007.

[19]    N. Ashrafi, P. X. P. Xu, J. Kuilboer, and W. Koehler, Boosting Enterprise Agility via IT Knowledge Management Capabilities, vol. 2, no. C. Ieee, 2006, p. 46a–46a.

[20]    E. Bottani, “A fuzzy QFD approach to achieve agility,” International Journal of Production Economics, vol. 119, no. 2, pp. 380–391, 2009.

[21]    A. Ganguly, R. Nilchiani, and J. V Farr, “Evaluating agility in corporate enterprises,” International Journal of Production Economics, vol. 118, no. 2, pp. 410–423, 2009.

[22]    M.-Å. Hugoson, T. Magoulas, and K. Pessi, “Interoperability Strategies for Business Agility,” Health Care, vol. 10, pp. 108–121, 2008.

[23]    B. Sherehiy, W. Karwowski, and J. Layer, “A review of enterprise agility: Concepts, frameworks, and attributes,” International Journal of Industrial Ergonomics, vol. 37, no. 5, pp. 445–460, 2007.

[24]    H. Sharifi, “A methodology for achieving agility in manufacturing organisations: An introduction,” International Journal of Production Economics, vol. 62, no. 1–2, pp. 7–22, 1999.

[25]    J. Ben Naylor, M. M. Naim, and D. Berry, “Leagility: Integrating the lean and agile manufacturing paradigms in the total supply chain,” International Journal of Production Economics, vol. 62, no. 1–2, pp. 107–118, 1999.

[26]    J. L. Burbidge, “Production flow analysis,” vol. 42, 1963.

[27]    P. Swafford, S. Ghosh, and N. Murthy, “The antecedents of supply chain agility of a firm: Scale development and model testing,” Journal of Operations Management, vol. 24, no. 2, pp. 170–188, 2006.

[28]    N. C. Tsourveloudis and K. P. Valavanis, “On the Measurement of Enterprise Agility,” Journal of Intelligent and Robotic Systems, vol. 33, no. 3, pp. 329–342, 2002.

[29]    M. Strohmaier and H. Rollett, Future research challenges in business agility -time, control and information systems. Ieee, 2005, pp. 109–115.

[30]    M. Christopher and D. Towill, “An integrated model for the design of agile supply chains supply chains,” International Journal Of Physical Distribution, vol. 31, no. 4, pp. 235–246, 2001.

[31]    E. Feitzinger and H. L. Lee, “An Integrated Model for the Design of Agile Supply Chains,” Harvard Business Review, pp. 116 – 121, 1996.

[32]    S. P. Bradley and R. L. Nolan, Sense & Respond: Capturing Value in the Network Era. Harvard Business Review Press, 1998, p. 339.

[33]    V. Sambamurthy, A. Bharadwaj, and V. Grover, “Shaping agility through digital options: reconceptualizing the role of information technology in contemporary firms,” MIS Quarterly, vol. 27, no. 2, pp. 237–263, Jun. 2003.

[34]    P. Weill and M. Broadbent, Leveraging the New Infrastructure: How Market Leaders Capitalize on Information Technology. Harvard Business Review Press, 1998, p. 336.

[35]    B. Yang and N. Burns, “Implications of postponement for the supply chain,” International Journal of Production Research, vol. 41, no. 9, pp. 2075–2090, 2003.

[36]    B. Yang, N. D. Burns, and C. J. Backhouse, “Management of uncertainty through postponement,” International Journal of Production Research, vol. 42, no. 6, pp. 1049–1064, 2004.

[37]    J.-S. Chiou, L.-Y. Wu, and J. C. Hsu, “THE ADOPTION OF FORM POSTPONEMENT STRATEGY IN A GLOBAL LOGISTICS SYSTEM: THE CASE OF TAIWANESE INFORMATION TECHNOLOGY INDUSTRY,” Journal of Business Logistics, vol. 23, no. 1, pp. 107–124, 2002.

[38]    R. D. Shapiro, “Get leverage from logistics,” Harvard Business Review, pp. 119–126, 1984.

[39]    W. Alderson, “MARKETING EFFICIENCY AND THE PRINCIPLE OF POSTPONEMENT,” Marketing Behavior and Executive Action, pp. 423–427, 1957.

[40]    W. Zinn and W. J. Bowersox, “Planning Physical Distribution with the Principle of Postponement,” Journal of Business Logistics, vol. 9, no. 2, pp. 117–136, 1988.

[41]    J. D. Pagh and M. C. Cooper, “Supply Chain Postponement and Speculation Strategies: How to Choose the Right Strategy,” Journal of Business Logistics, vol. 19, no. 2, pp. 13–33, 1998.

[42]    Anandhi S Bharadwaj, “A RESOURCE-BASED PERSPECTIVE ON INFORMATION TECHNOLOGY AND FIRM PERFORMANCE: AN EMPIRICAL INVESTIGATION,” MIS Quarter, vol. 24, no. 1, pp. 169–196, 2000.

[43]    P. Abrahamsson, A. Hanhineva, and J. Jaalinoja, “Improving Business Agility Through Technical Solutions: A Case Study on Test-Driven Development in Mobile Software Development,” in Business Agility and Information Technology Diffusion, vol. 180, no. 1, Kluwer Academic Publishers, 2005, pp. 227–243.

[44]    G. Kim, “Leadership – CIO challenges for 2013 and beyond.” p. 22, 2013.

[45]    H.-M. Chen, “Towards Service Engineering: Service Orientation and Business-IT Alignment,” in Proceedings of the 41st Annual Hawaii International Conference on System Sciences HICSS 2008, 2008, pp. 114–114.

Advertisements

2 comments

  1. Pingback: Resilience in IT | Marc Werfs - The Blog

  2. Filip

    Great read! Is this paper published anywhere in a academic journal or similar?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: