How do I decompose a big company? One diagram or multiple diagrams?

Started by NicoLoubser, August 21, 2017, 17:47:16 PM

Previous topic - Next topic


Hi everyone. I apologise if this is the wrong forum, but I decided to post my questions here as it seems to be the best place. Corrections welcome.

I am a software architect/developer doing post grad studies and enterprise architecture is on of my subjects, we use archi as a modeling tool. Our tutoring in this subject is not going as I hoped it would, hence me reaching out to other sources. I am also very confused at the moment so anyone with knowledge may pick up on that.

(I am modelling the company I work for as exercise)

I am a bit confused as to how to represent the business concept in a model(where a  model is a diagram). Here is my issue. I created my technology layer, and from there created my services layer. Now the business layer in general is quite vast. Much more so than the technology layer or even the services layer. Do I aim to get it all into on diagram? If I do two diagrams, then I need to duplicate the technology layer and parts of the services layer which I don't want to do. My stakeholder viewpoints may also span two or three diagrams then which may be a problem.

Is it one model per diagram?

Maybe the problem is in my thinking. I have a strong UML background so maybe my approach is to UML-like?

An issue is all of our examples are to simple. It is always one server with one business model and one service. But in reality, if you are working in a big enough company, it will be massive. Nowhere can I find easy to follow data on how to deconstruct a huge company into a diagram or diagrams.

Thank you, I hope I was clear in my explanation. This subject is very complex.

Nico Loubser

Jean-Baptiste Sarrodie


Welcome in the world of Enterprise Architecture modelling ;-)

The answer is that you have to decompose your subject into several diagrams (that we call views). Some may be on the same topic or with the same intent (that we call viewpoints). All those views will be into the same and unique model, and if a concept has to be present on several views, it will be the same that you will reuse (drag'n drop from model tree to the view in Archi).

If you really want to understand, learn and practice ArchiMate in a short amount of time, I would recommend you to buy and read the excellent book "Mastering ArchiMate" from Gerben Wierda. The current (second) edition is about ArchiMate 2.1, but a new edition about ArchiMate 3.0 will be publish very soon. If you are in a hurry, contact Gerben ( to ask if you can buy the 2d edition now (in PDF) and receive the updated version for free when it will be available (should be in september).


If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Chris Usher

Hi Nico,

I believe many people will have asked themselves the same questions you are asking, I certainly did.

Some quick hints:

  • Think who the audience will be, create different views for each audience.
  • There is no right or wrong way - use Archimate to suit your needs and if you are aiming to work with others in your organisation who also use Archimate it may be best to spend time understanding their interpretation, principles and workflow.
  • Buy a copy of "Mastering Archimate" by Gerben Weirda.  It seems expensive, but it is the best reference I have.  I found it well written and thorough.  It does not pretend to by the single definitive method of working with Archimate, yet seems to get the best out of the language by leveraging its power and working elegantly around some shortcomings of Archimate 2.  I eagerly await an update for Archimate 3.

When modelling an entire Enterprise it becomes apparent very quickly that complexity lies everywhere and the task that you thought achievable on one page soon runs into 10's or 100's of views.  It is possible to create a very simple overview of your enterprise in one view, however that view is likely to show business domains or departments and the high level services they provide rather than technology or application layers.

You will likely have a priority to model part of the business vertically e.g. Marketing/Sales and all their roles, processes, applications and hardware, or horizontally e.g. the entire technology layer to cover a CMDB.  It is fine to do either, but try to keep it simple and avoid modelling in too much detail at first.

For example, I attempted to model all steps of a single process, all applications and data read or written by each person in that process, before realising that the business process crossed several business domains applications and networks.  I would have been better served by identifying which business services were provided by the process and which applications it consumed.  This way the view would only contain two layers and the interaction between them.  I would then create other views for each application to show which technology services they consumed.

If you try to show too many elements in one view it becomes unreadable with too many relationships.  Remember to think who the audience is.  Nested block diagrams are good for showing groupings of services by domain when the audience is a group of executives considering rationalisation of services.  However, a network engineer will want to see detail - IP addresses, port numbers, how load balancing and resilience is achieved.  The two views may appear radically different.

Start at one place in your enterprise that you know well and build outwards - horizontally or vertically through the layers as appropriate.  Stop when you have collated just enough detail that you need. Also, accept that the model may never be fully complete and will show detail only on views where it is needed.

I spent 4 months solid last year and only scratched the surface of my enterprise, you may have a cleaner and simpler operating model and make better progress.

These are just my thoughts.  Good luck!


Thanks for the help guys! It is slowly starting to make more sense to me! I really like the topic of enterprise architecture as it also forces me to think differently about the company I work for.


The best advice I've received: "All models are wrong. Some are useful."  :)


Quote from: cvenable on October 06, 2017, 23:26:04 PM
The best advice I've received: "All models are wrong. Some are useful."  :)

;D  I will keep this in mind when I get my marks back!