Book Pick: Metrics & Complexity

Requirements stem from partial & biased expectations
Excerpt from Enterprise Architecture Fundamentals:

***

Measurements are not facts but observations defined by perspectives and purposes; consequently, they are contingent on the conceptual and technical apparatus used to get them. At the system level, three basic dimensions should be considered for measurement:

  • the business value of new applications,
  • the size and complexity of the functionalities to be supported by systems, and
  • the development work effort.

On the one hand, business value, whether assessed locally by business units or in light of broader objectives set at the enterprise level, is the preserve of business stakeholders. On the other hand, estimations of development costs are the preserve of systems architects and software engineers. In between, enterprise architects should lay the groundwork for consensual decision-making, balancing business value, functional scope, and development costs. For that purpose, both parties must agree on a double gauge: first, for the intrinsic size and complexity of the business issues and, second, for the expected contribution of supporting systems. Descriptive (or Computation independent) models are well suited for the former aspect, whereas prescriptive (or Platform independent) models incorporate both aspects — although the specific contribution of systems can be factored out given the intrinsic size and complexity of the business aspect (figure 11-5).

Based on our modeling paradigm (cf. chapter 2), descriptive models can be as- sessed with regard to:

  • Organizational complexity: estimated by the dependencies between enterprise capabilities (figure 11-5a)
  • Domain complexity: estimated by the number of business objects, aspects, and partitions (figure 11-5b)
  • Process complexity, due to business logic: estimated by the number of sym- bolic boundaries (roles), functional execution units, and functional variants (figure 11-5c)
  • Process complexity, due to the control of execution: estimated by the number of synchronized boundaries (events), synchronized execution units, and synchro- nization variants (figure 11-5d)
Figure 11-5. Requirements Metrics

As pointed out in chapter 3, prescriptive models represent IT artifacts, in contrast to descriptive models, which represent business environment and processes. While there is no reason to assume that systems should mimic environments, the representations of anchors in both representations must be aligned, which means that corresponding prescriptive metrics can be directly derived from (but not equated with) descriptive ones. For prescriptive models as a whole, the difference stems from anchors’ constraints (#), additional business objects, execution units, and aspects introduced at the system level. Adjusted prescriptive models could then serve as a basis for the assessment of the development work effort, taking into account targeted and engineering environments.

These three metrics (descriptive, prescriptive, work effort) could then be used to adjust the scope and schedule of new developments with regard to business revenues and returns on assets.

***

(From Chapter 11)
%d bloggers like this: