• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Software Architecture: Industry x State of the Art

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I'm an undergraduate student who studies software architecture as a "researcher apprentice" as we would name around here.

My question is pretty much explained on the title. Often, as a young researcher I hear that for software engineering in general industry is way different than the start of the art. Sometimes, people mention that "we" as researchers add way too much stuff that are not really used in the industry. Sometimes due to the lack of time, or budget some documentation might go out. You can tell that by the tons of diagrams, and loads of sheets of paper we do while at an undergraduate course at computer science.

So, seeing that this book is related to advices from experts specially at industry, as I saw at some comments at Amazon about the book, what would you (the author) think about this? Are they related or not? And how much?

I've also seen on the book glossary that there is some discussion about patterns which is also a focus of my research study. How do you see patterns being applied at industry?


Thank you!

~ Carlos
 
author
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Answering in my capacity as editor of 97 Things Every Programmer Should Know, contributor to 97 Things Every Software Architect Should Know, and co-author of POSA4: A Pattern Language for Distributed Computing and POSA5: On Patterns and Pattern Languages:

  • The 97 Things Every Software Architect Should Know book is very much about current state of the practice and working what is known as opposed to innovative directions for the future.
  • Research must necessarily focus on things that are not being done, otherwise it will only encourage stasis and the status quo.
  • Research must also necessarily focus on things that are being, otherwise we will miss opportunities for understanding why thing work and how we can improve them based on accumulated rather than hearsay or forgotten knowledge.
  • I have a strong interest in patterns, particularly in connection with the previous point, but a fuller discussion is definitely beyond the scope of the current thread. If you are interested patterns from a research and study point of view, I would strongly suggest POSA5.

  • Hope that helps.
     
    Marshal
    Posts: 75857
    361
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    It is quite surprising how people in industry are happy to lag behind the "cutting edge". If they have a technology which works, they will stick with it, even though it is ten years old.
     
    Carlos Andrade
    Greenhorn
    Posts: 4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hello,

    Thank you Kevlin for your reply!

    Regarding the POSA book suggestion, the first POSA book gave me a very interesting definition about patterns (architechtural, design and idioms). Is also of high interest to my research to identify Bass (2003) tatics on patterns, and quality attributes, which on literature seems to be still growing.

    I've noticed more work done on POSA1 suggested architectural patterns than GoF (Gamma) patterns as well.

    I'm going to check POSA5 as soon as possible for more information regarding this matter, thank you for your suggestion :-)

    As I agree as the pattern discussion would require much more details which is out of the scope of this thread, I would like to ask more other few questions related to software architecture and which is also related to my thread name. Seeing there are a lot of things i'm curious about things architects should know, one or other question might not be appropriated for this discussion, so please feel free to skip one or more (or even all of them) if that applies!

    1. For the current state of practice, how do experts see quality attributes and architecture? To be more specific, these are my real sub-questions:

    1.1 Software quallity attributes taxonomy varies among quality attribute communities (Bass 2003), SEI also has a report that dates (from 1995 if i'm not wrong)that discuss a little more about that at their website. Also, on papers there seems a constant need to state their definition so that people understand what are being talked about. How, in practice, do experts deal with this lack of standard on the quality attributes meaning, in special when it comes to architecture?

    1.2 Another thing I've been curious about is regarding how software architectures measure in practice quality attributes. So far on the literature i've seen a heavy use of scenarios (methods that i believe that are or were used at industry such as ATAM from SEI, AQA, SAAM, COVAMOF and others) normally suggest them, and much less metrics. They usually discuss that quality attributes are imprecise, and requires more context which is given by the suggested scenarios. So, how in practice do experts deal with this?

    2. Another huge curiosity I have is related to how architects design software architectures in practice. For example, for software architecture product lines i've come across UML notation from SEI and the views concept is prefered ; on a discussion with McGregor i've learned about ADLs is prefered, and on a discussion with David Weiss I learned about decision diagrams (which resembles feature models for product lines), sequence diagrams and simple text notation was prefered to document architecture. In general, what do experts prefer?

    3. How do experts use Tatics (Bass 2003), POSA architectural patterns, and design patterns (gamma) in practice? I'm aware they're very high level guidelines to construct architectures, so i'm sort of curious if this is also a problem in industry.

    4. Have you come across the term 'antipattern'? I've seen this being mentioned on the literature, but I'm also clueless if this is used in practice.

    Best Regards,

    ~ Carlos
     
    Kevlin Henney
    author
    Posts: 44
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    In POSA5 we revisit and critique the term "architectural pattern". It is more accurate to state, for many patterns, that they may be applied architecturally and non-architecturally than that they are intrinsically architectural or not.

    As an aside, the majority of research on patterns seems irrelevant or misses the point: there's a lot of research on GoF's Design Patterns book, but this is not the same as research on design patterns as a concept or an approach.

    1. Industry use of formal quality attributes is not widespread. QoS is normally described tacitly or in terms of measurements.
    2. In terms of diagramming, UML is the notation used by the majority. ADLs and other formal notations are relatively uncommon. DSLs are increasingly common.
    3. Patterns are sometimes used descriptively in communicating an architecture, sometimes prescriptively in defining it.
    4. The term anti-pattern is one we critique in POSA5. I find it misleading and not useful. It used to be commonly used, but these days it is as likely that people will use the term "smell".

    Hope that answers your questions!
     
    Carlos Andrade
    Greenhorn
    Posts: 4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hello Kevlin,

    Yes, you definely answered all my questions! Thank you again very much! I really appreciate it! :-)

    Regards,

    ~ Carlos
     
    Ranch Hand
    Posts: 10198
    3
    Mac PPC Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:It is quite surprising how people in industry are happy to lag behind the "cutting edge". If they have a technology which works, they will stick with it, even though it is ten years old.



    Might be they are not interested to spend money.
    reply
      Bookmark Topic Watch Topic
    • New Topic