29/04/2008 by Jon.

The topic of non-functional requirements has been raging for many years now and there seems little chance of it abating for some time to come. Most architects will be familiar with the issues here , particularly as they effect projects. Incomplete, unusable and sometimes missing non-functional requirements are a constant source of friction in projects.

There are a whole set of issues here but for me one of the root issues is understanding what a non-functional requirement is. There appears to be a fair amount of confusion here which is not helping us. If the architects can’t always agree and then can’t agree with the business analysts there is little hope of getting sensible answers out of the business owners.

A first step is to use a standard list of topics for what we mean. The best source I have come across are the SEI System Qualities, well described in this blog entry. Essentially we are looking at a well thought out and fairly complete list.

Agility - Agility is the ability of a system to be both flexible and undergo change rapidly. (MIT ESD 2001)

Flexibility - Flexibility is the ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed. (Barbacci 1995)

Interoperability - Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged. (IEEE 1990)

Maintainability - Maintainability is:

· The aptitude of a system to undergo repair and evolution. (Barbacci 2003)

· The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. (2) The ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions. (IEEE Std. 610.12)

Reliability - Reliability is the ability of the system to keep operating over time. Reliability is usually measured by mean time to failure. (Bass 1998)

Reusability - Reusability is the degree to which a software module or other work product can be used in more than one computing program or software system. (IEEE 1990).

This is typically in the form reusing software that is an encapsulated unit of functionality.

Supportability - Supportability is the ease with which a software system is operationally maintained.

Performance - Performance is the responsiveness of the system – the time required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes to complete a transaction with the system. (Bass 1998)

Security - Security is a measure of the system’s ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. Security is categorized in terms of the types of threats that might be made to the system. (Bass 1998)

Scalability - Scalability is the ability to maintain or improve performance while system demand increases.

Testability - Testability is the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met (IEEE 1990).

Usability - Usability is:

· The measure of a user’s ability to utilize a system effectively. (Clements 2002)

· The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. (IEEE Std. 610.12)

· A measure of how well users can take advantage of some system functionality. Usability is different from utility, a measure of whether that functionality does what is needed. (Barbacci 2003)

For full details of the references see the original blog entry above.

Now as ever with "standard" lists like this the first step is to look at it and ask yourself, "how does this relate to the problem in hand?". Personally I always split "performance" into "response time" and "throughput" as I find this useful. Usability is also an interesting one as I often work on package implementations so there is little scope for change here. As ever the art is to focus on the ones where the project faces the higher risks. The scarce resource is the attention of the project and your time so pick the ones that are most impactful on the task in hand, which will vary from project to project.

I have glossed over a key point here which would have anyone from the SEI throwing their hands up in horror by now. Non-functional requirements are not system qualities. This is the key tenet of the SEI approach. They just have requirements, no split of functional and non-functional, and then have the qualities that the system exhibits (as listed above). They have a point. It sometimes feels like a very pointless conversation when you are trying to decide whether a specific requirement is functional or non-functional. It makes little practical difference except in terms of which document the words end up in and potentially who approves them. Part of me says that the terms functional and non-functional are at least recognised by the people which gives them some value, confusing as they can be.

The compromise I tend to use is that the requirements can be functional or non-functional, but the system exhibits certain qualities, as per the list above. If you can start the business thinking about qualities rather than non-functional requirements then that’s great but we probably have some way to go as yet.

Posted in How to Architect | Print | No Comments »

24/04/2008 by Jon.

This post is part of a series based on the book Documenting Software Architectures: Views and Beyond.

We are on to page 18 now for those keeping track of these things.

The core of the approach set out in the book is the use of viewpoints. This is that when we try to describe a system it is simply not possible, or even desirable to, to do this in just one way. The leap that we as architects need to make is to ensure that what we put down in writing addresses the need of the reader, not the writer.

To use the bus analogy (see Is it a bird Is it a building? No! It’s a bus!), what the maintenance team are interested in is not the same as the accountant. There may well be some common ground, say in on-going costs, but they are looking at the same solution from very different perspectives. I’m guessing here, having not read the whole book yet, that the key is to have a commonly agreed and standardised viewpoints. Having these pre-agreed means that the architects know what to produce and the stakeholders know what to expect. This is not as easy as it sounds in the real world. It is not uncommon to find that there is some standard defined, but that it is not sufficiently explicit or even worse no examples are available.

“Every project has to produce this document”.

“Can I see an example then?”

“Er.. no”

“Then what about all the previous projects? What did they do?”

Silence.

Sounds like madness, but I’ve been there. Back to the book. hopefully the use of the industrial strength documentation standards will start to address this problem.

Posted in Views and Beyond | Print | No Comments »

21/04/2008 by Jon.

I’ve just read the blog entry Enterprise Architecture: From Incite comes Insight… which asks whether we really need Architects any more.

It seems to work on the basis that delegation of authority is the right thing to do, therefore as architects are all about keeping authority at a higher level then they are bad (although this could well be a bit of a thought experiment so I won’t pass judgement on this suggestion).

For me though it highlights something which is not quite an urban myth, but something similar.

Decisions should be delegated as far down as possible.

I have several problems with this.

1. People at the bottom (and I include myself in this) often don’t have all the facts so it can be difficult to make the right decision.
2. Generally the biggest problem I find in large organisations is making decisions at all, in which case allowing 500 people to be potential decision makers makes it harder to pin someone down to make a decision than if there is just one potential decision maker.
3. Great organisations usually have a very clear purpose and objective. This is set from the top, nowhere else. Clear direction makes successful organisations and you need good leaders who make decisions
4. People at the tops of organisations are (generally) paid a lot of money to lead them. Why let them off the hook and allow them to blame everyone else for not making the wrong decisions?

I’m all for delegation, but let’s get the balance right.

Posted in How to Architect | Print | No Comments »

20/04/2008 by Jon.

If you weren’t aware, the go-live of the new Terminal 5 at Heathrow didn’t go too well. I don’t know anyone involved and to be honest I don’t know yet what has really been going on. I’d just like to pass on my condolences to all the technical staff, engineers, software designers and testers involved. I can only imagine the grief you have been through in the last few weeks. Hey, we all have teething problems when systems go live, but not in the full glare of the media.

Stick with it guys. You will get there.

Posted in World of IT Architecture | Print | No Comments »

19/04/2008 by Jon.

Just when Microsoft thought it couldn’t get any worse, Google have hit another crippling blow to the software behemoth.

I’m happy to admit that I am of an age such that the first flight simulators to come out (in monochrome) were really cool; and I mean REALLY cool. I spent many frustrating hours trying to get that aircraft to take off from Chicago’s O’Hare airport with little success. The point is that Microsoft’s Flight Simulator holds a special place in the annals of software history.

Imagine my amazement when the latest version of Google Earth comes with a flight simulator built in!

Those guys in Redmond must be quaking in their shoes. What next? A first person shooter in Google Earth? Stranger things have happened.

Posted in World of IT Architecture | Print | No Comments »

19/04/2008 by Jon.

I’ve been thinking a lot recently about the interactions between systems; specifically the nature of batch files versus discreet transactions.

My instinct is to go for business transactions. The question is why. I think my rationale is as follows

• The business transaction is more likely to either successful or not. A batch has more chances to fail in ways not easily recoverable. If a transaction fails I can generally design the system so that it can process other transactions without having to wait for the failed one to complete.
• I can process one transaction at a time, or many in parallel. Batch has to be done completely and in sequence
• We used the batch approach in the first place because it was more efficient. We could take out table level locks and optimise processing. There is a law of software design that says that the more efficient you make something, the more inflexible it becomes. Data processing is getting cheaper but flexibility is getting more expensive. The economics have changed since we were all writing COBOL on the mainframe (although let’s not forget that many of us still are)
• Fundamentally, the business transactions approach matches more closely what the business understands, hence any changes that the business are likely to come up with are likely to be better served with the business transaction approach

So in summary we did batch because we had to. If we don’t need to any more then let’s use the approach that better supports our customer.

Posted in How to Architect | Print | No Comments »

02/04/2008 by Jon.

This post is part of a series based on the book Documenting Software Architectures: Views and Beyond.

One of the first sections (page xix) is about the picture on the front cover which shows a rather nice sketch of a birds wing. The section discusses the use of analogies and our usual staple of the “building” to help describe architecture. I am as guilty as anyone in using this as a way of explaining what I do. Yes, I do think about the structure of the system/building. No, I don’t worry too much about the colour of the screen background/carpet (apologies to any HCI specialists reading this, I do know that colour on a UI is important but hopefully you get my point).

The authors quite rightly point out that buildings are fundamentally static objects while systems and fundamentally dynamic. In fact most systems fail in their dynamic behaviour rather than their static structure. Hence the use of a birds wing which has a complex dynamic model is a far better analogy for architecture than the building. An excellent insight!

But somehow it wasn’t satisfying as an analogy. For the front cover of a book by architects, for architects, it works well. However when I tried to visualise myself standing in front of a group of business managers talking about bird wings it felt wrong. These people are fundamentally pragmatic and practical. If I start talking about hummingbirds I’m going to lose them. So what would be a good analogy?

Now I come from an engineering background so naturally started thinking about engines and alike. Again this failed the “audience empathy” test. Your average business person doesn’t care much for thermodynamics or metal fatigue. So I tried a little bigger. A car? Better on the empathy test but didn’t feel very business relevant. Then I struck on an idea. What about a bus? They are fundamentally about engineering which is good; we want to be based on good engineering practices. There are dynamic and static elements so it addresses the shortcomings of the building analogy. It has business users (the driver) as well as customers (the passengers). There are business owners (the fleet operator) and a support organisation (the maintenance team). Importantly it also meets the “audience empathy” test. We all know what a bus is, it is a common point of reference.

Now before we get too excited it is just an analogy. A useful way of getting understanding between different groups. This does not represent the birth of a new design method based on route planning and seat colours, but it might just help a little.

So I haven’t even reached the preface to the book and already the authors are making me think, even changing the tools of my job. While I will be using a different approach to theirs, this exercise has made me question what I do. I call that a good start, although at this rate it’s going to take me a long while to read this book!

Posted in Views and Beyond, How to Architect | Print | 1 Comment »