How SwissLife France’s Enterprise Architects Used Lean to Raise Their Level of Influence

We will dive into the specifics of how Lean has been successfully applied to its own activities by the Enterprise Architecture (EA) team at Swiss Life France. Starting from a situation in which the project flow was overwhelming, the team managed to regain control over it by first processing their activities and then applying Lean practices. Making the flow visible, loving problems and having fun solving them, and welcoming voice of the customer feedback were some of the practices that helped the team navigate the flow. In the end, this endeavour provided multiple side benefits for individuals as well as for the team, which has resulted in a greater influence in fulfilling the mission.

What architecture looks like at Swiss Life France

The purpose of the Enterprise Architecture team is to improve the sustainable agility of the Information System (IS). This mission grows even more important with digitalization, since the IS now is at the heart of more and more processes and needs to fulfill new roles that expose it directly to outside stakeholders (customers and distributors through portals, partners through APIs, etc.).

At SwissLife, we also have a deeply rooted belief which is that architecture does not happen on walls, but in the field. And more specifically, projects is really where architecture gets done. So, our architects have to be in the field to actually help project teams "shape" the architecture.

But the implications of this focus on projects are especially challenging since architects find themselves potentially in contact with many of the company’s project stakeholders. Moreover, projects can be numerous; they are still often conducted in silos and led by teams which are focused on their own delivery objectives. Finally, architects are not always very keen on devoting too much time thinking about the architecture in a world where business pace is high, time to market is king, and agile methodologies even reinforce this time pressure effect. Also to mention, our team is distributed between two locations (Levallois, near Paris, and Roubaix, near Lille in the North of France), and this obviously is also a hurdle for streamlined communication.

So, to put it short, as architects we were struggling with the deluge of projects and had trouble navigating them in order to get our job done confidently.

How we processed EA activities

Prior to our Lean endeavour, we already had created a seven-step process for architects’ handling of projects. We named it the "IDAC" process ("Indicateur d’Architecture et Cartographie" in French) which stands for "Architecture Indicators and Diagrams". This paragraph gives an overview of the fundamentals that we will build on for the rest of the article.

The IDAC process: Seven steps in handling a project

The IDAC process delivers three major assets that we track and build on over time in the other EA activities, like debt management or cartography:

• Architecture Indicators give an indication of the project’s positive or negative contribution to the architecture of the IS; they usually vary during the lifecycle of a project, as its intentions grow more concrete.
• Functional Architecture Diagrams give an overview of the functions, flows and applications impacted by the project and explain how the solution will work globally.
• Architecture Credits and Debts are the final recording of the project contribution to the IS’ overall sustainable agility. If the project delivers artefacts that are well-aligned with our architectural principles and help reach sustainable agility, we log an architecture credit. On the other hand, if the project has made shortcuts and is not aligned with what the architecture should be, we then log an architecture debt that will be tracked over time, in order to decide if the risks associated with it are tolerated by the business or if it has to be eliminated.

And the following is how it concretely works in the field:

• We start by identifying the projects that have started or are about to start
• Then we engage with the project stakeholders to evaluate the project’s intentions and the expected impacts on the IS’ architecture
• If the stakes justify it, the architect in charge works with the project to identify scenarios, qualify its impact, and help choose the most suitable one

We usually start with a so-called Express Diagnostic, which is a two-hour meeting that helps spot relevant architecture matters, if any, to focus on and the level of support needed by the EA team. The deliverable is a synthetic view of the project with an evaluation of its stakes.

The result of an Express Diagnostic

If the project needs further support, we elaborate the so-called "functional architecture scenarios and diagrams" which describe and help assess the impact and the architectural alignment of possible solutions for the project.

Example of a functional architecture diagram

During this task, we intentionally choose to stay at the "big picture" level of design, in order to identify macro requirements and impact on the different future components. This helps architects to focus on breadth, not depth, and allows other stakeholders to take their roles down the road in the design of the project. The tech leads and the application developers can take care of the in-depth design of the technical solution to fulfill the requirements inside their own area of responsibility. And architects of course support them during this more detailed work.

The Lean appeal

So, we already had this process that we designed with the team, but it was not running so well because we were fighting with the deluge effect of new projects.

To be more specific, we wanted to relieve the architecture team’s pain points, which were the following:

• Loss of control over the project’s flow
  • We kept discovering new subjects to be handled in a very short time and with little budget
  • We were in reaction mode and weren’t taking the time to get a higher view for both clients’ and IT’s best interests
• No clear focus on where it matters the most
  • We had the feeling we were missing important things while we were spending our energy on others
  • We also felt we were missing something by not working on the right projects.
• Sub-optimal influence on the project’s course and its impact on the Information System
  • Plus, we saw that architecture matters became larger and more transversal
  • We had an issue on how to position ourselves with our partners to serve our purpose of building an agile information system

The idea of relieving these pain points was not new since we had already tried in the past to get the flow under control, with agile-like or visual management techniques, but we only had limited success and momentum.

From what we knew about Lean, we felt it was something that could help us get a grip again on this flow to better deliver on our mission. But we also knew that Lean applied well on activities that were already processed with an important flow of "pieces" and short cycle times. And we were completely aware that Enterprise Architecture is different in essence, since it is essentially an upstream activity where you produce abstract artifacts like plans and designs, and no concrete items. Furthermore, there is also some fuzzy logic in what architects deliver, because measuring the "quality" of an architecture is a challenge and can involve very long cycle times.

At first sight, none of this was very compatible with Lean. But we had other IT teams at SwissLife which had already conducted successful Lean projects in the past, and we have had good contacts with the Lean coaches who had led them. So we decided to give Lean a go!

How we started applying the Lean approach

The Lean diagnostic of our coach revealed that the IDAC process seemed well-designed and there was no reason to change it. Also, when we worked on a project, our customers gave positive feedback, and they were even asking for more architecture involvement. There were also cases where we were not involved in some projects which had issues with the chosen solution. Sometimes we were even called in for help on the issues these projects had, thus reinforcing the "torrent" effect.

After a three-day coaching session with the whole team, we had identified our issues, and identified some facts about the feeling we had of missing important architectural topics and also of spending energy on the wrong subjects. Our issue really was executing the IDAC process properly and systematically. Some steps were fine, while others needed to be improved. Since we had difficulties identifying the project at the right point in time and we were also missing some of the steps, we went for the following strategy:

• focus on the inputs and the first steps of the process in order to spot new projects as soon as possible by using the right sources of information, like the budget reporting tool, various committee reports or simply coffee machine discussions.
• adopt a progressive approach by working on the tasks that already worked well to improve the closest downstream weak points with baby steps.
• to keep our base tools that were already in place and to add new ones only as needed.

Our Strategy to improve the process.

We also decided to be more flexible with the IDAC process by learning to say "no!" and leaving some projects on the side of the road. The most important thing was to know what was in our pipeline, and that the decision to work on a specific project and the level of support required now was a capacity and collective intelligence-based decision.

Also, architects are organized by area of responsibility, and we enabled more transversality between them; each architect is now encouraged to perform the first process’ steps (first meeting, express diagnostic, etc..) in any area, not only his own. The collaboration between architects improved, as well as their knowledge in other areas.

And, most importantly, we learned to love problems because they are opportunities to improve. All the architects are encouraged to spot problems, proposal how to improve them, and experiment. The famous PDCA (Plan Do Check Act) that is a must in any Lean approach.

So, we moved in the real world by experimenting with these principles and initiated a weekly meeting in Roubaix’s office, where we were co-located once a week. Based on the tools we already had, we enriched them to help us visualize and handle the flow of projects, identify problems and value the feedback from our customers.

The tools used to track architecture activities on projects

JIRA is the spine for following the stock and flow of everyday activities on a Kanban board. Our Wiki is the place to store our deliverables, One On Ones is the place to discuss priorities, issues and capacity. The weekly Lean meetings in Roubaix allow everyone to share his/her current topics with other team members, the difficulties faced, the deliverables which are about to be delivered, and who is going to take responsibility for new incoming projects. We also use these meetings as an opportunity to log problems to trigger the PDCA process. We also have introduced weekly team workshops which help the person in charge collect input from other team members on what to focus on, what to have in mind, and which other related projects are in progress, thus enabling to break silos inside the team and collectively be more effective.

The IDAC process cockpit

Where we stand today and what’s ahead

We are now able to have a much better view of the incoming flow of projects and how we are dealing with them through simple KPIs measuring the amount of work delivered by the team. And most importantly, we also have established short "voice of the customer" surveys that give us the opportunity to measure the project stakeholder’s satisfaction and identify problems though their feedback.

But we are only in the middle of the journey, as we still have to consolidate the practices and habits which are still young. We now have to focus on the IT Legacy analysis step to close the loop by identifying gaps in what has really been delivered to production, in order to log trustworthy Credits and Debts.

The current situation

Despite the fact that there is much more work ahead, we have already seen very positive effects. Firstly, architects are more satisfied because:

• They have an increasing feeling of control over projects’ flow
• They have a better sense of priorities
• They have more opportunities to share with fellows
• They are now also able to take time to anticipate by developing meaningful architectural visions to better drive project decisions
• Team spirit and collective Intelligence is growing

As a result, the managers are more satisfied:

• The incoming project flow is more predictable and manageable
• The projects are approached more systematically, reducing the risk of overlooking issues
• The team now can choose the right projects to focus on
• The EA practices improve continuously by the team itself

And, most importantly, customers are more satisfied:

• Timely, proactive and balanced architecture involvement
• Better-processed and more predictable contributions to projects
• More repeatable and homogeneous deliverables

In the end, we have also produced a number of unexpected benefits:

• Architects’ advice has become more attractive because we have become more demanding on the quality of inputs that we get from projects, in order to better perform our job. In turn, this helped project teams to ask themselves the right questions upfront.
• We are more focused on the decisive topics.  We make better use of our energy, focusing where it really matters.
• We broke the silos inside the team. We were able to leverage the collective intelligence by tapping into the knowledge and experience of every architect, who all now work together across their areas of responsibility.

The first learning is that despite the fuzzy nature of Enterprise Architecture, Lean can be applied to EA and raises benefits for customers, team members, as well as managers.

The benefits

But before we can see any of the benefits, core work is needed:

• You need to have a reproducible process to be able to apply Lean to EA activities.
• You need good coaching to help the team formulate issues, find solutions and start applying them, in order for them to improve by themselves.
• You need to have solid sponsorship and a motivated team leader to leverage, sustain and improve Lean practices once coaches are gone.

We also believe that our success with the Lean approach came from three key points:

• We did not aim for perfection. Rather, we tried to « make the first step » and then improve little by little, in an agile spirit.
• We kept it pragmatic by modifying strictly what was expected and not more, both on executing the process and on tailoring the tools.
• The sponsor invested in and trusted the team. In order to get benefits, they must spend time on Lean moderation. Even though this can be perceived as non-productive, it produces return after a while.

We can testify that something very powerful happened inside our team, which is that "Lean allowed to better live to our purpose, both individually and as a team". As a final word: Architecture is about influence more than power, and the more we improve our track record thanks to Lean, the more we raise our level of influence.

This article has been inspired by the presentation given by the authors on October 8th at the Lean Digital Summit 2019 in Paris. Check out the video Can Lean help improve the Architecture Maturity of an entire Organization?

About the Authors

Christian Phan-Trong has more than 25 years experience bridging the gap between IT and business, in companies such as IBM, Sanofi, and AXA, to name a few. He is currently head of the Architecture Team at Swiss Life France. Since seven years, he has accompanied the company in its digital endeavor, has helped introduce big data & data science, Robotic Process Automation, Cloud, and of course, Architectural Practices. He has a passion for pragmatically applying technology to business and recently wanted to experiment how Lean can be applied to Architecture.

Pierre Marchand worked for 18 years at Malakoff Mederic, a French insurance company where he had the opportunity to gain a rich set of skills from his different positions ranging from operational activities, end-users support, project management, change management, and finally, a newly created Architecture team where he worked as a functional architect for almost six years. Since one and a half years, he has been head of enterprise & functional architecture at SwissLife France, where he is leading, in his new manager position, a project that tackles how Lean can be applied to Architecture.