Software Architecture
Software Architecture''This page was created about a reductionist definition formed between CharlesWeir and JamesNoble.
Note that it is also the title of DavidGarlan? and MaryShaw's work "Software Architecture: Perspectives on an emerging discipline"
SoftwareArchitecture is what is left when the code has crumbled.
JamesNoble (in a phone call to CharlesWeir)
Hi, guys! I find this a clever reductio, but not one that much serves the person on the project. Is there a way to restate / readdress it to make sense to a person about to start, or having just started, a project? -- AlistairCockburn.
p.s. I think of "architecture" as roughly synonymous to "global decision(s)". Thus it makes sense to refer to the process architect(ure), system architect(ure), workstation architect(ure), etc., a way of referring to the term which has worked well for me.
Wouldn't Alexander's patterns be a counter-example of this? Architecture without reference to any "global" decision? Nothing restricts architecture to be only top-down architecture. -- MarcGirod
What works for me is to think of the SoftwareArchitecture as the set of decisions that we have to live with for the life of the project or system because it will be too expensive to change our implementation later if we change our minds.
So if you ScatterSqlEverywhere, your choice of database was an ArchitecturalDecision?. If you use some of JensColdewey's ObjectRelationalMapping ideas, the database can be changed so it was not an ArchitecturalDecision?. --PeteMcBreen
I would be willing to agree "the set of decisions that are hardest to change". I worked on a system that ScatterSqlEverywhere, and refactored it so it didn't. It was a pain in the neck to change, but it was affordable considering the alternatives. I thought of what we did as changing the architecture. In fact, many Smalltalk systems undergo a change of architecture during their lifetime that is nearly as extreme as adding a basement to a six-story building. And I don't think Smalltalk is unique in that regard. I think of the work that Microsoft did to retrofit Office applications to COM. That had to be an enormous amount of work, but they did it incrementally and didn't throw out their old code. --RalphJohnson
Great praise for Microsoft there and thoroughly deserved. --AnonymousCoward (just in case my WikiCredentials? suddenly time out)
The issue of how to "change the architecture" during an ED/XP project is well worth discussing, from my experience. I freely admit to nurturing a raving dislike of the word architecture in the last ten years. I suggested "tough choices" as an alternative a while back on Wiki purely to try to puncture the balloon of damaging pretension that often seems to surround the term. I'm much happier with the meaning I hereby compose from this page of
architecture = global choices that are tough in the important sense that it's likely to be very expensive to change them any time in the foreseeable lifetime of the project.
Some of my worst experiences in evolutionary projects in the last ten years have had the even more horrible verb "re-architect" associated with them. Worst case is when the programmers are groaning under a real or perceived need to "re-architect" just as the business SuccessStatement's undergo radical change from steady state to highly volatile again (what I heard TimMackinnon call a StoryStorm recently) - without an increase in budget. See for example the hedge fund project in ChryslerAndSteadyState. Without Microsoft's kind of development budget it's not always been easy to keep the evolutionary show on the road in such circumstances. Any ideas? --RichardDrake
The flowing life which comes from the sense of order in chaos, or if you prefer, from unity in diversity, as well as vice versa, which is the realization of the contradiction inherent in Architecture, ... -- AynRand
Hmmm. I've read loads of pages here and I don't see a consistent definition of "architecture". Fair enough, I'll throw my hat in the ring. For starters, I agree with those who think the term has been abused to mean "high level system design". I don't think that is useful and stems from certain parties wishing to be addressed as "Architect". For me architecture is the structuring of a space to do a job. In the computing domain, the space is composed of computer equipment; the job is some set of logical requirements/constraints. For me that includes macro-level logical constraints e.g. contingency, scalability; as well as micro-architectural concerns such as thread boundaries.
--RichardHenderson. Technical Architect :).
I think of architecture as something put in place to support something else. In the case of software, I think we are supporting our assumptions about what is common and what is variable across the "problem" domain. As the problem domain evolves, so do our commonality and variability assumptions, and so must the architecture to support them. When I was thinking about this I realised that if we refuse to rearchitect, we end up force fitting variability into places previously assumed to be common - we call this "hacking", and waves of hacking lead to nasty layers of implicit architecture on top of the systems legitimate architecture. These are horribly difficult to unravel.
Software architecture is the belief that since some sort of diagram representing the software can be drawn after the software has been developed, that same diagram could be drawn before development starts.
I would also like to note that in use outside of software development, "architecture" mostly refers to a general style not a blueprint for production. For example, think of Gothic architecture. Architects don't usually produce architecture.
Nope. Gothic is a style of architecture, despite imprecise usage.
The SoftwareEngineeringInstitute's web pages about SoftwareArchitecture can be found at http://www.sei.cmu.edu/ata/ata_init.html They have a collection of definitions at http://www.sei.cmu.edu/architecture/definitions.html that are quite interesting.
Architecture defines "how things are done." Each project gets to pick the levels at which they will have an explicit architecture. Architecture develops regardless of conscious effort.
Generally you have to decide things like:
But half of these topics are SoftwareMethodology, they are not SoftwareArchitecture. So, SoftwareArchitecture is NOT "how things are done". That is a bad definition.
SoftwareArchitecture has something to do with the "structure" of software. Though if you believe that SoftwareHasNoShape then the fact that SoftwareArchitecture is so important is quite ironic. (See also SoftwareHasShape, though I tend to come down on the other side, i.e. the shape is subjective and a bit arbitrary.) -RalphJohnson
But half of these topics are SoftwareMethodology, they are not SoftwareArchitecture. So, SoftwareArchitecture is NOT "how things are done". That is a bad definition.
Your definition of software is very narrow. If you understand what software is and how it is made and by whom it is made and to whom it is sold, the definition is appropriate. For someone who considers software only that which gets compiled, then i guess it is bad.
SoftwareArchitecture is the system combining:
moved here from ArchitectingWord
Here's my 0x0010 cents worth about Architecture:
As a youngster, I can recall asking my grandfather if there was such a thing as someone who was both an architect and an engineer (no knowledge of software at the time, but i sort of knew i wanted to be both). He didn't exactly say no with his reply, but what he did say has stuck in my mind "If you ever become an architect, the most important thing is to keep the user foremost in your mind"
So whether it is a building or some software, UserCentricDesign? is an important principle.
It seems to me that whether or not some structure is classed as "Architecture" is not something that goes in by design, but is something that is culturally determined many years later after having stood the test of time.
An aside:
Q. How do you tell the difference between a building and architecture?
A. Architecture is when the roof leaks.
e.g. 'Falling Water' by FrankLloydWright? --MartinNoutch
I'm sure there's some parallel for software here!
Sure there is. If you explicitly design a house (or a piece of software) to be "beautiful" or "artistic", then it will be uncomfortable and lacking in utility. Buildings (and software) should not be designed to make an artistic statement, but to meet the needs of their users. But we all knew that already. --MikeSmith
I think we all have to remember that SoftwareArchitecture is still an emerging discipline. Remember, it was only a few years ago that MaryShaw et. al. published Software Architecture: Perspectives on an Emerging Discipline. I honestly think your view of architects in such vaulted esteem relative to other roles only serves to exacerbate the problem we are having in the field of Software Development. Why are they more than engineers? Why do you see engineering as only a stepping stone to become a holy architect? IMO, regardless of the field, design is what architects do --- in some field they also supervise construction. It's only the focus, context, or scope that separates the building or building-parts engineer from the building architect. I don't consider that I am exalting myself to some lofty position. Instead, I consider that I am trying to bring more design to software architectures in the way of QualityAttributes, Styles, Patterns, and ProjectStakeholder Communication. I only call myself a software architect out of convention -- why not call building architects building designers? Why give it up? Because some people have an emotional reaction to the term? Personally, I believe humans tend to make language a lot more complex with their emotional baggage. The trend towards SoftwareArchitecture should be welcome thing, something that we should be encouraged to advance. We shouldn't cower in the presence of the word and exclaim we are not worthy.
As to the subject at hand -- What is software architecture, do we need it, and why should we care? Or Why should we even try when it will only pale in comparison to that true art of building architecture? I will go back to Booch's dog-house example. It's OK to build and fix a dog-house. You don't need a design upfront. If you don't get it right the first time, you can simply make some additions. You may even be able to apply some of these ideas to creating a log-cabin or improving your house. Unfortunately, you cannot use these same techniques to build or modify a sky-scraper. In fact, even if you did it for your own home in any significant way you'd probably violate scores of building codes. Until recently, most mainstream software systems were more like dog-houses. They were relatively simple and the operating systems they ran on were small. However, hardware systems, operating systems, and even users are becoming more and more complex and as a result, need software more akin to a sky-scraper (BTW, how great is that word sky scraper) than a log-cabin. Unfortunately, most software is still built like dog houses or barns.
We can clearly see that something is wrong when 70% of all software projects either fail or are canceled. It wasn't long ago that IBM failed on an 8 billion dollar contract with the US Federal Aviation Agency to create the next generation of air-traffic control systems. Another visible failure is United's Baggage Claim system which delayed the opening of the Denver International Airport by one and a half years!! Peter Neumann has catalogued thousands of these failures in his Risks Forums at http://www.csl.sri.com/neumann.html. Research shows that these systems lacked a coherent architecture and plan. There were plenty of specifications, lots of structures, but no overall sense of ConceptualIntegrity. Once construction began, it was a free for all. Despite all the specifications and structures, these systems were essentially using CodeAndFix -- a specification is not a design. At a certain point, fundamental design problems were addressed by tacking on left-over cedar shingles. OK for a dog house, but not for these sky-scrapers. I suppose what scares me so much about XP is that the passionate embrace of TheSourceCodeIsTheDesign could just be another way to logically rationalize CodeAndFix -- just a more sophisticated evolution of CodeAndFix. After all, as software engineers, this is what we are used to -- the source code, the implementation. However, if you read the original article on which this concept was based (i.e. JackReeves), you can see that he is very much in favor of DesignUpFront -- much of his point was lost in his own analogy to physical engineering and manufacturing. What he calls detailed design many assumed mean a priori design.
Back to the terminology and its definition. I have more on this in my response to Martin, but if I were pressed to say exactly what I thought Software Architecture is I would say it is the embodiment of various QualityAtttributes? using Styles and Patterns (or Metaphor's if you wish) and is represented by the structures of a system and their relationships/interactions. These might include construction quality attributes and operational quality attributes. It isn't any structures that make up the architecture, but the relationships and interactions between the structures. What's important here is that a SoftwareArchitecture must be more than the sum of its parts (i.e. structures).
moved here from ArchitectureDefinitions
Well, look at Building Architecture. Even architects in this field disagree and this discipline has been around for centuries. If we can't get a consensus among this field, why would you think we could get a consensus in an emerging discipline like SoftwareArchitecture?
However, I think I may have been too abstract when I made the statement structures are a software architecture's implementation. The point was not that a SoftwareArchitecture does not have structure or structures, but that it is made up of structures. To me this seems intuitive, but apparently not to anyone else. So, I'm certain I won't be able to communicate this well, but I will give it a shot. First, I imagine if you are using your field as a reference point for software design, I think you will be disappointed.
Software design is unique in many ways -- it is not tactile but it is visceral. Something else that is odd is that almost everything in software is a metaphor for something physical. Even in math software, the software is a metaphor for the actual algebra. Everything in software design is metaphorical. Think of any software system with a good or a bad design. For example, Quicken provides a metaphor for your checkbook. A Word processor is a metaphor for document. Even a real-time control system provides a metaphor for the system it is controlling. Unlike buildings, you don't see the software's design externally, one can only see the design of its user interface. I can think of many other fields that share this property. As a result, using analogies or abstracting from existing disciplines usually tends to dilute what is unique about software. But, I suppose analogies do that in general. As WilliamBurroughs said, language is a virus. With that in mind...
In software, a structure (maybe more properly a 'sub-structure') is just a component of an entire system. A single software structure has no value on its own. However, many structures can conspire together under the direction and ConceptualIntegrity of an overall design in an attempt to embody a complete system that is operating as a metaphor or a collection of metaphors. This is my take. However, this is kind of touchy-feely, so lets turn to the literature. My favorite is from LenBass? et. al. and taken from SoftwareArchitectureInPractice:
Once again, SoftwareArchitecture is a relatively new concept -- an emerging discipline. As such, what it means is changing and evolving. Personally, I think that is a good thing as it shows momentum and forward progress. However, it is clear to me that we cannot continue to develop software whose design is really the design of its implementation or user interface. Finally, just like any good architecture, I imagine that great software architecture captures some sort of QualityWithoutaName.
Robert, this 'definition' sounds awfully 'waffly' and subjective to me, (like one or two other page-debates raging at the moment!) I've read several of the pages 'defining' software architecture(s) but I think I may have ended up agreeing with those who consider the appropriation of the ArchitectingWord etc inadequate/misleading when applied to software and to what programmers do. There again I might just be being defensive! --MartinNoutch
from CanAnArchitectureEmerge:
I'm a skeptic. I strongly believe that an early vision, and the subsequent architecture that emerges to implement that vision, is the key to success. --JimRussell
I think most lightweight process that avoid BigDesignUpFront do recommend some kind of 'vision' (Its the Metaphor in XP) that guides development but I think that structure emerges. --TomAyerst
[DeleteMe. Jim's concern seems more about the value of emergence without guidance of vision, as opposed to the premise of whether architecture can emerge. Different topic?]
Perhaps -- But I'm not willing to define as "architecture" that which remains when the implementation is done. How about "that which remains when the implementation is deleted"?
OK, I probably shouldn't have used the 'A' word when I started this page but 'CanHelpfulMacroScaleStructureEmerge?' would have been a bit unwieldy (and probably wouldn't have been what I meant). On another page I mentioned AntNest?s, these have macro scale forms and structures (termite colonies are even more impressive as they include air conditioning) with specialized areas and construction techniques and modifications for local conditions. These 'emerge' from the interaction of very simple agents acting, and interacting, locally. The question is can we do something similar in software development. --TomAyerst
Or "Can we let something similar happen in software development?", or just "Does it happen there?". As far as I am concerned, it does. -- WaldenMathews
In my view, a SoftwareArchitecture consists of components, languages and their relations. A component uses languages to implement other languages. Uses and implements are the relations. The most important property of a language is that it lacks dependencies to other languages, which makes it reusable. All systems can be described with this terminology, but it is only when you actively design the system focusing on these concepts you will get a system that is easy to understand, test, and document, where it is possible to split up the implementation effort, and where the components and the languages are reusable.
-- MarcusAndersson?
Real architects sign their buildings with their names, meaning they created those solutions. There is nothing similar in the software world. You buy a software, and there is a company behind it, not a person. Even with Linux, you don't download Linus' software, you download Mandrake, RedHat or SuSe?. Also there is not a city in which the building is inserted in the case of software. Windows would be the city, but the software might or might not follow Windows rules. Either way, software architects are only needed when the programming model is too complex for developers to understand, as happens with J2EE (JavaTwoEnterpriseEdition). I bet the same happens with .NET.
Architecture is about form, fit and function. The architectural style defines the form. The customer's requirements define the function. The architect's task is to fit these requirements to the style. -- PeterLynch
Originally at IsqArchirecture:
The relation of Architecture to Internal Software Quality
There is an old joke.
All to often there is no architecture. The software just happened, it was created by many loosely cooperating developers, the original policies have been forgotten.
Even more often the software has simply outgrown its original structure. The result is kludge upon kludge upon KludgeItTillItWorks.
But no matter, it is never too late to get yourself an architecture. It is always better to get a right one early, but it is never too late to start.
''Rule 1 of Software Architecture for Internal Quality - Everyone is an Architect!"
So you coding away happily and you come to a point where you must decide...
Hey Presto! You're the SoftwareArchitect. Without the title, without the fat paycheck, but you're it. What you must not do is just leave it there.
So sit down now and start thinking...
Do not try to predict the future. Buildings change over time. Walls get added and removed. Windows become doors or disappear altogether. Decks and extensions are added. Software is even more adaptable then buildings will ever be. Don't try to be the defender of the faith against the invading hordes of programmers. Some of them may actually be competent to make their own decisions.
The civil engineers have a word for it. Embuggerance. The architecture has become lost in the flood of change. Refactoring and everyone's an architect are the only tools we have against it.
SoftwareArchitecture Links:
See: SoftwareArchitectureExplained, InterestedInSoftwareArchitecture, SystemsArchitecture, SoftwareArchitect, CanAnArchitectureEmerge, ArchitectsDontCreateArchitectures, WhatIsArchitectureAnyway
EditText of this page
(last edited November 5, 2012)
or FindPage with title or text search