That didn’t take as long as I expected!

The new blog is at www.conceptech.co.uk/blog

The RSS feed is www.conceptech.co.uk/blog/feed , so couldn’t be simpler!

You can see the new site at http:\\www.conceptech.co.uk. There is a blog there but I haven’t yet set up the RSS feeds. As soon as I do then I will publish the new address here.

Thanks for bearing with me.

Jon

In the meantime I have managed to get a Google Apps account and have got the same application up and running. You can see it at http://cth00001.appspot.com. Full details of the application can be found on the Google help pages at http://code.google.com/appengine/docs/gettingstarted/.

Please feel free to sign the guest book!

I use Outlook 2007 for my e-mail, calendar and to-do list. The task feature is vital in letting me keep track of my work. I also use a Windows Mobile powered phone onto which I sync my Outlook information. This is also very valuable in keeping me informed and up to date.

However I noticed that  several of my Outlook tasks were not being replicated onto my phone. I tried Googling, searching Microsoft Support all to no avail. I upgraded Active Sync, re-established Bluetooth connectivity (you can tell I was getting frustrated at this point) again without success.

So I went back to the tasks in question to see if I could spot any differences. Lo and behold there was! Those tasks which had a start date which had not yet arrived were not replicated. Obvious really, only those tasks that I should be working on were put on to the phone. As a developer I can see the sense in this, what annoys me is that it took me this long to work it out.

The annoying this is that depending on how you create the task in Outlook you sometimes get a start date and sometimes don’t. But at least I know what I need to do now!

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.

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.

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.

Stick with it guys. You will get there.

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.

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.