Someone asked me to show a type of diagram I’ve been using to quickly assess the architecture for a solution. The following diagram is one I’ve been using and it seems to work for me. However, let me make a few qualifications on this diagram and its use. The diagram can be found at the end of this post.
- My primary use of this diagram has been where I’m diagramming a proposed solution for procurement of SaaS. Because of this, I needed a diagram to quickly map the following:
- Functions of the SaaS
- Actors and/or roles using the functionality
- Logical data entities accessed by the functionality
- While gathering this information from the business line, I’d then derive the following:
- The interface between actors and the functionality
- I’ve kept functionality at a business level although I believe you could capture functionality at an application level. However, since I’m using this diagram as an initial capture of dependencies, I’ve kept it high level and focused on business processes.
- I’ve used Archimate as the notation because I’m integrating this information into a larger model of the enterprise.
- I’ve used ‘location’ in a somewhat unorthodox (but acceptable) manner. Location is not referring to a specific geographic location but more of a logical location (e.g., vendor site, satellite office, etc.) If I were to be more consistent, I’d assign all actors to locations, but I usually don’t need to in the analysis I’ve done.
I use this as a solution concept diagram with the idea of then building out supporting diagrams for these components. So what does this diagram give me?
- An easy to follow diagram whereby the business line can tell me that I’ve covered essential functionality of the solution or service.
- An easy way to identify key interfaces that the solution would require.
- Location allows me to segregate solutions.
- An easy way to capture and communicate data security level classification needs of the solution to our security team (at least as a first pass).
If I need to go into more detail on the mapping of the dependencies, this diagram still provides a launching point for this. The supporting diagrams I’d create would be the applications and systems that the business processes use. They could also show the applications or systems that are required to instantiate the interfaces.
So, in conclusion, this diagram would be advantageous if you needed to quickly do a number of surveys of business lines to capture what business functions solutions meet, the actors, and the basics on how interaction occurs. That would set the boundaries of what further detail needs to be mapped out.
This is a work in progress, so I’m always eager to hear any general constructive criticism on how this approach might be improved or how useful you might find it. Just keep in mind the context in which I’m using it.
One of the things I like about Archimate is how it can prompt you on better ways to represent the work you’re doing. I’ve left the original diagram I created (warts and all) so you can see how my thoughts changed. What I disliked about the original diagram is that it left me saying that many of the business functions of the facility mgmt. group were located at the vendor’s location. This didn’t sound right. So the second diagram now represents a better picture of what’s going on. The vendor’s location is where we find an application component that has application functionality associated with it. This functionality would probably realize an application service that is used in a business process, but I’m not focused on that relationship for this diagram. Right now I’m just concerned with who is using this functionality and how. (In fact, the way I had the old diagram would have done the job I had for it…..being a sheet of paper I could use to discuss what the business lines are using and why, but still the new diagram will be useful in a larger context.
So this is the old diagram:
And this is the new diagram (also including some clean up on roles and actors.