DYA - Maturity Focus Areas

subtitle: The 17 Focus Areas

Definition of Architecture by the Architecture Maturity Matrix 3.0?

The notion of architecture is being interpreted broadly as:

A consistent set of principles and models 
that give direction to the design and realisation of 
processes, organisational structures, information, 
applications and technical infrastructure 
of an organisation.

Usage in the agile organisation the Architecture Maturity Matrix 3.0

Project Organisation	Agile Organisation
Project (as in work package)	Epic
Project (as in organization)	Scrum Team or DevOps team or Squad
Working in projects	Working Agile
Project manager	Product Owner or Scrummaster
Project phase	Program Increment or Sprint

17 Focus Areas

Research indicates that there are 17 focus areas that are influence for an effective architectural practice.

00	Focus area	Description
F01	Development of architecture	The development of architecture can be undertaken in various ways, varying from isolated, autonomous projects to an interactive process of continuous facilitation in which all architectural initiatives are coordinated and the right stakeholders are being involved. In the first case, the emphasis is placed on architecture considered as a product, in the second, on architecture as a process. The more architectural design is incorporated as a continuous process within an organization’s trajectory of change, the greater the chance that real value will be delivered.
F02	Use of architecture	Developing architecture is not an end in itself. Architecture has a goal: it must accomplish something; it needs to be put to use. In practice, the uses of architecture can vary. It may merely be a conduit for information, or it may be a means of governing individual projects or even a tool for managing the entire organization. With increasing levels of maturity, architecture is used more and more as a management instrument throughout an increasingly large part of the organization, guiding the organization to do the right things in the right way.
F03	Alignment with business strategy	Architecture is justified insofar as it supports and facilitates business goals. Alignment with the business strategy (the degree to which the architectural process is in tune with what the business wants and is capable of) is therefore very important. This is about the connection between the choices made in the architecture and the business goals.
F04	Alignment with realisation	Architecture needs to channel changes in such a way that the business goals are achieved in the most effective manner. Alignment with realisation (programmes, projects, operations, maintenance) is therefore extremely important, no matter whether it involves process, organization or IT development. How is the realisation process synchronized with the overarching architectural process?
F05	Relationship to the As-Is state	Architecture is frequently associated with a desired state of affairs: the so-called to-be state. Most organizations also have to deal with an existing situation based on historical growth (frequently without architecture). In assessing the suitability of the architecture, it is important to realize that a set of circumstances already exists, which has its own range of possibilities and impossibilities. If this relationship to the as-is state is ignored, there is a danger that the organization will be able to do little with its elegantly drafted scenarios for future architecture.
F06	Responsibilities and authorities	If the roles and responsibilities concerning architectural thinking and taking action are clearly and unambiguously outlined to everyone, discussions and differences of opinion about architecture are prevented from falling into limbo. Moreover, parties can then be questioned about their own specific contribution to architecture.
F07	Alignment with change portfolio	In an organization, a (large) number of developments takes place in all sorts of areas at more or less the same time. Some of these developments are interrelated. Architecture is the control instrument to make sure that the content of such developments is coordinated. Of course, architecture must then be employed for this purpose.
F08	Monitoring	It is generally insufficient to just state that projects must comply with the architecture. Without a control mechanism, the temptation will be too great to choose the path of least resistance and to ignore the architecture at certain points.
F09	Quality assurance	Obviously, the successful employment of the architecture depends upon its quality. The goal of quality assurance is to ensure such quality.
F10	Management of the architectural process	Like every other process, the architectural process needs to be maintained. This is the only way to safeguard the effectiveness and efficiency of architecture. Maintenance of the architectural process means that a cycle of evaluation, development, improvement and implementation is periodically re-run.
F11	Management of the architectural products	It is not enough to issue architectural products (such as standards, guidelines and models); they must also be maintained. Maintaining architectural deliverables means updates are provided and outdated products eliminated, as necessary. Active maintenance guarantees that the architecture is always current and fully functional.
F12	Commitment and motivation	Commitment and motivation of the architecture stakeholders is critical in bringing the architecture up to speed and making it successful. These stakeholders include not only the architects but also, and especially, senior business and IT management, plus project management. Business and IT management are primarily responsible for creating a favourable atmosphere. This ensures that the architectural process is given sufficient time, money and resources. Ideally, there is support for the architectural artifacts (architectural principles and models) at all levels of management.
F13	Implementation of the architectural role	Being an architect is demanding. Architects not only need to possess the skills to develop architectures, they also need to have the knowledge and understanding for process development, systems development and technical infrastructures. As if that were not enough, high demands are made on their social and management skills. Acquiring this skill set takes training. Hence defining the architect’s role and providing the necessary training is an important concern.
F14	Architectural method	The way an organization develops its architecture is a methodical procedure made up of activities, techniques, tools and deliverables. The method chosen must be aligned with the organisation’s culture and mode of operation, and consequent approach to architecture. It is helpful if the architects share the same method.
F15	Interaction and collaboration	A great deal of interaction and collaboration among various stakeholders is required in developing architecture. Stakeholders like business managers, process owners, information managers, project managers and IT specialists are involved. This interaction and collaboration is very important in making the architectural process function well. They make the architectural requirements clear and they create an opportunity to share the results of the architectural process with the users of the architecture (such as projects and operations).
F16	Architectural tools	Working with architecture can be aided by architectural tools. They should be well suited to their task. Using tools in an integrated manner, preferably with the support of a repository, maximizes their efficiency and effectiveness. Of course, the tools should be aligned with the chosen architectural method.
F17	Budgeting and planning	The development of architecture can be budgeted and planned. Careful budgeting and planning helps de-mystify architecture. It also shows the organisation what it can expect. Budgeting and planning can range from drafting occasional plans to collecting past experiences with architecture.

Maturity levels for each focus area

00	Focus area	Level A	Level B	Level C	Level D
F01	Development of architecture	Architecture is developed with a clear focus on objectives	Architecture is developed in consultation with the stakeholders	Architectures are developed as a cohesive whole	-
F02	Use of architecture	Architecture is prescriptive	Architecture is aligned with the decision-making process	Responsibility for architecture as a product has been assigned
F03	Alignment with business strategy	Architecture is related to business objectives	Architectural process is steered by the business objectives	Architecture is an integral part of the strategic dialogue	-
F04	Alignment with realisation	Ad hoc	Structural	Interactive	-
F05	Relationship to the As-Is state	Attention to the As-Is state	Future and existing situations are viewed in connection	-	-
F06	Responsibilities and authorities	Responsibility for architecture as a product has been assigned	Management is responsible for the architectural process	Senior management is responsible for the effect of architecture	-
F07	Alignment with change portfolio	Steering the content of individual projects	Coordination between projects	Strategic portfolio management	-
F08	Monitoring	Reactive monitoring	Proactive monitoring	Fully incorporated monitoring
F09	Quality assurance	Explicit quality review	Quality assurance process has been set up	Fully incorporated quality assurance policy	-
F10	Management of the architectural process	Management is incidentally executed	Management procedures have been set up	Continuous process improvement	-
F11	Management of the architectural products	Management is incidentally executed	Management procedures have been set up	Presence of a management policy	-
F12	Commitment and motivation	Allocation of budget and time	Architecture is acknowledged as a management instrument	Architecture is acknowledged as a strategic issue	-
F13	Implementation of the architectural role	Role has been recognised	Role has been detailed	Role is supported	Role is appreciated
F14	Architectural method	Ad hoc	Structural	Fully incorporated	Fully incorporated
F15	Interaction and collaboration	Collaboration between architects	Involvement of the stakeholders	Shared ownership	-
F16	Architectural tools	Ad hoc and product-oriented	Structural and process-oriented	Integration of tools	-
F17	Budgeting and planning	Ad hoc	Structural	Optimising	-

Architecture Maturity Matrix 3.0

In which other should you increase the maturity of the focus area's in the most effective way?

00	Focus area	A01	A02	A03	A04	A05	A06	A07	A08	A09	A10	A11	A12
F01	Development of architecture	A			B			C
F02	Use of architecture		A			B				C
F03	Alignment with business strategy	A			B					C
F04	Alignment with realisation		A				B			C
F05	Relationship to the As-Is state				A				B
F06	Responsibilities and authorities			A		B					C
F07	Alignment with change portfolio			A				B		C
F08	Monitoring			A		B		C
F09	Quality assurance							A		B		C
F10	Management of the architectural process						A		B		C
F11	Management of the architectural products				A			B					C
F12	Commitment and motivation	A					B		C
F13	Implementation of the architectural role			A		B		C				D
F14	Architectural method			A					B			C
F15	Interaction and collaboration		A		B				C
F16	Architectural tools						A				B		C
F17	Budgeting and planning				A						B		C

Legend of the Architecture Maturity Matrix 3.0

Row and Columns
The rows contain the 17 focus areas.
The columns represent increasing scales/steps of maturity.
- Every column represents a step and is also reference to as "scale".
The letters in the cells represent the levels of maturity for each focus area.
The letters in the cells of the matrix stand for the levels of maturity of table 1.
Sequence
The steps (columns) to grow are defined in 12 steps.
Step by step improvement is done by moving left to right through the matrix.
Reading the matrix from left to right shows the order and extent of progress to be made in each area.
Grouping
The 12 steps / scale's / columns can be grouped together 5 "stages".
To validate if a focus area (row) has reached a scale (letter in column) there are checkpoints defined.
- The checkpoints are not discrete (exact) but provide room to adapt to the unique situation of an organisation.

Maturity level is achievement unlocked - The maturity level A is reached when all A's are achieved and non of the A's are left. - An organisation attains a (maturity) level when all the checkpoints at that level and all preceding (maturity) levels have been satisfied. - (EB: what is the meaning of the sentence below?) - An organisation achieves a scale of maturity when all the levels at that scale and at all previous scales have been attained.

Scales are steps grouped together.

Stage	Description
Stage 03	A start is made on the employment of architecture. The most important focus areas are developed to a basic level. There is an awareness that architecture must be embedded into the organization and work is being done on this matter.
Stage 06	Nearly all the focus areas are developed to a basic level. Consideration is given to architecture as a process. Architectural practices are structurally established.
Stage 08	Architecture now facilitates the most important organizational changes. There is commitment throughout the organisation.
Stage 10	Architecture is used as an integral part of all the changes occurring in an organisation. Architectural practices are integral to the organisation.
Stage 13	Architectural practices are at such a high level of proficiency that architectural processes and products are continuously optimized.

Question on the Architecture Maturity Matrix 3.0

When you work from A00, A01, A02 ... until A06 to grow into maturity level A. Should I skip the B's?
1. No, you would not skip the B's.
Why is there a step A00 ?
What is the point of the grouping? Is it used somewhere?

How to walk through the Architecture Maturity Matrix 3.0?

In goes as follows. In the column headed 1, there are “A”s in three focus areas (i.e. development of architecture, alignment with business strategy, and commitment and motivation).

This means that the minimum level (level A) must be attained in these three areas first. They are immediately followed in priority by the areas use of architecture, alignment with realisation and interaction and collaboration (the “A”s in column 2). And so on.

Once the focus areas marked with an “A” in column 3 have been brought to the “A” level, the development of architecture needs to be upgraded to the next level, the “B” level.

This is indicated by the B that appears in column 4 for this focus area.

Concurrently, we are working to attain an initial “A” level in relationship to the as-is state. And so on.

The model therefore concretely indicates the order in which we can best work on the various focus areas.

In this way, it could very well be that one of the areas must first reach the highest level, while others are not yet at level A. An example of this is the relative positioning of the development of architecture (at level C in column 7) and quality assurance (only at level A in column 7).

If an organisation possesses such principles and models, we consider those to be a part of architecture, even if they are not identified as such by the organisation.

Focus Areas pages

Foundation & References

Foundation of the Focus Area's

PHD dissertation Marlies?

Foundation of the Maturit Levels ?

PHD dissertation Martin ?

Whitepaper Architectuurvolwassenheidsmatrix DYA®

Version 1.1 (NL)
december 2011
1. Authors
2. Marlies van Steenbergen
3. Aldert Boersma
4. Martin van den Berg
Version 3.0.1 (EN & NL)
1. 16 juli 2019
2. Authors
3. Marlies van Steenbergen
4. Aldert Boersma
5. Martin van den Berg

DYA Volwassenheidsmatrix - survey form

Version 2.1
date unknown
Authors
1. Unkown.

@inproceedings{
  DyAMM-2009,
  title  = {The Dynamic Architecture Maturity Matrix: 
          Instrument Analysis and Refinement},
  author = {Steenbergen, Marlies and 
          Schipper, Jurjen and 
          Bos, Rik and 
          Brinkkemper, Sjaak},
  year   = {2009},
  month  = {01},
  pages  = {48-61},
  doi    = {10.1007/978-3-642-16132-2_5},
  URL    = {https://www.researchgate.net/publication/221050665_The_Dynamic_Architecture_Maturity_Matrix_Instrument_Analysis_and_Refinement}
}

2013 - Improving IS Functions Step by Step: The use of focus area maturity models

@article{
  DyAMM-2013,
  title     = {Improving IS Functions Step by Step: 
             The use of focus area maturity models},
  author    = {Steenbergen, Marlies and 
         Bos, Rik and 
         Brinkkemper, Sjaak and 
         Van de Weerd, Inge and 
         Bekkers, Willem},
  year      = {2013},
  month     = {01},
  pages     = {35-56},
  volume    = {25},
  journal   = {Scandinavian Journal of Information Systems},
  URL       = {https://www.researchgate.net/publication/311667299_Improving_IS_Functions_Step_by_Step_The_use_of_focus_area_maturity_models}
}

2011 - The Dynamic Architecture Maturity Matrix

@thesis{
  DyAMM-2011,
  title   = {The Dynamic Architecture Maturity Matrix: 
             Assessment analysis and instrument validation},
  author  = {Schipper, Jurjen and
         Bos, dr. Rik and 
             Brinkkemper, prof. dr. Sjaak},
  year    = {2011},
  URL     = {http://www.cs.uu.nl/education/scripties/},
  URL     = {http://www.cs.uu.nl/education/scripties/scriptie.php?SID=INF/SCR-2011-036},
  URL     = {http://www.cs.uu.nl/education/scripties/pdf.php?SID=INF/SCR-2011-036}

2019 - The Dynamic Architecture Maturity Matrix Assessment analysis and instrument validation

@inproceedings{Schipper2012TheDA, title={The Dynamic Architecture Maturity Matrix Assessment analysis and instrument validation}, author={Jurjen Schipper and Sogeti Netherlands}, year={2012} }