Agility And What's Keeping You From It

In our Forrsights Business Decision-Makers Survey, Q4 2011, we asked business technology leaders to rate IT’s ability to establish an architecture that can accommodate changes to business strategy. While 45% of IT rated its ability positively, only 30% of business respondents did. Clearly, both think there is room for improvement, but business is more concerned about it.

So are we agile? Only 21% of enterprise architects in our September 2011 Global State Of Enterprise Architecture Online Survey reported being even modestly agile, so I think we all know the answer.

What do we do about it? Continue to focus on technology standardization and cost reduction? Give up on that and focus on tactical business needs? Gridlock in the middle because we can’t make the business case to invest in agility? This is the struggle EA organizations face today.

To act with agility, firms must create a foundation for it, and three barriers can get in the way:

  • Brittle processes and legacy systems. We all know it this one; the current state mess of processes that cannot adapt to change and legacy systems where everything is connected to everything else, so even the smallest changes have broad impacts. Techniques to overcome this barrier include partitioning the problem into digestible pieces to show incremental progress and short-term payoff.
  • Victim mentality. Frequently when I talk to IT personnel, I hear, “The business doesn’t know what it wants,” or “The business doesn’t understand what it takes to build solutions.” The story is the same when I talk to the business: “IT is too slow. I don’t understand why they take so long”; or “I don’t deal with IT if I don’t have to.” People get too busy pointing fingers to act quickly, or too focused on their own pain to address it organizationally. Frequently this is coupled with a feeling of accountability without visibility or authority. Techniques to overcome this barrier include developing joint accountability and simple shared principles that align stakeholders.
  • The quest for bulletproof solutions. As enterprise architects, we are paid to create enterprise solutions that we design to have all kinds of qualities, such as recoverability, robustness, etc. Often the driving quality requirement is agility, yet we only know one trick — make it bulletproof. Frequently this is caused by an aversion to risk and conversation about failure avoidance rather than risk and reward. Overcoming this barrier requires techniques for managing risk, including use of architecture zones and empowering decision rights and accountability to promote better risk-taking.

We think each of these offers a unique opportunity for IT to become more agile and to innovative by recognizing why the barriers exists and acting now to begin overcoming them. What do you think? Have you done something that has been effective at addressing one of these barriers? Do other barriers exist? Let’s start a conversation here, then continue it as Khalid Kark and I present a keynote on the topic at the 2012 CIO/EA Forum in Las Vegas on May 3 and 4, and in Paris on June 19 and 20. As part of our presentation, we will provide examples of companies that have made progress against these barriers and give you more of our own recommendations.

Comments

The Agile process has been abstracted from its essence.

One of your colleagues wrote a post on Agile with a key sentence: Developers would much rather stick with what they know: typing class definitions, if-then-else statements, and looping constructs into glorified text editors. If that sentence is true in your organization, Agile will be an ineffective process. Scrums do not produce customer-centric software solutions (the ones that solve real problems and please customers) if no one in the organization works toward them purposefully. Employing a detailed process without understanding the essence (the problem the process solves) is about as effective as having NO process (although no process is less expensive). The frustrating part about organizations that fall into this trap is that they often don't have measurable objectives to begin with, which makes holding them accountable for failure almost impossible (or unnecessary).

Can't disagree

I was concerned when I wrote the post that the use of the word "Agile" would immediately lead people to jump to agile sw development methods. I think one of the things you allude to is that many firms jump into Agile development without having a foundation of organizational agility and this leads to failure. IOW Agile will be an ineffective development process if your people and culture do not accept some fundamental tenants of agility in the broader sense.

It is this broader sense that I use the word "agile" in this post and ask the question - is your organization agile? Can it quickly adapt to change (both internal and external)? These issues are cultural and deal with clarity of decision rights and accountability (think I just said governance...but many view that as a dirty word.) And you point on the governance issue by talking about accountability.

Thanks for your comment. Brian

Agility versus Enterprise Architecture

We have the integration with the business, and therefore IT is a part of designing the business solution. To me, that is the only way IT can hope to be seen as Agile by the business. The next step is backing up from the immediate project at hand, and figuring out how to put the systems design in context with larger architectural frameworks (that are supposed to save time eventually). However, getting developers to stop long enough to design for the bigger picture, and not just for the current project is a challenge. Even if you get them to design within our target architectural context, they don't have time to use the new way of working "this time", because the project has to be done quickly, and they don't have time for the learning curve to be factored in. I am interested in how others are dealing with this ongoing issue.

Doubt about architecture frameworks

Your wording is interesting, "figuring out how to put the systems design in context with larger architectural frameworks (that are supposed to save time eventually)"

I hear frustration there, and see this all the time. Some framework is supposed to eventually deliver the benefit, but clients can't get over the hump of investing all the time and energy to get it to the point of self sustainability. I suspect that very few firms ever get their when they start with the hope the the framework will eventually get them there. We are doing a good bit of research in this area now and are creating a couple of solution playbooks on creating a high performing EA organization and implementing a business centered EA practice that starts with sustainable business agility as its cornerstone. We think this focus and our method will not require EA team to take the "blind leap of faith" that a method or framework will eventually pay off. In our opinion, it has to pay off immediately or its not worth the time.

Schedule and inquiry with me, or Gene, Alex or Henry to get some perspectives on this.

All that to say, we understand the pain. Thanks for your insights.

From agile development to agile evolution of enterprise systems

It seems that this old presentation is still actual....
http://www.slideshare.net/samarin/from-agile-development-to-agile-evolut...

Thanks,
AS

Managing the integrated IT portfolio and IT budgetting

Thank you Brian. We are very much looking forward to see the best practice examples during your presentation at the 2012 CIO/EA Forum in Las Vegas on May 3 and 4, and in Paris on June 19 and 20. I do absolute on the post you wrote. I do believe there are two major contributors to the organizational challenge you describe.

1. No integrated IT portfolio
The interesting and unfortunate thing is that the business is pointing to IT and IT is pointing to the business. Organizations have to break these silo's and start managing IT from an integrated portfolio point of view. The integrated portfolio brings together all stakeholders and portfolios (incl. but not limited to application portfolio, technology portfolio, business strategies & demand portfolio, project / change portfolio etc.) in a central hub. This hub will act as the collaboration platform to make decisions in support of the business strategy.
2. No proper IT budgeting
In a study of Nucleus Research it reveals that barely 4 % determine their IT budget in accordance with the company’s actual business strategy. As a consequence, more than 90 % of the participants base their IT budget on industry benchmarks - as an arbitrary percentage of revenue - or simply tweak the previous year’s budget. Proper budgeting is important to bring them together. Otherwise the outcome of IT will be a function of the budget available, not the outcome which delivers the value the business is deserving. You can read more about the study at http://bit.ly/rCUDbR

Victim mentality

Brian,
I’m looking forward to your presentation. It occurs to me that the Gorgonian knot that we have to cut is the separation of “the business” and “IT”. We don’t talk about “sales” and “the business” or “HR” and “the business”, but we continue to speak as if IT was not part of the business --- when it fact for many enterprises IT is becoming more and more integrated in everything the business does.
This isn’t a technical problem of course but rather an organization change management issue and it should be handled as such. In fact we are observing that some of our leading customers are having their EA team partner with change management specialists to overcome this hurdle.
Bill