Showing posts with label IT performance. Show all posts
Showing posts with label IT performance. Show all posts

2013/02/26

Unsolicited Advise to a classmate

I've never been a politician, managed a large budget or run even a moderate sized project, so why do I have the hubris to offer some unsolicited advice to a newly minted I.T. Minister, to whom by accident, I was once briefly a classmate?

Rejecting these thoughts "because nobody else is doing them" is an option, though not a great reason.

Rejecting them "because they're too expensive" is a judgement call, but has to be measured against "Compared to What?".
Doing nothing will cost you a whole bunch, you've already have the report on that.

The core arguments in support of my observations are:
  • How important to the current and future BackOffice and FrontOffice operations of your Government is I.T.? I suggest that the machinery of Government cannot operate without it I.T. systems, not simply ineffectively, but like airlines, not at all.
  • There is an internal consistency in what I propose, derived from one of the toughest businesses around. The challenge is not "will this work", but "how can it be made to work for us".

2012/10/05

Unringing the Bell: Impact of IT systems on Large Business Survival

I've posited that Telstra will be severely challenged within 15 years due to Structural Change within their Industry. They aren't fast or agile enough to adapt to the new world..

What are the factors that will prevent them from adapting? My top two:
  • Management Culture
  • IT Infrastructure
An underlying problem is that we don't have language or metrics to describe and quantify the many important aspects of management. In Physics and Engineering we have many concepts and terms that are measurable to great precision. The importance of those is shown by the materials revolution over the last 100 years. For a tour de force on the topic, a book that's been in print for 45 years: The New Science of Strong Materials.

Whilst "Management" and descriptions and theories about it has become an increasingly large field of study, we don't have a "Science of Management" with precisely defined and measurable terms.

This is crucially important when ownership (shareholders) and control (managers) is separated. The owners have no nuanced, standardised measures to evaluate the most critical part of the business: management. All we've got is the Accounting Standard Reports provided in Annual Reports. This is far from enough to make informed decisions on a business' future prospects.

I can't detail or quantify the many problems of Telstra's Management Culture, just waive my hands and say "it's the vibe". E.g. they not only don't do Customer Service well, they prioritise short-term cost-savings above good service and seem to go to great lengths to not resolve customer faults, at least in some areas.

Management is about doing what's important consistently well, doing what has to be done well enough and not doing at all the things that don't need to be done. [And avoiding entirely the things that should never be done.]

My Professional expertise is in IT Infrastructure. I hold a contrary view to the mainstream Management view of "IT is a Cost Centre". IT provides automated Business Processes, like employees directly responsible for all the Business Revenues: IT is a Profit Centre, not Cost Centre.

We've already seen businesses failure due to their failed I.T. systems: One.Tel is a shining example.

IT Infrastructure has, for the last two decades at least, constrained business mergers. If I recall correctly, the St. George-Westpac merger was cancelled twice due to "incompatible IT systems". Not sure how they solved that in the end.

Westpac itself is notorious for a decade long project, CS90, that was cancelled in December 1990. It was meant to be the ultimate Banking System (an 'ERP') that IBM would resell around the world for them. It was consuming 5-10% of Westpac's operational revenue.

The $10B Telstra "IT Transformation" under Greg Winn ran for around 5 years with the intention of reducing 1500 systems to 300. It failed to meet its targets and went live in 2009 with the 30% most valuable customers not migrated [from my Case Study evidence, now full of migration errors.]

The point: large businesses are inextricably intertwined with their IT Systems - they are part of the Business DNA and essential to the Business Differentiation: What we do differently that people value.

Too often IT Systems are allowed to "grow like topsy" and are never rationalised or reorganised, presumably because no immediate savings or value can be demonstrated, but mostly because nobody is responsible for everything and ensuring IT Systems are well maintained and suitable.

Leading to "Big Bang" projects like Telstra embracing of off-the-shelf ERP and CRM systems to resolve the mess. Inevitably they find that things are much more complex and intertwined than they knew, not the least because they have no correct, current System Maps and the whole was never designed or planned, it just happened. All of which suggests Management asleep at the wheel.

It will probably take Telstra 10 years to get staff trained, most, not all, data corrected in their new systems and workaround established to cater for what the new systems don't do.

But what will it be left with then? Will those systems be nimble, quick and responsive or big, cumbersome and so hard to change as to be effectively frozen?

Young, small companies start small and add functions as needed: the I.T. equivalent of "greenfields".

They don't carry of a legacy or mindset of "we have to cope with everyone and everything".

This is the commercial advantage small ISP's had over Telstra: no past, no baggage, just simple effective systems.

This will be the problem that Telstra will have to face again in 2020 as Retail Providers using the NBN challenge it. Telstra knows the pain, cost and delay in redoing their I.T. Systems, they won't be going there again anytime soon.

This is a generic and on-going challenge for all successful businesses, including those small, nimble Retail Providers: how to keep I.T. Systems from degrading into an unchangeable morass?

When Data hardens in Organisational Arteries and structures/processes ossify, a major Cardiac event will follow... More of the Same cannot fix the problems, radical rethinking is needed.

In an increasingly automated world, a problem looms for every large business: what happens to the IT Systems when you downsize?

You get to drag the big, bloated corpse of yesterdays organisation along with you. It never gets better with age...

It's easy to lay-off staff and "reorganise", but I've never heard of any organisation looking to make commensurate simplifications to their I.T. systems.

I suspect that Large Business who aren't consciously and deliberately cleaning-up and refreshing their I.T. Systems will ultimately fail due to the complexity, inflexibility and inadequacy of their Legacy Systems.

You can lay off Staff and cut whole Departments, but where do you start with the weeds that permeate your whole organisation and choke the life out of it?

Once built, it seems you can't "Unring the Bell" of legacy I.T. systems, you're stuck with them and they define what you can do, while smaller companies whizz past you on their way to Market Domination and being strangled by their Legacy systems.



Jerry Gregoire as CIO of Dell Computers in 1999 talked about how he tackled this problem - and won.
When he joined Dell, there was a massive ERP project underway, "One System To Rule Them All". It was late, over-budget and failing. His first action was to cancel the project and front the board...

Instead, he moved Dell to a new architecture dubbed "G2", based around a message broker.
It reduces the N*N-1 or N-factorial system interface problem to one...

All every system needs to interact with every other system is one 'message broker' interface.
It comes with a cost - you need infrastructure and rule sets to switch the messages. But at least that's a known, computable cost.

Dell Business Strategy Secrets
An ERP Package for You...and You...and You...and Even You

2012/05/22

Changing IT from a Cost Centre to a Profit Centre.

1. ICT is a "force multiplier" (or 'cognitive amplifier').
It enables services and work to be performed "Better, Cheaper, Faster" (BCE).

It Amplifies the Effectiveness of staff at 3 levels:
  • individuals can perform tasks "Better, Cheaper, Faster", can need 5-25 times fewer staff.
  • co-ordination and communication tasks become 'zero-friction' improving cross-boundary efficiency and effectiveness. 
    • Reducing team & Department sizes removes delays and other barriers to productivity and efficiency.
  • Organisationally, decisions can be taken faster, with more informed sources and promulgated/implemented in real-time. Yielding much more agile and responsive products and services.

The future of IT Performance Analysis and Reporting

As IT/Computing moves through successive "event horizons" to becoming Ubiquitous, Universal and Invisible [like petrol, tyres, home telephones, plastic bags and ATM's], I think we need to monitor, model and report "Performance" in 3 areas:
  • Organisationally: For every dollar spent on ICT, what revenue and profit does it bring?
  • Technically: For each IT system and Computing Application, how does it scale, where are its bottlenecks and 
  • Business Systems and Apps: What are our ICT, staff and resource input costs? Where our bottlenecks? What investments are needed to optimise throughput, reduce costs and increase revenues?

2011/11/06

The importance of Design Rules

This started with an aside in "Crypto", Stephen Levy (2000), about Rivest's first attempt at creating an RSA Crypto chip failing because whilst the design worked perfectly on the simulator, it didn't work when fabricated.
[p134] Alderman blames the failure on their overreliance on Carver Mead's publications...
Carver Mead and Lynn Conway at CalTech revolutionised VLSI design and production around 1980, publishing "Introduction to VLSI System Design" and providing access to fabrication lines for students and academics. This has been widely written about:
e.g. in "The Power of Modularity", a short piece on the birth of the microchip from Longview Institute, and a 2007 Computerworld piece on the importance of Mead and Conway's work.

David A. Patterson wrote of a further, related, effect in Scientific American, September 1995, p63, "Microprocessors in 2020"

Every 18 months microprocessors double in speed. Within 25 years, one computer will be as powerful as all those in Silicon Valley today

Most recently, microprocessors have become more powerful, thanks to a change in the design approach.
Following the lead of researchers at universities and laboratories across the U.S., commercial chip designers now take a quantitative approach to computer architecture.
Careful experiments precede hardware development, and engineers use sensible metrics to judge their success.
Computer companies acted in concert to adopt this design strategy during the 1980s, and as a result, the rate of improvement in microprocessor technology has risen from 35 percent a year only a decade ago to its current high of approximately 55 percent a year, or almost 4 percent each month.
Processors are now three times faster than had been predicted in the early 1980s;
it is as if our wish was granted, and we now have machines from the year 2000.
Copyright 1995 Scientific American, Inc.
The important points are:
  • These acts, capturing expert knowledge in formal Design Rules, were intentional and deliberate.
  • These rules weren't an arbitrary collection just thrown together, they were a three-part approach, 1) the dimensionless scalable design rules, 2) the partitioning of tasks and 3) system integration and testing activities.
  • The impact, through a compounding rate effect, has been immense e.g. through Moore's Law doubling time, bringing CPU improvements forward 20 years.
  • The Design Rules have become embedded in software design and simulation tools, allowing new silicon devices to be designed much faster, with more complexity and with orders fewer errors and faults.
  • It's a very successful model that's been replicated in other areas of I.T.
So I'm wondering why vendors don't push this model in other areas?
Does it not work, not scale or is not considered 'useful' or 'necessary'?

There are some tools that contain embedded expert knowledge, e.g. for server storage configuration. But they are tightly tied to particular vendors and product families.

Update 13-Nov-2011: What makes/defines a Design Rule (DR)?

Design Rules fall in the middle ground between  "Rules-of-Thumb" used in Art/Craft of Practice and  the authoritative, abstract models/equations of Science.

They define the middle ground  of Engineering:
 more formal than R-o-T's but more general and directly applicable than the theories models and equations of pure Science, suitable for creating and costing Engineering designs.

This "The Design Rule for I.T./Computing" approach is modelled after the VLSI technique used for many decades, but is not a slavish derivation of it.

Every well understood field of Engineering has one definitive/authoritative "XXX Engineering Handbook" publication that covers all the sub-fields/specialities, recites all the formal Knowledge, Equations, Models, Relationships and Techniques, provides Case Studies, Tutorials, necessary Tables/Charts and worked examples. Plus basic material of ancillary, related or supporting fields.

The object of these "Engineering Handbooks" is that any capable, competent, certified Engineer in a field can rely on its material to solve problems, projects or designs that come their way. They have a reference they can rely upon for their field.

Quantifying specific costs and materials/constraints comes from vendor/product specifications and contracts or price lists. These numbers are used for the detailed calculations and pricing using the techniques/models/equations given in The Engineering Handbook.

A collection  of "Design Rules for I.T. and Computing" may serve the same need.

What are the requirements of a DR?:
  • Explicitly list aspects covered and not covered by the DR:
     eg. Persistent Data Storage vs Permanent Archival Storage
  • Constraints and Limits of the DR:
    What's the largest, smallest or complex system applicable.
  • Complete: all Engineering factors named and quantified.
  • Inputs and Outputs: Power, Heat, Air/Water, ...
  • Scalable: How to scale the DR up and down.
  • Accounting costs: Whole of Life, CapEx and Opex models.
  • Environmental Requirements: 
  • Availability and Serviceability:
  • Contamination/Pollution: Production, Supply and Operation.
  • Waste generation and disposal.
  • Consumables, Maintenance, Operation and Administration
  • Training, Staffing, User education.
  • Deployment, Installation/Cutover, Removal/Replacement.
  • Compatibility with systems, components and people.
  • Optimisable in multiple dimensions.  Covers all the aspects traded off in Engineering decisions:
    • Cost: per unit, 'specific metric' (eg $$/Gb),
    • Speed/Performance:  how it's defined, measured, reported and compared.
    • 'Space' (Speed and 'Space' in the sense of Algorithmn trade-off)
    • Size, Weight, and other Physical characteristics
    • 'Quality' (of design and execution, not the simplistic "fault/error rate")
    • Product compliance to specification, repeatability of 'performance'. (manufacturing defects, variance, problems, ...)
    • Usability
    • Safety/Security
    • Reliability/Recovery
  • other factors will be needed to achieve a model/rule that is:
     {Correct, Consistent, Complete, Canonical (ie min size)}

2009/09/05

Why Yet Another ReOrganisation won't improve the Public Service

The Rt. Hon. Ken Rudd PM has suggested on the News that he'll be seeking to improve the Federal Public Service. There's talk of a special Centre at the ANU to train people up too.

Rudd might end up with a bunch of tests, metrics and new programs & processes, but I can guarantee it won't amount to a hill 'o beans. The one thing known about Bureaucracies is their ability to Resit Change.

Read C. N. Parkinson ("Parkinsons Law" etc) for a view from the 1950's and some definitive economic analysis of the ultimate Bureaucracy: The UK's Ministry of Defence. After WWI, ships and fighting men - the essence of the Navy - declined dramatically. The Bureaucracy 'running' them increased overwhelmingly...

Why? Because the primary purpose of Bureaucracies is themselves, not producing outcomes.