DYA framework


Dynamic Enterprise Architecture is an enterprise architecture framework developed by the consulting company Sogeti. It focuses on software design in general, and improving the architectural design function.
The DYA framework is built up with the following modules:
The concept of the DYA framework was first introduced in the 2001 by Roel Wagter, Marlies van Steenbergen, Martin van den Berg, and Joost Luijpers of Sogeti in the Dutch book, entitled DYA: snelheid en samenhang in business- en ICT-architectuur, revised, translated in English, and published in 2005 as "Dynamic Enterprise Architecture: How to Make It Work".

History

DYA|Infrastructure was first hinted at in a whitepaper published by Microsoft MSDN in 2005. After a short development period, it was described in a book titled "DYA|Infrastructuur - Architectuur voor de fundering van de IT".
In 2009, the vocabulary and generic patterns were being published in an online repository, initially under an independent URL, but later on under a subdomain of the Sogeti Netherlands website. There was also a LinkedIn group created.
Development of the method continued at Sogeti until mid 2012; after that, development was continued under the sponsorship of BiZZdesign, at which time the name of the method was changed to Open Infrastructure Architecture method. The Repository is being continued under the name Open Infrastructure Architecture method.

DYA infrastructure

DYA|Infrastructure is a method that aims to support the infrastructure architect. It brings business agility, architectural effectiveness and manageable and expandable infrastructure landscapes within the grasp of any organization. DYA infrastructure provides three mutually supportive elements:
  1. A definitive description of infrastructure architecture as an integral part of the architectural process, and how it helps enforce architectural principles—with two focal points: defining a functional approach to infrastructure facilities and how to select and work with the appropriate quality attributes
  2. The building blocks model that...
  3. # Creates and describes logical, modular infrastructure facilities
  4. # Maintains a categorical and functional inventory of existing infrastructure "landscapes"
  5. # Structures and constructs architectural products, like reference architecture, impact analyses, and project start architecture
  6. Best practices to help begin infrastructure architecture smoothly, and guidelines for producing essential architectural artifacts that make infrastructure architecture work
Various implementation strategies are outlined, how to extend the Project Start Architecture is explained and the importance of a number of products such as Reference Architectures, Product Catalogs and Service Catalogs are also illustrated.
Apart from these three main ingredients, DYA|Infrastructure also provides guidance on how infrastructure architecture can improve security, project management, test management and production.

Background

In 1972, Gerrit Blaauw described how one could think about computer design as separable domains: architecture, implementation and realization. However, the concepts introduced by Blaauw do not hold just for mainframe architecture, but also for IT architecture. When working with DYA|Infrastructure, one can readily recognize the three domains as put forward by Blaauw:
At the implementation level, infrastructure services and functions can still be kept generic. There is no need to propose specific products or technical standards. However, because of the influences of the contexts, services and functions can often be organization-specific. Note that with the previously presented definition of infrastructure architecture, both the Blaauw "architecture" and "implementation" are subject to the infrastructure architect.
Business, information and infrastructure architectures share a common goal: to provide optimum support for an organisation's operations. This is impossible without input from, and feedback between, the three architectural disciplines. To act effectively within the architectural process and at the same time be sufficiently responsive, each discipline must follow the dynamics and structures which underline their own respective area of competence. This certainly applies to infrastructure architecture, which must make its role easily recognisable by clarifying the terms it uses within the infrastructure domain. The easiest way to do this is to describe infrastructure solutions in logical and functional terms. DYA|Infrastructure defines the "capability" of a solution with a set of quality attributes. Quality attributes also have an important role in harmonizing the architectural process across the three architectural disciplines, because regardless of the underlying structure, quality attributes can be reconciled across the domains and be used throughout the entire solution. At the same time, they also provide input for the engineering, creation and testing of solutions within their own area of competence. That is why quality attributes are a recurring theme throughout the different phases and activities of infrastructure architecture and why it is of the utmost importance to choose and define quality attributes carefully. At the very least, they must illustrate the unique and inherent quality of an infrastructure solution.

Quality attributes for communication

The architectural disciplines must be able to adjust to each other whenever necessary during the architectural process without compromising themselves. They should make clear what they can contribute and indicate their own limits. The full scope of wishes and requirements can not always be fulfilled; particularly if they conflict with each other. Should one of the disciplines want or need to dictate the eventual outcome, it should receive appropriate guidance from the architectural process, keeping in mind that the guidance must be relevant to the specific area of competence. The architectural process selects quality attributes most realistic and appropriate for the direction of the desired solution. This set of quality attributes can be seen as a mandate for each discipline to individually work on their own part of the total solution. Quality attributes ensure the resulting solutions are not developed in isolation, but that they remain consistent within the complete architectural framework. Quality attributes also provide a way to check and report on delivered results.
To stop disciplines talking at cross purposes, unequivocal agreement is needed on the quality attributes each discipline brings into the architectural process. These must serve as a basis for further reconciliation and harmonization of definitions within the architectural process. Infrastructure architecture provides its own set of quality attributes, alongside the specific quality attributes of the business and information architectures.
Apart from the quality attributes, there are two major restrictions that influence the potential direction of a solution, namely cost and time. These restrictions are imposed by the outside world and affect all forms of architecture. Time and money are generally the most important determinants of the scale and quality and thus feasibility of a solution. In many cases, time and money are so restrictive that a different weighting must be given to a number of quality attributes to come up with a realistic solution. As a result, the architectural process occasionally and justifiably turns into a debate between stakeholders, resulting in a solution that, optimally, serves all organizational interests within the confines of time and money.

Quality attributes for infrastructure architecture

Quality attributes are by nature abstract, because they indicate how but not what. Within the architectural process, relationships are identified between the quality attributes from one discipline and comparable quality attributes in another discipline. This makes it easier to identify how choices made in one area influence solutions in other areas. The more pro-actively this occurs and the more quality attributes that can be reconciled, the more constructive the process. Within this harmonization process, "similar" quality attributes are easily traceable to each other, while others are far more likely to underline the uniqueness of a particular discipline. Nevertheless, a discipline usually recognizes itself in the quality attributes of other disciplines, provided that they have been properly defined and explained.
Keeping in mind the objective of building the infrastructure function as a utility, there are three categories, with two quality attributes each, that express the inherent quality of infrastructure solutions:
The six quality attributes defined here do not apply exclusively to infrastructure applications, but they are the guiding set for building infrastructure as utility.
Participants in the architectural design process are not always sufficiently aware of the importance of the quality attributes of their own fields of expertise, and consequences that their explicit requirements have on other areas. Other participants must then explain the implicit or explicit consequences for their own domain. For example: a certain business architecture solution requires 99.99% availability. Infrastructure responds that they can meet this requirement in terms of availability, but it creates significant consequences in terms of scalability and cost. Business architecture is then expected to indicate whether, in that light, the specified availability requirement is still justified. A situation must be avoided where disciplines impose quality attributes and terms on each other purely to achieve their own goals while disregarding other disciplines, because it is utterly counter-productive and thwarts the architecture process itself. Quality related terminology within one discipline often means something else, or even nothing at all, outside that discipline's domain.

DYA infrastructure decomposition and modeling

This Infrastructure Architecture Repository contains architecture & design guidelines in the form of construction models at various levels and from various angles. It is constructed by making use of one of the most important tools of DYA|Infrastructure: The Building Blocks Model. The first thing you should know about the Building Blocks Model is that it is primarily a decomposition tool. That means that it is used to dissect infrastructure landscapes into logical dimensions and parts to enable structured and methodological modeling. It's like defining the Periodic Table first, to subsequently practice chemistry in an orderly fashion.
The Building Blocks Model dissects the infrastructure landscape from five directions:
The decomposition order that is imposed by the model can be described as follows:
These facilities "live" in an Environment, that means that they are used in a certain business context and that the way of usage that is dictated by this context demands specific quality requirements.
Examples of Environments within the Client Realm Working Area are Office, Kiosk and Remote. Within each Environment, quality demands are denoted by Quality Attributes with a value that is fitting to that Environment. On their turn, these values correspond to classes, provisions and/or permutations that are relevant to that Quality Attribute.
Applied to building blocks in a certain environment, the architectural process designates universal standards to a building block for that environment. These standards are elements in the building block model.

Gallery