“The little reed, bending to the force of the wind, soon stood upright again when the storm had passed over”
The consequences of digital environments go well beyond a simple adjustment of business processes and call for an in-depth transformation of enterprise architectures.
To begin with, the generalization of digital environments bears out the Symbolic System modeling paradigm: to stay competitive, enterprises have to manage a relevant, accurate, and up-to-date symbolic representation of their business context and concerns.
With regard to architectures, it means a seamless integration of systems and knowledge architectures.
With regard to processes it means a built-in ability to learn from environments and act accordingly.
Such requirements for resilience and adaptability in unsettled environments are characteristic of the Pagoda architecture blueprint.
As can be observed wherever high buildings are being erected on shaking grounds, Pagoda-like architectures set successive layers around a central pillar providing intrinsic strength and resilience to external upsets while allowing the floors to move with the whole or be modified independently. Applied to enterprise architectures in digital environments, that blueprint can be much more than metaphoric.
The actual relevance of the pagoda blueprint is best understood when the main of data, information, and knowledge is set across platforms, systems, and organization layers:
That blueprint puts a new light on model based approaches to systems engineering (MBSE):
- Conceptual models, targeting enterprises organization and business independently of supporting systems.
- Logical models, targeting the symbolic objects managed by supporting systems as surrogates of business objects and activities.
- Physical models, targeting the actual implementation of symbolic surrogates as binary objects.
Pagoda Blueprint & Digital Environments
The Pagoda blueprint gets a new relevance in the context of digital transformation.
Moreover, the blueprint is not limited to enterprise architectures and can be applied to every kind of systems:
- Devices associated to physical platforms supporting analog communication through the Internet of Things (a).
- Equipements associated to physical platforms controlled by systems, supporting digital communication (b) and functional alignment (c) .
That would greatly enhance the traceability and transparency of transformations induced by the immersion of enterprises in digital environments.
Systems & Knowledge Architectures
If digitized business flows are to pervade enterprise systems and feed business intelligence (BI), systems and knowledge architectures are to be merged into a single nervous system as materialized by the Pagoda central pillar:
- Ubiquitous, massive, and unrelenting digitized business flows cannot be dealt with lest a clear distinction is maintained between raw data acquired across platforms, and the information (previously data) models which ensure the continuity and consistency of systems. .
- Once structured and refined, business data flows must be blended with information models sustaining systems functionalities.
- A comprehensive and business driven integration of organization and knowledge could then support strategic and operational decision-making at enterprise level.
Rounding off this nervous system with a brain, ontologies would provide the conceptual frame for models representing enterprises and their environments.
Agile Architectures & Homeostasis
Homeostasis is the ability of a viable organism to learn from their environment and adapt their behavior and structures according to changes.
As such homeostasis can be understood as the extension of enterprise agility set in digital environments, ensuring:
- Integrated decision-making processes across concerns (business, systems, platforms), and time-frames (tactical, operational, strategic, … ).
- Integrated information processing, from data-mining to knowledge management.
To that end, changes should be differentiated with regard to source (business or technology environment, organization, systems) and flows (data, information, knowledge); that would be achieved with a pagoda blueprint.
Threads of operational and strategic decision-making processes could then be weaved together, combining OODA loops at process level and economic intelligence at enterprise level.
- Modeling Paradigm
- Views, Models, & Architectures
- Abstraction Based Systems Engineering
- EA & MDA
- EA: The Matter of Layers
- EA: Maps & Territories
- EA: Work Units & Workflows
- Ontologies & Enterprise Architecture
- Ontologies as Productive Assets
- Models Transformation & Agile Development
- Agile Architectures: Versatility meets Plasticity
10 thoughts on “EA & The Pagoda Blueprint”
>> My solution is a set of 4 workshops crisscrossing architecture layers.
I understand the diagram labelled ‘Work units can be defined directly with regard to architecture’ at the link you give best summarizes what you mean.
Assuming so, in ‘*Engineering* is orthogonal to *architecture*,’ please clarify where (i) Engineering and (ii) Architecture appear on that diagram (or on some other diagram at that link) .
>> I could give you a link to a preliminary version of the article if you’re interested
Yes. Please do.
Next step … My idea: I began looking for a double (side of by side) layered model. One side models the system, and the other side models the project/product management.
Then I came across your pagoda blueprint. So what the world needs is a *double pagoda* model – two pagodas, side by side. One pagoda to model the system (you call this enterprise?), and the other pagoda to model the project/product management.
Question 2: What do you say on the ‘double pagoda’ idea? Is this what you mean by the ‘Business Intelligence and Decision-Making’ diagram on this page?
Fixed to the first part of the question:
Written: “I have now been presented with two further modeling requirements:”
Should be: “I have now been presented with two further modeling tasks:”
Engineering is orthogonal to architecture so the second half is not parallel. My solution is a set of 4 workshops crisscrossing architecture layers.
You will find the principle in the following article but the detailed and complete model is still a work in progress
I could give you a link to a preliminary version of the article if you’re interested
Hi Mr. Caminao,
Thank you so much for answering me.
And maybe this page and the link you sent me answers a question for which I have been looking for an answer, and maybe you can relieve some confusion…
I have just completed modeling the top-level *design* of our company’s product to a basic functional level. (Background: Our product is a very large and complex mission-critical embedded system.) Our company has now defined an additional layer of ‘features’ for customer systems to access at a higher level. I have now been presented with two further modeling requirements:
(i) To continue to model the system, now with its additional layer of ‘features’.
(ii) To model the company project/product management organization.
I have been through dozens of articles and papers in the last few days and I think I see two different (and contradictory?) meanings for the term *’business layer’*. One meaning: ‘business layer’ is the highest level of the company’s product, as I described above. Second meaning – totally different: ‘business layer’ is the project/product management – and the authors added it on top of the product system layers. This second meaning does not make much sense to me.
Question 1: What do you say on the above 2nd meaning? (I.e., ‘business layer’ is the project/product management layer)
Never heard about one.
Is there a Pagoda design pattern in BPMN?