Dynamic Enterprise Architecture (DYA) is an enterprise architecture framework developed by the consulting company Sogeti.^[1] It focuses on software design in general, and improving the architectural design function.^[2]

The DYA framework is built up with the following modules:^[3]

• DYA|Infrastructure, concerning infrastructural architecture
• DYA|Software, concerning software architecture
• DYA|Business, concerning business architecture
• DYA|Governance, concerning IT governance, and
• DYA|Principles, about the development of architectural principles

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,^[4] revised, translated in English, and published in 2005 as "Dynamic Enterprise Architecture: How to Make It Work".^[5]

DYA|Infrastructure was first hinted at in a whitepaper published by Microsoft MSDN in 2005 (superseded by a new submission in 2007).^[6] After a short development period, it was described in a (Dutch) book titled "DYA|Infrastructuur - Architectuur voor de fundering van de IT".^[7]

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.^[8] There was also a LinkedIn group^[9] 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 (OIAm).^[10] The Repository is being continued under the name Open Infrastructure Architecture method (OIAr).

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 (an architectural meta-model for infrastructure) that...
   1. Creates and describes logical, modular infrastructure facilities
   2. Maintains a categorical and functional inventory of existing infrastructure "landscapes"
   3. Structures and constructs architectural products, like reference architecture, impact analyses, and project start architecture
3. 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.

In 1972, Gerrit Blaauw^[11] 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 (and arguably for all forms of architecture). When working with DYA|Infrastructure, one can readily recognize the three domains as put forward by Blaauw:

• Architecture : Blaauw argued that, "The architecture of a system can be defined as the functional appearance of the system to the user, its phenomenology."^[11] When discussing the architecture of an infrastructure facility, we limit ourselves to the essentials: what does it do? To this end, we regard the facility as an infrastructure service, compounded of basic, atomic infrastructure functions. Atomic infrastructure function in this respect means a logical infrastructure function that cannot be meaningfully subdivided into sub-functions—at least not meaningfully for architectural purposes.

When infrastructure functions are described in generic terms, apart from any technical implementation, they look identical for most organizations. Similarly, when infrastructure services are composed out of basic infrastructure functions, they also look identical between organizations. And this is precisely what one would expect on an architectural level, according to the definition by Blaauw.

• Implementation  : Blaauw argued that "The implementation is the logical structure which performs the architecture. Where the architecture tells what happens, the implementation describes how it is made to happen."^[11] In any organization, an infrastructure service must be delivered within one organization specific context, or possibly multiple of these. These contexts influence the way in which an infrastructure service must be delivered. For instance, a Ministry of Defence PC in an office in the capital looks different from a PC in the back of an armoured personnel carrier on the battlefield. This is because the context battlefield imposes different requirements on the infrastructure facility than the context office.

Thus, implementing an infrastructure service means:

• • Identifying the contexts and their requirements in which the service must operate
  • Locating the infrastructure functions that are part of the service in these contexts
  • Specifying them to a level of detail that can account for the identified requirements

At the implementation level, infrastructure services and functions can still be kept generic. There is no need to propose specific products or technical standards (although this is possible). 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.

• Realization : Blaauw argued that "The physical structure, which embodies the logical design, will be called the realization. Here, the 'which' and 'where' of component selection, allocation, placement and connection will be considered separate from the 'how' of the logical structure."^[11] Realization of an infrastructure service is the field of infrastructure designers and engineers. It is their responsibility to create from the implementation a facility that is both feasible and maintainable (including the cost aspect of both). In this phase, infrastructure designs are created and the facilities actually get built.

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 (technological) 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.

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 (even minimally) 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 (usually by the organization) 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 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:

• Flexibility (adaptability and scalability);
• Reliability (availability and integrity);
• Maintainability (manageability and accountability).

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.

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 (composition). 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:

• Working Areas
• Environments
• Building Blocks
• Elements
• Quality Attributes

The decomposition order that is imposed by the model can be described as follows:

• An infrastructure landscape consists of several Working Areas (Storage, Network, Server, Middleware, Client Realm).
• Within each Working Area, some kinds of infrastructure functionality reside (Building Blocks), for example:
  • the Working Area Storage offers a Centralized Storage facility,
  • the Network Working Area offers Access and data Distribution facilities and
  • the Client Realm Working Area provides PC's, Mobile PC's, Printers, Scanners and other facilities that serve as an interface to end-users.

These facilities (Building Blocks) "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 (technical components) are elements in the building block model.

• 
  DYA Infrastructure modeling (ideal flow).png
• 
  DYA Infrastructure modeling prerequisites.png
• 
  DYA Infrastructure ontology.png
• 
  DYA Infrastructure Problem solving support.jpg
• 
  DYA Infrastructure Project guidance.jpg

• Dynamic enterprise
• Dynamic enterprise modeling (DEM)
• Open Infrastructure Architecture method

As of this edit, this article uses content from "dya-knowledge.sogeti.nl", which is licensed in a way that permits reuse under the Creative Commons Attribution-ShareAlike 3.0 Unported License, but not under the GFDL. All relevant terms must be followed.

• DYA at dya.info
• DYA Infrastructure Repository