176591517Unless we re-think Enterprise Architectures (EA), and bring it into alignment with the agile development movement, we may be in for a collision between two cultures.

Here at Info-Tech world headquarters, we are working on a series of project blueprints on agile development (more about that below). I’ve been involved quite a bit in quality reviews of these blueprints and have started thinking about the impact of agile development on Enterprise Architecture. I see the implementation of EA as being at odds with the Agile Manifesto. Here’s the manifesto, in case you haven’t seen it in a while:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Enterprise Architecture, as currently implemented in large organizations, tends to favor the items on the right over the items on the left. The stock in trade of EA consists of processes, tools, comprehensive documentation and creating plans for others to follow. As agile development grows within large organizations, something clearly has to give.

Reinvent, Oppose, or Meet in the Middle?

Can Enterprise Architecture reinvent itself as an agile practice or must it, by its very nature, oppose agile development as yin to its yang? Or should agile and EA meet somewhere in the middle?

Those of us with many years of IT experience sometimes shudder at the thought of the agile manifesto. With the gift of 20/20 hindsight, we look at the tangled mess of systems built in a typical IT shop over the last 30 years and wonder if a little planning might have saved the day. If we were guilty of anything, it was being too responsive to our business users.

Instead of building that fifteenth billing system because the user’s product line was special and needed to launch yesterday, maybe we could have insisted on re-purposing an existing system and saved the company from the burden of duplicate customer databases, nineteen different customer identifiers and revenue reports that don’t reconcile. Do we really want to become even more responsive and adding to the spaghetti that is already strangling the typical IT department in a huge technical debt that soaks up 80% of the budget?

On the other hand, our business users are so fed up with the slow pace of IT that they are taking matters into their own hands and implementing cloud solutions left and right. If we insist on rigorous central planning, we’ll end up managing yesterday’s IT department and wondering where all the new applications went.

The Road to Re-invention

Clearly, we need to re-invent Enterprise Architecture to retain its best features and avoid technical debt while adapting to the new realities of agility and the cloud. How on earth do we do that?

Here are some of my early thoughts:

  • We need to focus on high-level principle statements and vision diagrams that can communicate the essence of our target state quickly. Our audience now consists of people who have grown up with sound bites, infographics and video games. If we can’t communicate to this audience, we are lost before we begin.
  • Our revision cycles have to speed up and adapt. The ponderous Application Development Methodology (ADM) that forms the heart of TOGAF doesn’t cut it anymore. Our architects need to become part of the agile teams, contributing to the development of working software and constantly feeding back to agile EA teams who are actively maintaining the integrity of our target state vision.
  • The various core practices of architecture (business architecture, technical architecture, data architecture etc.) need to be practiced simultaneously in agile sprints, not in sequence.
  • The notion of architecture governance, based on review gates and review boards for large waterfall projects, must be discarded and replaced with a “roll your sleeves up” approach that embeds architects with agile teams so that they can practice governance in real-time. This will avoid costly rework when teams fail to meet standards and adhere to guidelines.
  • The holy grail of a fundamental repository of re-usable artefacts must finally be set to rest. Artefacts rarely, if ever, get re-used and no one ever trusts the state of current documentation as an accurate representation of the actual state of the application. Let’s get over it and be practical.

Please note that I’m not advocating any abdication of EA responsibility. We need a clear central vision of what we’re building to avoid technical debt and ensure that systems mesh together well. However, the way we accomplish this must change with the times. We need to be able to clearly and quickly communicate our vision and become active evangelists for it, contributing to real work as we encourage our team members to do the right things.

Agile Sprint
Click For Infographic

Those Info-Tech project blueprints on agile I mentioned above include Agile Practices that Work. This blueprint is aimed at organizations implementing agile technologies for the first time and is a no-nonsense practical guide to implementing scrum. A second blueprint called Increase the Agile Footprint, currently in production, is focused on optimizing the application of agile methods and gaining momentum in the organization for the roll-out of agile to more projects. The third and final blueprint will be aimed at scaling up agile methods to take on large projects and will be based on the methodology created by Scott Ambler, called Disciplined Agile Development.

We are also thinking about creating a blueprint on this subject of re-inventing EA for the Agile Movement. I welcome your thoughts and experiences. Has anyone out there implemented agile enterprise architecture in some fashion?

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter
Barry Cousins
Barry Cousins
Senior Consulting Analyst
Info-Tech Research Group

The “agile footprint” in the IT organization has reached critical mass. Like most organizations, the number and size of Agile projects represents most of the project portfolio.

There is enough Agile to render traditional portfolio metrics useless. The challenge is to improve project oversight without imposing old-school command-and-control.

Please join me and subject matter expert panelists on Thursday, May 29, 2014 at 4:00 pm EDT for a Webinar on, “Agile Portfolio Management: Are you still old-school command & control?”

Register Here For This Webinar
(Video of this webinar will be available at this link after the event)

We will discuss:

  • Prevalence of Agile
  • Executive oversight of a partially Agile portfolio
  • Metrics that matter
  • Portfolio owner as ambassador

Info-Tech Research Group webinars occur during the early weeks of our research projects.  Attendees will weigh-in on several key polls and will be able to pose questions to the group. We want to work closely with our members and potential members as we build out our research to ensure we are thoroughly meeting your needs.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

152994631Since its creation in 2001, the Agile Manifesto has helped transform software development. Many organizations have embraced its iterative approach to development that facilitates the frequent release of working software in short sprints. Teams take on an attitude of “just enough.” For Agile developers, it is more important to deliver software to the clients quickly and often, than to spend a longer period of time perfecting a final product. The customer is able to provide intermittent feedback and developers can adapt accordingly before the last release. The idea is to fail early and fail fast.

Agile has proven itself to be a valuable approach in the Dev environment, but it has not yet been widely considered for IT Infrastructure. Can Infrastructure adapt Agile methods for their own teams to increase the frequency and speed of Infrastructure releases? Critics will argue that Agile is ill-suited to the conservative, risk-averse Infrastructure environment, and it might be if it is not tailored to the needs of individual Operation groups. However, if it is implemented correctly, an Agile approach is EXACTLY what Infrastructure needs to begin matching the agility and adaptability of the Business it supports.

When you remove development from the equation, Agile is simply a philosophy that values people and collaboration over processes and tools. A tool or process is only as effective as the individuals responsible for putting it to use.

Infrastructure is tasked with maintaining a stable environment, delivering new and enhanced functionality to the Business, and ensuring that internal and external regulations are met. It’s no wonder that IT governance is often over-built to protect against failure and outages. This might ensure good control, but also discourages change and makes it almost impossible for Infrastructure to match the speed of Business development, or to keep up with shifting Business priorities. This is where Agile can help.

When Infrastructure gets Agile, the result will be a faster time to market for Infrastructure release, without any sacrifice of control. The appropriate experts will be used advantageously to give the CIO greater confidence in approving more frequent change. IT will be able to embrace a culture of saying YES to the Business, because teams are in place to handle a higher rate of change without risking Infrastructure stability.

Perhaps the greatest value of Agile is in its approach to team collaboration. Walk into an Infrastructure department and you might be hard pressed to know who is working on what. When that shop gets Agile, every single project that Infrastructure takes on will be broken down into tasks, given task owners and deadlines, and moved along a visual board from start to complete. Visibility is increased amongst team members, and outside stakeholders will never have to ask twice about the status of a project.

There will be a massive payoff for Infrastructure teams willing to apply Agile to their change and release processes. The most significant benefits will be faster and more frequent releases and a reduction in change related incidents, but this only scratches the surface of Agile’s value. If you ever dismissed Agile as a philosophy reserved for developers, you should consider taking a second look.

To learn how your Infrastructure team can begin reaping the rewards of this approach, read Info-Tech’s solution set Deploy Changes More Rapidly by Going Agile.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

When we begin to look at project methodologies, best practices for running projects, many 101352155businesses are turning to Agile or Agile-like methods in order to find success with the deliverables. Over the past few years, Scrum has become so common that you regularly hear people using it synonymously with “Agile.” More recently however, Kanban appears to be the big buzz for many organizations.

Organizations that have mastered Scrum are beginning to move to Kanban. Many of the major Application Lifecycle Management (ALM) vendors are also adding Kanban features to their suites and solutions. How to work lean, or with continuous flow throughout your projects, often equates to the use of Kanban.

Let’s look at the principle phases throughout the application lifecycle that have dramatic affects on project success, regardless of team size, project type, etc.

Read more here: When looking at app PM methodologies, what considerations should I make?

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Agile ALM imageAs development platforms, coding methodologies, and devices proliferate, Agile ALM tools support integrations with an ever-increasing range of systems.

Long-standing vendors in the Application Lifecycle Management (ALM) space can trace their roots to the 1980s, or even earlier. Since the 1990s, ALM tools have played a key part in the project manager’s arsenal, allowing him or her to track project status and progress towards objectives.

Managers have paid top dollar for ALM suites that could track project data and provide meaningful reporting. However, as development environments have evolved, the tools and components being used to manage this process have grown to become integrated and convenient, covering all phases of the development lifecycle including architecture, testing, and deployment with a single common interface.

Process flexibility has become key. Instead of a strict adherence to Agile or waterfall development, most firms have pursued a middle path and customized their methodology to meet their own needs. Some Agile ALM tools cater to the need for flexibility.

Quality control has become a core part of ALM. Several major ALM tools are built around testing tools and process maturity.

Going forward, expect stronger integration between ALM tools and the ecosystem of products supporting development, such as testing, PLM tools and IDEs.

For more information, please see Info-Tech’s recently released solution set on selecting an Agile ALM vendor.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter