Agility is a legitimate and measurable business goal. However, the actual pursuit and proof of your efforts will be elusive if you do not have a solid definition, a comprehensive framework and a vision for how agility can alter the status quo.
Table of Contents
This special report offers Gartner's take on agility. Gartner has been researching agility for several years, and has taken a broad view of the topic, even keynoting the International Federation for Information Processing (IFIP) academic conference on agility in 2005. Here, we will present 20 pieces of research (including this article) that provide a fundamental overview of agility and show how agility can be defined, measured, financially evaluated and incorporated into your ongoing efforts. These efforts include security, process management, information search and retrieval, and dealings with external service providers (ESPs).
Outside Gartner, we believe the term "agility" lacks a consistent meaning across the IT industry. For every person who believes it is simply a term associated with new ways to develop systems (for example, agile methods), there is another who sees it as the label for successful supply chain management. We hear talk of agile business and talk of agile IT. Is it both? Is it neither? How do they relate? The industry talks of creating, enhancing, improving and leveraging agility as if everyone responsible understands what that means and how to go about the process. This is clearly false. The IT industry does not collectively agree on what agility means, nor does it know the best way to go about the process of becoming agile. This is the problem when IT adopts a word that already connotes and denotes a world of pre-existing images of what it means to "be agile": dancers, athletes, wild animals, watchmakers, surgeons and so on. It is not shocking that enterprises want to be agile. What is shocking is that very few of them know what it means to be agile. Imagine a meeting where agility is exhorted as the next big goal, and where the meeting participants run in 10 different directions. Some want to investigate new development approaches, others want to tune the supply chain, and the majority simply recall childhood memories of gazelles leaping on the African plains as their only anchor points to this critical topic. Without definition, coordination and a shared vision, exhorting IT to be agile is an exercise in futility.
The first challenge for agility is definitional: What is agility? In "Achieving Agility: Defining Agility in an IT Context," we define agility as "the ability of an organization to sense environmental change and respond efficiently and effectively to that change." Sensing the need for change also includes the proactive initiation of change. This is a simple definition to start the discourse, but a concept such as agility needs flesh beyond the bare-bones definition. The remainder of our definitional research explains why agility is emerging as a critical topic, how agility fits within the context of IT, why an agility cycle is the best approach to managing your agile action, and why the human factor (people issues) may be the biggest impediment to success with your efforts.
Once defined, agility has to be taken to the next level; actual investments must be implemented and the results measured. In "Achieving Agility: The View Through a Conceptual Framework," we discuss some of the intricacies of achieving and then measuring agility, as well as creating an enterprise's "agility score." Based on our own experience with agility measurement, we offer a set of steps for enterprises that are seeking to build their own assessment methodologies. This research provides a conceptual framework of agile continuous improvement — one that can guide implementation of IT prescriptive aids to agility and that can allow an enterprise to track its own agility vector over time. This research can serve as a building block for new approaches to answer a difficult question: "Just how agile is my enterprise?"
Agility cannot be divorced from its impact on the enterprise's bottom line. If methodologically sound measurement shows that an enterprise has increased its agility (that is, obtained a better agility measurement) compared with its past performance, there should be tangible results to show the impact of being more agile. If not, agility is a worthless measure. Michael Smith shows how to bring financial impact assessment to agility in "Achieving Agility: Measuring the Financial Implications of Agility." By tying agility to the key components of financial analysis, the impact and import of being agile can be assessed and valued. Such an assessment is critical if IT is to prove value from the significant investments of time, technology and organizational change management that will be required of those seeking agility.
Organizational resistance and socio-technical dynamics are two perpetual boulders on the road to agile change. In "Achieving Agility: Plan for Workforce Reconfiguration, Expect Resistance," Diane Morello describes how the desire to be agile will likely drive IT workforce change and create resistance in the process. She offers a taxonomy of resistance (levels of why people resist) and shows how to combat resistance before it becomes entrenched. One of the most collaboration-intense and human-rich areas that must be prepared to embrace agility is discussed by Tom Austin in "Achieving Agility: Growth, Agility and High-Performance Workplace Strategies Are Intimately Linked." As stated before, "people issues" are often the most vexing challenge to IT progress, and we expect that to be the case with agility. Ultimately, success with agility requires mastering the people issues.
Agility, done right, will create substantial internal change and has the potential for disruption in parallel with innovation. However, agility is not a self-contained venture, local only to the enterprise attempting to be agile. Agility will have causes and effects beyond the enterprise's immediate organizational boundaries. Michele Cantara gives an overview of how agility is influencing and being influenced by the ESPs. In "Achieving Agility: Evaluating the Agility-Enabling Abilities of External Service Providers," she reviews several of the largest integrators' agility strategies — strategies that may (wittingly or not) be the basis for your next venture into agility. Jack Heine shows that your need to be agile must be proactively factored into contracts with your suppliers (see "Achieving Agility: Searching for Agility in IT Contracting" ). You cannot seek agility in hindsight. Finally, in "Achieving Agility: Take the Right Steps to Ensure Agility in Outsourcing Contracts," Bill Maurer and Lisa Stone show that agility must guide one of the most heated forms of contractual relationships today: your outsourcing relationships. Overall, your relationships and contracts with external parties can be anchors holding you down, or they can be living documents allowing you to proceed with your plans for agility unfettered. Agility requires foresight and an open dialogue.
The information exchange required by agility is substantial (for example, sensory data, contract information, organizational change requirements, financial impact of agility and measurement of agility). Because the first step in being agile is "sensing environmental change," information access and information quality are key enablers or inhibitors to agility. In "Achieving Agility: Information Access Essential to Understanding Your Business," Rita Knox and Whit Andrews show how information access technologies and concepts can provide early insight into environmental change, opportunities and disruptions. Frank Schlier, in "Achieving Agility: Information Architecture Is a Key Component of Enterprise Agility," describes how an information architecture must underpin enterprise agility efforts and shows that such a move often requires enterprises to accept more upfront costs for significantly increased long-term value. Once again, we see the need for cultural change and for clear metrics of agility's value. As a final proof point of the value of information to agility, we have two companion pieces. David Newman and Debra Logan describe enterprise information management (EIM) and its role in agility (see "Achieving Agility: How Enterprise Information Management Overcomes Information Silos" ), and Andrew White and Thilo Koslowski describe EIM's role in value chain agility (see "Achieving Agility: Enabling Agility Across a Value Chain With Enterprise Information Management" ). In a nutshell, bad information is a wrench in the agility machinery. Good information planning is the remedy.
The remaining research pieces in this special report address one of the most popular questions we are asked about agility: "How does agility relate to my technology choices and IT best practices?" We believe that IT investments can be prescriptive to agility — that proper doses of the right technologies and IT best practices can increase an enterprise's agility potential. That point is made in the definitional research and is an underlying point of the entire measurement of agility. To demonstrate how agility can be related to specific technologies and IT best practices, the following research pieces tackle that question head-on:
"Achieving Agility: BPM Delivers Business Agility Through New Management Practices" — Janelle Hill and Michael Melenovsky
"Achieving Agility: The Agile Power of Business Rules" — David McCoy and Jim Sinur
"Achieving Agility Through Communication-Enabled Business Processes" — Bern Elliot, Steve Blood and Bob Hafner
"Achieving Agility: SOA Will Build Organizational Agility, but Watch the Hype" — Charles Abrams and Janelle Hill
"Achieving Agility: The Data Center Is the Foundation" — Thomas J. Bittman
Notice the strong focus on agility and business process management (BPM — including business rule management) — four of our research pieces directly address that linkage. Clearly, the synergy of BPM and agility is exciting. Agility's role in security, the data center and advanced software architectures such as service-oriented architecture (SOA) round out the technology choices and IT best-practice discussion.
Be Agile: There should be no reason to struggle with an understanding of agility. There is no reason to delay efforts to improve agility. This research is a starting point. Now, go and be agile!