By Allen Brown, President and CEO, The Open Group
In his 1970 bestseller, Future Shock, futurist Alvin Toffler predicted that the rate of technological change and progress was beginning to accelerate at a rate faster than what people are often ready for or can handle. Looking over the course of history—from agrarian societies through the industrial age to our current post-industrial age in which more people work in service-oriented fields than agricultural ones—Toffler noted that the rapid changes brought on by technology often leave people in a state of “future shock.”
Future shock, Toffler argued, can cause not only disorientation for those who are caught up in it, but it can also induce a kind of paralysis brought on by being confronted with too many choices. In its worst form, future shock can lead to alienation and a breakdown of the social order due to “information overload” (a term originally coined by Toffler).
Toffler’s predictions were amazingly accurate for the time. We are most certainly in an era where we can barely keep up with the constant technological changes we are faced with on a daily basis. This is certainly true of how consumer technologies have changed our lives. Not only is the laptop or phone you buy today practically obsolete by the time you get it home, but we constantly struggle to keep up with our technologies and the volume of information—via email, text messages, the Internet, Twitter, etc.—that we consume on a daily basis. We are all likely suffering from some degree of information overload.
Similarly, technology change is accelerating business drivers at rates that are increasingly difficult for organizations to keep up with, not only for IT, but also for management. Trends such as Cloud, BYOD, Big Data and the Internet of Things are driving information overload for today’s enterprises putting intense pressure on lines of business to respond quickly to market drivers, data-driven imperatives and internal demands. Organizations are being forced to change—whether they are ready or not.
According to Toffler, the only way to combat future shock is to learn to adapt and to do so constantly. Toffler likens an inability to adapt to a new kind of illiteracy, with those who cannot adapt being left behind. “The illiterate of the 21st Century are not those who cannot read and write but those who cannot learn, unlearn and relearn” he said.
The problem is that most organizations today are not in a position to handle rapid change or to adapt quickly. In The Open Group Convergent Technologies Survey, only 52 percent of organizations surveyed felt they were equipped to deal with convergence of new technologies, while 27% said they were ill-prepared. Prepared or not, the tide of convergence is coming whether organizations like it or not. But to survive in our current economy, companies must learn to architect themselves in the moment.
Using Agile Development as a Model
Over the past ten years, agile software development has emerged as one of the ways for IT developers to adapt to the requirements of constant change. Based on a definition coined in the Manifesto for Agile Software Development in 2001, agile development is characterized by iterative, incremental and rapid development that evolves through collaboration. Rather than making development a process that takes years of painstaking planning before execution, the agile method puts a product out into the market at the earliest convenience, tests it with users and then adapts it accordingly. The process is then repeated with feedback and upgrades on a constant, iterative loop.
Agile development is driven by flexibility and the ability to respond rapidly to keep up with the endless change in the market. With agile principles, organizational focus shifts from processes and tools to individuals and interactions, the organization to the customer, from negotiation to collaboration, and to responding to change rather than sticking to rigid plans.
For many readers, “agile” is a loaded term and largely associated with solutions rather than the enterprise architecture but there are some appealing aspects to it. An adaptation of the twelve principles of Agile Development to the discipline of Enterprise Architecture would be an interesting place to start. I have just picked out half of the principles and adapted them here by way of example – using parenthesis to show possible deletions and adding a few words here and there in italics.
- Our highest priority is to satisfy the customer through early and continuous delivery of (valuable software) valuable architecture guidance to the enterprise
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Business people and (developers) architects must work together (daily) throughout the project.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
What Organizations Can Learn from Agile Development
As Toffler predicted, the rate of business change is happening so quickly that if you take too much time to do anything, your organization is likely to lose out. Business schools have even taken a page from IT development and have begun teaching the principles of agile development to graduate students. As Toffler noted, “if you don’t have a strategy, you’re part of someone else’s strategy.” In business today, as in combatting “future shock,” adaptability must be at the core of every organization’s strategy.
Organizations that want to survive and thrive in this paradigm will need to take a page from IT, agile development and start-up cultures to become more nimble and move more quickly. Becoming agile will take significant shifts in culture for many organizations. Business and IT must work together in order to facilitate changes that will work for each organization. Enterprise architects and IT leaders can help lead the charge for change within their organizations by helping the C-Suite not only understand how to apply agile development principles to the business, but by showing the potential consequences of being slow to adapt and how business imperatives are the real drivers for these changes.
Architecting things as you go is a difficult thing for most organizations and most industries. Most of us are not used to that level of flexibility or a need to adapt that quickly. We are more comfortable with planning ahead and sticking to a well-thought out plan. Agility does not preclude planning or forethought—rather it is part of the process and action plan instead of being a precursor to action. Although many organizations are likely in for a large dose of “future” or culture shock, adaptation and business transformation is necessary for today’s organizations if they don’t want to be left behind in the face of constant change.
Allen Brown is President and CEO, The Open Group – a global consortium that enables the achievement of business objectives through IT standards. For over 15 years Allen has been responsible for driving The Open Group’s strategic plan and day-to-day operations, including extending its reach into new global markets, such as China, the Middle East, South Africa and India. In addition, he was instrumental in the creation of the AEA, which was formed to increase job opportunities for all of its members and elevate their market value by advancing professional excellence.
Thanks for your post. Question, does The Open Group provide or plans to provide formal guidance on agile approaches to applying TOGAF?
Allen. This is an excellent and important post. I’m particularly struck by your observations about learning to do “architecture as you go” and the need for flexibility and adaptability. It’s not something that can be addressed by, for example, grafting Scrum on top of TOGAF. It requires an understanding of the history of and rationale behind agile methodologies.
To be honest, with all respect to Jose, I don’t think the Open Group should be providing “formal” guidance. I’m one of those strange people who think TOGAF is perfectly capable of being used without modification in an agile context. The ADM is not a waterfall methodology (or even RUP) but a depressing number of people seem to assume it is. The key lies in setting goals, expectations and targets based on what the enterprise knows it needs and would have today if possible. And when we’ve delivered that, review and move on.
Hi Stuart, You are right on that we cannot put Scrum on TOGAF to make it agile, it needs a different approach. But at the same time, there is no harm in Open Group giving guidance on how to make TOGAF agile. ADM is not waterfall,but how many know to iterate or how to tailor it to make it agile.
FYI, can you go through this presentation and let me know your thoughts
Comments are closed.