Discussions

News: An Architect's Perspective on Application Quality: Part 2

  1. The responsibility of an architect is to define applications that are functionally accurate, performant, robust and reliable. These characteristics, according to Allen Stoker, can only truly be achieved with a focus on quality. Stoker believes that the overall key to higher quality is the adherence to a well-defined process. And most importantly, this process should be followed consistently to ensure easier auditing of quality and also reuse. Another essential element to quality applications is a set of requirements.
    Requirements must encompass both functional and non-functional aspects of the system including performance and reliability, and are the primary communication medium for the definition of quality goals. The combinations of both functional and non-functional requirements are critical to the development of an appropriate architecture. The development of use-cases helps to foster the communication of true requirements, but always be sure to limit the requirements to "what," not "how." This minor point can become a major issue. If you allow yourself to fall into the "how" trap, you may limit yourself later on the options for implementation. How is a design question that should not be asked until all requirements are identified and can be considered in relationship to each other.
    Stoker and Ottinger go on to discuss the importance of communication, community and strategy to quality production. Read An Architect's Perspective on Application Quality: Part 2. Do you focus on a consistent process and defined requirements in application development? What actions do you take to ensure quality?

    Threaded Messages (17)

  2. In an organization where ten teams follow ten different processes it is difficult (if not impossible) to audit quality across the teams. When a process is followed consistently, deficiencies in the process become evident and can be addressed with a common solution increasing the quality for all project teams.
    I think that attempt to unify processes and align all 10 teams is futile and counterproductive. All the nature ecosystems work best when there is diversity. Monocultural ecosystems systems are manmade (lawns for example) but they are all unstable and require great expenditures of efforts and resources to maintain. Companies are miniature ecosystems and therefore should mimic natural ways because they were refined over millennia for efficiency and stability. In finances key to profitable portfolio is ‘diversity’. All big companies strive to diversify their business to assure stability and long time survival. Why do we require software and methodologies to be the same? I do not advocate anarchy, I do think that it makes sense to minimize number of used techniques, but the number should be greater than 1.
  3. Hello, it's 2006, not 1970[ Go to top ]

    Authors state: "I believe that the overall key to higher quality is the adherence to a well-defined process" and "How is a design question that should not be asked until all requirements are identified and can be considered in relationship to each other." OMG! Why do I hear the sound of a waterfall here? First off all, software development is "new product development". It cannot be successfully predefined with a "well-defined process". Secondly, we have over 30 years of experience that "gather _all_ requirements and then do design" does not work (waterfall). I also think that the content of this article is quite weak and it lacks focus. In my experience, in terms of software architecture and quality, it is important to: a) use iterative and incremental development model b) define quality metrics and setup testing environments and tools as early as possible c) gather _architecturally significant_ requirements early. This does not mean that you need all requirements. In fact, you mostly need to get the non-functional requirements and of course a general idea of the problem domain. d) test continuously and test all artifacts (not just code). Use continuous integration, TDD, automated tests, automated code review tools etc. from day 1 when you start writing code. e) get the "skeleton architecture" implemented first (and as early as possible) by using risk factor as priorization method. Make sure that the skeleton architecture can do the tricks required by the business logic (based on best current knowledge of business requirements). f) test the skeleton architecture rigorously (performance, scalability, recovery, security etc.) and make sure it meets the quality requirements. Make sure you test the architecture with estimated real user loads. Also test the limits, when does your architecture collapse under load? Then the team can start implementing the actual business logic (still iteratively and incrementally). Finally, if the new system uses existing systems, it is very important to test the system integration as early as possible and as often as possible. Stubs, mocks and drivers are essential here.
  4. Re: Hello, it's 2006, not 1970[ Go to top ]

    OMG! Why do I hear the sound of a waterfall here?
    I had the same feeling even when reading the first part of the series. The second one just confirms it.
  5. Re: Hello, it's 2006, not 2000[ Go to top ]

    OMG! Why do I hear the sound of a waterfall here?

    I had the same feeling even when reading the first part of the series. The second one just confirms it.
    The XP hype is over. Solid Software engineering practices are back!
  6. Having worked at one of the largest companies in the world that stressed process and adherence to more traditional waterfall development, we were consistently behind schedule and full of bugs. Switching to iterative development with rapid prototyping, you can run circles around other teams. It is a main reason why this company eventually dropped adherence to the process and transitioned to a more iterative approach. Managers whose teams went agile met schedules and gained more notoriety. You still need to spend some time gathering requirements. Not just business requirements but load expectations, in-house technical expertise, etc. People who attend a single meeting and start writing code 9 times out of 10 find out they implemented the wrong thing. But, writing a test application and throwing it out there for customers to see can give you 1000% more feedback than a document. If anyone thinks that spending weeks in meetings discussing the intricacies of tiers and clustering and adopting all the new buzzwords into a product will give you a better solution should guess again. From my experience, a majority of applications implement technology not because it was the right choice, but because they bought into the hype and thought 'we may need it some day'. As far as architecture, in the end its all about the interfaces and the data model. Just make sure someone is paying attention to that. My two cents, Mark drop.com
  7. Re: Hello, it's 2006, not 1970[ Go to top ]

    Secondly, we have over 30 years of experience that "gather _all_ requirements and then do design" does not work (waterfall).
    Time for a reality check. Waterfall and other traditional, heavyweight, big-design-up-front methods have worked and still work. Here's one study with some numbers: http://www.stsc.hill.af.mil/crosstalk/2005/03/0503Humphrey.pdf I don't know what the numbers would be for agile projects so I can't say how well or poorly agile compares to BDUF for large projects. But to say that they don't work is absurd. Do you really think that all software projects prior to the advent of agile were failures?
  8. Re: Hello, it's 2006, not 1970[ Go to top ]

    Hey, heres a radical idea: What if *all* types software projects cant fit into one process? What if some software benefits from a waterfall approach and some from a agile, xp, whatever approach? What if "rapid prototyping" isnt the best way to implement OS/390, or land something on far, far away planets? What if long requirements gathering phases arent the best way to kick of your next web project? No, cant be...there must be ONE process...there must be a magical silver bullet...
  9. Time for a reality check. Waterfall and other traditional, heavyweight, big-design-up-front methods have worked and still work. Here's one study with some numbers:

    http://www.stsc.hill.af.mil/crosstalk/2005/03/0503Humphrey.pdf
    I don't understand how figure 2 in this paper can be construed as a vindication of water fall. I read this figure to indicate that success rate approach zero as project size increases, with a 50 % chance of success disappearing around $1 million project. The rest of the article also seems to be at least as compatible with agile as waterfall. Did you actually read the article before you posted the link? I fail to see how statements like these are compatible your view that "waterfall and other ... big-design-up-front methods have worked and still work.": "These plans [for what Watts characterizes as a successful project] extended through 19 releases over a period of 30 months" "Most projects have major milestones such as specifications complete, design complete, code complete, and the like. The problem is that on real software projects, few of these high-level tasks have crisp completion dates ... coding usually starts well before design completion and continues through most of testing."
  10. Re: Hello, it's 2006, not 1970[ Go to top ]

    I'm not sure why this article was linked. The evidence that the waterfall process works is the fact that modern business depends upon projects - some of them very large indeed - sucessfully 'completed' using that process. There may be better methods, and of course the 'waterfall' methods may have been poorly described, but those are different stories.
  11. Authors state: "I believe that the overall key to higher quality is the adherence to a well-defined process"
    I think we all agree. In your post, for example, you detail your personal well-defined process.
    OMG! Why do I hear the sound of a waterfall here?
    Dunno. Bathroom noises ? ;-) Certainly the phrases 'well-defined process' and 'waterfall' have no relationship.
    First off all, software development is "new product development".
    Actually, something like two thirds of software development effort hours are spent on maintenance.
    we have over 30 years of experience that "gather _all_ requirements and then do design" does not work (waterfall).
    Actually, we have over 30 years of experience that (waterfall) works. That's why banks running their old-fashioned COBOL programs are successful today. By the way, is there a relationship between the phrases 'gathering requirements' and 'getting powerful people in the organization to support you' ?
    In my experience, in terms of software architecture and quality, it is important to:

    a) use iterative and incremental development model

    b) define quality metrics and setup testing environments and tools as early as possible

    c) gather _architecturally significant_ requirements early ...
    Here, apparently, you agree with the original poster and go on to define your own process.
    This does not mean that you need all requirements.In fact, you mostly need to get the non-functional requirements ...
    Really ? Just the 'non-functional' requirements ? Forgive me for being ... well, less than completely trusting, perhaps, about your process ... but how do you test the scalability or reliability of the system when you don't understand the transactions the system must handle ? Maybe you will need to understand just a smidgin more than the non-functional requirements ... maybe just a pinch more ... like, perhaps, ALL of the important features of the software. Every single darn one of them you are telling me you will build. Because, frankly, if I talk to a guy who assures me that my product will scale even though he does not know the features my product will have to support ... frankly, as I say, I am reluctant to hire that guy. Maybe it's just me, but I prefer dealing with architects who actually know what they are contracting to build. Nah, I was only kidding. It's not just me.
    ...from day 1 when you start writing code.
    I think we all understand by this point that if we start testing the day we start writing code we are much too late to catch the expensive mistakes.
    Stubs, mocks and drivers are essential here.
    Well, of course they are not. There are more ways to build and test software, Horatio, than are dreamt of in your philosophy. And so on ... why is this in any way controversial ? Adherence to a well-defined process leads to reduced execution and training costs and is a key to continuous improvement. It matters less which process you choose as long as you work on continuous improvement. Choosing the process that fits your people is more important than choosing the 'best' process. Man, it's like saying that Mom and apple pie are good things ... can't we just move on ? As for the ecosystems guy ... it might we worth considering that human beings could actually improve on a model that relies upon the death of the majority to bring about change. A natural ecology is not a happy place to be ... which is why human beings have chosen not to live in one since we figured out how to avoid it.
  12. A natural ecology is not a happy place to be ... which is why human beings have chosen not to live in one since we figured out how to avoid it...
    Those are two most absurd(and dangerous) misconceptions.
  13. Elaborate ?[ Go to top ]

    Are they ? We generally build houses, after all. Perhaps you consider New York a natural ecology ? Or maybe we are just disagreeing about words ...
  14. Re: Elaborate ?[ Go to top ]

    Perhaps about words. We are not alone building houses bees, birds, and others do that too. http://www.resurgence.org/satish/kumar-nature.htm As for NY, of course it is part of ecosystem, very poisonous part (as every big city), but that is the separate issue. NY is part because it cannot exist in isolation, nothing can for that matter.
  15. Re: Elaborate ?[ Go to top ]

    Perhaps about words.
    We are not alone building houses bees, birds, and others do that too. http://www.resurgence.org/satish/kumar-nature.htm

    As for NY, of course it is part of ecosystem, very poisonous part (as every big city), but that is the separate issue.
    NY is part because it cannot exist in isolation, nothing can for that matter.
    Yeah, it is words - well, mostly. Birds and bees do not build houses. New York is part of an ecosystem, but not part of a natural ecology. It is an artifical part we have created. We created it because the natural alternatives sucked even worse than New York ;-) My point was that human beings can improve upon natural processes and that we should not necessarily regard the natural world as the standard of excellence. Of course it is equally foolish to totally disregard the natural world ...
  16. Re: Elaborate ?[ Go to top ]

    Yeah, it is words - well, mostly. Birds and bees do not build houses.
    Hmm, how about this guy? http://www.arthurgrosset.com/sabirds/rufous%20hornero.html
    We created it because the natural alternatives sucked even worse than New York ;-)
    It is the assumption. Even we suppose that it is true it does not mean NY is that good. I personally find many other cities to be more habitable than NY.
    My point was that human beings can improve upon natural processes and that we should not necessarily regard the natural world as the standard of excellence. Of course it is equally foolish to totally disregard the natural world ...
    Sure we can improve, I just against calling every human deed and endeavor "improvement". BTW:Ethan, It is better to move out 'philosophical' discussion offline. Please email me if you want to continue.
  17. Why it is just the architect's job to worry about and deilver quality is beyond me. All parties drive quality. It's like a Ouji board. How is quality different for a car, a Mars probe or a porn site. Go back and read the article an see how silly it sounds for each of these cases. Why is software so different? What are the drivers of quality? What are the forces on the project or system that drive quality. Read Zen and the Art of Motorcycle Maintenance about quality. Applying a process, requirements, and people only gets you part way.
  18. Quality IS everybody's job, but it may be the architect's responsibility to ensure that jobs is being done effectively. Maybe not.
    Why should it not be different ?
    LOL Read Deming about quality.