What To Expect From A Framework

Preamble

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.

expoGX
Frames are meant to bring light on artifacts (Y. Levin)

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.

Prerequisite: Measurements

The heterogeneity of metrics is clearly a major impediment to assessment at enterprise level due to the different yardsticks associated with business value, development costs, and processes maturity.

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.

Conclusion

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.

Further Reading

 

Leave a Reply

Discover more from Caminao's Ways

Subscribe now to keep reading and get access to the full archive.

Continue reading