Combining Agile Methodologies and Business Architecture

Agile methodologies and business architecture may seem to be two conflicting approaches to delivering software initiatives at first glance.

In reality, they are very complimentary. Agile methodologies get you to execute projects at a much higher pace. Business architecture makes sure that you are not forgetting anything important and looks at all impacts of a project. An Agile project can be executed with lower risk and higher odds of success if it is bulletproofed using business architecture at the same time. Two presentations made at various Business Architecture Guild events are eloquent about that subject:

• Business Architecture & Agile Methodologies made by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk among others.

• Experiences Linking Business Architecture with an Agile/Lean Development Method made by John Baker.

Agile Methodologies

The Agile Manifesto , explains very well the philosophy that is behind the various Agile methodologies used in IT departments to develop relevant software rapidly.

Agile methodologies focus more on the following:

• Individuals and interactions rather than on processes and tools;
• Working software rather than on comprehensive documentation;
• Customer collaboration rather than on contract negotiation; and
• Responding to change rather than on following a plan.

As shown in Diagram 1 above, Agile methodologies can involve the use of various methods. One of these methods is called the Scrum Software Development Method with roles, workflow, artifacts, and sprint backlog among others. John Backer shows a typical Scrum lightweight project management process in Diagram 2 below.

Another Agile method often used is called the Iterative and Incremental Development Method as shown in Diagram 3. This method includes in iteration the following steps: planning, requirements assessments, analysis & design, implementation, testing, evaluation.

Before executing any Agile methodology, making a requirement breakdown is preferable, as shown in Diagram 4 below. Unelaborated stories need to be estimated and roughly drafted. Serious ones should then be regrouped by high-level requirements, which are enumerated and ranked usually based on business strategies and tactics – where business architecture can play an important role.

As pointed out in Diagram 5, Agile methodologies are not an excuse to stop producing documentation. Agile is not an opportunity to eliminate planning. Neither is Agile open season for uncontrolled changes or continuous growth in a project’s scope. Finally, Agile methodologies are not about blindly following a set of “best” practices that can be changed from project to project. In brief, Agile is not a reason for not building and maintaining your business architecture from one initiative to another. If, while practicing Agile methods, you don’t know the overall destination and communicate it clearly then are you just making things up as you go along, potentially creating a fragmented mess. Hence the necessity of Business Architecture!

 

Business Architecture

Business Architecture is all about building capability, value, organization, stakeholder, information, asset, product, strategy and initiative maps and describing the relationships between them that are specific to your business, as shown in Diagram 6 below. Once in place, Agile experts can use their business architecture model to link their requirements and processes to capabilities and values among others to enable full impacts analysis to lower risk and make sure that there are no surprises while delivering a project/initiative/program.

According to The Open Group , Business Architecture is part of Enterprise Architecture as one of four architecture domains that constitute Enterprise Architecture. Yet, Business Architecture does not need to be as complicated as Enterprise Architecture tools often suggest. These tools use traditional stages of design, build and implementation. Project management best practices work well with this approach, and it is highly comfortable. However, this approach is lengthy, costly and to cap it all by the time you get to implementation the world has moved on. You potentially end up having the wrong solution because your speed to change is so poor. It is, therefore, understandable that Agile purist cannot warm up to the heavy Enterprise Architecture approach.

Business Architecture, in contrast, is much lighter than Enterprise Architecture. Getting setup for the first initiative(s) may take between 2 and 6 months by importing existing data from other systems already in place in an organization, by building the first levels of capabilities, organizations, information and relevant value streams maps and by finally describing relationships between components/elements of your business architecture model that reflect your company’s reality. Once in place, updated at regular intervals and if made available to the IT community and key stakeholders, your business architecture model will have positive and rapid effects for each additional initiative helping business analysts build well-defined user stories and requirements for which Agile methodologies can be used for better and quicker execution.

Blending Agile Methodologies and Business Architecture

As explained at much greater length in this article entitled “Align your Requirements to Corporate Strategies Using Business Architecture,” Agile experts should build their user stories as shown in Diagram 7 below to make sure that all possible impacts are known and taken into account before delivering an initiative. This technique enables to trace the requirement logic from its basic components, like capabilities, stakeholders, value, information and process. This way, the focus is placed on the strategy and origin of the requirements via business architecture, not simply back to a project artifact.

As pointed out by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk , by knowing the business and having taken the time to articulate its value streams and capability maps, you can now have immediate and reusable impacts in the following:

• Requirements/Grooming: what areas must we understand for development or process changes,
• Prioritization: what is important, what capabilities may not yet be in place, and
• Scrum/Release planning: better understanding of dependencies and groups of stories/requirement(s) that make up a capability.

Like it or not, Agile Methodologies will gain in its outcome if they blend in their process the use of a regularly updated business architecture model that is made easily available to the IT department of an organization.

 

[1] The Business Architecture & Agile Methodologies made by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk among others on September 17, 2014 at the Business Architecture Guild Workshop Event in Austin TX.

[1] Experiences Linking Business Architecture with an Agile/Lean Development Method made by John Baker, Business Architect at MasterCard on March 13, 2013 at a Business Architecture Guild Innovation Summit event in Washington DC.

[1] The Agile Manifesto is described on this webpage.

[1] The Scrum Software Development Method Wikipedia webpage.

[1] The Iterative and Incremental Development Method Wikipedia webpage.

[1] Top Diagram in the article entitled “Align your Requirements to Corporate Strategies Using Business Architecture” written by Daniel Lambert

[1] From this webpage.

[1] Figure 5 in the article entitled “Align your Requirements to Corporate Strategies Using Business Architecture” written by Daniel Lambert

[1] Page 13 of the Business Architecture & Agile Methodologies made by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk among others on September 17, 2014 at the Business Architecture Guild Workshop Event in Austin TX.