Where did you (all) start?

Hi ​@Eric,

we started with registering Applications (long time ago),because LeanIX was started as a pure IT-Project. We needed to document and model our Application Landscape, so we decided to go that way.

1.  I think the approach depends on your companies size in relation to the no of & seniority of your EA departments employees. We did it department by department (or do it by 1st Level Business Capabilities). You have somehow to get existing items into LeanIX and doing it by projects may not cover everything. Anyway to get first experience it’s a useful approach.
2. Just a recommendation, start always simple a not too detailed. Many IT people are loving details, but you have stakeholders outside IT so always consider to keep it understandable. Managers usually do not like too much details, so always be aware of your audition/users. Additionally consider the size of the group maintaining the data in LeanIX: The more details, the higher the effort to maintain.
3. Yes: BIC Cloud for Processes (they offer an Interface), ServiceNow and PowerBI (we are using standard ODATA and also Fabric with Lakehouse and PySpark). We utilize Azure Functions where Calculations and Automations are insufficient. All as Interfaces / Components / Application and microservices in LeanIX.
4. To find the right approaches for you EA setup and needs, you have to go through a learning process. Anyway it is useful to take some consulting to have somebody experienced helping you. We had good experiences with taking services from LeanIX to discuss the pros and cons of different approaches. E.g. In the beginning we set up middleware as an application. Although this is form IT perspective technically correct, nobody outside it will understand. You may model CRM->Middleware and Middleware->ERP for Customers, but nobody who does not know will see that customer data is transferred from CRM to ERP. We also decided not to model provider and consumer as it may be technically correct for the interface, we take the application providing the data as provider and to one(s) retrieving it as consumer, because the business will it understand easier.
   Be aware of seen as sitting in an ivory tower, this will isolate you and prevent others form participation. LeanIX strength is collaboration, so always make it easy to all users!

Best regards,
Carsten

Thank you very, very much Carsten!
For the quick reply and for your time you took for such a well-founded answer.

“Not to many details”, that`s what I heard a lot of times now - I will definitely keep that in mind :)

In terms of your toolchain: Are you doing a lot of automation? Is that even possible?

Example for what`s in my mind:
New IT assets (applications, data / interfaces, technology) should only be created in our ITSM tool (e.g. ServiceNOW) and through the underlying ITSM-processes (demand, change, etc.). This should be the single point of truth, where assets are guided through their lifecycle. 

These assets (from the CMDB) could now automatically be send to LeanIX. Here, the mapping to the supported capabilities and / or other IT assets (App - Interface -App) icould be done.
If now one of these assets changes (through change management), the change in the architecture in LeanIX, automatically appears.

So the initial set up let`s say, is done by sending IT assets to LeanIX on demand. Updates of theses assets could then be automated.  

Do you think, it is realistic? Or do I even completely miss the topic as a greenhorn :) 

Hi ​@Eric ,
generally you can make that work. The first step is to define the Items, LeanIX should be the Leading one for Applications, Interfaces (ServiceNow is not the right place for Interfaces) and -if there is no MDM tool in place- Data. Be aware that understanding of application  is often different in the different IT disciplines. The term application is of of used as synonym for Software Component (IT-Component in LeanIX), be aware. You should first setup definitions and a dictionary before talking to other IT-Areas to avoid misunderstanding and confusion. Will you utilize the TRM Module of LeanIX, the thrid party interface by ​@Thomas Schreiner or will you program an interface by yourself? Anyway without experience I recommend to get some consulting (Best someone neutral, or LeanIX). You may look at: One Pager - Integrate EA and ITSM with the LeanIX ServiceNow Integration and documentation ServiceNow Integration | SAP Help Portal
Anyway gain some experience before starting such integrations.

I’d make LeanIX leading for Applications, Interfaces, Business Capabilities, Data (If there is no MDM or anything else) and Processes (if no BIC, Signavio or other Process tool in place).

BTW: This page contains generally contains additional information which may help: Resource Library | SAP LeanIX

Best regards,
Carsten

Thank you once again ​@Carsten!

May I ask a last question, before I`ll dig deeper into the world of EA and gain more knowledge?

I`m totally with you, that LeanIX needs to be the leading application for applications and interfaces - especially in terms for their interconnection. This in the end is the digital blueprint of the supported business process (OBASHI), for my understanding. In addition to that, the interconnection may hardly be done on a CMDB-layer.

I think it`s because I`m coming from the IT side, that I`m thinking a lot of how to manage the lifecycle of applications, interfaces, technology objects, etc. Today it is really challenging, to keep the information about IT assets up to date, especially when they`re used in different tools and for different purposes. So the logical consequence is, there needs to be one place where the lifecycle of IT assets is realized - what should be the tool the LC-process (ITAM) is build upon (ServiceNOW)  -  and all other applications & platforms, who need to work (visualize, monitor, etc.) with these assets, should pick them from there. It could be possible to update an asset through another application via an interface (e.g. SAP CALM → ServiceNOW), but the sovereignty over the asset and its actuality itself, stays in the CMDB of ServiceNOW. Like processes will be kept up-to-date in SIGNAVIO. This at least, would be my ambitious vision at the moment.

To your question on the TRM Module: I absolutely have no clue :D At the moment I`m just trying to figure out, what may make sense in building up the EA from scratch. Thinking about, what will help in the long run. My main goals:

• High degree on automation
• Minimum need of manual work (otherwise it`ll hard to keep it up to date) 
• High potential on interaction (between the application)
  •  Consolidate information for different perspectives over the “toolchain” 
    • Risk, economic efficiency, transformation, PMI, etc

It`s absolutely clear, that the main focus is to support the core business. I`m convinced, that the chance to succeed will be significantly higher, if the EA-perspectives need - in a project, etc. - could be “generated” very fast and comprehensive, to answer the open questions, lower the risk, keep the right persons informed, etc.

Let`s see how long it will take to disillusionment :) Hopefully never…

Thank you very, very much once again and have a nice day!

Eric  

Now I saw, that the question marks in my former post are missing *sorry about that* and now I`m not able to edit my post anymore….

Maybe I could ask you that way ​@Carsten:
How deep did you integrate your EAM into your ITSM-processes?
Hasn`t that been one of your first questions as you started to build up LeanIX? Especially in terms of keeping your information up to date and integrate changes in your architecture into your existing change management?

BR

Eric 

Hello ​@Eric ,
to your post 2 days ago:
I’d start small. Applications have a different Lifecycle than Software-Components, so often there is no CMDB entry available for the lifecycle. Start manually and then you may look step by step what is useful to Interface or automate. LeanIX is a collaborative tool, so you may collaborate with your colleagues. We are a small EAM Team and do simply not have the capacity to do all the data maintenance. Therefore you have the accountable (and responsible) subscribers, who are knowledgeable about the factsheets they are subscribed to. I assign the subscription to a manager who assigns it to a team-member. By using automated tools you may get more into LeanIX than desired. And be aware that there are some hidden traps. Further do standard interfaces not take care of modifications of the data models, so fields you added yourself may not be transferred.
You are very enthusiastic, but to make it a success patience, communication, enablement is required not just technology. LeanIX is not purely IT, it’s main value is bridge between IT and business, if you take a pure IT and technical approach you will fail. Enrich you Enterprise Architecture knowledge first, because just looking at a tool does not help. 

Best regards,
Carsten

Hello ​@Eric,
to your question today: the first year I did nothing on that. As I am the leading EA and the ITSM Change Manager, I was aware of what was going on. So it was a complete manual process. Meanwhile we integrated some things like When a demand is created, the undying objects (Applications, Components, Interfaces) have to be created in LeanIX. The service desk (1st Level) uses LeanIX to gather information. Actually we developed our concept are now working on mapping and interfacing, which is the most complex task, this is now running for more than one year. (But we are actually in a big ERP Project, which takes much of our time). We link related applications and components to a change. If a change is related to an introduction, rollout, withdraw or decommission we’ll update the lifecycle or relations.
We do not sync too deeply, because if you need the details you can jump into the system holding that information.
Best regards,
Carsten
 

Hi ​@Carsten,

thank you very much for your reply.

I absolutely agree in terms of:
“LeanIX is not purely IT, it’s main value is bridge between IT and business,”
“Enrich you Enterprise Architecture knowledge first, because just looking at a tool does not help”

I just try to consider what is necessary to make an EAM helpful and to make it work - from all perspectives (business and IT). The tool is completely irrelevant, but will bring some restrictions in terms of the modelling, etc.
So it´s more about: “Which Enterprise Architecture for the Enterprise Architecture Management do I need?” to make it work at the end of the day. Not only in terms of the technical circumstances, but also on the needed processes, governance and so on.

We are also a small “Team” and so one main focus, which in my opinion makes sense. is automation. For automation, I need good data and solid data sources. This should bring more time, to concentrate on helping the main business in it`s continous transformation or even be in a position to help.

For me, it would be great to have the opportunity to see a completely modeled business case to get a better understanding.
Something like expanding common HR processes (joiner, mover, leaver) to other subsidiaries for example. I guess that`s something, most companies face, when they expand globally.
Is that a business case / an enterprise architecture you have modeled in LeanIX? Just for interest.

BR
Eric

 

Hello ​@Eric ,

sure automation will help a bit, but if you ask SAP LeanIX they will tell you that you should involve people outside your EA team, because LeanIX is a collaborative tool. We have a very small EA team and with collaboration - not automation- we made it work.

Best regards,

Carsten

Hi ​@Carsten,

absolutely no doubts on that and that`s exactly the goal. Automate as much as possible, to gain time to be able to generate “real” value through proximity to the business and better collaboration. Supported by “expressive images” that lead to a common understanding - in the best case scenario, at the touch of a button.

BR
Eric

​@Eric Thank you for mentioning OBASHI methodology - Different industries uses different approaches to business / application / data representation. Interesting. And surely supported in LeanIX diagrams.

Thanks,
Moise