What is the best architecture? It really is a silly question, especially when asked completely out of context. Yet, for some reason many in our industry feel a need to discuss architecture as if on a quest for the best architecture as a singularity; almost as if architecture itself was a concrete object that could be created and given from one person to another. I think there are some that hope once the best architecture is defined, they will be able to give it to the masses (for a nominal hidden fee), as if it was a thing, and say "here, behold the best architecture, use it to build truly excellent system. Your systems will taste great and be less filling!"
It is well known that our industry tends to be very trendy. If you are trying to sell a software solution today, and you aren’t using today’s buzzwords in your marketing it becomes a difficult sales job. The decision makers (who ultimately choose to buy software products) are just as caught up in the trends as the people building the software. For example:
- prospective client: "Are you using SCNA (Some Cool New Architecture)"
- software development firm: "Yes, we are leaders in SCNA"
- prospective client: "Good! Because we have a commitment going forward to only purchase software which adheres to the core principals of SCNA"
- software development firm: "Great! We are the man when it comes SCNA"
- software development firm to newly contracted consultants: "We need you to put an SCNA wrapper around our YCNA (Yesterday’s Cool New Architecture)"
The general reason for most of this is people getting all caught up in "What is the best architecture" instead of architecting the right solution.
Putting a wrapper around something is an abstraction, and it’s a fundamental software engineering practice. There is nothing wrong with making one thing adapt to another via some level of abstractions. The abstractions alone don’t describe an overall architecture but may allow things built with different objects, components, services, architectural styles, platforms, etc. to all get along. The satire above is not an attempt to be cynical about abstractions, just nonsensical approaches towards architectural decisions.
Architecture has obviously been around a lot longer then software development. A quick search on its definition returns 1) "The art or science of building". I’m sure there are many more complicated definitions then these to be found in architecture textbooks. It is interesting to note that even in the results of the dictionary definition there is an adaptation for the computer generation in definition 5) "The manner in which the components of a computer or computer system are organized and integrated" The commonality that I take from this, is that we are talking about the art, science and manner of building, organizing and integrating stuff. So architecture is an abstract noun and not a concrete noun. I don’t think person A can give person B an architecture, and say here, go use this, any more then person A can give person B an art, science or manner. Yes, there are certain styles of architecture that can be identified, and these styles can be applied to the art or science of new buildings or the manner in which computer system components are integrated. We can look at a finished building and see traces of one architectural style or another, just as we can look at a software solution and see traces of one architectural style or another. Additionally, as we look at buildings erected during specific time periods and geographical locations we can see common traces of certain art and science styles and we can identify these commonalities as an "Architectural Style". Similarly, we can look out at our relatively short history of software engineering and see repeatable styles of manner in which computer systems are organized and integrated.
Let’s not confuse software architecture, with software frameworks. Because, there are indeed frameworks that are real things that person A can give person B and say here, go use this to build a system. These frameworks can be designed and built with an architectural style in mind and they can promote and enhance the use one particular style over another. However, even frameworks do not guarantee that an overall solution will be organized and integrated in the manner of the style intended by the creator of the framework. Using a framework can drastically reduce the amount of plumbing code required to organize and integrate the parts of an overall computer system solution associated with a particular style or manner; but just can’t guarantee that the end result will be considered by all observers to be strictly speaking "of a particular manner" or architecture style. So architecture is an abstract noun in the sense that it is the art, science and manner of constructing things. But, its not a concrete noun like rocks, dogs and trees.
When one sets out to erect a building, usually one employs the talents of a building architect. I really don’t know anything about true building architecture save what any common person learns by observing things. However, when constructing a building, I imagine there are some common questions asked about the building’s purpose; is it a bank, a house, a church, a factory, a castle, a hotel, a whole town or village, etc.? I would imagine there are some environmental climate questions; is it in a cold climate, tropical climate, or dessert? I would imagine there are some environmental geography questions; is it on a mountainside, is it by the ocean, is it by a river, is it part of some larger preexisting complex? Does the client have a particularly favorite time period or style; such as Gothic, Roman, Victorian, 21’st Century Modern, High Tech? I would imagine that by asking these questions the architect would start to get a feel for the best type of building materials; brick, steel, wood, concrete, glass, etc. I would imagine the architect would start thinking about some common building elements; columns, stairways, domes, arches, etc. I imagine the architect might start thinking about how to best integrate some environmental resources; like daylight, hillsides, or local rock formations. Additionally, I would imagine that the individual architect is going to have some special uniqueness and artistic abilities that set them apart from other architects.
There are so many combinations of things that seldom do two building structures end up identical unless it is purposely a cookie cutter design choice. Additionally, it’s almost impossible to say what the best architecture is. From a technical point, when erecting a building, the best architecture might be the one that best integrates all these various interest (environmental contexts, styles, purposes) into a common structure. But with building architecture, there is also an aesthetic component, and the aesthetic component can sometimes be more about art and expression. In the end, I don’t know if it so much a quest for the best architecture, as it is a quest for the right architecture.
It seems to me that in some respect software architecture should be more similar. How can we talk about what the best architecture is, if that talk transcends a given project, application or solution?
Already in the relatively short life of software architecture there are various identifiable architectural styles, time periods, building elements, and reusable patterns. Our goal as software architects should be to draw upon these learned and proven things and apply our knowledge and unique abilities to architect the right solution. The quest for the best architecture, when it transcends a given project or problem domain, can often cloud our judgments. It becomes difficult to architect the right solution, if you enter a project or problem with what you believe to be the best architecture before you’ve even started.
Similar to a building architect, we should be asking many questions. What type of application is this? Is it a game, a hardware driver, a business automation system, a data entry / data collection system, a business service, or an enterprise solution that might be made up of a bunch of business applications? Who will use the solution and how? How will the solution or the applications in the solution interact with the environment; i.e. what type of other cooperating systems, databases, file storage, networks, etc. will there be interaction. What system quality metrics will be the most important; security, performance, scalability, availability, usability etc.? Additionally the architect should be thinking about how this solution may evolve in the future and what type of minimal extensibility needs to be core to the design.
Does this mean that it is wrong to talk about and dissect architectural styles outside the scope of a specific project, application or solution? No. Does this mean that it’s wrong to talk about Object Oriented concepts, outside the scope of a specific project, application or solution? No. Does this mean that it’s wrong to talk about Service Oriented concepts outside the scope of a specific project, application or solution? No. Is it possible to judge either of these concepts as "better" on it’s own, outside the scope of a given solution or problem domain? I’d say no. So Object Oriented concepts or styles can be used when architecting a solution, and Service Oriented concepts or style can be used when architecting a solution. Can both of these concept or styles be used when architecting a software solution or are they mutually exclusive? I’d say yes, both can be used when architecting a solution and no, they are not mutually exclusive. I’d say that they both answer different problems and concerns and provide different value to the overall solution, but at different scales. I’d also suggest that when viewing a large solution from various scales of magnification, you might see only Object Oriented concepts being applied, or only Service Oriented concepts and not even realize that both are playing an important part at each various scale. It can almost become an example of the fractal geometry of nature*. This isn’t always the case, but can be part of the overall art, science or manner in which the right solution for a problem has been organized, built and integrated; i.e. the architecture.
So, lets forget about the quest for the best architecture, or the assumption that we have already found it. Let’s continue to recognize repeatable software architecture styles, patterns and practices. Let’s continue our quest to use out art, science and manner of organizing, building and integrating to build the right solution to today’s problems, and creatively solve the problems of tomorrow. As we do, new repeatable patterns in our work will be recognized which solve new problems and some will be important enough that they become known as new architectural styles. And still others will build upon these. Architecture is an art, a science, a manner of building things, but it’s not a concrete product and there isn’t a single best.
Note: I don’t know too much about building architecture. More accurately stated, I don’t know anything about building architecture at all, save what any common person learns by casual observations. Oh yeah, and a few years ago I read Ayn Rand’s "The Fountainhead", in which I think I learnt a little about objectivism with a dashing of architecture :-)
* By comparing the relationship of Object Oriented concepts and Service Oriented concepts coexisting at various scales of measurement in a single software solution to that of the fractal geometry of nature, I was exploiting Mandelbrot’s discussion of Richardson’s work on the research of the length of coastlines; in which Richardson suggested that the measured length of a coastline changes as the unit of measurement changes. Mandelbrot used this concept to help explain how self-similar patterns can be repeated to produce shapes with infinite length but finite volume. I remember this being explained to me years ago by a math teacher with a length of string. You can look at a length of twine from a far distance and see a perfect straight line. Look a little closer, and you might see a rough course grained surface of fibers that make up the twine. Look a little close still and each of these fibers appears to be a straight line, a little close, and you again see a rough course grained surface on the fiber itself, etc.