Misplaced Pages

This is an old revision of this page, as edited by Mdd (talk | contribs) at 14:53, 6 August 2013 (→References). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Dynamic Enterprise Architecture (DYA) is an enterprise architecture framework developed by the consulting company Sogeti. It is particularly focussed on architecting in general and improvement of the architectural function.

The DYA framework is build up with the following modules:

• 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 development of the DYA framework started in 2001 , and the framework was first published in 2004.

DYA|Infrastructure

DYA|Infrastructure brings business agility, architectural effectiveness and manageable and expandable infrastructure landscapes within grasp of any organization. There are three mutually supportive key elements which DYA|Infrastructure provides:

1. The definitive description of infrastructure architecture as an integral part of the architectural process, and how it can help to enforce architectural principles. There are two focal points: the need for 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) which can be used to
   1. create and describe logical, modular infrastructure facilities,
   2. maintain a categorical and functional inventory of existing infrastructure landscapes, and
   3. structure and construct architectural products, like Reference Architectures, Impact Analyses and Project Start Architectures.
3. A number of best practices to get infrastructure architecture off to a flying start within an organization, as well as guidelines for producing essential architectural artifacts which will make infrastructure architecture really 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 (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 will 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, then they will look identical for most (if not all) organizations. Similarly, when infrastructure services are composed out of basic infrastructure functions, they will 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 needs to 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, and
• locating the infrastructure functions that are part of the service in these contexts, and
• 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 quite generic; there is no need to propose specific products or technical standards (although this is of course possible). However, because of the influences of the contexts, the services and functions can often be expected to 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 will select the quality attributes which are most realistic and appropriate for the direction in which the desired solution should be sought. 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. The quality attributes ensure that the resulting solutions are not developed in isolation, but that they will remain consistent within the complete architectural framework. The set of quality attributes will also provide a means checking and reporting on delivered results.

To avoid disciplines talking at cross purposes, unequivocal agreement is needed on the quality attributes which each discipline brings into the architectural process. These must serve as the basis for the further reconciliation and harmonization of definitions within the architectural process. Infrastructure architecture will provide 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 will occasionally and justifiably turn into a debate between the parties involved, resulting in a solution that will optimally serve the organization’s interests within the confines imposed by 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 will influence possible solutions in other areas. The more pro-actively this occurs and the more quality attributes that can be reconciled, the more constructive the process will be. Within this harmonization process, "similar" quality attributes will be easily traceable to each other, while others are far more likely to underline the uniqueness of a particular discipline. Nevertheless, a discipline will usually recognize 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".

The participants in the architectural process are not always sufficiently aware of the importance of the quality attributes of their own fields of expertise, and the consequences that their explicit requirements will have on the other areas. It is then up to the other participants to explain the implicit or explicit consequences for their own domain. For example: a certain business architecture solution requires 99.99% "availability". Infrastructure responds by saying they can meet this requirement in terms of "availability", but it will have significant consequences in terms of "scalability" and "money". Business architecture will then be expected to indicate whether, in that light, the specified availability requirement is still justifiable. A situation must be avoided where disciplines impose quality attributes and terms on each other purely to achieve their own goals with disregard for those of the other disciplines, because it is utterly counter-productive and will thwart the architecture process itself. Quality related terminology within one discipline often means something else, or even nothing at all, outside that discipline's domain.

References

This article incorporates CC-BY-SA 3.0 material from the dya-knowledge.sogeti.nl websites by Daniel Jumelet, Jan Schoonderbeek (for history, see here).

1. Marc Lankhorst (2012) Enterprise Architecture at Work: Modelling, Communication and Analysis. p. 2
2. Maarten Waage, ‎Herman Hartman (2010) The Integrated Architecture Framework Explained: Why, What, How. p. 157
3. ^ Sogetti (2011) "Fields covered by DYA" at dya.info. Accessed July 8, 2013.
4. Martin van den Berg, ‎Marlies van Steenbergen (2007) Building an Enterprise Architecture Practice: Tools, Tips, Best Practices, Ready-to-Use Insights. p. 1
5. ^ Gerrit A. Blaauw (1972) "Computer Architecture", Elektronische Rechenanlagen, Vol 4, p. 154-159

External links

• DYA at dya.info
• DYA Infrastructure Repository

• Enterprise architecture frameworks