Qualities Attributed to the Architecture

Functional requirements describe how a system delivers value. However, the quality attributes of those functions will make or break it. For example, if your functional requirment is about something that takes you from one city to another, I have a car to sell. Really cheap, for that matter.

Every system has an architecture. It may be elegant or it may be ugly. It may be described or it may be unknown. But it is.

Architecture is what determines the qualities that the system delivers. Is it fast? Is it secure? Can it be extended? Does it scale?

The qualities you strive for should determine the design of the architecture – not the other way around.

What do I mean with quality, then? I’m not in the philosphical mode today so there will be no Zen-talk. I’m simply refering to measurable requirements such as response time and throughput. Quality to an engineer.

Some say non-functional requirements. I’d say, stop saying that!

You can’t have response time without refering to a function or a group of functions. E.g. all interactive functions. Therefore, "response time" is an attribute of those functional requirements.

Since it is an attribute, it does not live on its own. There has to be a functional requirement, at least one. Also, functional requirements always have attributes even if they are not determined or poorly understood. Remember the cheap car? Well, forget it, it disintegrated on the way to that other city.

So, once you have understood what quality attributes are, why should it matter? Well, my point is, it is about the design of your system’s architecture!

It is how you divide your system in components, software-wise and hardware-wise, how these components interact and how new components can be added, that determine qualities of your system.

Say, you like security for your website. Is that a requirement on the website? No, it is the requirment on some of your pages. You probably have at least one public page.

So you decide you need people to login with name and password. That doesn’t make your system deliver any value to anyone, it only lowers usability. But still, you need that security so you put in some components for that. Considering using LDAP? Well, here comes a LDAP-server to your architecture.

Not all quality attributes determine architecture but those that do, are really handy when it is your job to design the architecture. They help you by narrowing your design options. Stay tuned.

You think architecture means Big Design Up Front (anti-pattern from the agile community)? Wrong. Every system has an architecture, regardless of you did it in increments or in one go.

5 responses on “Qualities Attributed to the Architecture

  1. Well spoken Per. I’d like to add a couple of points to the importance of architecture.

    1. The architecture has a great impact on the long term cost of the system. A system with a poor architecture is more error prone and harder to maintain. The longer a system i planned to live, the better architecture you need. Unfortunately the maintainability of a system is often not considered when building it. You rarely find the maintenance organization as one of the stake holders in the beginning of a project.
    2. A good architecture makes implementation so much easier. Now that we develop stuff faster than ever in short sprints with time to market in focus, there is a lot to gain in doing this in a well functioning architecture. It’s simply faster.
    3. I totally agree that architecture dos not imply BDUF. The architecture is (as many has recognized the code to be) in constant evolution these days. Therefore it’s important to make your architecture refactorable and always improve it in small steps as you add functionality to the sytem. Otherwise, you will end up in an alley where the only way out as a big bang.
  2. I agree with most of what you guys say, but the problem to me is that I don’t really like your definition of "architecture".

    I am fond of the definition that says that "architecture is the part of your solution that is hard to change". If we look at a system after the very first sprint, where is the architecture? The answer must be that there is barely any at all. And everything can be changed in at most another sprint.

    The problem with your definition, "Architecture is what determines the qualities that the system delivers", is that it implies that much of the architecture is already there after the very first sprint, since it may not be "fast", "secure" or "scale well". I don’t think that is reasonable!

    The implementation may be slow, insecure and scale poorly, but you can’t really say the architecture lack these qualities, since there isn’t really anything there yet.

  3. There are many things that can be hard to change that are not part of the archtecture. Evil bugs, for example.

    You are making the same mistake as many are doing in the agile community; just because you are implementing only a fragment of a complete system in the first sprint,  it doesn’t mean there isn’t an architecture.

    If you like, view the architecture as the master plan for how you are going to build your system. The master plan can be there before you put the first stone in place. It will contain stuff like principles, choices of technology, an overall design of the system. The architecture is there, although only a small part of it is visible as implemented code.

    In an agile project, the architecture may change as you go along. It should evolve. That’s one of my points in my previous comment. But it should be there all the time – don’t stop doing architecture just because you are agile.

  4. Well, you don’t really change bugs, you fix them. But I see your point. And I still don’t agree.

    What you mean is that a piece of code can have an architecture that isn’t implemented in the code. But does that make sense? I don’t think it does.

    What if the master plan is lost (assuming it was written down) and its authors were hit by a bus. That would imply that the implemented system suddenly lost its architecture. How was that possible? I think the only reasonable assumption is to believe the architecture is an attribute of the implementation.

    Lets assume a systems architecture could exist outside the implementation. Also lets assume the system is old and the original developers have quit and new ones have been assigned that doesn’t really know the system too well. Lets finally assume the new developers believe, from an incompetent or incomplete look at the code, that the architecture is built on JMS. Does that assumed architecture reflect reality? No. So, what is that assumed architecture? It is nothing!

    Finally lets assume we have a system built according to a blueprint architecture. At sprint planning there’s a long discussion (against all practices…) to change a lot in the blueprint architecture. Now, the existing code has one architecture, and the blueprint has another. Which one is correct? Can both co-exist?

    My belief is that only what exists in code can have an architecture. What you talk about isn’t architecture, but maybe a plan for the future architecture.

  5. Every system has an architecture, even if it is a small system.

    So your tiny thing doen’t scale? Well, it is the architecture that is talking to you.

    It is not your functions that make it scale bad, it is your divisioning of the system into components and allocation of resources that make it behaving bad when another 10.000 users try to log in.

    Any description of an architecture, call it blueprint, SAD or whatever, is a – description. Like a map, it may have some resemblance with reality.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.