Wednesday, August 24, 2005

Mid-Range Systems Analysis

Mid-range systems are great, aren't they? Chuck a few hundred unix boxes at an infrastructure and horizontally scale to your heart's content.

Great theory... However, there seems to be a perception that having hundreds of servers "complicates" the infrastructure and fractures the understanding of the end-2-end process. I suppose that is one way to look at the issue - the route a transaction can take from a browser (for instances) through content switches, firewalls, load-balancers, proxies, application servers, messaging systems and on to mainframes (and beyond?) can be one of millions of possible routes. How can you troubleshoot and troublesome transaction in this case?

All is not lost, however.

Just because the architecture requires 10 proxy servers spread over multiple sites doesn't necessarily complicate matters. If we look at the infrastructure as having a proxy "service" which is made up of a number of identical components then the architecture looks less complicated immediately. The key is ensuring each box is identical.

There are any number of CVS systems available - some open source, some very expensive. (In the enterprise environment, open source is still to scary!). However, CVS systems are only of any use if the development process demands (and enforces) its use. This often isn't the case and it is astonishing how identical servers, under close examination, are never really that identical.

Anyway... the enterprise may well have a team to look after the proxy service, a separate team to look after the application service, another team to look after the database service, the directory service, the security service, etc. If a transaction goes awry - which team is responsible for tracking down the fault? Each team automatically becomes defensive about their "service" and resolution can be tricky! This is usually exacerbated by the fact that often the teams don't know what the end-2-end process is and (therefore) the implications of their actions.

So... who joins up the infrastructure? Unix administrators? No! Application Server administrators? No! My answer would be... those people in the enterprise who are genuinely interested in the architecture, interested in the end-2-end process and are in a position to have an influential impact on each service owner. In other words, it is the personality that seems to make a difference rather than the position in the organisation hierarchy.

Just my tuppence worth for today... Next up, I want to have a go at the Unix v Windows debate! Won't that be fun?

Saturday, August 20, 2005

Why Joined Up Thinking...

...... because it seems to me that there is a distinct lack of "joined-up thinking" within the enterprise environment!

Business units work independently of one another and the glue that joins them together (ie. Technology) is too intent on hitting deadlines and coming in on budget to recognise their responsibility to actually act as a glue and.... join-up the business strategy.

Am I being harsh? From what I have seen in recent months/years, I don't believe so - to the extent that I have finally started a blog to record my thoughts on this particular subject.

I hope the postings will amuse you; stimulate you; strike a chord with you; but most of all... will help you avoid the same mistakes in the future.