Misplaced Pages

Revision as of 14:14, 6 August 2013

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 folowing 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. Working within an architectural structure, the foundation of DYA

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

"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

"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

"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.

References

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. ^ Fields covered by DYA,
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. ^ “Computer Architecture”, Gerrit A. Blaauw, Elektronische Rechenanlagen, 1972 heft 4, page 154-159

External links

• DYA at dya.info
• DYA Infrastructure Repository

• Enterprise architecture frameworks