The 12 Agile Principles Adapted to Business Architecture

You are probably familiar with the Agile Manifesto that was written in 2001 by several forward-thinking software developers.

However, it is a manifesto for software development and, as you may have seen in a previous post, business architecture is about more than software requirements. Does that mean we cannot apply the 12 principles behind the Agile Manifesto to our work as business analysts? In fact we can, and we should. Here is my adaptation of the principles, with changes in bold italics.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable models of the business.
  2. Welcome changing requirements, even late in development of the models. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver models of the business frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business experts and analysts must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within an analysis team is face-to-face conversation.
  7. Tested models of the business are the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, analysts, and business experts should be able to maintain a constant pace indefinitely.
  9. Continuous attention to excellence in analysis techniques and good business design enhances agility.
  10. Simplicity — the art of maximizing the amount of work not done — is essential.
  11. The best business architectures, requirements, and business designs emerge from self-organising teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Producing software in an agile and iterative fashion has many benefits, as long as you are producing the software the business actually needs (and drives it towards achieving its strategic goals), rather than what individual users say they want. How do you know the business’s acceptance criteria are the right ones? How do you know the backlog of user stories is internally consistent? Producing business architecture in an Agile fashion is what drives out a robust backlog of user stories, with the right business knowledge to be able to define the most appropriate acceptance criteria (see my earlier post: Business analysis is about more than software requirements).

What do you think?

Kind regards.

Declan Chellar

4 comments to The 12 Agile Principles Adapted to Business Architecture

  • Luc

    As a BA, I’ve always simply substituted the word ‘software’ in the principles with ‘system’ i.e. manual + automated parts of a solution. Surely the whole project-team is made up of developers of a solution, including the BAs.

    • Declan Chellar

      Many thanks for taking the time to read and comment, Luc. Your comment does imply a technological solution (or at least, I infer it from your comment), since you mention “developers”. In that context, I totally agree with you. However, business architecture is technology-agnostic. In fact, some of the solutions to the business needs expressed in a “should be” business architecture will not be technological at all. Some examples:

      • – A recruitment drive to resolve staffing issues
      • – A training programme to resolve skills issues
      • – An office move to resolve location issues
      • – A public relations campaign to resolve image issues
      • – Divesting an unproductive arm of the business to improve the cost/revenue ratio

      Kind regards.


      • Luc

        Yes… the presence of the word “developers” could imply that in this context. Right now, just outside my window there is the noise of a team of developers in a different context creating an extension to a house. I was careful to not say ‘software-developers’, or any specific type…. so I would include eg. HR or training personnel, sales managers, marketing, architect, lawyer or anyone with whatever mix of skills are required for the design, construction and delivery of the project. But yes, I do tend to seek-out and (perhaps incorrectly) assume some degree of added or improved automation.

        I agree one needs to be technology agnostic and keep models as logical as possible as deep into the design as possible.
        Eventually, even ‘logical’ models do move from ‘what’ towards ‘how’.

        • Declan Chellar

          Fair points, Luc.

          Bear in mind a couple of points that a lot of BAs forget or were never aware of:

          • – A “To Be” (or as I prefer “Should Be”) business architecture is a business solution design and a software development (if needed) is just the implementation of that design. When you say “design”, I suspect you mean the software solution design.
          • – People often think of business analysis as the “What” and the software solution as the “How”. In fact, there is a “What” and a “How” domain within business architecture, as well as domains for When, Where, Who and (very importantly but largely overlooked) Why. More on this in another post.



Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>