How can you get an overview of architectural concerns such as inter-service communication, lifecycle, security, health in a new or big project? Usually the answer is: "Ask the architect" or "look into the documentation". And the usual outcome is well known. The talk demonstratesa tool which can help answer many of these questions. It is designed to automatically gather information from existing sources, like code repos or deployed services and to be enriched by code committed by the team. The goal of the talk is to show the current progress and get feedback from the audience. How can a new team member get to know the application landscape it is working in? Where to find insights on typical Enterprise Architecture Management concerns like lifecycle, security, health and so on? Usually these questions arise sooner or later in most projects, even smaller ones. To answer them, however, is not always easy. EAM tools will help, but are not always available because of costs or high ramp-up effort like learning a sophisticated meta-model or TOGAF. In addition, architects usually design the landscape, gather information and have teams implement it, which results in a gap between design and current state. At times there is no dedicated architect, nor up-to-date documentation. Or generic tools are used, such as graph designers producing nice visualizations which are outdated at the time they are published and require much maintenance. Same goes for wikis if not maintained with high efforts. As a result the team has to work with a partially incomplete picture of its environment at least for a longer period. Nivio (working title) is a free and open source tool to address this issue. It is Application Landscape Management for teams, i.e. a bottom-up approach targeted primarily at the working class (developers, ops, designers, ...) not working full-time on EAM. It can be run one-off as docker image on a local computer, generate reports and then be discarded. The idea is to use the information that is already available and enhance it with information which is known to some developers or admins, but usually not required in code repos or operational environments. The model behind Nivio is biased and rather simple, partially based on and inspired by pivio. The main concept is to put services into groups and describe their state and dependencies, data flow and so on. Configuration is mostly YAML, which is easily readable by humans and known to most targeted users. There is one configuration per landscape, containing things like the name and the responsible persons, and most importantly, a list of data sources. This list can contain git repos, docker-compose files, rancher or kubernetes (some of them in alpha state at the time of writing) and a proprietary format. The report produced by Nivio is an automatically formatted landscape diagram and a few html pages containing all info that could be found. In addition to that there is an web API. Future plans are to provide a Java plugin API for customisation of input and output plus some more automated reports. Visit github.com/bonndan/nivio to learn more. Daniel Pozzi https://programm.froscon.de/2019/events/2360.html