Frames are meant to bring light on artifacts, not to cover them with veils; on that account, frameworks’ primary justification should be their leverage on engineering practices.
It ensues that enterprises frameworks should only be considered in relation to actual contents (organization, artifacts, processes, …), and their benefits for core governance issues, in particular measurements, processes integration, and economic intelligence.
The least frameworks should do for enterprise architects is to provide common bearings at both application and enterprise levels:
- Application level: a consolidated scale for the mapping of value points, function points, and development costs.
- Enterprise level: a common basis for a reliable assessment of systems capabilities and processes maturity.
A detailed account of how a framework would support such bearings should therefore be a prerequisite.
Cornerstone: Business & Engineering Processes Integration
Except for the Zachman framework, providers haven’t much to say about how actual business and engineering processes are to be hung to the proposed framework, and more generally about the continuity with existing methods, tools, and practices.
Conversely, being specific about the hinges linking it to processes is to give credence to a framework leveraging impact:
- Business: leveraged agility from the harnessing of users’ stories to business functions.
- Engineering: leveraged transparency, traceability and reuse from model based systems engineering (MBSE).
As the cornerstone of any enterprise framework, integration is to support their ultimate purpose, namely economic intelligence.
Deal Breaker: Economic Intelligence
Economic intelligence is usually understood as a merge of data analytics, information architecture, business intelligence, and decision-making; as such it can be seen as a primary justification for enterprise architecture frameworks.
As a corollary, one would expect frameworks to be specific with regard to the integration of data analytics, information processing, and knowledge management:
- To begin with, no framework should be considered without being explicit about the ways such integration could be achieved.
- Then, integration schemes should aim at being neutral with regard to engineering or support environments deployed at architecture level.
When options are considered, that should be taken as a deal breaker.
Assuming that expectations about measurements and processes could be reasonably borne out, decisions would rest on economic intelligence strategies.
Depending on the weight of information systems legacy, full neutrality may deem a too ambitious strategy. In that case an enterprise architecture framework could be built bottom up from MBSE environments.
Given that proviso, a neutral framework designed on purpose would bring much more leverage due to the generalization of well-defined slots and interfaces for business and engineering platforms; that would also facilitate modernization and consolidate quality assurance across enterprise architectures.
Finally, for EA frameworks to ensure consistent metrics, processes integration, and economic intelligence, knowledge management must encompass a wide range of concerns (business, engineering, regulations, …), contexts (environments, enterprise, systems), and resources (texts, models, people, …); that can be best achieved with profiled ontologies.
- Thread: Enterprise Architecture
- Enterprise Architectures & Separation of Concerns
- Where to Begin with EA
- EA: The Matter of Layers
- EA: Maps & Territories
- EA: Work Units & Workflows
- EA: Legacy & Latency
- Focus: Enterprise Architect Booklet
- Ontologies & Enterprise Architecture
- Caminao & DoDAF
- EA Frameworks: Non Negotiable Features
- Caminao & EACOE
- Enterprise Governance & Knowledge
- Squaring EA Governance
- GDPR Ontological Primer
- Focus: Enterprise Architect Booklet
- EA Documentation: Taking Words for Systems
- Governance, Regulations & Risks