Advertisment

Emergent Design & Evolutionary Architecture

author-image
Rahul
New Update

Architecture and design in software have resisted firm definitions for a long time because software development as a discipline has not yet fully grasped all their intricacies and implications. But to create reasonable discourse about these topics, you have to start somewhere. This article concerns evolutionary architecture and emergent design, so it makes sense to start the series with some definitions, considerations, and other ground-setting.

Advertisment

Defining Architecture

Architecture in software is one of the most talked about yet least understood concepts that developers grapple with. At conferences, talks and birds-of-a-feather gatherings about architecture pack the house, but we still have only vague definitions for it. When we discuss architecture, we're really talking about several different but related concerns, which generally fall into the broad categories of application architecture and enterprise architecture.

Application Architecture

Application architecture describes the coarse-grained pieces that compose an application. In the Java world, for example, application architecture describes two things: the combination of frameworks used to build a particular application which we call the framework-level architecture and the more traditional logical separation of concerns, for which we stick with the application architecture moniker.

Enterprise Architecture

Enterprise architecture concerns itself with how the enterprise as a whole consumes applications. A common useful metaphor for the relationship between enterprise and application architecture likens enterprise to city planning and application to building architecture. City planners have to think about getting water, electricity, sewage, and other services to allow the city to function. You can't have one building that consumes more than its share of the water supply. Enterprise architecture ponders the same kinds of things for applications: you can't allow one application to consume all of the network's bandwidth, and if infrastructure services crash, (virtual) sewage backs up.

Enterprise architecture has gotten a lot of attention over the last few years because of service-oriented architecture (SOA). SOA is a massive topic in its own right, so future installments of this series will tackle it as a special case. It has its own interesting aspects because it blurs the lines between enterprise and application architecture when it dictates characteristics of application construction.

Advertisment

Architecture is about important stuff, whatever that is

This is appropriately vague but so descriptive at the same time. Many of the arguments about architecture and design revolve around misunderstanding what is important. What's important to business analysts differs from the important stuff for an enterprise architect. This definition nicely encapsulates that you must define your terms within your environment before you can try to define other things.

Architecture and design in software have resisted firm definitions for a long time because software development as a discipline has not yet fully grasped all their intricacies and implications. But to create reasonable discourse about these topics, you have to start somewhere. This article concerns evolutionary architecture and emergent design, so it makes sense to start the series with some definitions, considerations, and other ground-setting.

Defining Architecture

Architecture in software is one of the most talked about yet least understood concepts that developers grapple with. At conferences, talks and birds-of-a-feather gatherings about architecture pack the house, but we still have only vague definitions for it. When we discuss architecture, we're really talking about several different but related concerns, which generally fall into the broad categories of application architecture and enterprise architecture.

Advertisment

Application Architecture

Application architecture describes the coarse-grained pieces that compose an application. In the Java world, for example, application architecture describes two things: the combination of frameworks used to build a particular application which we call the framework-level architecture and the more traditional logical separation of concerns, for which we stick with the application architecture moniker.

Enterprise Architecture

Enterprise architecture concerns itself with how the enterprise as a whole consumes applications. A common useful metaphor for the relationship between enterprise and application architecture likens enterprise to city planning and application to building architecture. City planners have to think about getting water, electricity, sewage, and other services to allow the city to function. You can't have one building that consumes more than its share of the water supply. Enterprise architecture ponders the same kinds of things for applications: you can't allow one application to consume all of the network's bandwidth, and if infrastructure services crash, (virtual) sewage backs up.

Enterprise architecture has gotten a lot of attention over the last few years because of service-oriented architecture (SOA). SOA is a massive topic in its own right, so future installments of this series will tackle it as a special case. It has its own interesting aspects because it blurs the lines between enterprise and application architecture when it dictates characteristics of application construction.

Architecture is about important stuff, whatever that is

This is appropriately vague but so descriptive at the same time. Many of the arguments about architecture and design revolve around misunderstanding what is important. What's important to business analysts differs from the important stuff for an enterprise architect. This definition nicely encapsulates that you must define your terms within your environment before you can try to define other things.

              

Rampant Genericness

The last of the overarching concerns for architecture and design is a phrase I've made up called rampant genericness. We seem to have a disease in the Java world: over engineering solutions by trying to make them as generic as possible. The motivation for this is clear: if we build in lots of layers for extension, we can more easily build more onto it later. However, this is a dangerous trap. Because genericness adds entropy, you damage your ability to evolve the design in interesting ways early in the project. Adding too much flexibility makes every change to the code base more complex.

Of course, you can't ignore extensibility. The agile movement has a great phrase the sums up the decision process for implementing features are implemented: YAGNI (You Ain't Gonna Need It). This is the mantra to try to avoid over engineering simple features. Just implement exactly what we need now, and if we need more stuff later, we can add it then. We've seen some Java projects so bloated with compromises in both architecture and design made at the altar of genericness and extensibility that the projects failed. This is of course ironic because planning for the project to live as long as possible truncated its life.

Advertisment