“Scale” in Enterprise Architecture

“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/500 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.

So far, current practice is stuck in modeling at a detailed level.
It address the overall coherence by extending the view, going “Enterprise-wide”.

But, …

Enterprise-wide doesn’t mean Enterprise as-a-whole.

Current practice may invent, use and reuse, methodologies, frameworks, patterns, canvas, …
Yet, it will be stuck in its sights boundaries of obsessed “IT’ed Business process for ROI”.

“Scale” can be a way for current practice to broader the view and evolve.
But is it the purpose ?

Detailed level modeling is a useful practice, of course.

Naming it “Enterprise Architecture” means that “architecture” is poorly a synonym of “structure”, and “Enterprise” is just a simple adjective, meaning “enterprise-wide” at most.

This 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, integrates 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.


So much more can be talked about.

“Scale” can help current EA practice to evolve,
“Scale” can help to understand that, actually, Architecture perspective is the opposite of current practice,
“Scale” can help to understand how current EA practice and Architecture can be related,

Anyway,

“Scale matters !”