The Enterprise Architecture Blog covers commentary and insights about Cloud and Enterprise Architecture

What Notation for Enterprise Architecture Modeling?

Guest Author

I've been a huge fan of architecture modeling for over a decade now. I feel there is no better way to get stakeholders on the same page so quickly. It is true what they say...a picture is worth a thousand words (or meetings).

I feel consistent notation is important for consistent interpretation of the "picture". For many years those implementing software-intensive systems have relied on UML to describe their code. I think the consistency and expressiveness of UML is a benefit to the developer but also the stakeholder in gaining understanding.


One long-time colleague and friend had me going down the Google rat hole about 18 months ago. He comes from a DoD hard-core systems background. When I say system I mean they build the hardware, created the machine instructions and the the high-level compilers. When you need to blow stuff up, that is how you roll I suppose. Myself, I was corn-fed on COBOL and business systems whose only explosion was an abend or seg fault at 2:30 in the morning. However, both of us had something in common when it came to enterprise architecture; we needed a consistent way to express what was going on beyond all the silicon-based entities.

Architecture description languages (ADLs) have existed in academia for sometime as well. But these seemed to be focused in the product space where "system" meant specialzed hardware or software (e.g., automobile, helicopter). I wanted something that was simple and extensible. And would cover the unit of architecture I was dealing with - the enterprise. Yes, the enterprise with its mix of people, process, and technology all (hopefully) aligned to meet corporate objectives. And I didn't think straight UML was the way to go.

The nice thing about standards is there are so many to choose from. To date I've been exposed to a couple of modeling notations that would seem suitable for modeling enterprises. The first is ArchiMate that was ratified/certified by TOGAF not too long ago. The other is SysML. I've personally been using SysML for project work and for developing a reference architecture. Its expressive enough to be precise yet I've been successful in using it with non-IT stakeholders. Both modeling languages are derivatives of UML (technically, they are UML 2.0 profiles) so one benefits from any previous UML knowledge when manipulating diagrams.

What sort of approach are you using to document current or future state enterprise architecture? Does a consistent, standardized notation even matter? I would love to hear your thoughts.

Join the discussion

Comments ( 3 )
  • Adrian Campbell Tuesday, July 13, 2010
    I've been using ArchiMate for a number of years quite successfully, and recommend it to all enterprise architects.
  • Ric Phillips Wednesday, July 14, 2010
    Industrial designers and building architects have it over us. They have different ways of modelling that are appropriate to the stages of their programs.
    Concept drawings, elevations, cross sections, building plans, exploded component diagrams. All eloquent modelling tools fit for purpose and easy to understand by the intended audience.
    It's the same with other design disciplines.
    But EA does not have an adequate set of tools for the visual representation of its objects. Archimate and other UML like diagramming tools don't rigorously specify product at the implementation end, but at the conceptual, creative end they fail to tell a compelling story that can be easily and intuitively grasped.
    Only uber-geeks can "read" a complex Archimate diagram. Even those of us who practice in EA have to "decode" them. It takes a lot of time to look through a real-world set of Archimate models and come to an understanding of the enterprise they represent.
    I can absorb town planning and building sketches in a few minutes.
    In another domain. I can comprehend the complete vision for a movie from a half hour read of the story board.
    As you pointed out existing tools are 'ontologically colonised' Archimate already decides what a service or a product is in your model. Maybe your organisation uses their ontology maybe they don't. In the latter you have to go around stipulating. Not a good look for a role that is supposed to be about communicating knowledge.
    I am starting to come to the conclusion that EA can't progress past it's current challenges until some practitioners start to evolve exactly what you are calling for, a simple, elegant, and extendible language that communicates the way pictures do - by packing a lot of accurate understanding into a few minutes of intelligent attention.
  • Adrian Campbell Saturday, July 17, 2010
    You say that ArchiMate is not rigorous enough but also that it's too complex to read and decode??
    Am I the only one who thinks this is doublethink?
    Once you fully learn any modelling approach, such as ArchiMate, SysML, BPMN or UML, properly then it becomes easier to understand and to rapidly grasp the meaning of the diagrams produced with it.
    ArchiMate was deliberately designed not to be as rigorous as UML especially to help make it easy to understand at the strategic planning level, and is in my opinion simple, elegant and extensible.
    The stakeholders of Enterprise Architects are not usually looking for the excruciating implementation details in an EA model, but just want to understand the overall context and concepts in order to make the right decisions about business and IS/IT strategy and strategic planning.
    For this purpose, the book 'Enterprise Architecture as Strategy' describes the creation of a single 'Core diagram' to illustrate the essence of the Enterprise Architecture at a glance, on a single page. I frequently use Archimate to produce such 'Core diagrams'. My C-level stakeholders have no problem reading these diagrams and they are certainly not 'uber-geeks'.
    Anyway, I suggest that instead of hoping for 'some practitioners start to evolve exactly what you are calling for, a simple, elegant, and extendible language', why don't you evolve your own and show us all how it should be done?
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.