Preamble
Enterprise architecture being a nascent discipline, its boundaries and categories of concerns are still in the making. Yet, as blurs on pivotal concepts are bound to jeopardize further advances, clarification is called upon for the concept of “capability”, whose meaning seems to dither somewhere between architecture, function and process.
Hence the benefits of applying definition guidelines to characterize capability with regard to context (architectures) and purpose (alignment between architectures and processes).
Context: Capability & Architecture
Assuming that a capability describes what can be done with a resource, applying the term to architectures would implicitly make them a mix of assets and mechanisms meant to support processes. As a corollary, such understanding would entail a clear distinction between architectures on one hand and supported processes on the other hand; that would, by the way, make an oxymoron of the expression “process architecture”.
On that basis, capabilities could be originally defined independently of business specificity, yet necessarily with regard to architecture context:
- Business capabilities: what can be achieved given assets (technical, financial, human), organization, and information structures.
- Systems capabilities: what kind of processes can be supported by systems functionalities.
- Platforms capabilities: what kind of functionalities can be implemented.
Taking a leaf from the Zachman framework, five core capabilities can be identified cutting across those architecture contexts:
- Who: authentication and authorization for agents (human or otherwise) and roles dealing with the enterprise, using system functionalities, or connecting through physical entry points.
- What: structure and semantics of business objects, symbolic representations, and physical records.
- How: organization and versatility of business rules.
- Where: physical location of organizational units, processing units, and physical entry points.
- When: synchronization of process execution with regard to external events.
Being set with regard to architecture levels, those capabilities are inherently holistic and can only pertain to the enterprise as a whole, e.g for bench-marking. Yet that is not enough if the aim is to assess architectures capabilities with regard to supported processes.
Purpose: Capability vs Process
Given that capabilities describe architectural features, they can be defined independently of processes. Pushing the reasoning to its limit, one could, as illustrated by the table above, figure a capability without even the possibility of a process. Nonetheless, as the purpose of capabilities is to align supporting architectures and supported processes, processes must indeed be introduced, and the relationship addressed and assessed.
First of all, it’s important to note that trying to establish a direct mapping between capabilities and processes will be self-defeating as it would fly in the face of architecture understood as a shared construct of assets and mechanisms. Rather, the mapping of processes to architectures is best understood with regard to architecture level: traceable between requirements and applications, designed at system level, holistic at enterprise level.
Assuming a service oriented architecture, capabilities would be used to align enterprise and system architectures with their process counterparts:
- Holistic capabilities will be aligned with business objectives set at enterprise level.
- Services will be aligned with business functions and designed with regard to holistic capabilities.
Moreover, with or without service oriented architectures, that approach could still be used to map functional and non functional requirements to architectures capabilities.
The alignment of non-functional requirements with architectures capabilities can be seen as a key factor for enterprise architectures as it draws the line between what can be owned and managed by business units and what must be shared at enterprise level. It must also be noted that non-functional requirements should not be seen as a one-fits-all category but be defined by the footprint of business requirements on technical architecture.
Further Readings
- Architecture Capabilities
- Alignment for Dummies
- Alignment: from Empathy to Abstraction
- Requirements & Architecture Capabilities
- From Process to Services
External Links
- Sowa John F., John A. Zachman, “Extending and formalizing the framework for information systems architecture”