I was searching the web recently and stumbled across a site that explained how to irritate people at work – I thought it was mildly amusing at first then realized it was being serious, so as a result (along with the annoying little pop-ups) I soon became irritated by it (that’s irony BTW). The reason why I bring it up now is that what I’m going to say in this post will irritate many I’m sure.
Those of you who know me, know that I hate simulation tools. Over the years I have spent many hours explaining to people why I have never got excited over process simulation and have never built it into or recommended it for, any of the products I’ve designed or advised on.
So at the risk of alienating a bunch of people here’s why.
The CIO – has the task of making sure the needs of the CEO are fully met quickly, effectively and with zero disruption to the business. Systems implemented in today’s rapidly changing technology world must show fast ROI and bring benefits to the bottom line, without having to discard what works. Which means that good analytics and reporting capability is one of the key, and most visual, benefits that come from implementing a BPM system – the term often used for this is Enterprise Process Analytics?
The majority of Organizations now realize that although they can implement BPM without analytics capabilities, they do not have a complete end-to end solution. Their BPM system does not help their strategic planning nor enable them to accurately develop contingency plans for opportunistic and threatening scenarios. They do not have real insight into their processes or the outcomes they produce let alone an automated way of addressing them.
Analytics give business managers and executives the ability to track and measure performance based on real-time feedback of their processes this gives them real insight into how the organization is operating. Once good and accurate analytics are in place, end users can make informed decisions because they are presented with issues that need to be addressed, as well as with the context so they can take the right action. They have the ability to “drill down” into an anomaly and to look at the information from different dimensions giving them greater understanding of the “information behind the information.” Forecasting is made possible through ongoing statistical data capture, and reporting functions ensure real-time and predictive information is available.
The powerful combination of real-time process analytics and Business Operations Management means that users can:
1. Adjust processes to changing business dynamics
2. Move from managing business processes to managing business process lifecycles
3. Tie together Business objectives, strategic planning, process modeling, workflow, application/content management and analytics so that they interact
4. Develop feedback loops for change management and incremental optimization of business processes
5. Eliminate gap between strategy and business objectives
6. Ensure workflow and processes support key business objectives
7. Gain the control of operations to manage process lifecycles from end-to-end
By implementing BPM, the business community will be able to build and execute processes that are designed with customers in mind, deliver better quality, faster and at lower costs, and retain competitive advantage by being able to execute processes that deliver the business strategy.
So why don’t we need simulation?
First and foremost most proprietary BPM embedded simulation tools cannot simulate the entire business process. At best they simulate the part which has been modelled and automated. They do not take into account the parts of the process which are not forming part of the BPM implementation. Secondly, more often than not, they are “2 dimensional”. What I mean by that is that they do not take into account other processes that are executing in parallel. So the simulation is misleading since it doesn’t take into account availability of the resources required to support it. Without taking into account the impact of other work priorities, other processes in flight, and many other imponderables, the user of the tool does not get a real picture of what would really happen during the process – just a snapshot of a part of the process that is presented in isolation.
And if that’s not reason enough not to trust them – by definition, the data used to drive the simulation is almost always based on guesswork.
So what is the answer?
Simple; using real analytics in real situations is the only way to achieve real continuous improvement.
Simulation tools help sell products – they look good, impress and give the impression of real planning. However, until you have gone through real process discovery, designed the new process, get it agreed and tested they are of very little practical benefit. It is only after you have gone through these stages that you will be ready to use the process in a live environment and then all the outputs of the simulation are little more than historic representation of what we thought would happen rather than what actually happens.
Friday, 13 November 2009
Friday, 2 October 2009
Organic IT – would this work for you?
Over the past few months I’ve been on the road giving a presentation called “The Cloudy world of Disposable IT”. The presentation is all about the impact the advent of cloud computing is having on the way we build, buy and deploy software applications. These changes are happening very quickly and the ramifications on the entire IT world will be quite profound.
As an example of the way things are going I ask the listeners to consider the runaway success of the Apple AppStore. Its impact is nothing short of phenomenal. Within a year of its launch there were, according to Apple, more than 1 billion downloads and there were over 35,000 applications ready and waiting for iPhone users to access. That’s quite something. There are a few other examples I use to explain how “people power” is affecting the entire world of IT services and how these services are rapidly becoming consumer technology (CT) and Business Technology (BT) but you’ll need to come along to a presentation to learn about those.
However, one thing I’ve found myself talking about is the concept of, what I call, Organic IT. This has nothing to do with the green debate (but it probably impacts it in ways I’ve yet to consider) nor is it to do with not using any form of chemicals to rid the technology of bugs – no – this is to do with living, breathing IT that expands and shrinks as you need it. All this is made possible by cloud computing and is real. What I’m going to tell you can be done as you read this blog, and probably wouldn’t take that much longer to do either – so if you’re sitting comfortably I shall begin.
Imagine for a moment that I’m going to start a new business. Doesn’t matter what type of business, because this would work for any type, but for the sake of argument, let’s say it’s some sort of “intellectual” business such as a consultancy. The first thing I know I will need (after I’ve done all the tax stuff) is some sort of computer, a way of accessing the internet, some sort of word processing capability and probably a spreadsheet package. I’ve got lots of choices so I decide to make my first port of call the largest retailer for this stuff in the UK, PC World.
As I walk up to the door I get stopped by a mobile broadband vendor who offers me unlimited internet access for £15 per month as long as I enter into an 18 month contract. Well; I know I need access to the internet so I sign up – then he hits me with the bonus – signing up for the 18 months gets me a free laptop computer. Fantastic, I came out expecting to pay £300+ and I’ve got my PC and broadband with no capital outlay. So where next?
I carry on into the store (remember I hadn’t got in there yet) and look around for some office type applications. I look at the obvious choice from Microsoft and think that this is all I need. Until, that is, I look at the price. Small business edition £380 – I need smelling salts. I decide not to buy but go and search on the internet to see what else is available.
So I search, and I find readily available applications to use in the cloud. I can try them out for a while but after that I pay a $1 per week to use it. So I go ahead and sign up. Now I have a PC, Broadband connectivity and office applications, in fact, my entire office in the cloud and I’ve yet to spend any money. But I need more – I need some business support applications like billing and tax returns – is this where I start to spend money?
Spend money? Not me – I search and I find a marketplace where I can subscribe to a platform that will enable me to run little applications as and when I need to. So I subscribe and away I go.
I have everything I need to run my business: The PC, the connectivity, the office applications and the support applications. Not a penny spent from the money borrowed from the bank.
But where does the “Organic IT” come in to this? Well if I can do it for me I can do it for new employees. As my business expands I can take on more IT without spending capital. If I hit hard times and have to reduce numbers I can do that without having lots of expensive hardware and software lying about the place. So my exposure and risk is reduced significantly.
How will this impact the corporate IT world? Well on the face of it you might think “not at all” but think some more. In the future people will not want to own a “company PC” – they will much rather have one device for personal and company use. So corporate IT will be able to source virtual platforms with all the connectivity, applications etc. and load them on to personal computers allowing the employee to switch use as and when.
This means that Corporate IT will not have to buy lots of hardware, nor will they have to maintain it. The real advantage though comes from the fact that all of the corporate data will be held in the organization’s data centre not on an individuals laptop – if a laptop gets lost or stolen – who cares?
There’s no doubt that the way we use and acquire IT is changing – and it’s happening very fast and it’s happening today – be ready!
A disclosure – if you visit http://www.theprocessfactory.com you can start doing this today – simples – as my favourite meerkat Aleksandr might say.
As an example of the way things are going I ask the listeners to consider the runaway success of the Apple AppStore. Its impact is nothing short of phenomenal. Within a year of its launch there were, according to Apple, more than 1 billion downloads and there were over 35,000 applications ready and waiting for iPhone users to access. That’s quite something. There are a few other examples I use to explain how “people power” is affecting the entire world of IT services and how these services are rapidly becoming consumer technology (CT) and Business Technology (BT) but you’ll need to come along to a presentation to learn about those.
However, one thing I’ve found myself talking about is the concept of, what I call, Organic IT. This has nothing to do with the green debate (but it probably impacts it in ways I’ve yet to consider) nor is it to do with not using any form of chemicals to rid the technology of bugs – no – this is to do with living, breathing IT that expands and shrinks as you need it. All this is made possible by cloud computing and is real. What I’m going to tell you can be done as you read this blog, and probably wouldn’t take that much longer to do either – so if you’re sitting comfortably I shall begin.
Imagine for a moment that I’m going to start a new business. Doesn’t matter what type of business, because this would work for any type, but for the sake of argument, let’s say it’s some sort of “intellectual” business such as a consultancy. The first thing I know I will need (after I’ve done all the tax stuff) is some sort of computer, a way of accessing the internet, some sort of word processing capability and probably a spreadsheet package. I’ve got lots of choices so I decide to make my first port of call the largest retailer for this stuff in the UK, PC World.
As I walk up to the door I get stopped by a mobile broadband vendor who offers me unlimited internet access for £15 per month as long as I enter into an 18 month contract. Well; I know I need access to the internet so I sign up – then he hits me with the bonus – signing up for the 18 months gets me a free laptop computer. Fantastic, I came out expecting to pay £300+ and I’ve got my PC and broadband with no capital outlay. So where next?
I carry on into the store (remember I hadn’t got in there yet) and look around for some office type applications. I look at the obvious choice from Microsoft and think that this is all I need. Until, that is, I look at the price. Small business edition £380 – I need smelling salts. I decide not to buy but go and search on the internet to see what else is available.
So I search, and I find readily available applications to use in the cloud. I can try them out for a while but after that I pay a $1 per week to use it. So I go ahead and sign up. Now I have a PC, Broadband connectivity and office applications, in fact, my entire office in the cloud and I’ve yet to spend any money. But I need more – I need some business support applications like billing and tax returns – is this where I start to spend money?
Spend money? Not me – I search and I find a marketplace where I can subscribe to a platform that will enable me to run little applications as and when I need to. So I subscribe and away I go.
I have everything I need to run my business: The PC, the connectivity, the office applications and the support applications. Not a penny spent from the money borrowed from the bank.
But where does the “Organic IT” come in to this? Well if I can do it for me I can do it for new employees. As my business expands I can take on more IT without spending capital. If I hit hard times and have to reduce numbers I can do that without having lots of expensive hardware and software lying about the place. So my exposure and risk is reduced significantly.
How will this impact the corporate IT world? Well on the face of it you might think “not at all” but think some more. In the future people will not want to own a “company PC” – they will much rather have one device for personal and company use. So corporate IT will be able to source virtual platforms with all the connectivity, applications etc. and load them on to personal computers allowing the employee to switch use as and when.
This means that Corporate IT will not have to buy lots of hardware, nor will they have to maintain it. The real advantage though comes from the fact that all of the corporate data will be held in the organization’s data centre not on an individuals laptop – if a laptop gets lost or stolen – who cares?
There’s no doubt that the way we use and acquire IT is changing – and it’s happening very fast and it’s happening today – be ready!
A disclosure – if you visit http://www.theprocessfactory.com you can start doing this today – simples – as my favourite meerkat Aleksandr might say.
Monday, 14 September 2009
Cloud, BPM, SOA - the real value of on-demand
The automation of processes is a key enabler of the Cloud phenomena – without process the Cloud remains a passive environment that undoubtedly saves you money and removes some of the operational headaches, but does little else. The Cloud without process cannot deliver on the promise of Business Technology or the Service-Oriented Enterprise. All of the thoughts and ideas around assembling applications quickly to support a business imperative simply wont happen without process technology.
However we need to be very clear – process management in the cloud is not just about BPM Suites on demand. Indeed, the term BPM on Demand is beginning to take on a new meaning when used in conjunction with cloud computing.
The traditional use of the term “BPM on Demand” is often used to describe Software as a Service that delivers a BPM Suite as a Service, much like customer relationship management (CRM) applications are delivered as a service (e.g., Salesforce.com). Both use a pay per usage or subscription pricing model. BPMSaaS provies a full suite of BPM lifecycle capabilities, from modeling to deployment, and on to analysis and optimization. It’s a third party, Cloud hosted alternative to bringing in a BPM Suite in house. But there is much more to BPM on Demand than would at first appear to be the case. If we take the stance that the Cloud can deliver an infinite number of business software Services to all who need them, then we need a mechanism that makes that easy to orchestrate those Services and delivers the maximum flexibility. This is where a new meaning for “Process on Demand” comes in.
Process on Demand means having the capability to call up business Services when needed to change or augment a process that is already being executed.
This capability is in intrinsic part of the Service-Oriented Enterprise. The Services we are talking about are not the usual, fine-grained ones normally associated with the SOA world. These services are far more sophisticated than simple “get data/put data” activities. What we have are Services that contain:
• User Interface
• Business Rules
• Key Performance Indicators
• Meta data
In short, we have everything that makes a self-contained application all wrapped up as a Service that can be incorporated into an end-to-end business process.
Why do I need this type of capability? In a word Simplicity.
The concept of Process on Demand enables you to build dynamic processes that can be changed “on demand” to meet changing business needs. This dynamic process selection provides a substantial improvement in flexibility and agility and reduction in design complexity. But we have to see if those advantages are sufficient enough to achieve the gains in agility, scalability, and robustness to meet the ever changing needs of today’s business environment.
When developing business processes it is quite often very difficult to determine what will ultimately be needed in terms of documentation, sub-processes, timing and dependencies of tasks to accomplish some given requirement. For example, in designing a process to handle an insurance claim for a traffic accident, the analyst may know that the customer will need to get his car assessed for repair and that a payment may or may not be forthcoming, but may not know the types of documentation (e.g., the mechanics costing, police witness reports, and hospital bills) that will potentially be required to process the claim, nor will he or she know the dynamics that determine which one or ones of possibly many documents to use.
These interrelated paths through the claim process may already have been defined by different people, in different parts of the organization as self-contained business Services or sub-processes, and may be changed frequently as the procedures and rules change. In such cases, it is not possible for the main claim process to determine, even dynamically, what particular Services to use. All the developer knows is that a particular goal is to be achieved, but exactly which Service can be used to achieve it cannot be easily determined. Nor, in fact, does the developer really care—he or she simply wants the goal accomplished in an appropriate way.
To solve this problem, we need a repository where we can keep the Services for use by the company. What differentiates these Services from sub-processes or data integration tools is that our Cloud applications know what each Service does, the circumstances in which it can be used, and the goals and outcomes that are required.
This enables us to define which required Services are available “on demand.” By this means, the calling process simply needs to access a Service in the process flow, leaving it to the system to determine which business Service best achieves the goal in a given circumstance. During the execution of the process all those Services that satisfy the goal are known so that on evaluation of a value or the detection of an event, the Service that is required can be incorporated and executed one second before the transaction occurs – making each iteration of the process totally different from and previous or subsequent processes depending on the dynamics in play at the time.
This approach improves significantly the development, agility, and scalability of business processes. The main process is simple, the “happy path,” and is therefore easily understood. New services can be added or removed without any change whatsoever to the calling process or processes. So Process on Demand provides a simple and effective way of defining processes that completely encapsulate their definition in self-contained, semantically complete business Services, significantly increasing agility and scalability as a side effect.
This is the real power of BPM, SOA and the Cloud.
There will be more on this subject in a new book from Fingar, Mulholland and yours truly :)
However we need to be very clear – process management in the cloud is not just about BPM Suites on demand. Indeed, the term BPM on Demand is beginning to take on a new meaning when used in conjunction with cloud computing.
The traditional use of the term “BPM on Demand” is often used to describe Software as a Service that delivers a BPM Suite as a Service, much like customer relationship management (CRM) applications are delivered as a service (e.g., Salesforce.com). Both use a pay per usage or subscription pricing model. BPMSaaS provies a full suite of BPM lifecycle capabilities, from modeling to deployment, and on to analysis and optimization. It’s a third party, Cloud hosted alternative to bringing in a BPM Suite in house. But there is much more to BPM on Demand than would at first appear to be the case. If we take the stance that the Cloud can deliver an infinite number of business software Services to all who need them, then we need a mechanism that makes that easy to orchestrate those Services and delivers the maximum flexibility. This is where a new meaning for “Process on Demand” comes in.
Process on Demand means having the capability to call up business Services when needed to change or augment a process that is already being executed.
This capability is in intrinsic part of the Service-Oriented Enterprise. The Services we are talking about are not the usual, fine-grained ones normally associated with the SOA world. These services are far more sophisticated than simple “get data/put data” activities. What we have are Services that contain:
• User Interface
• Business Rules
• Key Performance Indicators
• Meta data
In short, we have everything that makes a self-contained application all wrapped up as a Service that can be incorporated into an end-to-end business process.
Why do I need this type of capability? In a word Simplicity.
The concept of Process on Demand enables you to build dynamic processes that can be changed “on demand” to meet changing business needs. This dynamic process selection provides a substantial improvement in flexibility and agility and reduction in design complexity. But we have to see if those advantages are sufficient enough to achieve the gains in agility, scalability, and robustness to meet the ever changing needs of today’s business environment.
When developing business processes it is quite often very difficult to determine what will ultimately be needed in terms of documentation, sub-processes, timing and dependencies of tasks to accomplish some given requirement. For example, in designing a process to handle an insurance claim for a traffic accident, the analyst may know that the customer will need to get his car assessed for repair and that a payment may or may not be forthcoming, but may not know the types of documentation (e.g., the mechanics costing, police witness reports, and hospital bills) that will potentially be required to process the claim, nor will he or she know the dynamics that determine which one or ones of possibly many documents to use.
These interrelated paths through the claim process may already have been defined by different people, in different parts of the organization as self-contained business Services or sub-processes, and may be changed frequently as the procedures and rules change. In such cases, it is not possible for the main claim process to determine, even dynamically, what particular Services to use. All the developer knows is that a particular goal is to be achieved, but exactly which Service can be used to achieve it cannot be easily determined. Nor, in fact, does the developer really care—he or she simply wants the goal accomplished in an appropriate way.
To solve this problem, we need a repository where we can keep the Services for use by the company. What differentiates these Services from sub-processes or data integration tools is that our Cloud applications know what each Service does, the circumstances in which it can be used, and the goals and outcomes that are required.
This enables us to define which required Services are available “on demand.” By this means, the calling process simply needs to access a Service in the process flow, leaving it to the system to determine which business Service best achieves the goal in a given circumstance. During the execution of the process all those Services that satisfy the goal are known so that on evaluation of a value or the detection of an event, the Service that is required can be incorporated and executed one second before the transaction occurs – making each iteration of the process totally different from and previous or subsequent processes depending on the dynamics in play at the time.
This approach improves significantly the development, agility, and scalability of business processes. The main process is simple, the “happy path,” and is therefore easily understood. New services can be added or removed without any change whatsoever to the calling process or processes. So Process on Demand provides a simple and effective way of defining processes that completely encapsulate their definition in self-contained, semantically complete business Services, significantly increasing agility and scalability as a side effect.
This is the real power of BPM, SOA and the Cloud.
There will be more on this subject in a new book from Fingar, Mulholland and yours truly :)
Friday, 14 August 2009
What goes around comes around
I’ve just returned from the annual pilgrimage to the south of Europe to soak up the sun, relax with the family and practice my swimming techniques that I had learnt anew 12 months earlier. I came back looking like a half broiled lobster, 6 pounds heavier than when I left to face a stack of work that had built up while I was away. Does all this sound familiar?
Like countless others, one of the things I like to do when on holiday is read. I read anything and everything, from the normal holiday stuff by the likes of Grisham through to Tudor history from Starkey. There are times when I have up to 4 books on the go at any one time. I read to relax and educate – I immerse myself and chill out.
This year was different, not through choice I might add, but simply because of one of the books I decided to take with me. The horrid little tome that messed things up is a fairly old book. One which I was certain I had read before and enjoyed so the plan was to “refresh” my understanding of it. Also the copy I was given was a revised version – an “old” updated version – bringing everything bang up to date as of 1996.
What is the book that’s the subject of this piece? It goes by the title “Accidental Empires” by Robert X. Cringley (the subtitle’s good as well it’s “How the boys of Silicon Valley make their millions, battle foreign competition, and still can’t get a date”) – it’s a great book. But before we go any further here’s a short disclaimer. When I sat down to write this blog, I decided not to do any research on what the Cringley machine has written since the revised edition of the book was published (1996). That may seem strange but there’s good reason (at least in my mind).
So if I like the book so much, why then did it mess up my vacation? Well, as I said I like to read to relax, but all I kept doing was rereading passages and making copious notes to myself – I didn’t complete another book – just kept going over and over various bits to get the arguments and ideas straight in my mind. All the while with a view to write this blog because it was still so relevant, still able to teach us lessons.
For those of you who don’t know this book, it describes the birth of the PC industry, exploding myths and revealing interesting personality traits of those we’ve come to know and love over the years. Cringley tells us how it all happened more or less by accident. The people who made it happen were amateurs and that for the most part (at least in the early 90’s) still are.
Now for those of you who know me, you already understand where I’m coming from – I’m passionate about two things outside of my family and they are history and technology – so when they combine I’m in my element. History has a habit of repeating itself – we ignore the past at our peril – and that’s what got me this time.
In 2009, the world of IT is changing – and, at the risk of being shot as a heretic, the era of the PC as we’ve known it over the past 3 decades is coming to an end. The new IT paradigm is the cloud. But reading Cringely’s book one would be forgiven for thinking that he is describing what is happening in the world today.
Accept for a moment that the cloud offers a new computing platform upon which to develop applications. To take advantage of this new environment major software vendors are taking their existing products and trying to make them “cloud enabled” – this is a bad idea.
Why so?
Well let’s take an example from Cringley in the 80s. The application that made the Apple II so successful was Visicalc. Visicalc was the killer application and was responsible for the sale of millions of Apples. It wasn’t the hardware, it was the software – written for the specific piece of kit then ported to other platforms. For example, Westinghouse in Pittsburgh had decided that the Apple II wasn’t suitable for their use and yet business users had collectively bought 1,000 of the things just to run Visicalc. So why don’t we still use Visicalc today? After all, hardware may appear to get slower and die, but software remains in the same pristine shape it was in when first installed.
Well along came the IBM PC with a new operating system, new chip set, new everything. The simple answer was to “port” Visicalc to the new environment; take an “old” product and revamp it for a new environment. There’s a problem with this approach – you never get the same “intimacy” with the hardware, which means that performance is degraded, code becomes more fragmented, harder to understand and more expensive to maintain. This is where the genius of folks such as Mitch Kapor comes into play. Kapor is the father of Lotus, specifically Lotus 123. He started what became one of the fastest growing software companies ever – at one stage Lotus was the largest software company in the world. But Kapor didn’t invent the spreadsheet – his genius was to realise that the IBM PC represented a new computing platform – so he bet his house on making it happen and developed a “new” “killer” application for the PC.
What Kapor recognized is true today, it’s true for the cloud. Some of the best known products in the market today are just not suitable for cloud deployment. Porting them isn’t going to hack it either. The cloud demands a new breed of technology – written from the ground up to support multi-tenancy, to be accessible from anywhere, have good connectivity to the “old” world and provide a solid platform-as-a-service.
There are lots more examples and I would urge you to go and get a copy of the book and read it in schizophrenic mode – from an historical perspective and a “it’s happening again” one. Also a plea to Cringely – bring the book up to date you were right then and still are today.
To conclude I want to tell you about the extra couple of chapters that constitute the 1996 edition. Cringley makes a stab at predicting the future and in doing so introduces “I” word; the internet. He makes two points:
1. “…the internet topology is most often described as a cloud. Packets of data enter the cloud in one place and leave it in another…”
2. “…a set top device is not a computer because it has no software applications and no local storage, right? Wrong. The set top device will be connected to a network, and at the other end of the network will be companies that will be happy to download spreadsheet code as they are to send you a copy of gone with the wind…there goes the PC business…also unnecessary owning your own software since it’s cheaper to rent”
Cringley also says that these ideas take 10 to 15 years to come to fruition – it’s 13years since he wrote that.
Like countless others, one of the things I like to do when on holiday is read. I read anything and everything, from the normal holiday stuff by the likes of Grisham through to Tudor history from Starkey. There are times when I have up to 4 books on the go at any one time. I read to relax and educate – I immerse myself and chill out.
This year was different, not through choice I might add, but simply because of one of the books I decided to take with me. The horrid little tome that messed things up is a fairly old book. One which I was certain I had read before and enjoyed so the plan was to “refresh” my understanding of it. Also the copy I was given was a revised version – an “old” updated version – bringing everything bang up to date as of 1996.
What is the book that’s the subject of this piece? It goes by the title “Accidental Empires” by Robert X. Cringley (the subtitle’s good as well it’s “How the boys of Silicon Valley make their millions, battle foreign competition, and still can’t get a date”) – it’s a great book. But before we go any further here’s a short disclaimer. When I sat down to write this blog, I decided not to do any research on what the Cringley machine has written since the revised edition of the book was published (1996). That may seem strange but there’s good reason (at least in my mind).
So if I like the book so much, why then did it mess up my vacation? Well, as I said I like to read to relax, but all I kept doing was rereading passages and making copious notes to myself – I didn’t complete another book – just kept going over and over various bits to get the arguments and ideas straight in my mind. All the while with a view to write this blog because it was still so relevant, still able to teach us lessons.
For those of you who don’t know this book, it describes the birth of the PC industry, exploding myths and revealing interesting personality traits of those we’ve come to know and love over the years. Cringley tells us how it all happened more or less by accident. The people who made it happen were amateurs and that for the most part (at least in the early 90’s) still are.
Now for those of you who know me, you already understand where I’m coming from – I’m passionate about two things outside of my family and they are history and technology – so when they combine I’m in my element. History has a habit of repeating itself – we ignore the past at our peril – and that’s what got me this time.
In 2009, the world of IT is changing – and, at the risk of being shot as a heretic, the era of the PC as we’ve known it over the past 3 decades is coming to an end. The new IT paradigm is the cloud. But reading Cringely’s book one would be forgiven for thinking that he is describing what is happening in the world today.
Accept for a moment that the cloud offers a new computing platform upon which to develop applications. To take advantage of this new environment major software vendors are taking their existing products and trying to make them “cloud enabled” – this is a bad idea.
Why so?
Well let’s take an example from Cringley in the 80s. The application that made the Apple II so successful was Visicalc. Visicalc was the killer application and was responsible for the sale of millions of Apples. It wasn’t the hardware, it was the software – written for the specific piece of kit then ported to other platforms. For example, Westinghouse in Pittsburgh had decided that the Apple II wasn’t suitable for their use and yet business users had collectively bought 1,000 of the things just to run Visicalc. So why don’t we still use Visicalc today? After all, hardware may appear to get slower and die, but software remains in the same pristine shape it was in when first installed.
Well along came the IBM PC with a new operating system, new chip set, new everything. The simple answer was to “port” Visicalc to the new environment; take an “old” product and revamp it for a new environment. There’s a problem with this approach – you never get the same “intimacy” with the hardware, which means that performance is degraded, code becomes more fragmented, harder to understand and more expensive to maintain. This is where the genius of folks such as Mitch Kapor comes into play. Kapor is the father of Lotus, specifically Lotus 123. He started what became one of the fastest growing software companies ever – at one stage Lotus was the largest software company in the world. But Kapor didn’t invent the spreadsheet – his genius was to realise that the IBM PC represented a new computing platform – so he bet his house on making it happen and developed a “new” “killer” application for the PC.
What Kapor recognized is true today, it’s true for the cloud. Some of the best known products in the market today are just not suitable for cloud deployment. Porting them isn’t going to hack it either. The cloud demands a new breed of technology – written from the ground up to support multi-tenancy, to be accessible from anywhere, have good connectivity to the “old” world and provide a solid platform-as-a-service.
There are lots more examples and I would urge you to go and get a copy of the book and read it in schizophrenic mode – from an historical perspective and a “it’s happening again” one. Also a plea to Cringely – bring the book up to date you were right then and still are today.
To conclude I want to tell you about the extra couple of chapters that constitute the 1996 edition. Cringley makes a stab at predicting the future and in doing so introduces “I” word; the internet. He makes two points:
1. “…the internet topology is most often described as a cloud. Packets of data enter the cloud in one place and leave it in another…”
2. “…a set top device is not a computer because it has no software applications and no local storage, right? Wrong. The set top device will be connected to a network, and at the other end of the network will be companies that will be happy to download spreadsheet code as they are to send you a copy of gone with the wind…there goes the PC business…also unnecessary owning your own software since it’s cheaper to rent”
Cringley also says that these ideas take 10 to 15 years to come to fruition – it’s 13years since he wrote that.
Sunday, 19 July 2009
Who's afraid of the big bad wolf?
Some time ago I remember reading (or hearing, I can’t quite remember which) a comment by Bill Gates about who he feared the most as a competitor. His response was interesting and probably one of the most insightful things I’d every heard attributed to him. What he said was something like (and I can’t find the actual quote so can’t cite it) the competitor he worried most about was two kids in a garage. Now he just might have been spot on in his thinking.
Let me tell you a story…
Once upon a time there were three little pigs. One day, the time came for them to leave home and seek their fortunes and make lives and families for themselves. Before they left, their mother told them “Whatever you do, do it the best that you can because that's the way to get along in the world and make mountains of cash” So the pigs set off and started to make lives of their own.
Task number one for each of the pigs was to build a solid reliable business that would secure their futures and they would never have to worry again. But building businesses is not as easy as it looks – you need the right strategy, the right product and the right skills – nothing happens by chance.
The first little pig was called Larry Lotus. Larry decided to build a house out of straw and he proudly named it Chez Lotus Development Corp. The basic building blocks were a pile of home grown and bought in Office Productivity tools (loosely glued together and called Lotus SmartSuite). Larry did this because at the time it was the smart thing to do, and no one else had such a thing. Larry’s approach looked like a sound and sensible strategy.
The second little pig built his house out of sticks. His name was Nigel Netscape. Nigel also had a unique capability and one which seemed unassailable. There were those that thought this house was a little stronger than the one made from straw but looks can be deceiving as we shall see. The other problem for Nigel was called the business model – no one had really figured out how to make money from the pile of sticks Nigel had – how could the house weather any storm?
The third little pig built his house out of bricks – we’ll come back to this little pig a bit later after we take a look at what the wolf (who went by the alias of Bill) did to the other pigs.
One night the big bad wolf, who dearly loved to eat fat little piggies, came along and saw the first little pig in his house of straw. He said "Let me in, Let me in, little pig or I'll huff and I'll puff and I'll blow your house in!" "Not by the hair of my chinny chin chin", said the little pig. But of course the wolf did blow the house in and ate the first little pig.
The wolf then came to the house of sticks. "Let me in Let me in little pig or I'll huff and I'll puff and I'll blow your house in" "Not by the hair of my chinny chin chin", said the little pig. But the wolf blew that house in too, and ate the second little pig. But there was some indigestion and the wolf was almost decapitated – but all was soon well.
The wolf then came to the house of bricks and walked right passed it. There was nothing in this house remotely interesting to him so he let it be. The pig flourished, built up some healthy ways of making money and began to plant new things in the garden – now the wolf began to take notice.
One night the wolf returned to the brick house -" Let me in , let me in" cried the wolf "Or I'll huff and I'll puff till I blow your house in" "Not by the hair of my chinny chin chin" said the pig.
Well, the wolf huffed and puffed but he could not blow down that brick house. But the wolf was a sly old wolf and he climbed up on the roof to look for a way into the brick house.
The little pig saw the wolf climb up on the roof, so he lit a roaring fire in the fireplace and placed on it a large kettle of water. When the wolf finally found the hole in the chimney he crawled down and KERSPLASH – he fell right into that kettle of water and that was the end of the pig’s troubles with the big bad wolf.
This little Pig’s name is Gary Google.
So, were did the wolf go wrong? While the Wolf was hunting around for new pigs to eat, a revolution was taking place under his very nose but he just couldn’t see it. The clouds were gathering and Gary was making some neat new stuff to take advantage of it. What stuff? Chrome, Chrome OS, App Server, the recent release of non-beta Google Apps, Secure Data link, Android, and there’s probably more that I’ve forgotten to mention. But you see the point.
So to remind a senior executive what he said about Gary’s company “that’s not a real company it’s a house of Cards”.
Well it’s starting to look very much like a house of bricks to me and the two kids in the garage have done rather well from where I sit. Sorry big bad Wolf you missed your opportunity big time!
But wait! Is that an apple I see in Gary’s mouth?
Let me tell you a story…
Once upon a time there were three little pigs. One day, the time came for them to leave home and seek their fortunes and make lives and families for themselves. Before they left, their mother told them “Whatever you do, do it the best that you can because that's the way to get along in the world and make mountains of cash” So the pigs set off and started to make lives of their own.
Task number one for each of the pigs was to build a solid reliable business that would secure their futures and they would never have to worry again. But building businesses is not as easy as it looks – you need the right strategy, the right product and the right skills – nothing happens by chance.
The first little pig was called Larry Lotus. Larry decided to build a house out of straw and he proudly named it Chez Lotus Development Corp. The basic building blocks were a pile of home grown and bought in Office Productivity tools (loosely glued together and called Lotus SmartSuite). Larry did this because at the time it was the smart thing to do, and no one else had such a thing. Larry’s approach looked like a sound and sensible strategy.
The second little pig built his house out of sticks. His name was Nigel Netscape. Nigel also had a unique capability and one which seemed unassailable. There were those that thought this house was a little stronger than the one made from straw but looks can be deceiving as we shall see. The other problem for Nigel was called the business model – no one had really figured out how to make money from the pile of sticks Nigel had – how could the house weather any storm?
The third little pig built his house out of bricks – we’ll come back to this little pig a bit later after we take a look at what the wolf (who went by the alias of Bill) did to the other pigs.
One night the big bad wolf, who dearly loved to eat fat little piggies, came along and saw the first little pig in his house of straw. He said "Let me in, Let me in, little pig or I'll huff and I'll puff and I'll blow your house in!" "Not by the hair of my chinny chin chin", said the little pig. But of course the wolf did blow the house in and ate the first little pig.
The wolf then came to the house of sticks. "Let me in Let me in little pig or I'll huff and I'll puff and I'll blow your house in" "Not by the hair of my chinny chin chin", said the little pig. But the wolf blew that house in too, and ate the second little pig. But there was some indigestion and the wolf was almost decapitated – but all was soon well.
The wolf then came to the house of bricks and walked right passed it. There was nothing in this house remotely interesting to him so he let it be. The pig flourished, built up some healthy ways of making money and began to plant new things in the garden – now the wolf began to take notice.
One night the wolf returned to the brick house -" Let me in , let me in" cried the wolf "Or I'll huff and I'll puff till I blow your house in" "Not by the hair of my chinny chin chin" said the pig.
Well, the wolf huffed and puffed but he could not blow down that brick house. But the wolf was a sly old wolf and he climbed up on the roof to look for a way into the brick house.
The little pig saw the wolf climb up on the roof, so he lit a roaring fire in the fireplace and placed on it a large kettle of water. When the wolf finally found the hole in the chimney he crawled down and KERSPLASH – he fell right into that kettle of water and that was the end of the pig’s troubles with the big bad wolf.
This little Pig’s name is Gary Google.
So, were did the wolf go wrong? While the Wolf was hunting around for new pigs to eat, a revolution was taking place under his very nose but he just couldn’t see it. The clouds were gathering and Gary was making some neat new stuff to take advantage of it. What stuff? Chrome, Chrome OS, App Server, the recent release of non-beta Google Apps, Secure Data link, Android, and there’s probably more that I’ve forgotten to mention. But you see the point.
So to remind a senior executive what he said about Gary’s company “that’s not a real company it’s a house of Cards”.
Well it’s starting to look very much like a house of bricks to me and the two kids in the garage have done rather well from where I sit. Sorry big bad Wolf you missed your opportunity big time!
But wait! Is that an apple I see in Gary’s mouth?
Monday, 6 July 2009
Standard Case management
The human being always looks down when he is examining another person's standard; he never finds one that he has to examine by looking up.Mark Twain - What Is Man?
As many of you who have followed my rants and occasional blogs through the years are aware, I have always considered the idea of case management to be an intrinsic part of the technology that we now call Business Process Management. So it should come as no surprise that I have been an active supporter of the efforts of Henk de Man of Cordys to put together an RFP for the Object Management Group. What Henk has defined makes absolute sense to me. The RFP essentially says that BPMN is inadequate for case management but that case management should leverage BPMN for the "process" part. Since the two “technologies” (Case Management and Process Management) are, in my view, inextricably linked, how I could not agree with Henk’s arguments. It’s not just me who’s saying this is the right thing to do; Bruce Silver’s excellent blog on Henk’s work (probably for the first time in history, I agree completely with what Bruce has to say) means that I don’t have to write anything more on case management in this paper though you may want to take a look at previous blogs I’ve written here and here to see how important I believe the subject is.
So that’s OK then – someone has taken the initiative to put something together that is going to help bring case management to the fore and give it its rightful place in the “BPM Stack”.
No – nothing’s ever that easy.
There seems to be 2 issues that stemmed from the proposal, and for the sake of clarity I was not at the meeting, so much of what comes next is hearsay, however the information comes from a trusted source that was present at the meeting.
First and foremost is the usual OMG dilemma – conflicting standards supporters whishing to protect their own turf – in other words, which group wants to “own” the standard. This was beautifully illustrated by none other than that well known advocate of industry standards IBM. During the debate on the standards (which would normally culminate in a vote) IBM seemed to be at odds with itself (always a potential issue if you have more than one person representing an organization at a standards meeting) in trying to decide what to base the potential case management specification. Should it be UML, or BPMN? Or should a separate and independent meta-model be proposed? This suggests a fundamental problem within the OMG, the perceived competition between UML and BPMN. The BPMN folks want to use “new BPMN extension mechanisms” to define the case management meta-model (which sounds tricky to me) whereas the “UML supporters thought it obvious that case management has to be data-driven, and that it requires state machine, therefore would have to be UML-based. Poor Henk, having taken the initiative to propose a standard he was immediately faced with the realities of getting things understood let alone moving forward.
It’s easy to see and understand the dilemmas organizations like the OMG are faced with (and having been involved in the standards world for the past 14 or so years I’ve sat through endless, unresolved, debates myself) but these things are simply a fact of life. However things have started moving and even though organizations such as SAP and IBM were a little late in recognizing the case management business case and standardization initiative. There is growing support and recognition of the value of this initiative, there is no doubt that the proposal is going to be debated and supported.
The small issue of late recognition has led to an unfortunate delay of a further three months is unfortunate but given the fact that case management is now broadly recognized as a viable and much needed addition, I hope that the expected release of the RFP will go smoothly in September.
The second issue is more of a problem and needs to be voiced.
One of the things one needs to do when trying to gain support for a standards proposal is to lobby as many folks as possible to ensure they understand the need, the objectives and the benefits from putting a standard in place. So it’s all about garnering support and not getting sides swiped or torpedoed either intentionally or otherwise. But it does happen and it’s always disappointing when it seems that it is done intentionally, by people that didn’t actually attend the meeting.
As Bruce Silver says in his blog (see above) “a major problem with case management is that there is no common definition for what it is. I would assert you could say the same thing about BPM until BPMN provided a standard vocabulary.” So why would anyone want to halt the development of a standard because it is too early, when clearly the earlier we can get some sort of standard notation in place will be for the benefit of all. If we accept that the technology has been around for a while we have to conclude that it’s hardly set the world on fire, even though I firmly believe that workflow automation and case management are different sides of the same coin and go hand in glove. I would even suggest that a large proportion of workflow users thought they were buying case when they started out. So the line of thinking that suggests standards are in some way too early or will stifle innovation in the advancement makes no sense to me whatsoever, especially when the thinking is coming from the analyst/consulting side of the industry!
Don’t get me wrong I have nothing against the analyst or consulting community, they do an excellent and very valuable job, but they don’t build products. Now I know that some will take issue with that but they don’t. That’s not to say that some have not been in the vanguard of product development at some stage in their careers. Indeed, some of my favorite sparring partners are were once chief architects and/or CTO’s from product companies, but they don’t build them anymore. As I say, analysts and consultants do an excellent job of commenting upon products or suggesting ways to take them to market or advising on market trends. I don’t see them as vehicles for developing standards, and I certainly do not see any value in trying to scupper the development of standards for “wooly” and ill-defined reasons.
A technology that’s been around since the late 80s and early 90s could certainly use some help from the likes of us that are supposedly in the know. It’s not too early to put the ideas under the spotlight and bring them to the front so that Case Management can get its time in the sun.
My plea is that we not take every opportunity to derail things just because it suggestions might be at odds with an individual’s original thinking.
If you want to make a real difference, build a product.
As many of you who have followed my rants and occasional blogs through the years are aware, I have always considered the idea of case management to be an intrinsic part of the technology that we now call Business Process Management. So it should come as no surprise that I have been an active supporter of the efforts of Henk de Man of Cordys to put together an RFP for the Object Management Group. What Henk has defined makes absolute sense to me. The RFP essentially says that BPMN is inadequate for case management but that case management should leverage BPMN for the "process" part. Since the two “technologies” (Case Management and Process Management) are, in my view, inextricably linked, how I could not agree with Henk’s arguments. It’s not just me who’s saying this is the right thing to do; Bruce Silver’s excellent blog on Henk’s work (probably for the first time in history, I agree completely with what Bruce has to say) means that I don’t have to write anything more on case management in this paper though you may want to take a look at previous blogs I’ve written here and here to see how important I believe the subject is.
So that’s OK then – someone has taken the initiative to put something together that is going to help bring case management to the fore and give it its rightful place in the “BPM Stack”.
No – nothing’s ever that easy.
There seems to be 2 issues that stemmed from the proposal, and for the sake of clarity I was not at the meeting, so much of what comes next is hearsay, however the information comes from a trusted source that was present at the meeting.
First and foremost is the usual OMG dilemma – conflicting standards supporters whishing to protect their own turf – in other words, which group wants to “own” the standard. This was beautifully illustrated by none other than that well known advocate of industry standards IBM. During the debate on the standards (which would normally culminate in a vote) IBM seemed to be at odds with itself (always a potential issue if you have more than one person representing an organization at a standards meeting) in trying to decide what to base the potential case management specification. Should it be UML, or BPMN? Or should a separate and independent meta-model be proposed? This suggests a fundamental problem within the OMG, the perceived competition between UML and BPMN. The BPMN folks want to use “new BPMN extension mechanisms” to define the case management meta-model (which sounds tricky to me) whereas the “UML supporters thought it obvious that case management has to be data-driven, and that it requires state machine, therefore would have to be UML-based. Poor Henk, having taken the initiative to propose a standard he was immediately faced with the realities of getting things understood let alone moving forward.
It’s easy to see and understand the dilemmas organizations like the OMG are faced with (and having been involved in the standards world for the past 14 or so years I’ve sat through endless, unresolved, debates myself) but these things are simply a fact of life. However things have started moving and even though organizations such as SAP and IBM were a little late in recognizing the case management business case and standardization initiative. There is growing support and recognition of the value of this initiative, there is no doubt that the proposal is going to be debated and supported.
The small issue of late recognition has led to an unfortunate delay of a further three months is unfortunate but given the fact that case management is now broadly recognized as a viable and much needed addition, I hope that the expected release of the RFP will go smoothly in September.
The second issue is more of a problem and needs to be voiced.
One of the things one needs to do when trying to gain support for a standards proposal is to lobby as many folks as possible to ensure they understand the need, the objectives and the benefits from putting a standard in place. So it’s all about garnering support and not getting sides swiped or torpedoed either intentionally or otherwise. But it does happen and it’s always disappointing when it seems that it is done intentionally, by people that didn’t actually attend the meeting.
As Bruce Silver says in his blog (see above) “a major problem with case management is that there is no common definition for what it is. I would assert you could say the same thing about BPM until BPMN provided a standard vocabulary.” So why would anyone want to halt the development of a standard because it is too early, when clearly the earlier we can get some sort of standard notation in place will be for the benefit of all. If we accept that the technology has been around for a while we have to conclude that it’s hardly set the world on fire, even though I firmly believe that workflow automation and case management are different sides of the same coin and go hand in glove. I would even suggest that a large proportion of workflow users thought they were buying case when they started out. So the line of thinking that suggests standards are in some way too early or will stifle innovation in the advancement makes no sense to me whatsoever, especially when the thinking is coming from the analyst/consulting side of the industry!
Don’t get me wrong I have nothing against the analyst or consulting community, they do an excellent and very valuable job, but they don’t build products. Now I know that some will take issue with that but they don’t. That’s not to say that some have not been in the vanguard of product development at some stage in their careers. Indeed, some of my favorite sparring partners are were once chief architects and/or CTO’s from product companies, but they don’t build them anymore. As I say, analysts and consultants do an excellent job of commenting upon products or suggesting ways to take them to market or advising on market trends. I don’t see them as vehicles for developing standards, and I certainly do not see any value in trying to scupper the development of standards for “wooly” and ill-defined reasons.
A technology that’s been around since the late 80s and early 90s could certainly use some help from the likes of us that are supposedly in the know. It’s not too early to put the ideas under the spotlight and bring them to the front so that Case Management can get its time in the sun.
My plea is that we not take every opportunity to derail things just because it suggestions might be at odds with an individual’s original thinking.
If you want to make a real difference, build a product.
Friday, 26 June 2009
The man who saved the world
I’m warming to the theme of these underdog blog posts – unsung heroes. People who have made a significant, yet largely overlooked contribution to the world of information technology. The previous post of this type was singing the praises of a real pioneer in the development of software; this time I’m going to focus on the development of hardware. But before I tell you about this individual I need to address a delicate, possibly controversial, subject.
Who was it that invented the programmable digital computer?
Everyone knows the answer to that, or at least they think they do. The popular perception is that the programmable computer was invented in 1946, by John Mauchly and J Presper Eckert, as part of a project they were working on at the university of Pennsylvania's Moore School of Electrical Engineering. They called their new invention the ENIAC I (Electrical Numerical Integrator And Calculator). From this unquestionably pioneering work, the two went on to found Univac, a computer manufacturing company that eventually became today’s Unisys corporation. So that’s who invented the first programmable computer – right? Wrong:
Wrong; wrong; wrong.
This may come as a shock to many, but it’s time to set the record straight (and not for the first time) – the myth that we have heard over the years about Eniac is just plain wrong, untrue, dare a I say it? A fantasy. The Eniac was not the first programmable computer. All that we have heard in the past from Univac, and various other interested parties, is no more than marketing bunkum. So if Eniac is not the answer then what was the first programmable computer and who was responsible for its birth?
Colossus was; plain and simple.
The following is a potted history of its birth. But the real story is about the man that invented it; the humble, quietly spoken, genius from the U.K. The man that may just have saved the free world from countless deaths and a reign of tyranny.
Allow me to introduce you to Tommy Flowers MBE. Tommy Flowers (or to give him his full name Thomas Harold Flowers) was born in the east end of London at the end of 1905 to ordinary working class parents (his father was a builder). When he left school (which in those days was at the age of 14) Tommy became an apprentice Mechanical Engineer at the Royal Arsenal, but while he was learning his trade, he took himself off to evening classes and earned a degree in the relatively new science of electrical engineering.
Soon after graduating, Tommy joined the telecommunications branch of the General Post Office (many years later it was privatised and renamed British Telecom) as a research scientist at the Dollis Hill research station in North London. From about 1935 onwards, his major research interest was the problem of transmitting control signals over long distances, thereby enabling human operators to be replaced by automatic switching equipment. This resulted in his experiments with early electronic systems that would form the basis not only for Colossus, but also for advanced long-distance telephone systems that developed into modern direct dialling.
Tommy’s research was interrupted by the outbreak of World War 2. This meant that all civil work in Britain had to be subordinated to war work. In 1942 Tommy was sent to Bletchley Park, where he met Alan Turing (a brilliant mathematician and a leading figure in the activities taking place in Bletchley) – this meeting ultimately resulted in Tommy becoming involved in top-secret code breaking activities and the development of Colossus.
Tommy’s own account of the development of Colossus is written up here. But the extraordinary thing he tells us is “That Colossus occurred at all was the result of a series of lucky chances to which one more is added if because of it I am to be numbered among the computer pioneers. At the time I had no thought or knowledge of computers in the modern sense, and had never heard the term used except to describe somebody who did calculations on a desk machine.”
Tommy and his team designed and built (for the most part with their own money) the first Colossus machine in 11 months. It contained 12,000 vacuum valves, didn’t store any data and was programmed through external use of telephone plugs and cord connections. But it did the job that was asked of it and it did it accurately and quickly.
Before the end of the war a total of 10 machines had been built and commissioned. Their contribution, and that of Tommy’s, in shortening the duration of World War 2 is unquestionable. Tommy’s own conclusion was “Although the final outcome of the war would no doubt have been the same, its history might have been different with greater loss of life and damage”
After the War, Tommy returned to his “day job” at the Post Office. The then prime minister, Winston Churchill, ordered the destruction of all Colossus machines and accompanying documentation. The work of the pioneers at Bletchley Park was covered by the official secrets act, so the work of people like Tommy went unrecognized for over 30 years.
He did receive some recognition for his efforts. He was awarded an MBE by a grateful nation and a “prize” of £1,000 at the end of the war. However, I doubt this covered his expenses since he built the first machine from his own pocket.
Colossus undoubtedly made a contribution to the development of computers in Britain by showing Turing, Newman, and others what electronics could do and that knowledge turned their minds to computers immediately after the war. Tommy more or less turned his back on computers and concentrated on his first love, telephone exchanges. In 1946 he solved the problem he’d encountered back in the late 30s when he discovered that what was needed to make electronic exchanges economic was time-division multiplexing, but no practical use was made of the discovery until after he had retired – but that, as they say, is another story.
Tommy died in 1998 at the age of 92. He’s my number one Hardware engineer.
So now you know – Eniac – pah!
Additional Reading http://c2.com/cgi/wiki?TommyFlowers
http://www.acsa2000.net/a_computer_saved_the_world.htm
Who was it that invented the programmable digital computer?
Everyone knows the answer to that, or at least they think they do. The popular perception is that the programmable computer was invented in 1946, by John Mauchly and J Presper Eckert, as part of a project they were working on at the university of Pennsylvania's Moore School of Electrical Engineering. They called their new invention the ENIAC I (Electrical Numerical Integrator And Calculator). From this unquestionably pioneering work, the two went on to found Univac, a computer manufacturing company that eventually became today’s Unisys corporation. So that’s who invented the first programmable computer – right? Wrong:
Wrong; wrong; wrong.
This may come as a shock to many, but it’s time to set the record straight (and not for the first time) – the myth that we have heard over the years about Eniac is just plain wrong, untrue, dare a I say it? A fantasy. The Eniac was not the first programmable computer. All that we have heard in the past from Univac, and various other interested parties, is no more than marketing bunkum. So if Eniac is not the answer then what was the first programmable computer and who was responsible for its birth?
Colossus was; plain and simple.
The following is a potted history of its birth. But the real story is about the man that invented it; the humble, quietly spoken, genius from the U.K. The man that may just have saved the free world from countless deaths and a reign of tyranny.
Allow me to introduce you to Tommy Flowers MBE. Tommy Flowers (or to give him his full name Thomas Harold Flowers) was born in the east end of London at the end of 1905 to ordinary working class parents (his father was a builder). When he left school (which in those days was at the age of 14) Tommy became an apprentice Mechanical Engineer at the Royal Arsenal, but while he was learning his trade, he took himself off to evening classes and earned a degree in the relatively new science of electrical engineering.
Soon after graduating, Tommy joined the telecommunications branch of the General Post Office (many years later it was privatised and renamed British Telecom) as a research scientist at the Dollis Hill research station in North London. From about 1935 onwards, his major research interest was the problem of transmitting control signals over long distances, thereby enabling human operators to be replaced by automatic switching equipment. This resulted in his experiments with early electronic systems that would form the basis not only for Colossus, but also for advanced long-distance telephone systems that developed into modern direct dialling.
Tommy’s research was interrupted by the outbreak of World War 2. This meant that all civil work in Britain had to be subordinated to war work. In 1942 Tommy was sent to Bletchley Park, where he met Alan Turing (a brilliant mathematician and a leading figure in the activities taking place in Bletchley) – this meeting ultimately resulted in Tommy becoming involved in top-secret code breaking activities and the development of Colossus.
Tommy’s own account of the development of Colossus is written up here. But the extraordinary thing he tells us is “That Colossus occurred at all was the result of a series of lucky chances to which one more is added if because of it I am to be numbered among the computer pioneers. At the time I had no thought or knowledge of computers in the modern sense, and had never heard the term used except to describe somebody who did calculations on a desk machine.”
Tommy and his team designed and built (for the most part with their own money) the first Colossus machine in 11 months. It contained 12,000 vacuum valves, didn’t store any data and was programmed through external use of telephone plugs and cord connections. But it did the job that was asked of it and it did it accurately and quickly.
Before the end of the war a total of 10 machines had been built and commissioned. Their contribution, and that of Tommy’s, in shortening the duration of World War 2 is unquestionable. Tommy’s own conclusion was “Although the final outcome of the war would no doubt have been the same, its history might have been different with greater loss of life and damage”
After the War, Tommy returned to his “day job” at the Post Office. The then prime minister, Winston Churchill, ordered the destruction of all Colossus machines and accompanying documentation. The work of the pioneers at Bletchley Park was covered by the official secrets act, so the work of people like Tommy went unrecognized for over 30 years.
He did receive some recognition for his efforts. He was awarded an MBE by a grateful nation and a “prize” of £1,000 at the end of the war. However, I doubt this covered his expenses since he built the first machine from his own pocket.
Colossus undoubtedly made a contribution to the development of computers in Britain by showing Turing, Newman, and others what electronics could do and that knowledge turned their minds to computers immediately after the war. Tommy more or less turned his back on computers and concentrated on his first love, telephone exchanges. In 1946 he solved the problem he’d encountered back in the late 30s when he discovered that what was needed to make electronic exchanges economic was time-division multiplexing, but no practical use was made of the discovery until after he had retired – but that, as they say, is another story.
Tommy died in 1998 at the age of 92. He’s my number one Hardware engineer.
So now you know – Eniac – pah!
Additional Reading http://c2.com/cgi/wiki?TommyFlowers
http://www.acsa2000.net/a_computer_saved_the_world.htm
Subscribe to:
Posts (Atom)
