Agile in Practice

Agile in Practice


Architects are often criticized to be too slow when developing the overall architecture in their enterprise. When their overall architecture is finished they are often criticized, because it is difficult to understand, difficult to use and the quality of the architecture is not acceptable.

How these problems may be solved at the Swedish Board of Agriculture (SBA) is described in this article. During an architectural journey we gradually learned how to work with Enterprise Architecture (EA) in a new way. The reason was a large program (ProCAP) with a lot of uncertainty, rapid changes and strong deadlines. The solution was Agile EA.

By combining agile methods with more traditional EA work, we have found a way to succeed developing the EA step by step based on current needs – while we support and participate in the program’s projects.

A number of Critical Success Factors are in place at SBA; some due to hard work and some by lucky circumstances in our environment. The agile development method Scrum was the standard development method in use. In the very ambitious program ProCAP, Scrum has been successfully related to the EA.

Agile EA is used in Practice managing both iterative development of the EA and guiding and supporting the development of new IT solutions.

This ambitious program at SBA may be regarded as a global breakthrough to achieve an Agile EA in Practice.

Table of contents

  1. Introduction
    1.1 The EA approach
    1.2 The Swedish Board of Agriculture
    1.3 The ambitious program ProCAP
  2. In theory
    2.1 Business Architecture
    2.2 The Agile approach – Scrum
  3. In practice
    3.1 The EA approach at the Swedish Board of Agriculture
    3.2 The Agile EA approach
  4. Summary of further challenges
    4.1 Advantages achieved with Agile EA
    4.2 Critical Success Factors
    4.3 Challenges
  5. About the authors
  6. References


The EA approach

To handle today’s changes we build an overall enterprise structure based on a stable foundation. The information resource is such a stable foundation. It does not change very much even if the organization, the business innovation canvas, or the business processes change. Information Management – the way an organization deals with information – makes information available as a resource to be used in business processes and the business innovation canvas. Formulate a business strategy that allows an open exchange of relevant, meaningful and useful information.

Most approaches to thinking about an enterprise in a holistic way involve abstractions and the use of metaphors. The metaphor we use is the business as a city to be planned. A City Plan draws up an organized arrangement of sustainable zones or areas as when Baron Haussmann remodeled Paris in the middle of the nineteenth century. Our areas in the enterprise are based on stable and sustainable information groups.

The goal of this EA approach is to restructure the business and their IT solutions to become more efficient, robust, and integrated. When integrating with Scrum, an agile development method, an Agile EA approach in practice is achieved.

The Swedish Board of Agriculture

The Swedish Board of Agriculture is the Swedish Government’s expert authority in the agro-food sector. This means that the board of Agriculture monitors and analyses the development within the sector and implement related political decisions.

The Swedish Board of Agriculture promotes food production that is competitive, adapted to environmental and animal welfare concerns, and that benefits consumers. The political decisions may change sometimes dramatically and with short notice. To handle these changes is a big challenge.

The ambitious program – ProCAP

To understand the background of our architectural journey at SBA, we start with a travel to Brussels and the European Union. Every seventh years, a new long-term budget is added. The current budget period is 2014 to 2020. The Common Agricultural Policy (CAP) accounts for about half of the budget and therefore it can be assumed that the agricultural policy will be reformed before a new budget period.

At SBA we thus know years in advance that a reform is on the way; even if we don’t know any details. The conditions are thus: we don’t know what to do; we don’t know when to be finished. Late decisions and rapid changes are a daily challenge. We had to start preparing for the reform changes and an agile approach became one of the prerequisites for being able to manage the assignment.

The CAP reform includes three new policy programs. In 2012 SBA starts the program ProCAP to prepare for and implement CAP in Sweden. ProCAP is divided into three major projects; Business Rules and Processes, IT Development and Business Change. These major projects are supported by expertise in Enterprise Architecture, Methods and Information Security.

Because of three new policy programs in CAP to be implemented, the need for a new modern IT platform (the legacy systems are from the 90-ties and have difficulties to meet new business demands) and an ambition to take a holistic approach on business change, business processes, business rules and IT solutions, the ProCAP is a big undertaking including over 400 persons with a budget of 530 000 hours with a calculated cost of 30 billion Euros. The program was initiated in March 2012 and is planned to be finished Q1 2016. During this time around 10 new IT-systems will be developed.

This very big Program is managed by the Chief Architect, during the program replaced by another person in his architecture role. This gives a very good understanding and support from the Program management to the architecture team.

In theory

Business Architecture

To handle today’s changes we want to establish an overall business structure based on a stable foundation. The information resource is such a stable foundation. It does not change very much even if your organization or your business processes change.

The metaphor we use is the enterprise as a city to be planned. A City Plan draws up an organized arrangement of sustainable zones or areas as when Baron Haussmann remodeled Paris in the middle of the nineteenth century. Our areas in the enterprise are based on stable and sustainable information groups.

The goal of this EA approach is to restructure the enterprise to become more efficient, robust, and integrated. Traceability will secure that the solutions relate to the business architecture as intended. It is also a way to continuously maintain and develop the architecture based on more detailed knowledge in new solutions.

The first Business Architecture was developed by IRM in 1984 for SKF, the Swedish Global Ball Bearing company. Developing over 100 Business Architectures since 1983 at SKF, IKEA, Statoil, Scania, TeliaSonera and other private and public business. Since 1994 around 1000 Business Architects have been certified at an academic level in Sweden.

Today it is fully accepted (at least in theory!) that EA should be based on business knowledge and not driven by IT.  In consequence we focus on the Business Architecture. The IT Architecture and the Solution Architecture have consequently to be aligned with the Business Architecture.

Defining Business architecture

The Business Architecture definition by Len Fehskens at The Open Group says

“The Business Architecture ensures that the enterprise as a whole is always fit for purpose of achieving its vision, mission and strategies”

If your ambition is to always be fit for purpose you should choose an artifact that is stable and doesn´t change when you change your organization, make a new innovation, or you choose to outsource part of your business. The most stable resource or artifact we know of is the Information Resource itself. Another very useful and rare characteristic of this resource is that data and Information is not used up or consumed when you use it.

The definition implies that the lifecycle of the business architecture starts when the enterprise is established and ends when the enterprise is closed. The lifecycle of a vision, mission, strategy, IT solutions, and business innovation may have a much shorter lifecycles. That implies that the Business Architecture should not be made dependent on these shorter lifecycles, but instead be based on the business itself.

The Information Resource

The artifact of the Information Resource is the most stable one and an architecture based on the information structure may reach a stability needed to achieve a fit enterprise as stated in the definition above. Shorter for this is “keep your artifacts in good order”. Maintain your Information Resource and your Business Rules in good order and you are well prepared for future known or unknown changes – internal and external.

Business Architecture – the Big Picture

Figure 1 The main Artifacts of Business Architecture

In a Business Architecture we usually have 25 to 50 normalized Overall Business Information Groups (OBIM). A single data element belongs to one and only one Information Group. We also usually have 25 to 50 Business Processes where one specific activity belongs to one Business Process. The Business Process Matrix tells in which process a specific Information Group is created or used.

The Business Architecture is created in an agile way over a two month period by 12-15 business experts all participating in three two day workshops facilitated by two experienced Business Architects. The Result consists of an Overall Business Information Model, an overall Process Architecture and a number of high level Innovation Canvases. Please, stay at the overview level and avoid details at this stage if you want to fulfill it in two months.

Our world is growing more and more complex. We have many driving forces adding to this complexity and very few creating simplicity. Companies like IKEA, where “simplicity is a virtue,” are very rare.

”It seems that perfection is reached,
not when there is nothing left to add,
but when there is nothing left to take away”

Antoine de Saint Exupéry, French author and pilot, 1900 – 1944.

The Agile approach – Scrum

Scrum is an iterative and incremental agile software development framework for managing product development. It defines a flexible, holistic product development strategy where a development team works as a unit to reach a common goal and enables teams to self-organize communication among all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need often called ”requirements churn”. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements

Product Owner

The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and they may also be a member of the development team.


A sprint or iteration is the basic unit of development in Scrum. The sprint is a ”time boxed” restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month.

Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

Scrum emphasizes working product at the end of the Sprint that is really ”done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.

The figure below illustrates how important it is not only to have a working product at the end of the Sprint, but also deliver it to users to learn from their feedback.

Illustration by Henrik Kniberg at Spotify and Crisp

In practice

The EA approach at the Swedish Board of Agriculture

A few months before the ProCAP program started at SBA, some architects received the assignment to lay the foundation for the ProCAP program – a foundation that included objectives and guidelines for the architecture which would form the basis for the new generation IT systems to be implemented during the program. The assignment was given by the chief architect (who then became program manager of ProCAP) and the ProCAP steering Committee chair. This gave a very good understanding and support from the Program management to the architecture team.

To handle changes in our environment – sometimes dramatically and with short notice – it was important to establish an overall EA based on a stable foundation. Our two architecture principles became ‘a holistic perspective’ and ‘an information-driven architecture’.

We started to map overall information and processes. By matrix analyses we captured the most important business capabilities and our city plan was born. The city plan became our way to communicate and visualize our overall target architecture.

The city plan was divided into different views – for business architecture, information architecture, applications architecture and infrastructure architecture. In this way we could start aligning Business architecture and IT architecture.

The Agile EA approach

The ProCAP program had to start although the conditions were ‘we don’t know what to do, we don’t know when to be finished, late political decisions and rapid changes’. The agile development method Scrum had been used at SBA for some years and would be used in ProCAP. This led us to the idea of testing Agile EA.

We formed an architecture team of business architects and IT architects (at the moment five business architects and three IT-architects) working together. Our assignment given by the program manager and the steering committee chair was:

  • Create conditions for good planning and effective implementation of IT development within ProCAP
  • Contribute to effective business and IT development within the entire SBA

Based on the IT project needs we made a rough plan for six months at a time – a plan that was adjusted before each sprint. The tasks in this plan (our back log) included both tasks to continuously develop the architecture step by step and tasks to guide and support the IT projects when understanding and using the architecture.

With the city plan, we had a rough, adaptive architecture. With Agile EA we added a rough, adaptive plan. This became our approach to meet the everyday challenges in ProCAP.

The Agile approach illustrated by Henrik Kniberg at Spotify and Crisp

 The Architecture Team and the Product Owner

The role Product Owner is staffed by three persons – the program manager, the chief architect and the head IT project leader. The Product Owner helps and supports the architecture team to focus on their most important tasks in each sprint based on the needs within the different parts of ProCAP. In one period it could be to focus on the architecture itself and in another period to assist and guide development team using and understanding the architecture.

In practice this means that the Product Owner and the Business Architects work in very close cooperation to secure that the result of the sprint delivers value both to ProCAP and the EA – avoiding specific “quick and dirty” solutions that represents an ‘architecture debt’. The architecture team and the Product Owner work together to identify, add and prioritize tasks to the backlog.

The chief architect is both Product Owner and part of the architecture team.

Three week Sprint

The architecture team works in three week sprints. Each sprint is started by a planning meeting where we review the back log and decides what are the most value giving tasks to do right now. Sometimes tasks are deleted from the back log because they are now longer necessary. The highest priority tasks from the back log represent the sprint goal and they are estimated and planned in detail.

At the end of the sprint there is a retrospective. At the retrospective both methods and deliverables are evaluated and adjusted accordingly. During our architectural journey in ProCAP a lot of changes have already been made, both big and small. Some changes have been about the methods, some in what has being delivered and focused on and some about the forms of the deliverables.

Examples of deliverables from a sprint are:

  • generic principles and guidelines within a business capability
  • a new part of a business process
  • a more detailed information model
  • a solution pattern for how to implement an IT function.

The result of each sprint is delivered to relevant parts of ProCAP, for example through briefing, education or by being used by the architects when supporting and guiding IT development projects. Feedback from the ‘architecture users’ is important input to next sprint to continuously further develop the architecture while adding business value.

How to reach all project members and getting them to understand and use the architecture deliverables is a difficult challenge. The best way is to have the architects involved in various projects and use the deliverables in this work. The consequence is that then there is no architect left in the architecture team to keep developing the shared architecture. And when the architects instead focus on developing the shared architecture – the result doesn’t reach every project member.

This is a tricky challenge and we use the learning process to constantly find the most right approach for the moment.

The Learning process

The architecture team uses the retrospective as a method to continuously evaluate the work and adjust accordingly. Some changes are made because you learn and get smarter and some because the environment changes. The retrospective and the learning process it creates is one critical success factor because the conditions are constantly changing.

The Product Owner and the architecture team work together in the ongoing learning process to transfer business knowledge to the project teams.

The product owner helps the ongoing learning process. The business knowledge is transferred from the architects and the Process Owner to the project teams. This transference of business knowledge is an ongoing learning process partly because of the need to repeat and add new business knowledge to the project teams whenever needed but also because of high turnover of external consultant in the projects.

Summary and further challenges

Advantages achieved with Agile EA

We have tried to describe a number of advantages achieved by using the Agile EA approach, like:

  • Agile EA provides the ability to switch focus and change approach quickly when needed.
  • The architecture development is driven by the business value where the ongoing projects set the priorities
  • The architecture value is achieved directly. Early versions of architecture deliverables are released to set the direction and enable early alignment. The detailing of the architecture continues when needed.
  • A valuable dialogue occurs around architecture, as an effect of not presenting finalized deliverables.
  • The product owner ensures management commitment within architecture

Critical Success Factors

A number of Critical Success Factors are in place at SBA; some due to hard work and some by lucky circumstances in the environment.

Some ‘lucky’ circumstances are:

  • ProCAP needs gave the opportunity to get resources for the architecture effort.
  • Management understands the benefits of architecture.
  • The chief architect was appointed manager of the ProCAP program.
  • Agile development method Scrum was has been in place for some years within the organization.
  • The Business is rather stable even if the Business Rules may change frequently.
  • The size of the business is manageable for a shared architecture (the personnel is 1200 persons with 650 at the main office).

Some “hard work” factors are:

  • Results from previous projects where the new IT platform was prepared have provided a good foundation for the shared architecture.
  • Tight and very professional architecture team with extensive business knowledge are established.
  • Mix of Business Architects and IT Architects working closely together in the same team.
  • The agile method containing the retrospective makes the ongoing learning process possible.
  • Working closely with the projects in the program and listening on their needs.
  • The courage to try new ways of doing things.


There are a number of challenges like:

  • Keep focusing when the ongoing projects have a lot of various challenges to handle. We are all torn between competing tasks and prioritizing is demanding.
  • Architects are ’nice to have’ persons, with a deep understanding of the business – useful for other activities besides architecture development. The role of the architects needs to be evaluated continuously to make conscious decisions possible.
  • How to reach all project members with architectural deliverables and at the same time achieve the balance between developing the architecture versus guiding and supporting the projects.
  • Find a good balance between guiding and supporting the ongoing projects and the work with the shared architecture.

About the authors

Boel Ohlin – Boel is Business Architect at the Swedish Board of Agriculture. She is a certified business architect and has a background working with business intelligence (as BI architect, BI analyst, BI developer and BI strategist) and system- and method development. She can be reached at

Jenni Dahlkvist Vartianen – Jenni is Business Architect at the Swedish Board of Agriculture, managing the architecture team in ProCAP. She is a certified business architect and has a background working with business analysis, system development and method development. She can be reached at

Eskil Swende – Eskil is a main partner at IRM , a Scandinavian consulting company focusing on Enterprise Architecture and the Innovation Process. He is also a partner at IRM UK, a strategic education company in London that provides seminars and arranges yearly conferences on EA, IA, MDM and BPM. Eskil is President of DAMA Chapter Scandinavia and has developed a global wisdom network of leading experts inside and outside DAMA, inviting them to give presentations and tutorials in Scandinavia. He can be reached at


  • Chisholm, M.D. 2010. Definitions in Information Management – A Guide to the Fundamental Semantic Metadata, Design Media
  • Greefhorst, D and Proper, E. 2011. Architecture Principles – The cornerstone of Enterprise Architecture, Springer
  • Guenther, M. 2013. Intersection – How Enterprise Design Bridges the Gap between Business, Technology and People, Morgan Kaufmann
  • Hammer, M., and Champy, J. 1993. Reenginering the Corporation: A Manifesto for Business, New York, Harper Collins
  • Hammer, M. 2001. The Agenda – What Every Business Must Do to Dominate the Decade, New York, Crown Business
  • Kniberg, K, and Skarin, M. 2001. Kanban and Scrum – making the most of both (Enterprise Software Development).InfoQ
  • Langefors, B. 1966. Theoretical Analysis of Information Systems, Lund, Sweden, Studentlitteratur
  • Nonaka, I., and Takeuchi, H. 1995. The Knowledge-Creating Company – How Japanese Companies Create the Dynamics of Innovation, Oxford, Oxford University Press
  • Potts, C. 2010. RecrEAtion – Realizing the Extraordinary Contribution of your Enterprise Architects, New Jersey, Technics Publications
  • Ross, J. W., Weill, P., and Robertson, D. C. 2006. Enterprise Architecture as Strategy – Creating a Foundation for Business Execution, Boston, Massachusetts, Harvard Business School Press
  • Sykes, M., Malik, A.N., and West, M. D. 2013. Stories That Moves Mountain – Storytelling and Visual Design for Persuasive Presentations, Wiley
  • Swende, E. 2014. Core Knowledge for EA, Journal of Enterprise Architecture
  • Swende, E. 2010. Defining and naming Data Models Related to the Zachman Framework, Pittsburg,
  • Weill, P. and Ross, J. W. 2009. IT Savvy – What Top Executives Must Know to Go from Pain to Gain, Boston, Massachusetts, Harvard Business Press