Architectural Qualities – Availability Part 2

The last blog on availability covered Interface Availability in terms of Network Qualities, and today I'd like to turn to Performance in General. There are thousands of texts on measuring performance and on the performance of particular technologies, processors and such. Well I'm not going there…
I like to think about Performance as something that a Business user specifies as part of those wonderful "Non-Functional" requirements that I'm always on about. Customers demand performance, they demand service within limits, and we need to capture those limits in several ways. We'd like to know:
o How Many transactions they would like to make per hour, per day?
o Are there any peak times, amounts?
o If it's on-line, we'd like to know what is the maximum time a function can take.
And we'd like to know where these numbers will go to in the future for another of our Qualities, Scaleability. And always remember Minimums, Maximums, and Business-Critical or Survival values.
We need to ensure that Customers always think about these qualities at the same time they think about the functions, and they should be captured together. Then Architects and Designers are well armed with constraints during the design process, and we have a chance to go back and re-estimate those early figures before committing to buy kit.
If Customers demand a level of performance that you can't provide within the estimates, then go back and tell them, perhaps their performance requirements were too stringent? If the requirements were correct, then the Customer should re-assess their Return on Investment for the Project and determine whether to go ahead.
All Projects don't all have to go ahead, the earlier you stop one that isn't going to perform to requirements, the lower the risk of failure, and the better for all concerned.

Considering a change? – Part 2

In my last blog on this subject I was going on about Business as Usual Costs and the Cost of Change, but I would like to go a little more about the reasons for Change.
We live in a world of rapid development of technology and Software Houses are fighting just as much as we are in keeping their products up to date with this rapid change. It's all this J2EE and .Net stuff, the Internet, and eCommerce. They need to keep offering new Product, and they can't afford to keep on supporting all the old stuff, so they keep marking old Product as End-Of-Life an we, being a good, compliant and well-regulated organization keep following them on their development path.
We keep changing to the new Product, but we find there are enormous numbers of dependencies on other stuff, other Technology Products. You know this happens; you read the label and it says "Requires Java 1.4", when all your development is based on Java 1.2 and 1.3. Now, we've got a bigger change on our hands; one that involved the very nature of the logic of our Applications, and one that involves more than a quick once-over and a kick of the tires. We need to perform full regression testing, and that's expensive.
Well, some companies have gotten wise to this kind of Change, and introduced the Change Program. What's a Change program? Well, it's like a Change Project except it's bigger and more centralized. You identify all Applications and Project Managers, you check which ones have the Technology you'd like to upgrade, and start the ball rolling with identification of which Technology versions are going to migrate, which Technologies are dependent or impacted, which technology versions you're going to move, and start measuring the Project costs of the change.
Because you're doing one exercise on dependencies and migration paths, and sharing experience you're lowering costs and lowering Risks; that much is good. But have you ever considered the cost of providing sufficient kit to swap around the applications for another development environment, and another testing environment, and guess what, another production environment? And of course, you're going to be doing all your Applications together, so you'll need all this extra kit in waves, and that represents an enormous cost; frightening costs. And, guess what, you don't need it all after the whole shooting match is over, and no, what's left is the old kit, not the nice new kit, so you can't lease it and you can't get much if you try to sell it.
Yes, Change is expensive, and no matter how you try to do it, you can't avoid the costs, and note again, we haven't considered giving the business any new functionality in any of this…

Considering a change - part 1

As I work for a large company, I was considering the enormous "Business as Usual" cost of maintaining our Technologies in place for our Businesses; this typically amounts to perhaps 75% or more of total IT Budget. Does that surprise you? Well, let's consider where all the money is being spent…
First off, let's consider all the Technology we've got in place today. We've got Applications going back to the Jurassic age with lots of obscure technologies in them, in fact if I really did some analysis, I would expect to find 90% of all the Applications ever produced in the last 20 years in our organization to be still running today.
It's not hard to see why those Applications are still there, and they're probably not there to ensure that we are getting a return on investment, since that probably expired 10 years ago. The last 10 years have seen increasing costs on those Applications due to many factors - Legacy Technologies with Legacy (Consultant) Technologists. It's expensive to keep the Technologies current due to high maintenance costs, and expensive to keep the Consultants in place to support the Applications, In fact, we've got someone to cover every Technology produced in the last 20 years, here on site, sitting on their hands waiting for the day that the Applications need changing.
But we can't migrate the Applications because it would be too expensive to re-Architect completely, and we can't roll the change in with functionality change because the business really isn't changing much. It's a difficult balance, on the one hand we don't like the BAU costs, and on the other, Change is expensive.
Every Change we perform, no matter how small, requires re-build, System Integration testing, User Acceptance testing, and Deployment, oh, and people of course, and money.
IT does seem the major driver for change, and the business secondary, and this is mainly due to our policies of keeping Software current and supportable. We have Patching, Version Changes, and Generation Shifts in Technologies, and all of them require varying amounts of code change, plus the common overheads of Testing and Deployment.
In Part 2 we'll consider some other reasons for change and ways of lowering the cost of change…

Architectural Qualities – Availability Part 1

Our Components have Service Interfaces that offer functioniality to other Components, and when we talk about the Performance of our Components, we have to look at two aspects; the Component itself and the Component's Interface. But the Component's Interface is reached sometimes over a long and complex journey that is the Network...
What are the Architectural Qualities at work here on this Interface?
- (Network) Bandwith, or the capacity to carry data
- (Network) Latency, or the delays affecting delivery of the data
- (Network) Protocol, or the contract between Components to pass the data
All three of these Qualities interact in various ways to affect total Quality of our Service Interface and, you will realise, this is before we actually do anything useful functionality-wise inside the Component. Dealing with these Qualities in turn, we'll first look at Bandwidth.
Bandwidth or capacity affects us more or less dependent on the amount of data we want to pass; keep your data transfer low, and your requirements for bandwidth will be low thereby affecting your performance less.
With Latency or delay, you are the victim largely of your network topology, the numbers of routers or hops on your path, and the distance over which your data has to travel. To optimise here, you need to send data less often, i.e. lower the number of transmissions, since the latency is incurred for each transmission, and not the size of the transmission.
The last Quality, Protocol is not really solely an Availability Quality, it is also an Integrity Quality. If you have a requirement to absolutely guarantee the transfer of data, you're going to need a complex protocol involving store-and-forward methods and handshakes to support the transfer and this is going to be affected by all sorts of latencies in data stores and networks whilst we negotiate safe passage for our data.
Today, we're moving much more towards Web-based applications and centralised service because it's a compelling model, and these three Qualities are central to your design. As every aspiring juggler knows, it's easy to juggle one or two balls, but you know you're really becoming a competent juggler when you juggle with three.