You will need about 8 minutes to read this text.
Modern technology is evolving incredibly quickly. It took 75 years for 50 million people to adopt using the telephone in the past, but now a simple app like Angry Birds can reach this user level in a matter of days. Many organizations still need to learn how to cope with this tempo – but can use an Agile Way of Working (WoW) to adapt. It can be quite difficult, however, to balance this rapid pace with a solid architectural strategy and certain level of autonomy while staying aligned with business goals. But challenging doesn’t mean impossible. Below you can find several insights which we’ve discovered while researching Agile together with Enterprise Architecture.
New technologies are popping up all the time, and the rate at which wider society adopts them has sped up immensely over the past ten years. This has culminated in the market evolving towards a so-called application economy – a huge, global economy where software finds its way into all aspects of business and life. To compete in this new type of market, the speed at which organizations can deliver software – and by extension all sorts of technology – is vital.
Many companies are turning towards Agile software development in order to compete in the evolving market and gain the required speed. This is an approach that focuses on self-organizing, cross-functional teams and their end users. Popularized by the Manifesto for Agile Software Development, it has become a widely adopted way of working through different derivative frameworks such as Scrum and Kanban.
The Agile approach focuses on offering value in the shortest possible, sustainable lead time. These key features are required to achieve this:
While Agile frameworks are focused on adding value in the shortest time span possible with a lot of autonomy for individual teams, Enterprise Architecture is all about providing a clear long-term base that is fully aligned with business goals. Seemingly in opposition, the two actually work better in symbiosis. Agile adds speed and autonomy to the mix, while Enterprise Architecture ensures that all Agile development serves a purpose and isn’t just innovation for the sake of it.
As such, the concept of Agile Architecture marries the autonomy – which motivates teams and keeps decisions local and therefore fast – with alignment – which ensures teams adhere to the corporate mission. This balance is perfectly illustrated in the ‘Spotify Model’, for example.
To achieve this sweet spot between speed and alignment, the architectural practice needs to be reshaped. From the way we structure our Architecture to the way we shape and build our teams. We’ve identified four main areas that need to evolve:
These areas generally correspond to four different levels within an organization. Distributed leadership sits at the top level and determines how different parts of a company function together when tackling an IT project. The runways impact your portfolio. Changelogs concern program or project level. Finally, the T-shaped architect shapes the composition of your team.
IT isn’t the sole party involved in developing a new project. When creating a new customer-facing portal, for instance, departments such as sales, customer experience, product management, and more need to be involved. This requires a change in how we orchestrate teamwork. One popular and effective approach is distributed leadership, where you don’t look at the individual characteristics of each leader, but instead consider how actors engage in their tasks across the organization. In essence, it is about different department leaders working together, for example to clarify investment priorities or decide the best course of action to achieve overarching goals.
During a recent webinar, John Christiaen, Head of IT Strategy and Architecture at BNP Paribas Fortis, shared his insights and experience with regard to combining an Agile environment with Architecture. BNP Paribas Fortis has been on a digital transformation and Agile track since 2015, supported by a team of XPLUS consultants. Fast-forward a couple of years to 2019 and they noticed a couple of improvement points for their Agile implementation. To begin with, Agile was implemented and used only within IT. Furthermore, twelve investment themes and one regulatory theme were constructed which existed separately from each other, each with their own backlog.
These points later proved to be an obstacle when tackling cross-Tribe projects such as PSD2 – a new European regulation that had a significant impact on how payments and collaborations with third parties are handled, especially in determining priorities and getting both security and business on board with it. They therefore made a couple of changes that enabled more of a distributed leadership structure:
Enterprise Architecture has always focused on introducing predictability through blueprints and roadmaps. But this is too rigid an approach to reach the speed that’s required today. Going to the other end of the spectrum, however – i.e. launching initiatives without clear roadmaps and goals – isn’t ideal either.
As always, the solution lies somewhere in the middle, and for Architecture and Agile this is the ‘runways’ idea. Instead of rigid structures, architects define a framework of top-level principles and patterns. The principal actors in individual projects fill this framework with the necessary components, sort of like a honeycomb. In addition, runways require you to split your Architecture into smaller sections with a focus on maximum reusability across projects.
Creating runways is another new method for the BNP Paribas Fortis team. Instead of only allocating budget to specific projects, they have a run budget set aside that exists solely for the purpose of creating patterns and decision trees. Having these at the ready means they can move faster when a project is launched. They also hold early intake meetings with all stakeholders at the start of every project, with the goal of assessing the impact of a trajectory on the IT landscape. If this involves major changes, they explore in more detail how new technology can be reused as much as possible in future tasks.
When you need speed, you need just-enough, just-in-time architecture. Starting every project by producing lengthy architectural studies and documents will not help you achieve this goal. Just as you would cut your architecture into smaller pieces when creating runways, so must your reports be made smaller. One way to do this is working with changelogs where you only keep track of the changes a project brings with it.
Having too many architectural documents with unclear ownership was one of the major drawbacks for Fortis prior to moving towards an Agile way of working. But even after they made this change, they continued writing lengthy documents with the entire project description, hindering the speed of their trajectories. They therefore started to work with changelogs instead. On top of that, the bank is also looking to maximize the potential of these logs and reports by moving away from traditional document management tools such as SharePoint, and instead using tools that allow them to exploit their data and metadata.
The enterprise architect is already a rare breed with specific skills. And the need for distributed leadership will also require them to have people skills and guide the architectural conversation. Furthermore, to keep the project going and match today’s speed of delivery, architects sometimes need to occupy themselves with subjects they are not familiar with. They therefore need a broad, basic knowledge of a wide variety of topics. So, whereas the architect used to be more of an I-shaped person with one specialization, an Agile environment requires a T-shaped one. T-shaped profiles have a solid base in a wide range of skills – the top part of the T – and one area in which they excel – the vertical part. This type of architect is more flexible in terms of knowledge and skills, and can switch gears more easily.
At BNP Paribas Fortis, they realized early on that Agile required a different type of architect. Where previously there was a division between technical and functional architects within their team, this new way of working requires people to switch between the two – a task that many found difficult because they were firmly entrenched in one of the two. And indeed, lead architects suddenly found themselves in a people management role which proved challenging. The T-shaped architect seemed to be a solution for these issues, and this is what they have focused their recruitment and education efforts on ever since.
While seemingly at opposite ends of a spectrum ranging from full autonomy to full alignment, Agile and Enterprise Architecture can certainly be combined – and indeed they should be. It does require, however, that organizations restructure their architectural practice on different levels. On the organizational level, distributed leadership is key. Further down the line, architectural runways need to be built to give projects the required momentum while keeping everything aligned to overarching goals. Special attention needs to be paid to the reusability of building blocks when creating these runways and also during the project. Documenting these runways is crucial, but changes to any of them do not require entirely new descriptions – it is instead better to keep logs of the alterations. Finally, the architects in a company’s team need to move away from hyper-specialization and focus more on gaining a broader base of skills – of which people management needs to be one.
Do you want to know more about the harmonious marriage between EA and Agile? Then check out the thesis written by our Architect Peter Wuytack. His insights and paper are available for free on our blog.
Read the thesis
Our Business and IT Architects empower you to implement structural change and achieve lasting results with proven methods and tools adapted to your organization.
© XPLUS Consultants - Privacy Policy - Cookie Policy
XPLUS - Officenter Zaventem, Leuvensesteenweg 643, 1930 Zaventem - call +32 2 310 82 02
