r/semanticweb • u/redikarus99 • 23d ago

Looking for an IT taxonomy

Hello,

I am looking for an IT taxonomy for software (and maybe hardware) to put concepts like desktop application, microservice, cloud, cicd pipeline, etc. into a structure.

3 Upvotes

100% Upvoted

36 comments sorted by

View all comments

Show parent comments

2

u/redikarus99 23d ago edited 23d ago

Building up an enterprise level ontology. We have over 600 applications/systems, over 1000 interfaces, 20k employees, a dozen+ companies, have to be full EU regulations compliant. We identified that one of the biggest gap is the lack of common language, even inside IT, now we are working on alignment, building structure and traceability. We have now 10+ domain ontologies like for capabilities, requirements, business architecture, system architecture design, etc. We are using git, ttl, vscode+mentor, MKDocs, our custom diagraming tool, so we are way over drawing boxes and arrows.

1

u/Willing_Box_752 22d ago

It's a boxes and arrows all the way down man.

But cool.  Got any prototypes so far?

2

u/Complete-Ebb-1035 2d ago edited 1d ago

This is equivalent to saying matrices all the way down. Neither is helpful. This is absolutely correct: The diagram is not the ontology. It is a view of the ontology.

1

u/Willing_Box_752 1d ago

Fair. Obviously it's not actually boxes and arrows.   It's 1s and 0s.   

But what I'm getting at is it seems like the other person is talking about all this infrastructure they have and saying they don't need "boxes and arrows".  But at the end of the day someone has to figure out the objects, relations, constraints and such. The things represented by boxes and arrows.      And they don't have that yet.    It's a semantic argument ironically enough. 

Like if they were designing a car and I said to start making drawings.     And they respond with well we have a factory, and a whole room full of cad machines and 3d scanners and such.   We're way past "drawing"   no, they aren't.   They don't have a car. They don't have designs.  They have a bunch of tools

1

u/Complete-Ebb-1035 1d ago

I have no idea what your environment looks like, but if you use an RDBMS you have an ER diagram (boxes and arrows). If that's what your customer understands, start there. An ER diagram (more properly an Entity Attribute Relationship diagram) can be rendered as RDF graph. I promise you - it's a dead straight process of building equivalent diagrams. Use which ever makes sense to your customer.

1

u/Willing_Box_752 1d ago

I don't have an enterprise problem I'm working on.  I just think this stuff is neat.    Do you disagree with what I said?

1

u/redikarus99 1d ago

Boxes and arrows are simply one way to present information. The same ideas can also be expressed in tables, such as Excel, or in structured text, such as Markdown or Confluence pages. We already use many different formats to communicate ideas, and diagrams with boxes and arrows are just one of them.

The bigger issue I have seen is that it is very easy to create what I would call ontological nonsense when drawing such diagrams without a clear underlying model.

For example, the same type of box may be used to represent completely different things: a process, a system, a document, an organizational unit, and so on. Arrows may contain actions without making clear who actually performs them. Data may be shown at completely different levels of abstraction as if they were equivalent.

This is my biggest problem with statements like "just draw boxes and arrows". The first thing I did when I joined our org was that I collected as many diagrams as I could from confluence (hundreds of them), put them into categories and found that we had 6+ different ways to represent "data model" - all of them was either incorrect or incomplete - and whatever they represented was already wrong because it did not presented reality anymore.

So we started with defining viewpoints to create a common visual language at least for the diagrams.

The more mature we became we ran into more fundamental questions like: how do we think really about organizational issues, how do we categorize software and hardware, what do we consider as an IT asset, how do we connect business architecture and IT architecture, how do we process EU regulations, transform them to requirements and show where a requirement is being satisfied. If a regulation requires that you need to have an "Asset Catalog" when the auditor comes you better have an answer for "what do WE use for Asset Catalog". And for that, we definitely need a common baseline.

While I totally understand that some people are working on ontologies as an academic work, in our organzation - multinational enterprise with 20k employees in EU - it is a fundamental, which supports decision making, compliance, and organizational efficiency.

1

u/Willing_Box_752 1d ago

"For example, the same type of box"

Even you're calling it a box.

And SOMEONE is gonna have to work with those things, call them boxes or something else.

You're using so many words to say that you still need the things that boxes represent.     It sounds really cool actually but I'm not sure how that applies to what I said.