I am assigned a task in the job to draw a enterprise architecture diagram. We have stack of applications and they talk to each other. For example, Customer fill up the registration form from main site then it goes to one of our main applications to approve then once it is approved then customer can able to log in to portal. The portal is actually a REST api on back-end.
How can I express this in a diagram? What type of diagram it could be? Should it really call enterprise architecture diagram? Does it fall to any category?What type of UML notation I can use if any?
Thanks a lot in advance
There is no such thing as an "Enterprise Architecture Diagram"
"Enterprise Architecture" is software design and process at an enterprise level. Instead of working with class diagrams, you are working with full applications. The best standard as of Jan 2017 of Enterprise Architecture is Togaf 9 (or Zachman).
The list of diagrams that an Enterprise Architect would typically produce are here:
http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html
34.3.2 Core Architecture Artifacts
Sounds like you want an Application Communication Diagram.
I would read the above links, but be mindful that this is high level guidance.
Then think about what message you want to relay, for example, do you want your boss to approve the flow? Do you want to tell the users how the system works? Are you the architect and supplied the developers with a schematic? WHY are you creating this diagram?
Then, when you understand what you are trying to achieve, it should be obvious what diagrams to produce. In this situation I would probably produce two diagrams:
A diagram showing the physical parts of the system, UI, main applications, tomcat/apache server, database. I would probably do this from top to bottom and isolate the tiers, UI at the top (presentation), then business logic, then datastore at the bottom. Alternatively, left to right would work.
A diagram showing the "registration form" process. I would probably structure this as an event trace diagram or sequence diagram (UML) showing the lifelines (UI, app, db) and show the sequence of events, 1. fill in form, 2. security, 3. persist, 4. return. (The "registration form" process would ideally have been lifted from a use case diagram)
If this is one diagram of many then then second diagram could show other flows, such as "update user details" or "failure scenarios".
However if this is a short one off exercise then you could overlay the behaviour on top of diagram. There's no official name for a combined diagram like that but it sometimes helps get the message across.