0

EA view of having all CMDB components in LeanIX

Avatar
Sadeque, Kritee
None
Follow

         Fellow Members,

         Reaching out to all of you for your valuable insight on the following topics:

  • What are the ITCs should we import in LeanIX? Upto which level of hierarchy should we consider n (dev instance/prod instance/application server/windows server etc...)? Are these going to be only the ITCs that enable Business Applications?
  • Is there any benefit of importing Printers/Fax/Servers and their related services to LeanIX from EA view? If we don’t import these elements, will LeanIX be not utilized to its full extent?
Date Votes

7 comments

  • 0
    Avatar
    Michal Binder

    Hi Sadeque,

    Plenty of resources on the website but my suggestion is (and that applies to all factsheets) - include only data points that can be effectively maintained and support your use cases. 

    Are there use cases supported by number of printers? if so, go for it. If not, ignore.

    Michal

  • 0
    Avatar
    Galina Stancheva

    To be honest, I do not see the case to import/sync instances (CI-s) per environment of application servers/windows server/network nodes/databases etc., because this will make LeanIX to become a CMDB. What would you need to sync over all the CI-s?

    There is however a value to import/sync the SW/HW Product Models (product name, type, version, vendor ...) whatever is available, complement them on the LeanIX side with a lifecycle, recommendation, successors and use the as underpinning technologies to articulate the dependencies of the Business Applications.

  • 0
    Avatar
    Celso Sawaia

    Hello Galina,

    How do you handle the modelling of one application that has 3 working environments (dev, test, prod) each one with its own tech stack?

    If we model only the production environment, wouldn't the view of the total investment associated with that application be jeopardized?

  • 0
    Avatar
    Galina Stancheva

    Hi Celso (Celso Sawaia).

    To my understanding, and from EA perspective - representing the fact that an application has been deployed in multiple environments - is not a subject for the Application Portfolio Management, and should NOT be modelled in a tool like LeanIX.

    The approach we are following is that the "application" factsheet is to store unique Business Applications (either in-house developed or provided by a vendor), which on this level are technology agnostic and version agnostic logical concepts.
    The underpinning technology is modelled via the IT components (unique SW/HW products + versions), related to the Business Applications.

    For the in-house built Business Applications, we have introduced a separate factsheet (SW component, aka. Physical application), where we sync the information from our SW code repositories and maintain the relationship to the Logical Business Application Level.

    Now, if something is to be instantiated and deployed in different environments - those would be the IT Components (specific third party SW product versions) and the in-house built SW components (e.g. a microservice or a legacy perl module, with a version and release).

    But this information is in the scope of either the CMDB or the Build/Deploy tool (e.g. Bamboo).

     

    If the use case is to differentiate which Business Application is "offered" on what type of environment in order to have different SLA-s -> this is something we are solving in ServiceNow, employing the concept of the so called "Business Service Offering". The Business Service is synced from the Business Application in LeanIX.
    The "offering" adds the variation, which could be based on environment, user group that is using it, location of use, etc.
    The SLA is that assigned to a particular "Business Service Offering".

    This is our way of course.
    I would be happy to hear other solutions :)

    HTH,
    Galia

  • 0
    Avatar
    Sean Brady

    I'm looking into Microservices Intelligence module which is more aligned with capturing instances of components -- it pulls data from source repos, cloud accounts, and other engineering tools.  See https://docs-mi.leanix.net/docs/data-model.

  • 0
    Avatar
    Galina Stancheva

    Hi Sean.
    I do agree with you.
    It is just that the MI was not entirely ready when we were scoping LeanIX at Paysafe.
    And unfortunately expect for microservices based applications, we would still run 8 other legacy technology stacks, still running in on-prem DC-s, which most probably wouldn't be a subject of MI to discover.
    Plus - MI goes with its own licensing :)

    But on the long run - this should be a way forward!

  • 0
    Avatar
    Marek Odwarko

    Hi Galina and Sean,

    We do model working environments as Service components and assign them to the "one" (business) application. Furthermore we assign SW components to the application to show its technology. 

    If needed, you could also draw requires/required by relationships between Service components and SW components or relate to Tech Stacks. 

    Those Service components aka working environments are the common understanding between our Service provider and our inhouse IT department. For simplicity, we add the server names, DNS aliases, etc. in the description field for the service components. This way, everyone in the company can find the real application via LeanIX. Unfortunately, we do not have a CMDB.

    Best regards,
    Marek

    Edited by Marek Odwarko
Please sign in to leave a comment.