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 »

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 »

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 »

28/03/2008 by Jon.

Following on from my earlier post The Trouble with Documentation I went off and bought the SEI book by Paul Clements et al. I’m now working my way through the book with the intention of applying much of what it says. My hope is that this will help to kill off, or at least calm down, some of the on-going arguments that always seem to ensue. How detailed is high level design? What should we put in the design documentation? So how long is this design work going to take?

If the blurb on the back cover is anything to go by then help is at hand. I’m just hoping that the book can deliver on the promise.

I’m going to try and blog some of the interesting points I come across, mainly so that I don’t forget them, but also to explore them a little more. I’m not going to reproduce the book, that would be both illegal and rather pointless, but I do want to dig around some of the key ideas. I like to think that I’m a fairly practical architect, in that I work on projects with customers the whole time. Having tried out many approaches and techniques over the years I often find that while the theory is great the rigour tends to tail off when you get down to the practicalities. Given the authors and heritage of this book I’m hopeful this won’t happen.

To be continued….

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

Posted in Views and Beyond, How to Architect | Print | No Comments »

12/03/2008 by Jon.

Following on from my previous post about Practical Loose Coupling

So what is going on? What has happened to wreck havoc on what was probably a perfectly good set of systems? Let’s try a little exercise to see if we can simulate the effect.

First let us start with two nicely designed systems; System A and System B. System A needs to get some information from System B, for example the price of a product. Now the implementer of System A decides to play by the rules and use the interface already provided by System B. The designer of System B had realised that the price information they held would someday be useful to someone. They included in their design an interface which given a product code would return the corresponding price.

Now not wanting to state the obvious, but are we clear what an interface actually is? Sure it is some method or call you can make but is there a more fundamental point here? The interface is a contract. A contract is a way of saying, if you do this for me, I will do that for you. If you pay me some money then I will design a system for you; or give you a car; or fly you to the other side of the world. An interface contract is no different. If you send me some data formatted in this way, and you send it using this technology protocol, and you provide this type of security credential, then I will give you some data back; or update a database; or whatever. I may also insist that you take another action first, or follow-up with another action, such as a commit, before I will promise to do what you ask. The point is that the interface is far more than the specific call you make; there may be a whole set of activities that we both have to do in order for the desired result. At this point I get a mental image of of two tropical birds taking part in an intricate courtship dance. Wheeling and twirling in just the right way. Ensuring that no foot is put wrong. Unfortunately most interfaces are far less interesting and much less productive.

So back to our example. Our two systems are busy with their courtship dance. System A understands, by way of the interface contract of System B, what it needs to do. It creates a request in just the right format, it invokes the right type of communication technology and presents it credentials. System B takes the request from the communication stack, checks out the credentials and looks at the request. Assuming all is well it will find the price information and put it back on the communications stack and send it on its way back to System A. All is well in the world.

Posted in How to Architect | Print | No Comments »

10/03/2008 by Jon.

Developing good quality architectures is the what the Architect is there to do and there are many good architects who can do this. What often stops them from being great Architects is the communication of their thoughts and ideas. In fairness this is an incredibly difficult thing to do as there are usually many ways of describing the solution and, most importantly, many different readers or stakeholders.

The key point is that documentation is fundamentally about communication. The Architect has a mental model which they need to get into other people’s heads. The medium to do this is documentation as it provides a way of doing this in a communicable and durable way.

What this means is that the first step to good documentation is understanding your audience, also known as your stakeholders. This is where the trouble becomes apparent. What you need to communicate to a software developer is not the same as that for a network engineer. Then there are project managers, technical design authorities and of course senior executives

So how do we resolve this; how do we produce one set of documentation which adequately describes our solution and also meets the needs of our different stakeholders?

An approach which is gaining ground in the architecture world is that of views. Essentially this approach says that while there is only one solution, there is more than one way of looking at it. Some people also talk about the concept of filters or lenses as ways of distinguishing between different views.

The first step in this process is to list out your stakeholders; not all of them, just the ones who you need to communicate with. Then try to understand what they are looking for, what do they need to understand? You can then shape your deliverables around their needs rather than yours.

The approach is not perfect and takes some getting used to, but the outcome is something that is far more valuable, useful and hopefully appreciated!

If this sounds a little theoretical then there are quite a few resources to help you get started.

The Open Group Architecture Framework has a whole chapter on architecture views which can be found here.

The SEI have embraced the concept of views and have a template plus other information here.

Some of the SEI team have also produced a book on the subject which is available at Amazon.

There is also an ISO standard which much of the above but unless you are really interested in standards the above resources will be more use. The page on Wikipedia provides more details

Posted in How to Architect | Print | 1 Comment »

10/03/2008 by Jon.

Loose Coupling is good. Tight coupling is bad. A familiar mantra for any system designer. The problem with loose coupling is that it is incredibly fragile. Without constant care and attention it can easily whither and die. The challenge that the architect often faces is justifying what can often be a nebulous concept to a project manager who has a deadline to hit. So what exactly is loose coupling and how can the architect stand up for it?

To help get some clarity it is a little easier to talk about the opposite effect. Tight coupling is all too familiar to anyone who has worked in a legacy environment; the effects are all too evident. Systems that can’t be changed because it will break something else. Database schemas which can’t be updated because someone has knocked up a quick query rather than use the agreed interface. Changes that take so long and cost so much to implement that there is no business case for carrying them out despite them clearly being the right thing to do. Sound familiar? Well that is tight coupling in action.

In the next post we’ll look at an example to see if we can understand what happens with real-world systems.

Posted in How to Architect | Print | 1 Comment »