During this presentation Han will talk about the approach that was initiated in the beginning of this year to find another way of working, modelling and publication of analysis and data exchange standards within the container shipping industry. He will connect business analysis with data and REST Apis. After presenting the previous situation the new situation is shown by using EA and Prolaborate. Topics to be presented are BPMN, Use Case and API modelling and the lineage between the various elements to prove completeness and correctness. Publication of the models improve the consistency between the different design layers as well as early feedback by the various business analysts and developers of the various container shipping companies.
Use as less (but enough) model element types to express what you want to show. Less is more. So with BPMN we only use 5 element types or so. Did you see how many element type BPMN 2.0 has? way too much for normal people like me. Use patterns to help a modeller getting faster from A to B. Do not use empty boxes (so each model element must have a description (of at least 3 lines)) otherwise if you click on it in a webtool (WebEA, Prolaborate) it does not show anything. For a process title use at least 3 words to be specific enough. Let modelers feel that some things sound similar, but actually are not (or the other way around). Within this industry there exists multiple Glossary of Terms e.g. DCSA in combination with carriers, UNECE, FIATA, and probably more I am not aware of just yet. I import them all into the same repository, so e.g. business analyst can see them all and if required create a relationship between them. I noticed that the Glossary of Terms the right word and definition is of utmost importance. During each (modeling) session you have to check if the correct terms are used. When this is not done problems with data exchange will arise during testing of the API, which might be far too late. To make good (REST) APIs you have to take into account that functional exceptions are at least as important as HTML errors. Functional exceptions need to be discussed and designed with extra care. And functional exceptions are really important when more then 2 interacting parties are involved on the same data set.