Offshoring and Quality

I'd like to put the record straight here, because I may have given the impression with my last blog that somehow I was getting better Quality just because I had lower Costs from offshoring IT effort.
Quality is only indentifiably improved (i.e. you can prove it) when you have processes that support the required Quality steps, and Quality is only improved when you care.
So, what am I saying here? Well, what's the point of having the best quality in the world if no-one knows about it (i.e. they can measure it); they'll only go changing things about again and make things worse. Having a process and metrics for measuring your progress is the only sensible approach.
Problem is here that in order to carry out the processes you need dedicated resource, more people, and people don't come cheap. That's why I am hopeful that by spending the same amount of money offshore as I do onshore, I'm getting more people to carry out the same job with all the necessary Quality and IT Control processes.
Simple isn't it? I know it doesn't get me true Quality, since quality is more elusive than that. But at least it gives me measurement so that I know whether I've got Quality, getting Quality, or lost Quality.
The final piece in the jigsaw comes when we have Quality people; and I'm afraid this is the difficult one because to do that you need people who care, and people who don't work for your company care little about your company, they work solely towards the figures, the metrics, that you've so carefully put in place.......

Silicon is coming, watch out Grid!

Grid Computing is one of those technology areas that I'm not comfortable with. The concept of harnessing the power 100,000 machines together for a specific calculation purpose (e.g. SETI), I can understand. The concept of harnessing 100s or even 1000s of your own machines in your company in order to get consolidated compute power bothers me.
As I've said before silicon overtakes software sooner or later and in the case of grid we all know that speed is one of those attributes that is ever moving. So, processor speeds are still climbing and our super hardware engineers have found ways of putting multiple cores on a single chip; with a little more density, better processor scheduling, a little more speed, and a few more cores we will quickly be processing at 100 times our present speeds.
If you're doing Credit or Market Risk computations, surely this fills the gap? Otherwise if it's offline long-running processing for a few hours in the day perhaps, isn't this just a matter of scheduling ownership of the (same?) compute facility in that new blade server sometime overnight after the batch run has finished?
IBM's on-demand philosophy could also fit in here, why not buy compute power just when you need it (and at the cheapest time?).
Surely a managed environment is better for your business's processing rather than trawling the corporate desktop landscape? If you need it right now, and you don't have to invest much effort, then OK use it. But be prepared to move your code quickly off it when the alternative pops up.
So for me, Grid is OK now; it's even cool, but the writing is on the wall, silicon's coming.......
Come on, that must have got you going......Challenges please...

You can't beat silicon...

One of the things I really like to do is watch the Software Product space and how the Software industry finds ways of earning their meagre crust, and I'm often surprised at the way that some products make it big and some products don't.
Often, success turns on the product being there at the right time, and it's an aspect of what the right time is that has captured my attention today....
What is the right time for a software product? Well, often it's because of Hardware inadequacy, particularly in the performance space.
Many years ago I specialised in Mainframe System Performance (I won't tell you which mainframe to save me from embarrassment), spending much of my time benchmarking, collecting statistics, modelling and extrapolating performance etc. We did it because processor time or I/O time was expensive and upgrades were always major.
Software vendors sprung up into the space, automatically monitoring and tuning system parameters (of which there were an enormous number) to get the best performance from your machine. They were there at the right time, they got the revenue, they floated and got the cash, and the shareholders were left with the company. Trouble was, the shareholders often bought based on the start-up revenue stream, which of course depended highly on the opportunity window in the marketplace which had a habit of closing suddenly.
By far the most common closing of those opportunities was because hardware had advanced, processors and I/O got many times faster, Disk Storage got much denser and cheaper. The root cause of the opportunity disappears, the problem becomes less and less significant.
Try these:
Disk compression technologies, Run-Length Encoding - Closed.
Anything that saved 20% of your mainframe processor cycles - Closed.
Virtual Memory Systems? - Closing?
Bottom line is, that you can't beat silicon. It will always overtake software products in the end, and I'm going to give you a few more examples over the next few blogs.
But, as always, you know which software technologies that are in an opportunity window right now, soon to be closed, why not let our readers know? Comments, as always, are very much welcomed.
By the way, no comments about whether it's silicon, gallium arsenide or whatever, you know what I mean......

Development - Art or Science (again!)

I was reading an article on Martin Fowler's site today. It was centred around some issues of Agile Development and how we got there, and in reading it, I started to revisit the old question of whether Programming is an art or a science.
Now, of course, you have your own ideas on this, and I encourage you to share them with our readers; this is one of those highly debatable areas, and if there's one thing that I've learnt in this life is that nothing is true, nothing is certain and everything is subjective.
What were we trying to do when we invented System Development Lifecycles? Well, we were trying to put some form, some method, around development of systems so that they could become more predictable and that Intellectual Assets could be recorded in a prescriptive way. In short, we were mechanising the development of systems, turning it into an engineering task.
Development, or programming is an engineering discipline when done within a SDLC. It has to be, there is no way around it if you want the outcome to have any kind of certainty. Done this way, it's a science.
Art is a very different thing; for the most part the outcome is not required to be a certainty, indeed to have any value at all, the outcome should be unique and non-predictable. You will realise that I'm not talking about people who do portraits or those that do characatures of you at the seaside here, I'm talking about those that look at an empty canvas and start splashing paint around, not knowing where it will lead them.
You will notice that no-ones gone out of their way to produce a Artistic Development Lifecycle (ADLC) for painters here, they've given them free rein, left them to their own devices, and waited for a totally unique outcome; valuing the outcome based on its unique merits.
Is there a case, a situation, where you would leave developers to their own devices? Well, I guess that many of the great advances of today's technology
have actually come from artistic developers who didn't know the outcome when they started out; they played, they tried things, until they produced something that was valued (or not) based on it's own individual, unique merits.
So, do we have room for both kinds of developers, both scientists and artists, in this world of ours? Of course we do, each have their own place, their own value.
Is their any kind of methodology that can be applied to artistic development, so that we can get any certainty of outcome? Probably not. Which make funding of Research and Development costly and risky, best left to those with deep pockets, or $7B war chests........

Little has changed, we're still Data Processing...

A few weeks ago one of our IT Managers asked me how best to communicate Architecture and Design issues to our Business users. The premise was that although we had produced wonderful UML diagrams, pretty as they were,they weren't really telling them anything.
After asking a few more questions, as you do, it transpired that the Business themselves had produced equally wonderful Process Diagrams as part of the SOX compliance initiative, and that they couldn't relate anything they had to anything we had.
Our UML diagrams had covered Component and Deployment diagrams, they had covered a little of the flow details between the Components (complete with nice swimlanes), and something of the Process flow internally (Only where we had some complexity).
After a little thinking I realised that the Business were talking Business Process, no, actually Data Process. Their process flows were descriptions of the flow of data through different processes which included technology system references (e.g. "processed in (system)"), but didn't actually say exactly how the Data process mapped to System Components or Processes.
Our Business was still thinking Data processing, and on reflection I realised that the only significant thing that had changed was that we Technology people had renamed ourselves Information Technology, but, are still performing a Data Processing function.
So, my first stab at this is to think along the lines that we need to map the Business Process flows directly into our UML Component boxes so that they can see where the data processing is occurring, and where to look for their data control and reconciliation points. A kind of Data Flow Diagram or Flowchart onto UML Components is my current line of thinking, but I dont have a rigorous method of keeping it all together, but I really haven't got very far with this.....
Anywhere else I should be looking?

How thin is my organisation?

So, given that we are moving into this world of managing multiple suppliers of IT Services, it follows that we will need to get clever about organisating ourselves to be more efficient and effective. And of course, we can't get any "horizontally challenged" in shaping this new organisation.....
So, although we need a few less people for support, maintenance, and development, we need a few more people for management.
And, of course, the first thing we're going to need is Service Management so that we can be effective at measuring how well the Service Providers perform (so we can be "agile" with our Provider selection).
And we're going to need (Service) Relationship Management so that we can keep our Service Providers sweet, let them into our strategic directions and work with them in line with our objectives.
And we're going to need (Better) Cost Management across our own organisations and those of our Service Providers.
And we're going to need (Better) Knowledge Management in retaining our intellectual and other assets so we can manage them into and out of our Service Providers.
And we're going to need an agile and adaptable Systems Development Lifecycle to cope with all the "nested" methods.
And the biggest thing you need to keep in mind is that you need to make sure that at least 70% of your Costs in the total Service Relationship are going to be offshore for the model to be at all cost-effective.
So, we need to be thin, very thin, bearing in mind that our Costs can be no more than 30% despite the fact that our management rates are probably many times higher than the equivalent offshore rates.
And I'm sure that there are more roles to be introduced here.... Let me know which ones I've missed.....

Managing your portfolio (or have i finally lost it?)

If you're following my blog, you'll notice that I'm following a line of thought that seeks to figure out what tomorrow's IT organization should look like in this world of multiple service providers and multiple vendors.
And you will have noticed that I'm making an early attempt at dividing up the IT world by looking at commodity skills and service or relationship skills.
The bit that I'm going to home in on today is what we could call Portfolio Management (I've seen this in several corporations, but each has a different flavour) and I'd like to offer a sample definition for your comment.
The simple idea is, that since we have this multi-supplier operation, that we need to respond in a different way to normal IT governance. A Portfolio Manager looks after a service or portfolio of services. For instance, one PM would look after all the various Helpdesk Supports, another all the Application Development services. These PMs own the portfolio in terms of Cost Control, Service Agreements and Measurement, and of course, bringing in new or replacement ones.
What's the difference between Portfolio Management and traditional IT Management? The PM is accountable for the overall service and the efficiency of that service rests with that PM; how's that for governance and accountability?
What's the difference between Portfolio Management and Project Management? A little more obvious this one, since Projects are transient, the Project management doesn't have to go out and worry about suppliers for infrastructure and support; they go to the Portfolio Managers for those services. Projects cut across the Portfolios, and disappear when final deliverables end up in a PM's portfolio. I think this should make Projects more productive and Project Managers more successful, although you may be able to see that the PMs can present bottlenecks to the project.
You also need an allocated cost model in place, since the PMs need to recover pieces of their funding from the Projects.
Is this a workable model, or have I finally lost it (you knew it was coming) ? Comments, as always, are very welcome.....

How are you going to survive?

I was wondering yesterday what skills were going to help us in this brave new world of technology when I was reminded that Charles Darwin said "It is not the strongest of the species that survives, nor the most intelligent; it is the one that is most adaptable to change".
Are today's Java Evangelists yesterday's C++ Evangelists who have sucessfully changed? Or perhaps there are pockets of developers out there staunchly holding on to the idea that Cobol is still best and that they are going to hang on in there? You know who these guys are, they're the ones that growl at you whenever you come near, like an old grumpy dog.

One thing is for sure is that things change; we manage change, we breath change, it's what keeps us alive.

So, what skills do we need on our CVs to help us in this changing world? What roles are the most successful, who's always there when everyone's left?

Well, I'd like to offer some suggestions and perhaps you can add some more.
1. Systems Architects (not Technical Architects) should have always maintained well-abstracted skills, structures, qualities and methods.
2. Bearing in mind our moving towards outsource and offshore, Service management is always going to be required; the middlemen of IT.
3. IT management in general (yes I know your manager is an idiot, but look, he always survives where you don't).

Why don't you think about it and offer some more skills? Comments please..

Time for business alignment (again)

Actually, we're a little late here since the optimum time for Business Aligned IT has already passed, we're well into picking up the scrapings of residual value....
Regulatory pressures have been giving all us City Financial folk a lot to think about lately, what with all this Sarbanes Oxley(SOX) and Basel II stuff. Bottom line is, that we have entered into an evolutionary phase of development of our IT and Business models where we have passed from wouldn't-it-be-nice to do-it-or-go-to-jail.
It's a pity really, since the benefits of Business Alignment were there to see, the business would have transparency of Costs, Risks and Service Levels of their infrastructure, and IT get's a chance to clean up the mess of Objectives and Goals linked to Projects that are supposed to deliver real value. I think that we had got to a point where the Business really didn't trust IT since they could never relate all the wonderful stories of increased performance, function and quality with lower costs, to the stuff that we delivered to them that's fallen over three times this week....
Well, we get another chance. SOX and Basel II are here (actually SOX has been here a little longer), and I guess it's time to try to get Business Aligned again.
You will remember (perhaps) a blog on Business Alignment that I wrote on this last year, where I said
"Technique number three in this great alignment strategy is to map Applications to the Business Processes that they automate; we can then relate real Business Transactions to transaction flow in our Applications, and map our Applications to their Host servers and, coupled with Business Systems Management techniques, we can relate System Health, Problem Management and Risk right up to the Business Process."
Well, there's more, but in essence that's one of the places where we need to be.
Basel II for all you non-European Based Enterprises out there is really about addressesing Operational Risk, and focusses on failures to Internal Processes, Systems, People and External events. It points us towards adopting process-driven approaches to Risk Management and regulatory processes.
Trouble is here, that just collecting data on risks isn't the answer, since we don't really have a handle on our organisational model or our Corporate Governance. This is where Business-Alignment comes in; we need to model and keep our data and reporting processes aligned across Organisation, Business Process, Systems and People and, due to the complexity of our organisational models, I don't think this can be achieved using the usual suspects of Data Modelling techniques; it needs one of those quantum leaps into alternative data models, perhaps by using a variant of the Semantic Data Model.
I have been researching the area in depth and will attempt to give you some of my insights if you'd like; let me know.

Erratic or expected?

A colleague asked me how Architects cope with erratic changes in strategy by their organisations. Of course he knows there is no complete answer, no silver bullet, but there are some things we could consider.
What kind of strategy changes can we expect? There are two profiles of companies out there categorised by how they grow; there are organic growth companies and there are acquisative companies.
The organic growth companies grow steadily in small increments, but always retaining the same basic way of working. For Architects our main focus here is maintaining quality and stability whilst the level of business grows. Our infrastructure strategy emphasises scalability, reliability and good monitoring whilst our development strategy full lifecycle, waterfall.
The acquisative company likes to grow in large increments, but does not retain the same way of working, it rather subsumes another way of working for a time until the processes between the two companies can be rationalised. Infrastructure strategy emphasises integration skills, middleware and abstraction, development strategy based on Integration not code.
You know generally what kind of company you are in, and the larger the company, generally the less "jumpy" they are, and the less change to their strategy. In other words in large companies, Architects can generally read the strategy and plan for the changes before they happen.
In smaller companies, volatility plays a bigger part, smaller companies are more jumpy and have to be lighter on their feet. Lightweight technologies and agile methodologies may be the order of the day. I don't think we usually play Enterprise Architecture here, more likely we play Technical Architecture.
I referred to this kind of "profiling" of a company in an earlier blog on Strategy.