Application Classification - How to decide?

Thanks @aus, great start. We’re down the same road and it doesn’t seem as easy as we thought this would be. 🙂

If we start to unpack the LeanIX definition, it leads to more questions. 

1. What is business data? - are these data sets that are directly consumed in a business process? E.g. an invoice line item, purchase order number etc.
2. What is a business task - for e.g. if a business user logs into SAP using SSO to process a SAP transaction, then the Microsoft Azure AD provisions the SSO. Does this mean Microsoft Azure AD is a business application?
3. Which processes are we talking about - There are business (directly related to a value chain) and technical (not directly related to a value chain but enables the execution of the business process) processes in any organisation. So, in this case, does an underlying technical applications like Cisco Network Manager classify as an application? Without using this application, the business wouldn’t be able to execute their business tasks and processes.
4. Aspects of an organisation’s business model - this is a bit too vague to assign any attribute to help with the definitions.

Next big challenge for us is, how do we classify applications such as utility applications (viz. Calculator, Adobe Acrobat Pro, Snipping Tool), Web browsers (Chrome, Edge).

Keen to hear from your and the community’s experience. 

Hi @aus, @ganeshjanakiraman, @Bruce G. 

We’ve also been on a similar journey. The meta-model has also changed [for the better] during the time we’ve been using it. 

1. Data Objects we consider to be very close to an Entity in a relational database modelling. We’d consider them as high level, and abstract - a “business concept” - and we avoid the implementation detail. So we do have “Invoice” and “Purchase Order” but not invoice line item and PO Number. We don’t distinguish between an inbound invoice or one we are sending out, those being established by the various relationships. 
2. For SSO, we ended up with some custom properties on the Application Fact Sheet

   

   We tried other ways - IT Component, Application, Interface, but it was hard to keep things consistent. 

3. As a rule of thumb, we think of “Applications” as “Business Applications”. They should be  aligned to Business Processes / Capabilities. Payroll, CRMs, Marketing, Reporting etc. Systems that are provided to business users.
   The main alternative we use is “IT Component”. Anything that a Front Office user will not have heard of or care about. All of those utilities you mention. I’d also tend to put User Interfaces in IT Components if explicitly needed. 

Looking at the inventory for Applications, I believe it should give you a flavour of what the business does.

Establishing the “Tech Categories” and reviewing and assigning IT Components to through the IT Component Landscape report was really helpful to us. 

Thanks @Gundalf for sharing your experience.

1. Yes, data objects are well defined, and we are going down the same path of defining conceptual level entities rather than the detailed logical level data entities. E.g. PO, Work Order, Incident etc.
2. For SSO, doesn’t LeanIX already have the SSO Availability and SSO Available Providers in the application factsheet?
3. I like your definition of the Business Applications, however I feel the utilities might also be offered to the business user to do their day-to-day tasks. E.g. snipping an image into a report or using Adobe Acrobat Reader to view an invoice etc. What we’re planning is to customise the meta model to create 2 new factsheets - Utilities\Productivity and Technical Applications. Utilities will contain all the tools that the business uses, such as Calculators, Snipping Tool, MS Word, MS Excel, MS Teams etc. Technical Applications will contain all the underlying applications that our IT team will use, such as Cybersecurity Tool to monitor incidents, ServiceNow for IT service management, Cisco Network Manager etc. 
4. We want to use IT components to document the underlying technologies that support an application. E.g. if an HR System runs on a SQL Database, Apache Webserver, we will use the IT Components to document these.

Keen to hear your thoughts.

I came across this thread and found it quite useful.

Dredging up application vs IT component | Community (leanix.net)

 Hi @ganeshjanakiraman,

I do follow your reasoning on point 3.

As far as possible, our approach is to align with the official meta-model rather than extending it. That makes incorporating MM changes easier, allows us to use the official documentation and guidelines going forward, use reports as they are introduced and, maybe most importantly, holds us back from being too “creative”. 

For Utilities and Productivity, I’d suggest tracking them by exception. Calculators, Snipping Tools, Paint, Notepad etc are ubiquitous and shipped free with all desktop OS’s for as far back as I can remember (lets say the 90’s). Word processing, spreadsheets and presentation software also form part of our standard desktop environment.

Often these won’t be connected to other Factsheets - it feels redundant to add MS Office to every User group, or the Snipping Tool to a Business Context / Process. I feel like you would end up with a lot of unused and empty factsheets. 

Alongside the MS Office + 360 suite, I consider them part of the desktop “fabric”, part of a standard desktop build. If a specific teams or processes used LibreOffice or WordPerfect I might add that as an application. 

I have “Productivity / Collaboration” as a Tech Category for IT Components, which in-turn contains utilities.

For Technical Applications - I have them as IT Components - things like IDEs, Database GUI’s, Management Consoles and the like. 

Thanks! I ran out of time, so feel free to come back to me!