Excerpt from Enterprise Architecture Fundamentals:
***
Topping the job description, enterprise architects are meant to serve as brokers between business and systems stakeholders; to that end, they must be aware of the intrinsic difference between their respective agendas. Agility is a case in point.
For business stakeholders, Agile means customer-centric, lean, and just-in-time engineering processes — something that could be considered as a yardstick for the fourth maturity level.
For systems stakeholders, Agile refers to the versatility and plasticity of architectures — something that could be achieved at processes’ fifth maturity level.
Maturity levels could thus provide a double-sided ladder for business and systems perspectives, with processes and capabilities being improved independently along the first four levels, and brought together at the fifth. All along, alignments would be carried out in a piecemeal fashion, according to the level of maturity achieved (figure 15-12):
At the second (managed) level, the lining up of business and systems perspectives is shallow and limited to the feasibility of objectives concerning capabilities, without being specific about problems and solutions; that mapping of objectives and capabilities can be done through Use cases (cf. chapter 13).
At the third (defined) level, alignments can go deeper and chart engineering paths between processes and supporting capabilities, taking advantage of MBSE and model transformations (cf. chapter 14).
At the fourth (measured) level, with both perspectives consistently defined and assessed, the aim is to balance the pros and cons of specific vs. architectural changes; that can be achieved by assessing versatility and plasticity ratios from a process perspective.
Finally, at the fifth (optimized) level, the balancing of versatility and plasticity can be assessed in the broader context of enterprise architecture.
That double-sided maturity scale may help to clarify some confusion surrounding the so-called business architecture. While the term may make some sense when business processes and architecture capabilities are meant to converge at the fifth (optimized) maturity level, using it indiscriminately simply sidesteps the main issue of enterprise architecture, which is to dynamically manage the bevel gears linking architecture assets and mechanisms to business moves.
***