Preamble
Systems are made of three categories of components defined with regard to their capability to act and communicate:
- Users (supposedly human beings) come with social identity and may consequently be granted with organizational status and responsibilities. They are able to communicate using symbolic languages.
- Software systems have no social identity and therefore cannot be granted with organizational status or responsibilities; like users they do possess symbolic communication capabilities.
- Actual devices have no social identity and cannot be granted with organizational status or responsibilities; and they do not possess symbolic communication capabilities.
Architectures are meant to organize components and functions according to these capabilities.
Scope
Architectures are about continuity in space and time. They provide resources and mechanisms meant to support activities which, by nature, must be adaptable to changing concerns and objectives.
Regarding enterprise, architectures should be organized according to the nature of problems and solutions:
- Enterprise architecture deals with objectives, assets and organization associated with the continuity of corporate identity and business capabilities within a regulatory and market environment.
- Functional architecture deals with the continuity of systems functionalities supporting business processes.
- Technical architecture (platforms) deals with the feasibility, efficiency and economics of systems operations.
Our main concern here is with system architectures, namely how a system sees its environment, how it interacts with it, how the states of agents and things are represented, and how those representations can be used.
Views & Layers
Systems are the part of enterprise architecture in charge of processing symbolic surrogates. Beyond various terminologies, systems can be described in terms of four basic views:
- Infrastructure: resources (entry points, processing, storage, communication, etc) in contexts.
- Processes: role of supporting systems with regard to organization.
- Business activities: logic of activities as implemented by applications.
- Business objects: information structure and semantics.
These views can also be used to define architectures:
- Technical architecture (infrastructure) deals with the actual role of systems (context and processes).
- Software architecture deals with the symbolic representation of business objects and activities.
- In between the functional architecture deal with the relationship between actual contexts and processes and their symbolic counterpart.
Functional Architecture
Functional architecture describe the system behavior with regard to actual business context and processes independently of specific business contents:
- Persistency: information to be recorded and integrity constraints.
- Processing: activities to be performed and business rules governing them.
- Interactions: communication between external agents and systems.
- Communication: : communication between system components.
These categories are meant to be associated to dedicated components:
- Components with local execution and transient life-cycle (aka boundaries).
- Components with shared execution and transient life-cycle (aka controls).
- Components with shared execution and persistent life-cycle (aka entities).
Messages and services can be added to fully describe the basic layers (aka tiers) of functional and technical architectures.
As for system functionalities, an additional dimension is to be included for domain architectures: whereas system architecture targets the resources and mechanisms available to the different applications independently of their business meanings, domains architecture is meant to deal with the business semantics of system components and behaviors.
Based upon widely accepted functional stereotypes, domains archetypes can be mapped to system functionalities:
Whatever the perspective, both functional and domain architectures can be characterized by stability and versatility:
- Stability: architectural features cannot be changed without affecting main functionalities.
- Versatility: architectural features are meant to be used irrespective of domains or applications.
Yet, there is a difference as a part of domains architecture (aka Master Data) belongs to enterprise architecture because it supports the continuity of corporate activities within their business environment.
System, Context, and Bonds
First and foremost one need to decide what is represented and how tight should be the bind between business objects and their representation.
- At rock bottom, context and system are completely separated, i.e representations are processed independently of what may happen at business level (batch processing).
- Standard information systems support some overlapping, which means that some processing is simultaneously executed at business and system level (transactional processing).
- Control systems are more demanding and usually need full overlapping, meaning that whatever happens at business level must be simultaneously taken into account by system representations (real-time processing).
- Finally, one finds embedded systems which are real time ones whose symbolic representations are incorporated into active objects and cannot be accessed directly.
Distributed Systems
Next, one have to consider whether the relationship between context and system is to be managed locally or not:
- Standalone systems can be run under a single hierarchy, ie processes can be synchronized by a single clock and resources managed within a single address space.
- Distributed systems involve the collaboration of independent processes, each running under its own clock and accessing resources managed independently.
Clearly there will be critical arbitrage to be made between context coupling on one hand, and systems distribution on the other hand. Those arbitrage, and the resultant technical architectures, will directly impact upon functional architectures. For instance, a tier-to-tier architecture will put collaborations under a single authority, whereas a peer-to-peer architecture will let execution units communicate directly.
Enterprise & Systems
Enterprises are meant to be viable organizations; on that account, the primary objective of their architecture is to support the continuity of their identities and behaviors with regard to regulatory and business environments. As it’s safe to assume a number of cross-dependencies, the congruence between enterprise organization and system architectures should be a primary concern. All the more so with the generalization of digital environments and the tumbling down of the traditional gates.
With regard to business domains, the role of architecture is to identify core business objects and processes together with their associated constraints. In order to ensure stability while supporting versatility, domains architecture should define:
- The identity and semantics of business objects whose persistency and consistency are to be maintained in order to support the continuity of business activities independently of changing opportunities.
- The business procedures supporting the continuity of corporate identities within their contractual & regulatory contexts, independently of targeted business domains.
With regard to organization, for immersed enterprises to maintain their identity and integrity, architectures have to be aligned with responsibilities and symbolic representations:
- Responsibilities: the fusing of software components with the flows of products and services calls in return for built-in walls around human decision-making: whatever their intelligence, electronic agents cannot be held accountable.
- Symbolic representations: walls and more generally structures have to be symbolic or to be dissolved under digital flows. Hence the need to align systems architectures with data, information, and knowledge.
The weaving of architecture layers and symbolic representations (data/information/knowledge) is best illustrated by the Pagoda blueprint, itself derived from the Zachman framework.
