- SAP Managed Tags:
Sometime in the summer of 2004, during my studies, I attended a lecture about programming. It was a hot summer day. This noticeably lowered the students' attention 😉 During the lecture, the professor said something that I always remembered. I could understand it only after many years as a developer.
He said: "You will always have work with one topic during your whole working life: interfaces." He didn't mean the interfaces known from object-oriented programming. But the interfaces between software that runs either on the same or on different systems.
15 years later, this sentence is one of the experiences that I like to pass on to apprentices and students. In fact, the sentence was more than confirmed during my working life. I worked in various interface projects with formats such as XML and JSON, learned about software or systems from SAP AG or other vendors, set up standard interfaces with IDocs, tested the data exchange, monitored, corrected, documented and much more. Not to forget that I also got new contacts while working in such projects because many people were usually involved.
In my experience, certain questions are always the same in an interface project. Therefore, I thought that based on my experience, I put together a kind of "model". Just a few clues for orientation. So it can be used when talking about the requirements with a customer or while creating a concept.
The model is of course not complete, because interfaces have too many facets and at the moment it is "only" the result of a sunday afternoon think session. This is where the SAP community comes into play. Who is interested and has time can bring in his experiences. Thereby the model can grow and as it is available to everyone for free, anyone can use it. So to speak another small part in a big puzzle called "improve our software future" 🙂
I used draw.io to build the model. The software is available for free as an online and an installable edition. This allows anyone to edit the model and to adapt it to his needs. If you like to use it in the context of Jira or Confluence, there are paid draw.io extensions. I already worked with draw.io in Confluence. That worked very well.
What does the model include? I've tried to divide the topics that apply to an interface into four main categories. At the moment this looks like this:
Based on the Advanced Shapes of draw.io, I have created foldable trees below these categories. The trees include terms that I see in the context of the category. Since there are "only" terms and not texts, you should develop a common understanding of the terms in your project. In the future, it would be perhaps handy to use the tooltip function to store additional information. Some terms do not apply to every interface project, then you can omit them, of course.
The order of terms is likely to be changed for relevance. I'm still thinking about that at the moment.
The colors are used to better distinguish which category you are in. Otherwise, they have no meaning at the moment, especially red and green have no special meaning here.
I also tried to limit the model to topics that could be important to me as a developer in a project. So this does not necessarily fit for a consultant, project manager or administrator. Basically, you can add important key words from these disciplines.
As storage location I have chosen GitHub. Follow this link. draw.io supports direct access to GitHub. However, I have no experience whether you can actually work together on a draw.io document. As a storage location, it seemed to me in any case suitable.
Ok, that's all for now. Thanks for reading, perhaps even for sharing your knowledge. Have a good time and always not too much work with interfaces.
Best regards
Michael
He said: "You will always have work with one topic during your whole working life: interfaces." He didn't mean the interfaces known from object-oriented programming. But the interfaces between software that runs either on the same or on different systems.
15 years later, this sentence is one of the experiences that I like to pass on to apprentices and students. In fact, the sentence was more than confirmed during my working life. I worked in various interface projects with formats such as XML and JSON, learned about software or systems from SAP AG or other vendors, set up standard interfaces with IDocs, tested the data exchange, monitored, corrected, documented and much more. Not to forget that I also got new contacts while working in such projects because many people were usually involved.
In my experience, certain questions are always the same in an interface project. Therefore, I thought that based on my experience, I put together a kind of "model". Just a few clues for orientation. So it can be used when talking about the requirements with a customer or while creating a concept.
The model is of course not complete, because interfaces have too many facets and at the moment it is "only" the result of a sunday afternoon think session. This is where the SAP community comes into play. Who is interested and has time can bring in his experiences. Thereby the model can grow and as it is available to everyone for free, anyone can use it. So to speak another small part in a big puzzle called "improve our software future" 🙂
I used draw.io to build the model. The software is available for free as an online and an installable edition. This allows anyone to edit the model and to adapt it to his needs. If you like to use it in the context of Jira or Confluence, there are paid draw.io extensions. I already worked with draw.io in Confluence. That worked very well.
What does the model include? I've tried to divide the topics that apply to an interface into four main categories. At the moment this looks like this:
Based on the Advanced Shapes of draw.io, I have created foldable trees below these categories. The trees include terms that I see in the context of the category. Since there are "only" terms and not texts, you should develop a common understanding of the terms in your project. In the future, it would be perhaps handy to use the tooltip function to store additional information. Some terms do not apply to every interface project, then you can omit them, of course.
The order of terms is likely to be changed for relevance. I'm still thinking about that at the moment.
The colors are used to better distinguish which category you are in. Otherwise, they have no meaning at the moment, especially red and green have no special meaning here.
I also tried to limit the model to topics that could be important to me as a developer in a project. So this does not necessarily fit for a consultant, project manager or administrator. Basically, you can add important key words from these disciplines.
As storage location I have chosen GitHub. Follow this link. draw.io supports direct access to GitHub. However, I have no experience whether you can actually work together on a draw.io document. As a storage location, it seemed to me in any case suitable.
Ok, that's all for now. Thanks for reading, perhaps even for sharing your knowledge. Have a good time and always not too much work with interfaces.
Best regards
Michael
2 Comments
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
