Dynamic Enterprise Architecture (DYA) is an enterprise architecture framework developed by the consulting company Sogeti.Marc Lankhorst (2012) Enterprise Architecture at Work: Modelling, Communication and Analysis. p. 2 It focuses on software design in general, and improving the architectural design function.Maarten Waage, Herman Hartman (2010) The Integrated Architecture Framework Explained: Why, What, How. p. 157
The DYA framework is built up with the following modules:Sogetti (2011) "Fields covered by DYA" at dya.info. Accessed July 8, 2013. 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,Roel Wagter, Marlies van Steenbergen, Martin van den Berg, Joost Luijpers (2001) DYA: snelheid en samenhang in business- en ICT-architectuur. Sogeti. revised, translated in English, and published in 2005 as "Dynamic Enterprise Architecture: How to Make It Work".Martin van den Berg, Marlies van Steenbergen (2007) Building an Enterprise Architecture Practice: Tools, Tips, Best Practices, Ready-to-Use Insights. p. 1
History DYA|Infrastructure was first hinted at in a whitepaper published by Microsoft MSDN in 2005 (superseded by a new submission in 2007).Daniël Jumelet (2007) "Infrastructure architecture" After a short development period, it was described in a (Dutch) book titled "DYA|Infrastructuur - Architectuur voor de fundering van de IT".Daniël Jumelet (2007) "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.DYA|Infrastructure Repository (DIR) There was also a LinkedIn groupDYA|Infrastructure Architecture group on LinkedIn 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).DYA|Infrastructure development continues with a new sponsor, and a new name The Repository is being continued under the name Open Infrastructure Architecture method (OIAr).
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: 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 The building blocks model (an architectural meta-model for infrastructure) that... Creates and describes logical, modular infrastructure facilities Maintains a categorical and functional inventory of existing infrastructure "landscapes" Structures and constructs architectural products, like reference architecture, impact analyses, and project start architecture 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 BlaauwGerrit A. Blaauw (1972) "Computer Architecture", Elektronische Rechenanlagen, Vol 4, p. 154-159 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." 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." 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." 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.
The DYA infrastructure architecture process 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.
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 (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 for infrastructure architecture