“Scale” is an elementary aspect in Architecture.
Yet, it’s completely neglected in Enterprise Architecture, surprisingly … or not !.
EA current practices relates to defining components, and their orchestrations, meant to fulfil or to support identified business activities.
As the activity growths and evolves, so does the landscape of components.
As you’ll need to use a higher scale to view it, there’s a point where the view becomes useless and unmanageable.
Here’s a thing …
“We’ve never seen a 1/200 scale blueprint used to represent bricks !”
Actually, …
A view is relevant because scale relates to the granularity level of the content it shows.
As a matter of facts …
“scale” isn’t just a matter for views.
“shaping” happens at different levels, involving different granularities.
“shaping the overall” integrates the different levels and granularities.
From the viewpoint of current EA practice.
When designing components, current practice mostly determines their relevancy and granularity through their foreseen usage, their involvement in a process.
When considering overall coherence and orchestration, the landscape of components appears too complex and the size of its view appears too big.
This doesn’t really help to achieve operational efficiency or strategic adaptability.
Yet, to deal with that, current practice uses different techniques like “Business-IT” distinction, SOA schemes, APIs patterns, “Composable business” approaches, …
This can be useful because it introduces some modularity aspect.
Let’s go further though !
Actually, “modularity” means that you set criteria to determine decoupling rules and even genericity characteristics of components.
Obviously, criteria are multiple. They can be combined. They apply differently on different sets of components.
Again, for the sake of global coherence, those criteria need to be orchestrated as-well.
So, you might want to consider that defined criteria are represented by higher level components which have higher granularity.
From the detailed to the overall levels, shaping happens at different scales and involves different granularities.
Current practice may invent, use and reuse, methodologies, frameworks, patterns, canvas, …
Yet, it applies to modeling at a detailed level.
Current practice may address an overall coherence by extending the view, going “Enterprise-wide”.
Yet, it remains stuck in its obsessive sights boundaries of “IT’ed Business processes for ROI”.
“Enterprise-wide” doesn’t mean “Enterprise as-a-whole.”
Detailed level modeling (namely “Enterprise Modeling”) is a useful practice, of course.
Though, naming it “Enterprise Architecture” is truly missing the point of Architecture discipline and its benefits.
“Architecting” “the Enterprise”
Architecture (properly, as a discipline) considers the Enterprise as an entity as such (the overall sharing a same purpose).
Architecture assess the purpose of that entity, address its heterogeneity and dynamics.
And when conceiving the built, Architecture starts by defining main axes of shaping which will constitute generic criteria for further and more detailed shaping.
BTW., this is what makes the scheme scalable and adaptable.
“Scale” can help to understand that, actually, Architecture perspective is the opposite of current practice.
“Scale” can be a way for current EA practice to broader the view and evolve.
“Scale matters !”