Applicatie- en serviceassetbeheer voor ontwikkelteams
Before you start, this guide covers:
What does application and service asset management for application development teams mean.
Why service context, application dependencies, and configuration data matter for engineering teams.
How Service Collection supports developer workflows with Assets, a CMDB, Data Manager, and service relationships.
A practical walkthrough example from service modeling to incident and change context.
Service Collection products referenced: Jira Service Management, Assets, Customer Service Management, Rovo
Reading time: 9 minutes
Applicaties ontwikkelen en gebruiken met betere servicecontext
Toepassings- en service-assetbeheer is cruciaal voor applicatie-ontwikkelteams, omdat moderne digitale producten afhankelijk zijn van een web van toepassingen, services, omgevingen, infrastructuur en componenten van derden.
Wanneer informatie over applicaties, afhankelijkheden, eigenaarschap en ondersteunende systemen verspreid is over tickets, cloudconsoles, spreadsheets en impliciete kennis, hebben teams minder inzicht in de impact van wijzigingen, het risico op incidenten en de status van services.
Dat gebrek aan context kan de levering vertragen en de kans op storingen of verkeerde probleemoplossing vergroten.
Ontwikkelaarstoepassingen en service assetbeheer brengen deze context samen in een betrouwbaar, gedeeld model. Met Service Collection kunnen teams configuratie-items van toepassingen en services bijhouden, ze koppelen aan ontwikkelwerk, relaties in de hele stack begrijpen en snel eigenaren identificeren.
Dit helpt teams voor de ontwikkeling van toepassingen om veiligere wijzigingen door te voeren, incidenten sneller op te lossen, de overhead van afstemming te verminderen en betrouwbare services met meer vertrouwen te builden en te beheren.
Wat is applicatie- en service-assetbeheer?
Applicatie- en service-assetbeheer is de praktijk van het bijhouden van de levenscyclus, het eigendom en de afhankelijkheden van applicaties en services om de operationele zichtbaarheid te verbeteren. Door applicaties te verbinden met infrastructuur zoals relationele databases, webservices, microservices of cloudomgevingen, krijgen teams de servicecontext die nodig is om het risico op incidenten te verkleinen en implementaties te versnellen.
Het combineert verschillende nauw verwante mogelijkheden:
Service-configuratiebeheer: nauwkeurige informatie bijhouden over services, applicaties, databases, API's, cloudresources en de relaties daartussen.
Asset- en configuratietracking: de systemen en componenten organiseren voor ondersteuning van levering van softwaretoepassingen en productieactiviteiten.
Service management-workflows: die context toepassen op incidenten, wijzigingen, aanvragen, goedkeuringen en rapportage.
In Service Collection biedt Assets de structuur voor deze gegevens. Assets is je CMDB waarin alle configuratierecords en hun relaties in de tijd worden opgeslagen, zodat teams niet alleen begrijpen wat er bestaat, maar ook hoe componenten met elkaar verbonden zijn.
Assets Data Manager van Service Collection helpt vervolgens de gegevenskwaliteit te verbeteren door records uit meerdere bronnen te consolideren en af te stemmen voordat teams er operationeel op vertrouwen.
Waarom applicatie- en service assetbeheer belangrijk is voor ontwikkelaars
Wanneer informatie over toepassingen en componenten verspreid is over spreadsheets en gescheiden systemen, wordt het lastig om een duidelijk beeld te krijgen van welke toepassingen een bedrijf gebruikt, hoe ze worden gebruikt en, wat vooral belangrijk is, wat er kapotgaat wanneer er iets verandert.
Met Service Collection Assets beschik je over een gestructureerde, doorzoekbare CMDB die al je toepassings- en componentgegevens op één plek samenbrengt en verspreide spreadsheets vervangt door een live, verbonden register.
Atlassian Assets centraliseert je catalogus met toepassingen en services in één gestructureerde, doorzoekbare CMDB, en vervangt verspreide spreadsheets en geïsoleerde tools door live, verbonden records. Het brengt afhankelijkheden tussen apps, componenten en infrastructuur in kaart en sluit direct aan op workflows in Jira Service Management, zodat teams altijd weten wat ze hebben, wie ervoor verantwoordelijk is en wat er wordt beïnvloed wanneer dingen veranderen.
Snellere beoordeling impact van wijzigingen: Teams kunnen begrijpen welke applicaties, omgevingen of afhankelijke services mogelijk worden beïnvloed voordat ze een wijziging uitrollen.
Verbeterde incidentrespons: Responders kunnen snel de service-eigenaar, upstream- en downstream-afhankelijkheden en waarschijnlijk getroffen infrastructuur identificeren.
Minder contextwisselingen: Developers en operators hebben rechtstreeks toegang tot de context van service en assets in Jira Service Management-workflows.
Versterkt service-eigenaarschap: Teams kunnen eigenaarschap, supportverantwoordelijkheid en gegevens over afhankelijkheden makkelijker vindbaar maken en onderhouden.
Verbeterd vertrouwen in toepassingsservices en operationele gegevens: Assets Data Manager helpt records uit cloudtools, discoverytools en interne systemen af te stemmen tot een schonere bron van waarheid.
Betere samenwerking met operations-teams : Gedeelde configuratiecontext helpt engineering en operations vanuit hetzelfde inzicht te werken tijdens veranderingen en incidenten.
Hoe Service Collection app- en servicebewuste ontwikkeling ondersteunt
Service Collection helpt ontwikkelaars- en operations-teams om configuratiegegevens op te nemen in de workflows waar die ertoe doen. In plaats van servicemodellen gescheiden te houden van het dagelijkse werk, kunnen teams apps, services en afhankelijkheden rechtstreeks koppelen aan aanvragen, incidenten en wijzigingen.
Een servicegerichte CMDB bouwen met Assets
Met Assets kunnen teams objectschema's definiëren voor de onderdelen die belangrijk zijn voor software- en toepassingslevering en -activiteiten, en vervolgens infrastructuur en relationele databases in kaart brengen. Dat kan bedrijfsservices, applicaties, omgevingen, API's, databases, wachtrijen, cloudresources, repository's en ondersteunende teams omvatten.
Binnen een CMDB kunnen die configuratie-items worden gekoppeld via relaties die staan voor hoe services daadwerkelijk werken. Een toepassing voor klanten kan bijvoorbeeld afhankelijk zijn van een API-gateway, een databasecluster, cloudinfrastructuur en een verantwoordelijk team. Dat verbonden model wordt nuttig wanneer teams snel inzicht in de impact nodig hebben.
Best practice: start with one or two critical application services and the dependencies that matter most for incidents and changes. A lean, service-centric CMDB is usually more useful than a large model nobody maintains.
Assets Data Manager gebruiken om gegevenskwaliteit te verbeteren
Applicatie- en servicegegevens komen vaak uit veel verschillende bronnen: cloudplatforms, detectietools, spreadsheets, interne documentatie en engineeringsystemen. Als die bronnen het niet met elkaar eens zijn verliezen teams het vertrouwen in het model.
Assets Data Manager helpt gegevens uit meerdere bronnen te consolideren, op te schonen en af te stemmen in een betrouwbaarder operationeel gegevensbestand. Dit maakt het eenvoudiger om naamgevingsconventies te standaardiseren, duplicaten te verminderen en hiaten te identificeren voordat ze gevolgen hebben voor incidenten, audits of goedkeuringen.
Voor engineering- en platformteams betekent dat meer vertrouwen in eigenaarschap van services, omgevingsrecords en afhankelijkheidsgegevens.
Zakelijke services in kaart brengen met toepassingsservices en assets om de impact van incidenten en wijzigingen te beoordelen
Met Jira Service Management kunnen teams aanvragen of wijzigingen rechtstreeks vanuit de ticketweergave koppelen aan Asset-objecten. Dat betekent dat een incident kan worden gekoppeld aan de betreffende toepassing of service, terwijl een wijziging kan verwijzen naar de omgeving of infrastructuur die wordt geraakt.
Zodra ze zijn gekoppeld, hebben responders en goedkeurders meer context. Ze kunnen zien om welke service het gaat, wie de eigenaar is, welke andere componenten mogelijk worden beïnvloed en of gerelateerd werk al in voortgang is.
Snellere probleemoplossing dankzij relatiecontext
Een servicerecord op zichzelf is nuttig. Een servicerecord gekoppeld aan de afhankelijkheden is veel krachtiger. Relatiegegevens helpen teams om sneller van "er is iets kapot" naar "deze specifieke afhankelijkheid kan de oorzaak zijn" te gaan.
Als een webtoepassing bijvoorbeeld verslechterde prestaties heeft, kan het team de gekoppelde database, authenticatieprovider, wachtrij en cloudomgeving bekijken om het onderzoek te verfijnen. Dat gedeelde overzicht kan ook support bieden voor incident swarming door ontwikkel- en operations-teams een gezamenlijke kaart van de service te geven.
Automatisering gebruiken om operationele workflows in beweging te houden
Automatisering kan teams helpen te handelen op basis van service- en configuratiecontext, zonder extra handmatig werk. Teams kunnen meldingen triggeren, tickets routeren, opvolgtaken aanmaken of records bijwerken op basis van wijzigingen in de status of gekoppelde objecten.
Gangbare voorbeelden zijn:
Incidenten routeren op basis van de geselecteerde service of het verantwoordelijke team
Vervolgtaken aanmaken wanneer een kritieke afhankelijkheid verandert
Belanghebbenden informeren wanneer incidenten services met hoge prioriteit beïnvloeden
Standaard operationele controles koppelen aan specifieke omgevingen of componenten
Stapsgewijs voorbeeld: van servicemodel naar snellere incidenttriage, hoofdoorzaak en oplossing
Hier is een praktisch voorbeeld van hoe assetbeheer voor toepassingen en services kan werken in Service Collection met Jira Service Management en Assets.
Scenario
Een platform-engineeringteam ondersteunt een intern ontwikkelaarsportal en verschillende klantgerichte applicaties. Service-eigenaarschap is gedeeltelijk gedocumenteerd, maar informatie over afhankelijkheden is inconsistent en verspreid over diagrammen, cloudtools en teamkennis.
Wanneer incidenten zich voordoen, besteden responders te veel tijd aan uitzoeken wat er is veranderd en welke componenten betrokken zijn.
Stap 1: Definieer het servicemodel
Het team maakt een Assets-schema aan om belangrijke configuratie-items in de CMDB weer te geven, waaronder bedrijfsservices, applicaties, omgevingen, databases, API's en verantwoordelijke teams. Ze beginnen met één waardevolle toepassingsservice en brengen de belangrijkste afhankelijkheden ervan in kaart.
Ze definiëren relaties zoals:
applicatie is afhankelijk van API-service
API-service is afhankelijk van databasecluster
applicatie draait in productieomgeving
platformteam is eigenaar van de runtime-infrastructuur
Stap 2: Consolideer brongegevens met Data Manager
Het team gebruikt Data Manager om records uit cloud-inventarissen, interne spreadsheets en bestaande servicedocumentatie samen te brengen. Dubbele namen van toepassingen worden samengevoegd, ontbrekende eigenaren worden gemarkeerd en verouderde records worden opgeschoond voordat ze in het werkmodel worden gepubliceerd.
Outcome: the team now has a cleaner, more trustworthy service model rather than relying on competing versions of the truth.
Stap 3: Verbind het model met Jira Service Management-workflows
Het team voegt Assets-velden toe aan incident- en wijzigingsworkflows, zodat engineers en operators de betrokken service of het betrokken configuratie-item kunnen selecteren. Wanneer een nieuw incident wordt aangemaakt, kunnen hulpverleners meteen de gekoppelde toepassing, eigenaar, omgeving en gerelateerde afhankelijkheden zien.
Dat verkort de tijd die wordt besteed aan het stellen van eenvoudige triagevragen en helpt teams om eerder de juiste mensen te betrekken.
Stap 4: Gebruik het model tijdens een incident
Er is een incident gemeld vanwege een toename van fouten in een klantgerichte toepassing. De responder koppelt de getroffen service in Jira Service Management en controleert de gerelateerde configuratie-items. En ziet dat de toepassing afhankelijk is van een gedeelde authenticatie-API en een databasecluster.
Een recente wijziging is al gekoppeld aan de authenticatie-API. Die aanwijzing helpt het team het onderzoek snel te verfijnen en de juiste verantwoordelijken erbij te betrekken zonder te hoeven gissen.
Stap 5: Verbeter de planning van toekomstige wijzigingen
Na het incident gebruikt het team tijdens wijzigingsbeoordelingen dezelfde servicerelaties. Voordat updates worden uitgerold, kunnen ze zien welke afhankelijke services mogelijk worden beïnvloed en vooraf afstemmen met de juiste teams.
Hoe dit er in de praktijk uitziet
Fase | Wat het team doet | Operationele waarde |
De service modelleren | Service-, app-, omgevings- en afhankelijkheidsobjecten aanmaken in Assets | Bouwt een bruikbare CMDB voor engineering en operations |
Gegevenskwaliteit verbeteren | Data Manager gebruiken om gegevens uit meerdere systemen op elkaar af te stemmen | Creëert meer vertrouwen in eigendoms- en afhankelijkheidsgegevens |
Workflows met elkaar verbinden | Services en configuratie-items koppelen aan incidenten en wijzigingen | Geeft teams context waar ze al werken |
Sneller triage uitvoeren | Afhankelijkheidsrelaties gebruiken tijdens incidenten | Verkort de tijd voor onderzoek en escalatie |
Veranderingen beter plannen | De betrokken services en componenten controleren vóór de implementatie | Verbetert risicobewustzijn en coördinatie |
Hoe je de implementatie aanpakt
Als je deze functionaliteit bouwt voor engineering- of applicatieontwikkelingsteams, werkt een gefaseerde uitrol meestal het best.
Begin met één kritieke toepassing of service die vaak voorkomt in incidenten of wijzigingen.
Definieer de minimale bruikbare set configuratie-items en relaties.
Gebruik Data Manager om de kwaliteit van brongegevens te verbeteren voordat je breed opschaalt.
Voeg eerst Assets-context toe aan incident- en wijzigingsworkflows, waar die direct operationele waarde creëert.
Breid de CMDB geleidelijk uit naarmate teams bewijzen dat het model nuttig is en kan worden onderhouden.
Good first milestone: make it easy for a responder or approver to answer what service is affected, what supports it, who owns it, and what else may be impacted.
Klant in de spotlight: Lucid Motors
[Assets is een] absoluut cruciaal onderdeel van onze Jira-infrastructuur, en eerlijk gezegd weet ik niet hoe je hardware engineering met Jira zou kunnen doen zonder je hardware ook in dezelfde space bij te houden. Omdat toen we het probeerden te doen met versnipperde hardwaretrackingtools... er geen inherente traceerbaarheid in onze systemen was. En als je alles in die andere tools probeert te doen, zit daar ook geen flexibiliteit in. We hebben dus echt iets gevonden dat voor ons werkt.
Felipe Luisi, Senior Product Manager, Lucid Motors
Veelgestelde vragen
Wat is applicatie- en service-assetbeheer?
Applicatie- en serviceassetbeheer is de praktijk van het bijhouden van applicaties, services, afhankelijkheden, omgevingen, configuratie-items en eigenaarschap in een verbonden model. Het geeft ontwikkelings- en operations-teams betrouwbare context voor incidenten, wijzigingen, aanvragen en serviceplanning.
Hoe ondersteunt Assets teams voor toepassingontwikkeling?
Assets biedt een gestructureerde CMDB voor het modelleren van applicaties, API's, database, omgevingen, cloudresources en de teams die eigenaar zijn ervan. Teams kunnen deze context koppelen aan incidenten en wijzigingen in Jira Service Management om de impact te beoordelen, werk te routeren en sneller problemen op te lossen.
Wat is het verschil tussen een CMDB en een assetinventaris?
Een assetinventaris registreert wat er bestaat, terwijl een CMDB ook vastlegt hoe configuratie-items zich tot elkaar verhouden en een service ondersteunen. Assets kunnen als beide dienen door toepassings- en servicerecords samen met afhankelijkheden, eigendom en operationele context op te slaan.
Hoe kunnen teams de kwaliteit van toepassings- en servicegegevens verbeteren?
Gebruik Assets Data Manager om records uit meerdere bronnen te consolideren, op te schonen, te normaliseren en af te stemmen voordat je ze in het werkmodel publiceert. Begin met de gegevens die nodig zijn voor kritieke incidenten en wijzigingen, en breid vervolgens uit zodra het servicemodel nuttig en onderhoudbaar blijkt te zijn.