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 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 functionalities, 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.
Whatever architectures and technologies, system components can be organized into three tiers or levels:
- 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 (entities).
Messages and services can be added to fully describe functional and technical architectures of systems.
Systems & Domains
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.
Functional vs Technical
As should be expected for architecture driven modelling, a clear understanding of core architectural requirements, functional as well as technical, is a prerequisite.
Functional requirements describe how the system should support business processes:
- 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.
Non functional (including technical) requirements deal with whatever requirements not directly bound to specific business needs, namely:
- Their realization is not directly observable by users, eg encryption.
- Their impact is felt across applications, eg confidentiality or performance.
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, ie 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.
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.
Domain vs Functional Architecture
At this point it must be reminded that binding and distribution constraints are defined by business requirements, independently of the technical solutions used to support them. From there, the role of domain architecture is to identify core business objects and processes together with their associated constraints.
Since, as noted above, architectures must guarantee stability yet support versatility, domain 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.
Whereas technical architectures will deal with the resources and mechanisms supporting IT solutions, domain architectures will consider the structure and consistency of symbolic representations together with their access and processing rules. When combined with domain specific language (DSL), domain architectures may be used to build executable models, from which programs can be generated.
As opposed to domain specific architectures, Architecture Driven System Modelling takes a broader perspective by focusing on persistency and execution units and ignoring whatever features or behaviors without architectural footprint. That so-called functional architecture is meant to be shared by different and changing businesses on a long-term perspective and may not provide complete and detailed descriptions of business objects and processes. On the contrary, it will usually be made of abstract representations and generic procedures to be fleshed out by actual business processes.
Enterprises are meant to be viable organizations; hence, the first goal of enterprise architecture is to support their continuity in their regulatory and business environments, their identity being defined by the former, their behavior being conditioned by the latter. Considering that identities as well as businesses can be mixed, congruence of enterprise and system architectures may be critical as an antidote to entropy based on a consistent management of symbolic representations. For that purpose architecture blueprints are to be set against the two basic organizational criteria, namely management and rules:
- Management comes with responsibility: only human beings are meant to take decisions because electronic agents cannot be held accountable for the automated choices they may make.
- Rules comes with symbolic representation: since organizations can only be defined by words, a clear cut distinction is required between symbolic and non symbolic processing.
Due to IT ubiquity, the lines between business organizations and supporting systems are already mostly symbolic; unfortunately, technical constraints and legacy systems are still there, causing a significant drag on the enterprise ability to exploit market opportunities as may arise from changing business environments.
Then, the objective should be to identify the core system components supporting the continuity of corporate identity, the stability of its internal environment (aka homeostasis), and the effectiveness of its core competences.
- Clearly, that backbone would include whatever is needed to integrate the different applications across business domains and units.
- Next one would find the different functionalities of governance systems: analytics, audit, regulatory compliance, etc.
- Finally, one should also take into account the contribution of IT systems to the value of intangible assets like goodwill, brands, and collective identification to the organization.
As should be expected, and contrary to functional architectures, such a backbone cannot be grounded on well defined units. It belongs to the realm of corporate governance and strategic planning.
EA/IT Demarcation Lines: Non Deterministic and Non Functional
Whereas enterprise and systems architectures clearly overlap, edges should always be clearly defined regarding symbolic and actual behaviors.
As far as organizations are concerned, systems cannot be held responsible for their actions. As a consequence, rules governing their behavior must be deterministic: given a system state, the same event will always produce the same outcome. And as a corollary, non deterministic rules indicate the demarcation line between enterprise and systems architectures, namely where multiple outcomes can only be decided by agents with responsibility.
While systems functionalities are symbolic, they are meant to support actual processes as executed by enterprises. The distinction between contents (what) and operational constraints (how) is often associated with non functional requirements (aka quality of services). Those requirements should be expressed independently of symbolic contents and mark the actual limit between enterprise and system architectures.