Preamble
Deciding upon a framework is a choice that bears upon a wide range of enterprise activities and may induce profound transformations in organization and systems. It ensues that the outcome is practically settled at the outset: once on a wrong path the only option is often to cut the losses as soon as possible.
As it happens, there is no reason to hurry and every reason to take the time before opting for a long-term and comprehensive commitment.
Taking simple litmus tests can be used to avert overhasty moves into quagmires. Compared to a comprehensive assessment, the objective would only be to establish a shortlist of frameworks worth of a further assessment. For that purpose forms (but not substance) are to be considered for the consistency of definitions, the specificity of value propositions, and the reliability of roadmaps.
Consistency of Definitions
Frameworks come with glossaries covering generic, specific, and standard terms in various proportions; the soundness of these glossaries can be assessed independently of their meanings.
For that purpose simple metrics can be applied to a sample of definitions of core concepts, (e.g: agent, role, actor, event, object, activity, process, device, system, architecture, enterprise):
- Self-contained: terms directly and fully defined, i.e without referring to other glossary terms (c,a,m).
- Number of references used.
- Circular references: terms including at least one path to itself (d,e,f)
- Average length of non-circular references
- Overlaps (i and j)
- Conflicts (w by (x><e)
Even computed on small samples (10 to 50), these metrics should be enough to provide a sound yardstick.
Value Proposition Specifics
Pledges about meeting stakeholder needs, holistic undertaking, or enhanced agility are part and parcel of every pitch; but as declarations of intent they give little information about frameworks.
To be given consideration a framework should also be specific about its value proposition, in particular with regard to its description of enterprise architecture and systems engineering processes.
Assuming that the specificity of a value proposition equals the likelihood of a contrary stance (no framework would purport ignoring business needs or being non agile), general commitments must be supported by schemes meant to make a difference.
Roadmap Reliability
Given what is at stake, adopting a framework should only be considered if it can significantly reduce uncertainty. On that account road-maps built from pre-defined activities are deceptive as they rely on the implicit assumption that things will always be as they are meant to be. So, taking for granted that positive outcomes can never be guaranteed independently of circumstances, a framework reliability is to be assessed through its governance apparatus.
Along that reasoning, key stages, steps, or activities defined by a roadmap should be framed into a clear decision-making processes, e.g the observation, orientation, decision, action (OODA) loop.
A framework reliability could then be judged by its ability to support enterprise architects in assessing situations and picking a course of action.
Further Reading
- What to Expect from a Framework
- 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
- Ontologies & Enterprise Architecture
- EA Frameworks: Non Negotiable Features
- Enterprise Governance & Knowledge
- Squaring EA Governance
- EA Documentation: Taking Words for Systems
- Governance, Regulations & Risks