SAP Logo LeanIX is now part of SAP

Spotlight: Jan Puzicha Shares Insights on Microservices and Development Efficiency

Posted by Diana Hwang on March 23, 2021

Jan-Puzicha-Blog-Image-V2

When it comes to developing new products and running large development organizations, there’s no one better to fill that role than LeanIX’s Jan Puzicha. Jan has served as LeanIX’s chief technology officer and senior vice president of products since 2018, guiding the company in its product direction and overseeing a large development organization. Before Jan landed at LeanIX, he was the founder of Recommind, a company that used statistical machine learning and unstructured text analytics to provide software products for eDiscovery, contract analytics, process automation and knowledge management. The company was acquired by OpenText in 2016.

Today, Jan shares his vast industry experience by sitting on a number of tech company advisory boards such as racontec GmBH, akorda, and Conversica in addition to his responsibilities at LeanIX. Recently Jan sat down with Michelle Niedernhuber, product marketing manager of LeanIX to discuss microservices and its impact on LeanIX's own development organization. Jan also discussed his insights on why a microservice catalog such as Microservice Intelligence is essential for helping organizations navigate their microservice landscape and how it resolves issues ranging from governing open source licensing to measuring KPIs for development efficiency. 

On the development organization and microservices journey

Q. Hi Jan. Please provide us with a quick overview on your development organization.

Jan: Absolutely, at LeanIX we’re about 100 people in what we call product. The majority of that is developers, but it also includes product management as well as UX and UI. We're organized in four different tribes that are responsible for different parts of the product. Each tribe has between three and five different teams underneath so total number of teams right now is 17. So it's become quite sizable ever since I joined two and a half years ago, when there were two teams.

Q. Impressive growth! When you joined, what was the current situation of the architecture, within LeanIX compared to what it is now?

Jan: The principal approach was the same as today. When I had joined, there was a rewrite that had happened about nine to 12 months before I joined. We re-wrote a single service app, if you wish, into a microservice architecture and many of the microservices at that time still exists. Obviously the number has significantly increased.

Depending on how you count it, we have 20 to 50 different microservices. On the lower-end, if you count by logical service domain and on the higher-end, it's more the individual releasable artifacts that are either to back-end microservices or micro front-ends.

Q. I assume with the growing number of microservices and introducing micro front-ends, you have also experienced an increase in complexity?

Jan: That's a curveball question! Of course, we have significantly increased complexity in combination with the growing size of the organization, which has probably more than tripled ever since I joined.

We are experiencing growth pains so understanding what microservices actually exists, who owns them, what team do they belong to, and who to contact has actually become a real issue. It's something that we needed to address and have started to address.

Q: Would you say these growth pains are unique only for LeanIX? 

Jan: They're certainly not specific to LeanIX. But they are a set of use cases, and frankly problem areas, that for every growing organization becomes more severe with scale. The more you grow, the more sizable the organization becomes, the more important these things are for the organization.

But it's something that I've experienced in a previous life with very similar pain points and identical set of problem. It's something that I have seen confirmed from a number of leaders of product organizations with at least 20 people, and, of course, if you go to hundreds and thousands of developers, then it only becomes more severe.

Addressing microservices complexity

Q: How do you address the growing number of team members, microservices, and overall, stay on top of the complexity to ensure smooth operations?

Jan: We have an “eat your own dog food” approach, hence we use LeanIX Microservice Intelligence. It's a formal initiative we kicked off about two months ago but prior to this, we played with it for a while. For this year, we have adopted that as one of our key objectives: To move all of the key product use cases that we don't do in Jira over into Microservice Intelligence as a process.

We have around 30 different such use cases. We have already tackled the first four or five. One has recently gone live so you see it's still early on, but clearly it is our key direction. It truly helps our own development organization, but at the same time it's a great source of feedback back into the product.

Establishing a microservice catalog to govern open source licensing

Q. What are the four main use cases that you're now driving? 

Jan: The first one is really “inventorization” of microservices to understand the full picture of what microservices we have. Who owns them? Who’s the point of contact? What type of technology they’re using is already the second use case. What's the programming languages that are in use? What are some of the key technologies that we're using?

Understanding this as a domain model is part of it so that you have a catalog everybody can go to in order to understand who owns what and what do we have. The one key use case we're looking at in the next quarter that is much more specific is around open source license management and understanding what do we use in terms of libraries and what microservice do they belong to.

It's a problem that every software company has and now we’re going to use Microservice Intelligence to very quickly localize who to go to in terms of license management. Already we can extract all of the libraries and we can map them on to the corresponding open source licenses.

There's still a bit of noise in the data that needs to be cleaned up to get it fully live, but then we have defined license management workflows where you need to look up whether your license is approved. If it's a new license, then you need to get in contact with legal for an approval. Or you can have rejected licenses and then you know that the library that you're trying to use is not a good choice. Copyleft is an important topic here.  As a software company, we can't really use any type of copyleft license.

Q. Now that we understand your insights on copyleft license usage, are  colleagues from the legal department more confident with compliance?

Jan: I'm not sure whether it gives them a better feeling. In software development you don't use copyleft licenses. It becomes an important compliance issue in any type of financing or any other major event, where there is a legal due diligence. It is always a sensitive question so you need to have everything in place. In general, it's just assumed that we established that process and it's something that can be very tedious to carry out.

There's scanning tools, but to fully streamline the process of detecting these issues and then resolving them is a big pain in a growing organization. That's something that we're able to very nicely address with Microservice Intelligence.

On governance and open source vulnerability analysis

Q. Can you speak about governance for the microservice landscape?

Jan: Well, the open source license management is a governance process at the heart of what we need to do. Another use case we intend to support in the course of the year is around open source vulnerability analysis and understanding what part of the libraries that you're using is affected.

In every organization like ours, thousands of libraries are potentially affected by vulnerabilities. There's quite effective tools like Snyk in order to detect that information, but the hard part is whom to route them to. We intend to either integrate with Snyk and/or provide our own embedding of CVE security databases.

The ability to then group these findings and route them to different teams, as part of an automatic ticketing process is something that I believe would provide another key area of governance that needs to happen in the development organization.

And there's other aspects and governance that would fall more in the domain of Jira. Do we truly do a code review on every ticket and the processes that we need to ensure as code goes out into production? The ones that are outlined for me are really important processes that every development organization has, but they don't really solve the problem for me in a way that it's easy and streamlined and almost automatic.

Measuring KPIs for development efficiency

Q. Next to the microservice catalog and the open source licensing use case, I hear you are also investigating how to onboard new developers more quickly and monitor key development KPIs, correct?

Jan: This can be seen as two different use cases. Onboarding comes back to cataloging as an initial understanding of your architecture and the ability to navigate the company without the tacit knowledge that long-term developers have is very important.

Key KPIs are something that we're also quite interested in more from a leadership and steering perspective. We want to understand release frequency and other key DevOps metrics, and Microservice Intelligence will soon allow us to automatically measure them, monitor and take action based on the data.

Q: From a CTO’s perspective, what kind of use cases or information would you want to retrieve on a daily weekly or monthly basis?

Jan: At my level, it's really around KPIs to understand inefficiencies, and understand spend and investment allocation. That points to yet another area. We want to not only use Microservice Intelligence to monitor the as-is state, but also look more on where we change, where we invest, where we allocate development resources to change things so that's the part that I'm really interested in. I’m also really interested in our roadmap and the ability to tie a high-level roadmap back down to who owns what, and where does it need to fall. I think I'm going to get a lot of value from the tool in this regard.

Q. Let’s assume we are at the end of 2021. Looking back, what do you hope to have achieved this year?

Jan: So in my mind if we have tool support for 90% of the use cases that we have identified, I’d be a very happy person. These processes today are either not really well-defined or they live in bespoke places like Confluence pages and other disparate sources. What that means right now is that we, and I, spend a lot of time executing and monitoring and ensuring that these processes happen.

What I would hope for as an outcome is that I spend significantly less time on just standard stuff that simply needs to happen. At the same time I think that a good part of the organization has become much more effective in terms of communication eg. Finding out who to talk to. So to me that the knowledge base aspect is a really important one, as a productivity improvement that I would judge if we follow through is probably in the order of 10% additional productivity for the entire product organization.

Planning for Microservice Intelligence’s future

Q: From the product side, what are your priorities for further development of Microservice Intelligence?

Jan: There is product functionality that still needs to be built out in 2021 so a lot of the use cases that I described earlier are not fully supported out of the box. With the product and, in fact, on the data intake or connectivity side, we have put in place quite a few custom implementations that can now be played back to product development on the MI side for full productization.

Right now, the product comes with a set of CI/CD connectors and it comes with the Kubernetes connectors. One of the things we have learned and realized through the internal usage, is that we need a more proactive scan against the code repositories that is not tied to a new release.  That is something  now on its way for the Q2 roadmap.

We have seen a number of improvements on the license management use cases. We have uncovered what you typically find out in the wild in terms of licensed normalization. It's pretty bad so there's a lot of manual steps right now that we do in order to normalize a license. The same license may come with 10 different names that you uncover in the automatic scanning so one of the product ideas coming out of that is to provide it as a data service so that the work we do now manually is something we can multiply to all of our customers and provide as a standard.

As you can see we generate significant product ideas by really trying it out ourselves and that allows us to uncover some of these things much quicker.

A strategic direction that is not as important for us but rather for our customers is API management and API catalogs. We hear this frequently from our customers. We will need it if we go from a 100-person development organization to the next stage, with a few hundred developers. At that point even understanding where to find APIs and who owns them is important. It also has to do with the fact that LeanIX is an API-first company so every microservice actually has a well-defined API and it's very easy to locate in product where they are. It’s a key value add.

Subscribe to the LeanIX Blog and never miss a post again!