Software application development
This blog is intended to provoke discussion and exchange between like minded software application developers, engineers, architects, project managers - and keen hobbyists too.
Wednesday 28 January 2009, 12:19 AM
Fine tuning the virtual engine
As soon as I packed up my toothbrush and netbook for next week’s Parallel’s Summit 2009 in Las Vegas (aka Lost Wages), I started to tune my virtualisation sensor up a notch or two. It’s been a year now since I attended VMworld Europe and I met Parallels chairman and CEO Serguei Beloussov back then.
Since that time we’ve read much of virtualisation in terms of server consolidation efficiencies, co-related IT management and cost saving efficiencies arising from that consolidation… and ultimately there has also been talk of application virtualisation too.
From these areas, we can now pick up news of companies who provide capacity management analytics software. I suppose it’s a logical progression: first we build the engine, then we learn how to run it, then we look at the user experience – and ultimately we start to look for ways of fine tuning performance.
Before I get to the show next week and get swamped (albeit quite willingly) with messages coming from Parallels, I wonder if I can pick up the scent of some of the partner and the ‘related by marriage if not by birth’ companies in this space.
Stick a finger in the air for capacity management analytics and once again it’s Sun and CA that pop their heads over the cubicle. Smaller (I would logically imagine) but on the same side of the virtual coin is CiRBA who contend to be able to combine technical, business and resource constraints to determine optimal workload placements and resource allocations within virtualised data centres.
Well, I suppose virtualisation is all about planning for more dynamic capacity requirements, so this makes pretty obvious sense. What is disappointing about companies like this though is that they make a song and dance over their latest management dashboard and (however new and collaboratively enabled it might be) claim that it is some sort of virtual data panacea.
We get the idea – you have a neat product that looks slick and works great, so how does it do what it does then? If I’m a Formula One racing car engineer you’re not going to sell me on your new car management solution because it includes a new coat of paint and a shiny wax job. I’m going to want to look under the bonnet.
Hang on – I found a good bit with some guts. CiRBA’s web site talks about data-level integration enhancements that enable its product to be used as a centralised repository for enterprise capacity data. This repository design, it says here, combines centralised storage of capacity data with open data access capabilities.
I like it, how much have we got and how can we get to it. This is the: who, what, why, where and when of enterprise capacity management that I wish these companies would sometimes spell out to start with.
I don’t doubt that there’s now a broader spectrum of stakeholders (I hate that term) involved in capacity decision-making. But making sure these people are aware of virtualisation plans, hardware refresh schedules and other pending optimisations that affect their application systems must be a good idea.
Right – time to stop this rant. There is going to be bags of this stuff to delve into. The only trouble is I’ve used up my car analogy for virtualisation before I’ve even got to the conference next week. Any suggestions for a new virtual world parallel will be gratefully accepted. Think laterally please – start at beans on toast and work your way up.
Tuesday 27 January 2009, 12:41 AM
A Deeper Approach to Transaction Performance Management
I had been looking at transaction performance management paradigms and the differing means of data communication as they have evolved over the years.
In this context, ‘substrates’ refer to platforms if you like; bedrock foundations for a means of data exchange, essentially something that is acted upon by the data that forms business transactions. So defining and identifying differing substrates is a pre-requisite if you are going to extend upwards and examine, refine and improve performance management of the applications in the IT ecosystem.
As substrates have been developed they have, in some cases, evolved to become branded stand-alone transaction systems such as FTP, DBMS Remote Procedure Calls, standard ‘request-response’ protocols such as IBM’s DRDA or Sybase’s TDS and commercial replication mechanisms. On a higher level, these were accompanied by CRM/ERP software packages such as Siebel, PeopleSoft, JD Edwards, SAP etc.
Some argue that as corporate IT shops move towards a single data distribution mechanism in order to try and accommodate for growth, they must now look for a unified way to execute transactions along a single pipeline. A unified platform (or substrate) allows, so the argument goes, the ability to both merge and separate disparate office systems in a more natural way.
Companies that talk about transaction performance management (and it’s hard to find too many other than CA and IBM Tivoli) say that it is replacing the costly ‘Build/Deploy/Tear-Down/Rebuild model that was common in the late 80s and early 90s.
Experience has shown, we’re told, that it is more desirable to break the cycle of re-designing architecture to fit the current business model and instead develop a common re-usable infrastructure.
I asked for a contact of mine who works for a database company that operates with this type of technology for some guiding words on this subject and here's what I got.
“Self-managing transaction environments are a great idea, but to some extent these are still a fantasy. What is needed in modern data environments today is the ability to see into the inner workings of transactions so that we can track down and correct performance problems at a glance,” said Patrick Enright, director, Sybase 365.
DBMS vendors are reportedly building more ‘smarts’ into their database engines and Forrester Group predicts DBMS total automation such as seamless tuning of SQL statements at runtime (Forrester Group, April, 2008).
However, we’re a long way from self-tuning and self-managing transaction systems. Until that time arrives, it doesn’t seem like an unreasonable argument to suggest that IT resources need to manage and tune their respective environments as effectively as possible with a view to the above transaction performance issues – does it?
Monday 26 January 2009, 1:53 AM
Migration migraines: the top seven DBA data headaches
Anyway, this weekend I got to work on a project with Jason where together we tried to summarise the top migration headaches faced by DBAs like him in the workplace. Most of what we came up with was related to shoddy management (both business and technical) – and shoddy management with a poor appreciation for real-world data use case scenarios.
So please, grab two aspirin (or your preferred painkiller of choice) and see if you think we hit some of the top pressure points:
'Free image source: Morguefile.com
1. Migration has come about due to some corporate edict that is politically-driven from a business perspective and not necessarily rational from a technology perspective. It will therefore, by its very nature, never be truly efficient at its core.
2. The current staff base are not well trained on the new migration platform and the necessary skills planning has clearly not been put in place or thought through at this stage.
3. A large-scale merger is being pushed through and your IT stack is being forcibly pulled towards (or away from) your new parent company and migration is happening because it ‘must happen’ rather than because it ‘should happen’.
4. Re-platforming of applications is being done in order to decrease costs and increase efficiency, but a thorough cost-benefit analysis to quantify this procedure has not been carried out.
5. Migration is being undertaken with a view to it being an opportunity to improve the quality, quantity and storage of data. But storage issues are not the most relevant focal point of the IT system in question – more pertinent issues should be addressed first.
6. While every development environment is unique, it is sometimes suggested that only about 20% of it is actually different – meaning that 80% of the issues are common to all environments. That commonality points to an opportunity for automation in a migration situation – but it is an opportunity that has been overlooked.
7. Migration is being carried out as a result of the your CTO’s misguided and poorly researched decision to try and keep ahead of the next technology wave. Has he or she forgotten the old truism that states: “there is no such thing as legacy systems, this is just technology that works.”
If you withstood the pain threshold required in order to glance over this then thank you – and further thanks if you feel you can comment to steer us towards areas that we did not cover or pay enough lip service to.
'“Data stack lock down: when you REALLY don’t want that migration to happen!”
Approved image use courtesy of Luica Mak, independent freelance photographer.
Thursday 22 January 2009, 12:52 PM
Obama Wikipedia page under possible security attack?
A casual Google search for the term Obama brought up standard news results and his own dot com home pages. The fourth result was his Wiki entry, which appears to be the genuine site at: http://en.wikipedia.org/wiki/Barack_Obama
In between repeated visits using both a Mac and a PC accessed from the US and the UK, Obama’s picture was periodically replaced with a distasteful image and on some occasions no image (in the mug shot frame) showed up at all.
One user in the UK reported that the page listed the following response: “This site is now semi protected indefinitely in response to an ongoing high risk of vandalism.”
The essentially collaborative nature of Wiki’s of course means that they are “open” to external third-party input; whether this was compromised today it is not known.
At the time of posting this blog, the page appears to be functioning normally again.
Thursday 22 January 2009, 2:03 AM
Do mobile developers do IT with a social conscience?
But do they carry that thought process through to think about the implications that their software may have upon the everyday consumer in normal usage scenarios?
The reason I ask is that a complaint was filed last week with the Federal Trade Commission (which exists to: Serve and Protect America’s Consumers – I kid you not) about the privacy implications of mobile advertising and marketing.
The same group filed a similar complaint about Internet marketing several years ago - and now they've started picking on the mobile arena. Several news sources in the US picked up on the issue. Could this issue become more prevalent in the UK I wonder?
The only junk I get on my mobile is from Orange – and it’s not particularly ‘junky junk’ (must trademark that one) as it’s normally just half-price cinema ticket offers and that promotion is genuine and valid as far as I know.
The trouble is, you’ve probably seen the news about the huge amount of texts sent by the average youth these days and analysis companies are rapidly building up profiles of our mobile-based behaviour to CRM the ‘besjesus’ out of us (or so they hope to - further digging into the marketing industry may well tell you many organisations are not that sophisticated - but you probably already knew that from the level of service you get from some of your "service" providers).
There are a number of companies out there such as Xtract who claim to up the ante and be providers of data analysis solutions that create 3D profiles of mobile subscribers for… wait for it, “improved” marketing practices, but are they genuine - and if they are, can they help well intended mobile development to stay pure of heart and free from malicious malpractice?
I’m looking at Xtract as the company is releasing details of its privacy engine to highlight its stringent adherence to protecting subscriber privacy. If you were (or are) a mobile developer who wants to keep a clean conscience, would this be enough for you?
The main points of interest here are:
- When data analysis tools are used in a way such that data is kept completely anonymous and not mined from individual accounts, they provide the very foundation for privacy that subscribers rightly demand.
- Data should not be made visible at the network level, as some systems allow. Rather, aggregate data should be analysed with no link back to the subscribers' personal information such as what numbers they call.
- Aggregate data is a key asset for mobile operators that is underutilised today and can unlock more sophisticated mobile marketing with strict privacy credentials.
So that’s the long and short of it from Xtract, here’s a live link if you want to cast an eye over what they do and decide whether you think they are as squeaky clean as they say they are.
I personally tend to be sceptical about companies that use catch lines like “Monetizing Digital Communities” (I left the Z in for you there) – but then that’s probably just because there are so many truly junky junkers out there trying to monetise Twitter and the rest of the social computing universe and blogosphere.


