What Notation for Enterprise Architecture Modeling?
By Eric A. Stephens on Jul 13, 2010
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.