What Is Architecture Anyway
What Is Architecture AnywayDefining Architecture
We constantly bandy the term "architecture" about on the C2 without really knowing what we're talking about. So, how about a definition?
Architecture is the base, irreducible, and immutable set of rules defining how a system operates.
Now, you can choose to express these rules as UML diagrams, as flowcharts, as I/O data path charts, as some other kind of drawing, or as straight-up text. The point is that the architecture identifies these rules and makes a distinction between what is immutable and what may be transitory by exclusion. Architecture is what you have to have in place to make the product work at all.
Here's another definition for you:
Design is the application of knowledge, understanding, and technology to solve a system.
So, design is the process of slogging through the raft of available solutions, seeking the best one that can be had with the current knowledge, understanding, and technology. Design will match hardware, software, and systems integration into one big, happy product conclusion.
But you know what? You still need one more definition:
Implementation is putting design into practice.
Just as there are multiple designs that may fit, there are multiple potential implementations to any particular design. Implementation is about seeking the best match of technology to design, all within the limitations imposed by the overall considerations.
Guess where program code fits into this scheme? You got it, bunkie - it's implementation! Hey! That means the software is being created to meet the requirements of a particular implementation of a particular design for a fixed architecture. The whole discussion of source code as design or source code as architecture is total bunk.
Once one realizes that the discipline of engineering solutions to systems doesn't involve shooting from the hip, the software tends to settle down somewhat. Until then, these pointless discussions will continue to clog up the C2 Wiki and other online spaces with endless blathering about how agile and lightweight XP and other methodologies are, without ever dealing with the basic questions about organization first. No methodology will cover up the holes left by a lack of organization.
This page is an opinion with an asshole.
Okay, and you are -- what? An asshole with an opinion? [Sorry, couldn't resist.]
Meh. Architecture is not immutable, just difficult to change.
BZZZT! You Are Wrong, Sir! The whole idea behind architecture being immutable is that you simply don't change it at all. That's why it's architecture and not design. If the client requires a change in the system that can't be accommodated by the existing architecture then we have to talk about a new product, not some "change" in the architecture. Otherwise we'd never know what we're making.
Architecture defines what is immutable so that you don't have to accommodate changes that are so drastic as to try to make a new doodad out of the old dookickey. Hey, man -- this architecture defines a sow's ear. No matter how you dress it up, trick it out, or talk it through, you ain't gonna end up with a silk purse. If you want a silk purse then we're gonna hafta start out with some silk.
Your argument is fallacious, MartySchrader. You present word-games with "change" and an idealistic premise that architecture does avoid change based on your belief that it should. Were I to accept the definition of "change" you apply above, I would need equally to reject the notions that designs ever change (i.e. "we have to talk about a new design, not some "change" in the design, otherwise we'd never know what we're implementing!"). Regardless of your word games, the fact remains that we'll start with one architecture and end with another and we can point at a continuous history of tweaks between the two endpoints. Bugs can just as easily be part of the architecture as the design or implementation. Requirements analysis is never complete: what we want, what we intend, and what we need are ideas that we refine over time. The decision between a silk purse and sow's ear is not always known up front.
The entire point of having an architecture is so that we know what we're making in its base, irreducible, and immutable form. Design can change all over the place to accommodate new technologies, changing market conditions, BlahBlahBlah. Architecture can't change like that. Architecture defines the product under development as a doodad versus a gimcrack. If you want us to build you a doodad we can accomplish that. If you later decide that you really wanted a gimcrack, well, that's a new product development project.
And as for knowing that the architecture will meet the actual requirements of the original product specification, well, that's what formalized inspection and other zero defect process is about. If you can't get your sales/marketing/whatever group(s) to cooperate, then you won't have a product spec worth a hill of beans anyway.
I know that I've written quite a bit here on the C2 about the usefulness of formalized mechanisms in converting requirements into product. It isn't a matter of Big Design Up Front or any of that claptrap; it's about figuring out what has to remain fixed and what can change -- within the boundaries of the established architecture. The decision about whether a product is a silk purse or a sow's ear has to be made before any development decisions can be made, otherwise you won't know what you're making.
You do not counter any of the fallacies. You merely repeat yourself. You are not an authority on the 'definition' or 'point' of architecture. It is clear that other people disagree with your definitions, and you have no solid ground to call them 'wrong' for disagreeing. And I doubt you can provide a consistent definition of 'change' (independent of the definitions of design and architecture) that allows allows design to change yet keeps architectures immutable. Why should someone accept your definitions, MartySchrader?
See below.
Defining "architecture" as things that cannot ever be changed is not agile. On agile projects, there is nothing that cannot be changed.
If you're making purses out of sow's ears, and you want silk purses, then you can stop using ears and start using silk. You might need to retool. But you can do it. -- JeffGrigg
Well, then, we're not talking about any kind of hardware-based product. In the embedded systems world a change in fundamental architecture means a change in the underlying hardware, and that's an expensive and heavily front-loaded alteration to the project's path. Go ahead and "do it." I'll watch. -- MartySchrader
So you're limiting software development to just that portion used in embedded systems. And using that to define the rest.
Yes, I've done embedded systems, programming hardware. And yes, the hardware does change during the development cycle. The hardware has bugs and design flaws too. And after a successful release of a software-driven hardware product, there is often a market for improved versions of the same. Consider the iPhone: As extraordinarily well designed and well crafted as it was and is, are all iPhones today exactly bit-for-bit the same as the original iPhone? -- JeffGrigg
I am not limiting the discussion here to embedded systems, although that is my primary area of work. I use hardware-based products as a very tangible example of the need for solidifying architecture before attempting to build a product. The definition of architecture as being the unchanging and unchangeable rules behind a product's design is so that there is a central formulation for the product regardless of changes in actual hardware, the implementation of services, etc. Yes, it is possible to implement an architecture in a variety of ways, with a variety of hardware/software platforms supporting it. I am currently working on a data collection and reporting system that will run on at least three different OS platforms and a wide variety of underlying hardware, but the baseline of functionality will be consistent because all implementations will be built on the same architecture.
If you don't want to accept my definition of architecture then please come up with something better. Something complete, whole, encompassing, definitive, accessible, and without murk nor holes.
If you don't want to accept my definition of architecture then please come up with something better. Something complete, whole, encompassing, definitive, accessible, and without murk nor holes.
Architecture, Design, and Implementation are convenient names for different 'stages' in development of a system. There is, otherwise, no significant difference between them. (The English language is full of examples of the same 'substance' having different names based on context and stage: Data, Information, and Knowledge. Magma and Lava. Asteroid and Meteor. Cloud and Fog.) When working on each stage, it is convenient to treat all the stages below it as immutable. For example:
There are programming models that reflect this sort of arbitrary 'static staging' of platforms, i.e. modeling 'towers' and 'stacks' of languages, macros, interpreters, protocols. I do favor such languages. But I tip my hat to the ultimate mutability of everything, and thus focus on staged ReactiveProgramming and LiveProgramming models.
At this point we are forced to AgreeToDisagree, since you are not providing a solid definition for architecture and are not even willing to concede that it has a fixed meaning. I have offered a definition that meets the needs of engineers in any discipline and covers any development environment. I will let this stand on its own merits. -- MartySchrader
I did provide a solid definition. Architecture is a stage in development of a system. That is a fixed meaning. Staging is relative, but so are 'velocity' and 'altitude'; your personal preference for a fixed perspective is unnecessary. Your definition remains fallacious, and your belief that engineers need a definition of architecture is just plain pretentious. Can you find me even one example of an engineer who demonstrably failed due to a poor definition of architecture? Does your definition somehow make engineers more efficient or their designs more robust?
To address the matter of architecture being a "stage" in the development of a system, I agree that it is a stage, but not the way you put it. For instance, your treatment of data, information, and knowledge as equivalent is totally, completely, absolutely wrong. Data is raw measurements, such as 1.37 volts DC. Information is derived from that measured data, such as "the door is 3% open." Knowledge is derived from that information, such as "that durn kid failed to completely close the refrigerator door again." The measurement of 1.37VDC doesn't tell you that yer kid didn't close the frige door. You have to have the information and knowledge aspects of handling these entities to achieve that, and even then you still need one final aspect -- wisdom -- to know what to do even with the refined knowledge. In this case, you know to yell out, "Hey! Get back in the kitchen and close the frige door!"
As for the steps in development, it is more than convenient to treat the previous step as inviolate -- is it vitally necessary. Otherwise, we'd never be able to meet the requirements of building a product. The only time our work should force a change in a previous step is when discovery uncovers a failure of vision or a previously uncovered defect.
As for engineers failing because of a bad definition for "architecture," I'd instead point to many, many projects I've worked on that suffered bad architecture or none at all. (Although there have been a few that claimed to have an "architecture" that was anything but.) By contrast there have been lots of large scale projects in ongoing support of products that had a clearly defined architecture with definitions firmly entrenched. The Motorola EMS series of cellular telephony switches comes immediately to mind, as well as the Tellabs Cablespan network, or the old Bell CO switches.
As for efficiency and robustness, ask Motorola about the EMS 2500, its longevity, and the people who supported it. Ask them if it would have been possible for hundreds of people working around the world to have created and maintained such a product without a rigid set of definitions in place. I think you'll get the answer the next time you use a cell phone.
There is no unique floor for "raw measurements". We can always regress. Consider: how did you acquire the value 1.37 volts DC? Some sort of image processing, right? You look at a voltmeter and, by some process (character recognition, or counting tickmarks and interpolation) derived a value 1.37 volts DC. If it's a multi-mode voltmeter you might also examine the mode, or remember it. We can regress further - by what process did the voltmeter come to present the value we interpreted as 1.37? A digital voltmeter likely has its own internal CPU to process data that we never see.
Whether the `1.37 volts DC` is raw data or derived information ultimately depends on whether you're looking forward at how it is to be used or looking back at how it was acquired.
Meh. You're confusing your idealism with reality again. You are not the authority on `requirements of building a product` or what `should force a change`. People can and do design successful products while acknowledging various instabilities, even accommodating them in the design process.
I don't see valid points here. At best, you confuse correlation with causation and draw your correlation from a cherry-picked (and thus biased) sample.
It is unclear to me what you aim to contradict.
[EditHint: MartySchrader removed the above comments from their context, and should provide indicators (i.e. Re: ask Motorola...). Terrible etiquette, Marty. Shame on you.]
[Really? When somebody injects stream-destroying comments into the middle of my writings I'm just supposed to live with it? Nice try. Butchery is still just that.]
[You're free to edit, of course. You don't need to "live with it". But there is an etiquette to removing comments from context. Do you feel better about yourself for your petty revenge?]
<Oh, you ain't seen revenge yet. But let's not clog this space with useless crapola, shall we? And let's not inject our diatribe into the midst of someone else's discourse. There's your "proper etiquette" for you.>
Without wishing to delve into trivia, let's just say that there is a floor for the level of data any system needs to process. The transformation of that data from raw samples into the wisdom of decision-making doesn't happen without the entire mechanism being planned out strategically. Architecture defines what happens at what stage of processing as well as what the stages themselves are. Without an architecture the responsibilities of the system's components could change back and forth as work progresses or discovery takes place. You'd never know what component is responsible for what work.
I agree there is a floor to the level of data any system needs to process. But, in practice, we don't need to strategically plan out entire mechanisms to transform data and make decisions. And even if a system changes as work progresses and discovery takes place doesn't mean we don't know - at any given iteration - which components are responsible for what work.
Exactly wrong. The whole point of creating an architecture is so that we know what components are responsible for what work. And if discovery reveals an epiphany about the interaction of components that is so profound as to cause a change in architecture then we really didn't know what the heck we were doing in the first place, did we?
You keep speaking as if you're an authority on architecture. You aren't. You're a man with an opinion. And regardless of architecture, whether it has a point, whether you even have it, your sentence: "You'd never know what component is responsible for what work" is simply untrue.
No, my statement is precisely true. Even using tools like CRC cards and such leaves out too much in the overall planning of a system. I Know Of What I Speaketh, me laddie.
Your entire argument is well summarized by that last sentence.
My argument is summarized above in clear, concise language. If you refuse to acknowledge that then there's nothing for us to discuss. Sorry, Charlie.
Martin Fowler proposes defining architecture as “things that people perceive as hard to change.” -- http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
In Patterns of Enterprise Application Architecture, Martin Fowler outlines some common recurring themes when explaining architecture. He identifies these themes as:
Some goalposts move on their own, as if they were affixed to ships and blimps and subjected to the occasional storm. Some are hidden in a fog, and we need to guess where they are and give it a good shot, tweaking our architectures accordingly. If we can influence their direction, or anchor a few of them down, or find a few that are unlikely to move, that's convenient. But often we must be agile, creating solutions that can (with minimal effort) hit moving targets and be rapidly adapted to moving goals - open, adaptable, extensible, mutable architectures. Some problem domains are more `fluid` than others.
The point of establishing an architecture is to define the limits of flexibility. Otherwise your development project would be like one of those buoys, but without the anchor to hold it at station. If you don't want your product definition to be flopping about like a sheet of newsprint in a spring wind storm then use an architecture to nail down just how much variation you will allow.
That's the point of any design, any framework. Architecture is not absolute, just relatively (by design) less likely to change than design goals and implementation.
No. This is the very heart of the definition. The reason you need an unchanging architecture is because something has to be fixed, otherwise you never end up with a product.
Your logic is incredible.
My logic is entirely straightforward and in line with what the professionals who establish norms for the rest of us say. I am not hiding behind some strawman nor putting my head in the sand.
["...professionals who establish norms for the rest of us..." Good heavens. What magical property makes your so-called "professionals" more attention-worthy than any other random idiot?]
[As for the rest of this page, it's dire. If you want a real definition of "architecture", look in a bloody dictionary. In an information systems context, "architecture" is nothing more than the process of designing systems or the results thereof. Any extension to or deviation from that meaning is either idiocy or arrogance, and quite possibly both.]
Spoken like a true amateur. Those who refuse to acknowledge the need for a fixed set of rules around which to base a system are the same ones who complain that their buggy, sloppy, non-deterministic code is more "flexible" than hard validated code which complies with a rigid set of requirements. Such are the hackers who hang around the edge of professional software development.
[Whoa down there, Sparky. Where did I "refuse to acknowledge the need for a fixed set of rules around which to base a system"? I have no issue with that at all, though we usually call it "the requirements". What I do have an issue with is your misuse of the term "architecture". For some identifiable time period, only the requirements must be considered immutable; the arrangement of systems to meet the requirements is the architecture. If the requirements change -- and often they do -- then a new set of rules applies and a new architecture may be needed.]
MartySchrader has acknowledged that we might need 'new' architectures and products. The word he's misusing is "change". Arguments of the same flavor: I didn't change the file; I deleted the file and replaced it with a new file with the same filename. Or: I didn't change the toilet paper; I removed the roll and replaced it with a new roll. Similar arguments are sometimes made regarding state modeled in purely functional languages by people who don't grok the relationship between state, time, and identity. Whether the object of change is "the architecture" or "the toilet paper", such arguments are all foolishness or sophistry. "Change" is always defined relative to an object identified at two different times (the answer to 'what changed?') and it really doesn't matter whether the change was achieved by edit or replacement.
[Good point, but what I'm opposing is Marty's definition: "Architecture is the base, irreducible, and immutable set of rules defining how a system operates." That's not any recognised definition of "architecture". It's closer to "requirements", except requirements are often reducible and mutable. The possibly-reduced and fixed (for some period of time) "rules" are used to decide on architecture.]
Requirements probably shouldn't define "how a system operates". Most architecture descriptions seem to focus on relationships and communication between sub-components, and there are often many architectures that could meet a set of requirements. I would concede an argument that architecture usually closer to 'how a system operates' than are requirements. Requirements often do include how to interface with a product, of course, and I think that might have been what you meant. I find the 'irreducible' and 'immutable' more problematic. Irreducible expression is often difficult to decide or comprehend (like KolmogorovComplexity), and immutable requires unrealistic levels of foresight and often inefficient BigDesignUpFront.
[Indeed. Note that I wrote "closer to 'requirements'" -- for some vague value of 'closer' -- rather than "is the requirements". Regardless, requirements are (or should be) used to decide on architecture. Does Marty think it's the other way around?]
It is not unrealistic or unusual for architecture to heavily influence requirements; but that's a whole different discussion involving iterative or evolutionary development processes. I think Marty would say we need a new product (and hence a new architecture) if we have new requirements. My hypothesis is that MartySchrader's opinion is formed by PrematureGeneralization from long experience in a problem domain where products are fielded and change (e.g. code or hardware update) becomes infeasible. The cure would be sufficient experience in problem domains where requirements are incomplete or change is cheap and in high demand (R&D, web services and web apps, custom business widgets and reports).
[The most dogmatic often appear to have considerable depth of experience, but little breadth.]
Yeah, that's phunny. To be clear: yes, my experience comes in a realm where the underlying hardware is difficult to change and has long lead times. This is what prompts the bulk of the need for a clearly defined product before development work ever begins. However, the hardware considerations aren't the only contributing factor in the generalized definition of architecture, nor is rock-solid hardware the only driver for an unchanging architectural baseline in developing any product.
Even in the case of web applications (which I still do when the work comes to me -- I don't actively chase it any more) ya still gotta know if it's an online dating service or a long term preventative maintenance scheduling system that you're building. You can't have both, so pick one before starting.
The point of establishing an architecture, as I have repeatedly said, is that you know what the limits of change are going to be before you begin to create a product. Note that this is product development, not pure R&D, nor discovery, nor any kind of experimentation, but after all of that. If you are creating a product then you have to know what you are building before the work ever gets started. All that experimentation stuff shoulda already been done before you commit resources to building something that you intend to sell to somebody else.
Contrast: SoftwareEngineeringIsArtOfCompromise
EditText of this page
(last edited January 18, 2014)
or FindPage with title or text search