DYA: Development without architecture

I come across it regularly: Organisations implement a new service or application under high time-pressure.

Products or services need to be on the market fast, before the competition does (for instance in the telecoms sector), or some law is approved by the government which leads to a short-term change in applications (for instance in the Insurance business).

The problem here is that the application or service is built fast, but it does not comply to the company's architecture, or it does not comply with the security policy.

After the application or service is deployed, it takes much effort to manage the service. The extra cost of  managing this non-compliant service can be very high and will be apparent for many years after the original deployment. Also, the new service could introduce security issues that need to be solved later. Furthermore, the connectivity to other systems might be difficult or not rubust, because the other systems do comply to the architecture.

A solution for this problem is introduced in the DYA architecture method.

In DYA, one can choose to develop a project under architecture, or perform development without architecture. Systems that have to be introduced fast, don't have to comply to the architecture of the company. However, after the system is deployed, the development team is committed to start a new development cycle for the same system, but now developed under architecture. This second development cycle can take all the time it needs to develop the system using the normal architectural guidelines and principles.

A nice model.

I have never seen this working in practice. When a solution is in production, it is seldom replaced, just to comply to the architecture. Temporarily solutions usually remain permanent. On the short term the new development under architecture costs money, time and manpower, and it will deliver value only in the long run (mostly system admin costs). Usually system administration is on a different budget than the projects.

The only possibility I see is that the architecture must be followed always. When a project wants to circumvent the architecture, it can only do it if the cost or re-development under architecture is budgeted at the start of the project, and is an integral part of the total cost of the project. This way the cost of developing without architecture is known to the stakeholders of the project in advance. It makes it possible to make a balanced decision if the additional cost for de-development are worth the fast delivery of the service or application.

Obviously this only works if working under architecture is thoroughly embedded in the organisation (the so-called architectural governance), and has enough mandate from higher management.

This entry was posted on Friday 02 January 2009

Earlier articles

Quantum computing

Security at cloud providers not getting better because of government regulation

The cloud is as insecure as its configuration

Infrastructure as code

DevOps for infrastructure

Infrastructure as a Service (IaaS)

(Hyper) Converged Infrastructure

Object storage

Software Defined Networking (SDN) and Network Function Virtualization (NFV)

Software Defined Storage (SDS)

What's the point of using Docker containers?

Identity and Access Management

Using user profiles to determine infrastructure load

Public wireless networks

Supercomputer architecture

Desktop virtualization

Stakeholder management

x86 platform architecture

Midrange systems architecture

Mainframe Architecture

Software Defined Data Center - SDDC

The Virtualization Model

What are concurrent users?

Performance and availability monitoring in levels

UX/UI has no business rules

Technical debt: a time related issue

Solution shaping workshops

Architecture life cycle

Project managers and architects

Using ArchiMate for describing infrastructures

Kruchten’s 4+1 views for solution architecture

The SEI stack of solution architecture frameworks

TOGAF and infrastructure architecture

The Zachman framework

An introduction to architecture frameworks

How to handle a Distributed Denial of Service (DDoS) attack

Architecture Principles

Views and viewpoints explained

Stakeholders and their concerns

Skills of a solution architect architect

Solution architects versus enterprise architects

Definition of IT Architecture

What is Big Data?

How to make your IT "Greener"

What is Cloud computing and IaaS?

Purchasing of IT infrastructure technologies and services

IDS/IPS systems

IP Protocol (IPv4) classes and subnets

Infrastructure Architecture - Course materials

Introduction to Bring Your Own Device (BYOD)

Fire prevention in the datacenter

Where to build your datacenter

Availability - Fall-back, hot site, warm site

Reliabilty of infrastructure components

Human factors in availability of systems

Business Continuity Management (BCM) and Disaster Recovery Plan (DRP)

Performance - Design for use

Performance concepts - Load balancing

Performance concepts - Scaling

Performance concept - Caching

Perceived performance

Ethical hacking

The first computers

Open group ITAC /Open CA Certification

Recommended links

Ruth Malan
Gaudi site
Esther Barthel's site on virtualization
Eltjo Poort's site on architecture


XML: RSS Feed 
XML: Atom Feed 


The postings on this site are my opinions and do not necessarily represent CGI’s strategies, views or opinions.


Copyright Sjaak Laan