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 series 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 that generally fall into the broad categories of application architecture and enterprise architecture. Read the rest at http://www.ibm.com/developerworks/java/library/j-eaed1/index.html?S_TACT=105AGX02&S_CMP=EDU .
- Posted by: Peter Varhol
- Posted on: February 24 2009 15:00 EST
- Re: Evolutionary architecture and emergent design by rags kidiyoor on February 25 2009 13:51 EST
- Interesting title... by William Martinez on February 25 2009 17:31 EST
- Re: Evolutionary architecture and emergent design by Davy the Pirate on February 27 2009 13:29 EST
Isn't architecture the "vision" for the product/service and design, a "method" to realize that vision? There is no such thing as "framework architecture" or "DB architecture", but only "framework design" or "DB design." At least, IMHO.
There is no such thing as "framework architecture" or "DB architecture", but only "framework design" or "DB design." At least, IMHO."Design" presumes that you've already got technology in place. "Architecture" usually implies either adopting new technology and making it work like existing technology (e.g., making calls to remote "services" look like simple function calls) or making new technology that sits on top of existing technology (e.g., Struts on top of servlets on top of HTTP). Some people find design easier because you know what you've got to work with. Other people find architecture easier because you're not limited to an existing technology.
Although this is a first part, and goes to the point on setting the definitions, I feel the actual architecture definition is still vague (I had to post a set of definitions myself sometime ago ). Anyway, the idea of an evolutionary architecture is interesting as a title. In several discussions I had had, the idea of an architecture is repeatedly presented as a bunch of paper with fixed ideas that will not come true after all. I argue that should not be true. Granted, a bunch of paper may define the "architecture to be", but the architecture is not ideas but the actual structure of working software at the end. So, Architects must define the final goal not as an stone written truth, but as an ideal outcome which will be supported by principles and guidelines to succeed. Those guidelines should show the path of adjustments to the ideas depending on the construction evolution. And all that is aimed to solve the stakeholders concerns (see no-the-goal-is-not-the-code-nor-the-design) In that line, and architecture is what you get at the end, and you set your goals and guides to drive the solution at the beginning, and make your decisions not as late as you could but as soon as they are in the best moment to be taken. (Yes, it is not the same). Under that idea, the architecture is something alive, that will change over time while it is being developed. It "evolves", and that is what I like about the article.
William Martinez Pomares.
Personally, I think of the architecture as the "now". It is an evolving "now" but the vision and the design are how you evolve it. The architecture is the present landscape in total. Just my $0.02