Architecture Is Physical

The full statement which is over-shortened by the title, is that software architecture (like all architecture) is intimately concerned with physical issues.

For those who don't want to wade through all the argument below. Here's what has come out so far. My use of the word physical is not quite what some people are used to. The specific attribute that separates logical and physical in this usage is the matter of choice.

Physical issues cannot be wished away. To create some logical context inside some physical context is the function of architecture.

It is the literally physical world which creates the constraints/attributes we have to consider, thus linking the various logical levels down to the ground of chips and wires and magnetic stuff, but first we need to agree on this usage before I get into the mystical world of computers and how their nature affects their operation.

Architecture requires a physics, or at least the character of physical law. If software is not physical (and I believe this is the case) it's not useful to think about it in architectural or even engineering terms. What you can achieve in engineering or architecture is circumscribed by physics, often the goal is to creatively push against the physics. Software is informatic, so we don't have the guiding constraints that Architects and Engineers have. If we look at disciplines that are not constrained in this way (art, mathematics, philosophy, literature), we see the use of taste, axioms and rhetoric as necessary constraints. -- BillDehora

The first sentence makes a point I agree with. For something to be physical, it must have 'the character of physical law' and without it there is no need for 'architecture'. This moves the argument on to the demonstration that the issues that software architecture addresses have this characteristic.

The questions I ask:

Examples of architectures, please add/criticise:

Implementation:

Boundaries: Attributes: Here's the long version:

There appears to be two basic streams of thought. One is that an architect, as master builder, has a high level responsibility; and I would agree. Where I disagree is that the expression of this responsibility, which we describe as architecture, is also limited to some highly abstract level. Such an approach is dangerous. This is reflected in the building and engineering world where the architect (or chief designer) is intimately involved with the smallest functional aspects of a building.

Generally architecture is the manner in which components interact, within some fixed environment, to express a logical environment. The architecture of a system is usually described by the arrangement of functional elements in a running system. These elements, when implemented, convert the raw machine into some reasonably useful operating environment. As such these elements architectural because they express the architecture.

Microarchitecture looks in detail at the building blocks of these elements. A MultiCaster is a high level architectural pattern but it can be decomposed into a number of smaller elements which aggregate to express the architecture. Such an element is an AsyncAdapter. An AsyncAdapter allows one to decouple a sender from a receiver. If we want to split the sender from the receiver into separate threads (process boundary) then you need an AsyncAdapter. If you want to split sender and receiver onto separate machines (thread/code/referential boundaries), then the same issue applies. There will be other issues too, but there is still a need for asynchronous linking, and an AsyncAdapter is the explicit element for the job. Different AsyncAdapter s will be implemented differently depending on varying logical requirements versus varying physical platforms.

Does architecture limit itself to the glue adapter elements? The short answer is 'no'. The internal objects are not unaffected. For example they should deal with failure. If they don't then very heavyweight measures must be taken in transactional systems. The possibility of partial failure is implied by a distributed architecture therefore code which deals with this is by definition architectural. That failure code may be considered by the individual objects, though adapters can often be substituted.

Refs:

GoodArchitecture, QualityAttributes, ArchitectureTradeoffAnalysisMethod .

There exists a similar confusion about requirements. Specifically that because the requirements are not the software itself, then they must be some abstract form of the software design. I have had people react to my requirements precision with "that's implementation detail" when it was not implementation at all. It was detailed, physical description of the context. This attitude can prohibit requirements from being specific, and to use your term, physical. Michael Jackson explains quite well that making requirements very specific is a good thing, and is not identical to writing code.

Is the physical/non-physical maybe at the heart of the distinction between (1) the architecture of software product X and (2) the architectural style that product X adheres to? Or are architectural styles also physical in your book? It seems that in architecture, like other fields, there are terms operating at various levels of specificity and concreteness. "Victorian", for example, is not very specific, although it conveys a fair amount of information. "Thick plinth" is fairly physical, and might be considered an architectural detail representative of certain Victorian styles.

'Architectural style' corresponds to a metaphor. Building architecture tends to think in terms of periods, which is yet another way of cutting up the world. 'Style' is a tricky one to pin down, but it is a higher-level abstraction. A way of labelling a bunch of related entities. As such it is constrained by physical reality. It's more of a mnemonic for us poor humans who like to categorize everything.

So the 'product line' metaphor mentioned so often on Wiki strikes me as a logical architectural style. 'Pipes and filters' is a much more physical metaphor, much lower level.

If there is a physical constraint on a system such as 'it must work over a network', then it is very likely that the specification will need to get into implementation detail. I fail to see how it can be otherwise. I tend to break up specifications into structural elements and functional elements, thus all my banging on about MicroArchitecture. The functional/algorithmic elements need only be logically specified, but the structural elements, since they compose the architecture, must almost always be very carefully specified to match the physical arrangement of machinery.

Constraints may be logical as well as physical. Most people seem to get the logical bit, but the physical bit eludes them. Architecture is not only physical, but it should include the physical. Physical is the lowest level of abstraction, and must be included otherwise we are building castles in the air.

Not all detail is implementation detail

If you're building a (software) machine (in Jackson terms) that has to interact with the real world in order to bring about the real world conditions that are called requirements, then you must describe those parts of the real world that can be manipulated by your machine, and you must describe them in fine detail. Using physical analogy for example, if my real world includes a drinking glass which must be lifted without touching its bottom or any part of its inside, then the precise shape and texture of the outside of the glass need to be specified as part of the requirement. That's high detail, but it's not implementation detail, strictly speaking. But the point is almost moot, because of what an interface is. When you describe something on one side of an interface, you are strongly implying things on the other side, in this case the shape of the implementation where it touches the problem. This is different from specifying other details about the implementation, like what kind of motor it uses.

If physical is the lowest level of abstraction, then what do you call the level just below that?

-- wm

What did you have in mind?

You may mean "physical" when you say physical, in which case the only way I can make sense out of the claim "architecture is physical" is to translate it to something like "architecture is more physical than you think", or "architects are allowed to get physical". Some people think of job descriptions in software development as a partitioning of work according to detail level, not such a good partitioning. In that sense, "management is physical", "analysis is physical", "architecture is physical" are all wakeup calls. Pretty damned near everything is physical. But I agree with Ralph that if you use the word physical without qualifiers, most readers will infer that you mean objects and forces from the natural world, not logic constructs on the less derivative end of the metaphor spectrum. -- wm

Any specification is bound to be logical in some respect. Overconstraint can be a problem, but excess detail is a matter of opinion. If it isn't redundant then I don't see an issue.

Physical can be emulated too. Multitasking cpu's try and pretend to be lots of cpus. Distributed computations can be emulated in a single memory space. So 'physical' is rather fuzzy in any case. I am treating common physical situations in terms of the constraints they apply to a system.

You are not the only person who uses the word "physical" to talk about software. But in almost all cases, those people should use a different word. If something is physical then it has physical properties like mass and volume. Software does not. Some parts of software are abstract. Other parts are more concrete, but they are not physical. Software can have structure (music can have structure, a community can have structure, mathematics has structure) because it has parts and the parts have relationships to each other. But one software component is never to the right of another, though it might be to the right in a diagram we make of it. We say that one component is in another, but this just means that either one component requires another or (even strong) that acquiring one component automatically gives us another component.

I would like for people to quit using the word "physical" when talking about software. Find a more accurate word. -- RalphJohnson

A specific example, or two. Consider performance as a basic architectural attribute. Performance is limited by the technologies available. Performance is also limited by the software architecture. An efficient distributed parallel system requires a software architecture that can take advantage of it. A monolithic software architecture is unlikely to be a good fit. So the software architecture is fundamentally constrained by the target system topology. The places those constraints affect the software design are the places where architecture is visible. The individual elements which express that architecture, I call MicroArchitecture.

Another example. Reliability. Any one system can fail, indeed is likely to fail somewhere along the line. Business critical systems are usually specified to have no 'single point of failure'. This implies that each system has a backup system available. It also implies that the software that runs on that hardware can cope with one of those systems failing. Network software may need to retarget from the failed system to the backup system. Databases may need to retarget their efforts to the backup system, bringing it online, restarting sessions etc. The code that does this is ArchitecturalCode?.

From another direction. Consider the 3-tier architecture. The reason it is 3-tier is because we want to be able to separate concerns. It is more than a separation of logical domains. We wouldn't talk so much about component servers, persistence layers and presentation issues if we were only dealing with a logical arrangement of code. The logical separation reflects a desire to separate those concerns such that they may vary independently, be deployed in different locations and run on separate systems. Such an arrangement gives us a great deal of freedom because it enforces a reduced coupling between the runtime elements. As soon as we accept that the system needs to be able to run on physically separate boxes, and apply the constraints that this implies, we have a 3-tier architecture. Any software module that breaks those constraints must be adapted or we are no longer talking 3-tier. Thus the architecture is very basically defined by the system topology. In this case the presentation code (GUI), the logic, and the persistent state are constrained as if they were running on separate machines communicating over a network.

For software to communicate over a network, it must be able to move state over the network. It must also be able to execute code over the network. The code which does this is ArchitecturalCode?. The elements that make up that code can be analysed as architectural elements.

More generally. Architectural elements act to bridge boundaries set up by changing the system architecture from the simplest of models: single process single memory. They may create a more complex topology on top of a simpler one e.g. simulated multitasking on a single processor, or vice versa. The point is that architecture is concerned with adapting the resources available to the desired functionality within specified constraints. The expression of a computing architecture in the code is the software architecture.

-- RichardHenderson.

What might be the architecture of ArchitecturalCode?? Does the recursiveness of that cause any concern? "Move state over the network" makes sense to me, and sounds like REST. "Execute code over the network" is very imprecise, you might even say incorrect. I hope your ideas on the physicality of architecture don't depend on that metaphor. I sincerely wish it helped to compare software architecture with other architectures, but for me it doesn't. Our architect specified the building's girders and bearing walls, but he also specified the trim detail. And Pella windows come in Proline and Architectural series, the difference being barely discernible and purely aesthetic. Good luck. -- Walden

Fielding's definition of architecture is very close to mine. 'Execute code over a network' just means calling a method on a machine that is remote. REST is very much concerned with that. His preference is to make the software architecture as close as possible to the system architecture, which is by far the best way of doing things. There are some details where http isn't so great, particularly the client needs to act as a server in callback asynchronous interactions, but that is detail, and not too difficult to workaround.

The software architecture is expressed in the code. The elements are microarchitecture. It isn't recursive in a nasty way. To make the connection between this and building architecture, or any other architecture does require an appreciation of the concept of force resolution, where the forces arise due to the implementation context. Building architects often include aesthetics in their brief which can confuse the issue, though it is perfectly reasonable that aesthetic considerations be one of the forces that need to be resolved. Windows are an architectural element. At least in buildings :). Thanks for the feedback. I'll get it right eventually, I hope. Cheers -- RichardHenderson.

"Windows are an architectural element" doesn't tell me anything about windows or about architecture. What does it mean? Is there an example part of my house that's not "architectural"? If you could give some, then I'd have a better take on how you propose to use that (A) word. -- Walden

Purely decorative elements are unlikely to be architectural. Structural elements and functional elements are. With respect to a window you have to look at what logical problem it solves and the forces that constrain the problem to appreciate what makes it architectural.

The problem is that we wish to see out of a house, and let light in. The context is that we don't want to simply cut a hole in the wall as that allows everything else in or out, compromising the integrity of the structure. Additional attributes may be applied such as the ability to open the window if we want, we may want a certain amount of thermal insulation, we may want a particular strength, we may want it to be square etc. The resolution of all these forces/constraints/attributes is the window that you choose to do the job. It will probably be made of glass though it could be made of any transparent material. It's frame will be structurally strong etc etc. It is architectural because it serves more than just an aesthetic purpose.

The process of analysing the various forces within the context, deriving the particular attributes including logical and physical issues, ensuring that function is maintained, that is the architectural process. It is the role of the architect/engineer to do this. What you end up with is some structural form with a function. Architecture is about resolving forces. Alexander goes on about this a lot, but architecture in the building and engineering traditions has always been about this. Software architecture goes beyond algorithmic design when it is grounded in the target implementation rather than some theoretical computing space. That grounding in the 'real world', which I am calling physical issues, is what makes architecture go beyond the logical design process, which need only consider function.

Every time I try to analyze this stuff, I end up thinking that the "real world" that grounds everything is the feelings of the persons affected, and that's about all that's real. For instance, you may pontificate on the need for a window, while I may live in a depressive funk because the wallpaper's too dark. Which feature affects health more concretely? I can't tell, and for that reason I fail to appreciate the distinction you're calling "architectural" here. -- Walden

It is common in computing jargon to refer to "physical level", meaning the lowest and most detailed level, even if the physical level may not be literally physical. One example is database where you have the logical level and the physical level, and physical level has tablespaces, bits, files, pointers etc (which are not literally physical) as well as physical organization: tablespace X resides on disc Y on controller Z which has MAT of 5ms and transfer rate of 33Mb/s. In network design the physical level deals also with literally physical concepts, as well as mathematical concepts. So I guess I would give Richard a break here, he shouldn't be proving that the term physical is properly used. This usage of physical is common in quite a few areas of computing.

I'd like him though to clarify whether he thinks that architecture should account for physical level only, or for physical aspects mainly, or the integration between physical and logical or he means architecture should be physical also as well as logical. Many of his examples (like "transactional vs simple atomic" seems logical concepts to me). -- CostinCozianu

Yes Costin. And sort of yes again. Since Walden mentions postmodern, the basis of postmodern philosophy (and Buddhist) is that words only have a meaning within a particular context. So I'm not too worried about using the 'correct' interpretation, though I am curious about the wall some people have with this usage. I'm really trying to be quite literal. Still, I'm ending up with shorter and shorter definitions of architecture :).

Transactional versus simple atomic is an interesting one in that it is a logical constraint versus the physical universe. Consider two pieces of state that must be kept synchronized in some fashion. Call them A and B. They are separate things that are updated one at a time. If they could be updated simultaneously, in one go, then there wouldn't be a problem.

So the physical analog is two separate entities, constrained such that the updates to A and B must be done as if they were a single atomic operation. One may say 'it isn't necessarily physically a thing that you can hold in your hand' but the forces and constraints are exactly alike, and may be considered to be the same. Indeed it may well be an actual physical separation of the data to be updated. From the computing point of view the two may be treated identically. I tend to think that we are simulating a physical scenario.

The solution is of course to have a guardian which ensures that whenever one is updated, so is the other, or neither get updated. This is the transaction manager. The transaction manager is an architectural construct in that it generates the desired (logical) attributes in the (physical) situation. Therefore I consider it architectural much as a window resolves the desired attributes (lets only light in, can be open or closed etc.) with the situation (materials available, must fit in wall etc.).

In the end the forces/constraints/attributes may be due to logical or physical considerations, but the context may always be considered physical, or there wouldn't be a problem. Logical issues are a matter of choice. Physical issues are not. Indeed that may be the easiest way of dividing the two (I knew all these words would reveal something :)). This comes back to the idea that architecture creates a space with different attributes to that which existed before. -- RichardHenderson.

Costin, we're not holding Richard to the proper use of the term "physical". What we're doing is trying to find out if Richard has a distinction bound up in that term that can be conveyed to another human being, perhaps through the use of other terms, perhaps through the use of examples. If the distinction doesn't matter (as it seems now - read below), then I've been pursuing a mirage in this. I thought there was a strong assertion at the beginning about the essentially physical nature of things architectural. Doesn't seem that way anymore. I'm still hoping someone will shed some real light in this area. All I can glean from this page is that some code is "architectural" and that that code "does something" akin to resolving forces, where forces, resolution and physicality are all highly sensitive to a context that is probably not shared. I know when my boat's adrift, do you? -- WaldenMathews

Read it again Walden. The specific distinction below is: Logical issues are a matter of choice. Physical issues are not. That is the defining quality of physical versus logical in this context. Does that clear it up or you? Sorry to take so long to get to that statement, but intuitive things sometimes take a bit of digging out. Using this definition allows me to bridge the various domains where architecture is significant. I further argue that it is the really truly physical world which generates these issues, but that bit can wait for now -- Cheers, Richard.

I physically read it again, although clearly it was a matter of choice. The distinction between that which can be negotiated away and that which cannot seems to define a requirement, not an architecture. "Two pieces of state that must be kept synchronized in some fashion" is not a very good statement of a requirement, although it's a start. I wonder whether you could improve on that. Once the requirement is known, a minimal "machine" to fulfill it is a desirable thing, no? By your definition, it seems the entire product is "architectural", if it's a tight fit to the problem. That fails to make a distinction between useful code that is architectural and useful code that is not. If a feature (or whatever you'd call it) can be "wished away", then you oughtn't implement it at all.

So we have discovered requirement, but we're still waiting for architecture as something distinct.

If you carefully examine your requirement for "synchronized state" you may discover that a transaction manager is not the only solution, unless of course you're an "architect" in search of a problem that needs to be "architected". :-)

-- WaldenMathews

'Okay, you have the logical desire. The desire to keep two pieces of information synchronized. We can make that go away by simply changing the requirement. The bit we cannot wish away is the context, which is that the two pieces of information are separate. No architecture required until we have this collision of desire and unchangeable context.'

The collision of desire with context (part changeable, part not) is the essence of describing requirements, a la MichaelJackson. You are implying that each and every requirement calls out an "architecture", perhaps a micro architecture. I think your "architecture" is equivalent to Jackson's "machine", q.v.. I also think if you will substitute the term immutable or non-negotiable for physical, then we'd be getting somewhere. Something can be quite physical, but also quite changeable, and so will not provide a hard constraint your "machine" must conform to. As I recall, Jackson uses the term "autonomous" to describe external matter (external to us) that cannot be controlled. Are you familiar with SoftwareRequirementsAndSpecifications?

Architecture allows the requirement to be expressed on the machine. Some requirements require architectural code, and some don't. All literature on software design has to deal with infrastructural issues to some extent, whatever you wish to call it.

"Architecture allows the requirement to be expressed on the machine." Glad to hear it, but so does bibbity-bobbity-boo allow the requirement to be expressed on the machine. In fact, everything that doesn't prohibit the requirement being "expressed on the machine" (wish I knew what you meant) allows it. Okay, I'm done being silly, but I think there's a point in there having to do with crisp distinctions.

"Some requirements require architectural code." Doesn't the recursive requirement figure in that scare you a little? Can we simplify the thought? Maybe not. Either way, some examples of "requirements that require architectural code" and some that do not might be enlightening...for me. Are you just saying that some problems are harder than others? Hard problems require architectures and easy ones don't.

'Transactions need to be managed to maintain ACID properties. How would you do it?'

The requirement was not for a transaction, it was for "synchronized state", whatever that meant to the user when he said it. You haven't found that out yet, and it matters. For instance, it could be the user is willing to manage state, or just wants to know when state is not fully replicated at a given site.

I was thinking of the simplest case, where two pieces of state need to be reliably kept synchronized. I think I elaborated what I meant by that in the example. Since I am the user in this case I think I can be trusted on that one ;).

If you're both the user and the architect, then I need to apologize for butting in. If a user said to me "I need these two things kept synchronized", I would ask for a scenario or two that illustrate example and counterexample of "synchronized". Since the user cannot observe both things at the same time, there is obviously more to this requirement than you are willing to discuss. On the one hand, "throw a transaction monitor at it" is a "simple"* response, but it may miss a truly simple and elegant solution that's a tighter fit to the requirement. That means getting more intimate with the requirement, though. Not sure how this pertains to your "architecture is physical" thesis, but I smell some "architecture versus requirements" here, which is not such a good smell to me. -- WaldenMathews

I shall. We can explore this more if you like. The motivation for saying synchronized was 'transactional versus simple atomic' somewhere near the top. Consistency is the usual motivation for having 'all or nothing' semantics. A transaction manager is simply whatever code does this. Call it what you like. I wasn't necessarily thinking of anything particularly heavyweight. It can be quite minimal. Other requirements may have other solutions. In this case the specification is that two pieces of data (a non-atomic set) must be kept consistent (as if atomic). There should be no conflict of requirements and solution, otherwise, I think we can agree, it is simply a bad design.

--

The term architectural code didn't sound right to me. If you distinguish the "pipe" software from the application that writes to the "pipe", and claim that one is "architectural" while the other is "<what? applicational?>", that distinction is already covered by the terms "framework" and "infrastructure" and "middleware". But it's shallow, because if you shift your context, then the software parts change roles. Perfect example, today SOAP idiots are using HTTP as a "transport". I guess that makes HTTP "architectural", except if you're the HTTP programmer, then you're writing the application and the TCP guys are the architects. Sorry, I bail at that. Code's code, more or less. Patterns found within code are interesting. Are these "architectures" or just patterns found within code?

-- WaldenMathews

Infrastructure frameworks are certainly architectural. Middleware is also architectural by definition. We are talking about software at the end of the day so it is all code. Some code deals with infrastructure, and some code expresses function within the infrastructure. It is the former I am interested in, though in many complex systems the two issues are heavily mixed. I consider this an error.

SOAP is architectural. I don't like it much either. All that NameSpace stuff has an obvious corporate agenda, and makes it a complete mess, but I digress... It is built on HTTP and therefore the code which expresses SOAP is architectural code. The web page code which does all the getting and posting is architectural, as is TCP, the page formatting stuff is not. I can go on, but this relates to the division between architectural and non-architectural code.

The specific criteria I use to divide architectural from non-architectural is one of the (perfect) simple machine. The simple machine has a single (infinite) address space and a single thread. Code which runs in such an environment is not architectural. Code which deals with a more complex environment is architectural. This machine has other attributes like it never fails, and it runs at infinite speed and is never switched off etc. It is the machine we generally program to. Where the real-world intrudes is where architecture starts to be required. All architecture would become redundant if we had the perfect simple machine.

So to summarize, the architectural part is the part that has to be there because of immutable stuff and autonomous "agents" in the context. And it seems that it's also limited to not being part of the direct fulfillment of functional requirements. I'm getting that from your "virtual machine" description above. Architectural code is "helper" stuff for that part of the application which, due to the architectural code, can be a direct expression of application function. -- Walden

Yes. For the most part architectural code can occur at the edges of functional code. They interact, so there is always some overlap, but it seems a good idea to limit the overlap as far as possible. Unfortunately a lot of systems are not designed with this separation in mind, mainly, because architecture has been so abstractly defined as some sort of 'metaphor' or 'shape'. It is much more concrete than that. The reason many software systems do not express the attributes desired, on the platform of choice, is due to an architectural mismatch.

The fix may be to change the platform so it directly expresses those attributes (forklift upgrade), or to change the software architecture to express those attributes on what is available. Often a bit of both. For example, adding contingent reliability to a system requires two separated boxes, and the software needs to be able to deal with the various issues raised by such a configuration. These issues are very similar to those of distributed systems, since they stem from the same [physical] cause: 'one thing in two places = distribution'. It turns out there aren't very many other causes. The other main one is 'one thing shared by other things = sharing'.

See also: ArchitectureDefinitions

EditText of this page (last edited December 6, 2004) or FindPage with title or text search