While I generally like the [[CSVLOD]] model as described by [[Svyatoslav Kotusev]] in [[The Process of Enterprise Architecture]], it scopes the entire practice of [[Enterprise Architecture]] as **only** regarding [[IT-Business Alignment]], which I do not agree with. To some extent this is a disagreement over the admittedly "squishy" definition of `Enterprise Architecture`, it seems to me that [[Enterprise Architecture Artifacts]] would be every bit as useful in assuring **business-to-business** alignment - that is, **aligning different divisions** (or other organizational units) **within an enterprise**.[^1] > [!note] Example > A costly business process only exists to enable one business capability, but the enabled capability is _itself_ redundant with capabilities performed elsewhere in the business by other processes. You could easily extend the matrix further: | Communication Path | Rules | Structures | Changes | | -------------------- | -------------- | -------------- | ------------- | | Business-to-Business | Some BS word | Second BS word | Third BS word | | Business-to-IT | Considerations | Visions | Outlines | | IT-to-IT | Standards | Landscapes | Designs | This essentially redefines [[Enterprise Architecture]] as "the wonderful things you can do with diagrams!" which is a _bit_ less sexy? They all play in the same space, though - communication aids. The very same kinds of [[Enterprise Architecture Artifacts|artifacts that EAs make]] would be wildly helpful for any business of sufficient size and complexity to understand *its business*. Put another way, I think [[Archimate]] (just as an example) would be good enough to explain how one business unit's goals can [[Synergize]] with another's. **** # More ## Source - Self ## Related - [[CSVLOD]] [^1]: with some more time spent working in this area, I see this now as even more of an unusual perspective – and even more of a *necessary* consideration.