Nature has give us a wonderful example of software programming for complex business problems – us, humans. We are built out of some basic objects (DNA). These building blocks may be the same, but they offer enough latitude for mass customisation – each of us is so different from the other. And, more importantly, in most cases, there are no bugs!
Organisations can also be thought of like organisms. Each organization at a simple level is similar – offer products and services to generate revenue leveraging people and/or machines. Yet, out of these building blocks, each enterprise is very different. Even if there are two companies targeting the same market, they differ in their strategy, execution and end results. In such a situation, it is hard to think of software which actually works on standardising operations in an enterprise. It should in fact enable just the opposite – allow organisations to be different, just like humans. Software needs to be built to allow individuals and enterprises to enable them to mass customise the aggregations of building blocks.
Think of this as “Lego Software”. Just as from the colourful building blocks that Lego offers, we can create all kinds of wonderful structures, so too must software offer the ability to model complex business processes through a collection of building blocks. These blocks should have well-defined interfaces that they can be connected together. They must also take into account the differences in how organizations and enterprises operate. In other words, these software components must allow for the electronic representation of different business processes.
Just as children can connect Lego blocks and create houses and cars, so too must managers be able to put these software components together. They are the ones who have the perfect representation of what needs to be created. They need to be given the tools to model their business processes, and the software generation should be hidden from them. It is possible to think of the collection of these business process models as a library from which the managers can pick and chose from (based on what others may have created), or to customise if nothing matches the need. What software needs to do is to allow managers to build an integrated view of the enterprise.
Matt Nicholson elaborates on the need for software components:
In the late 1970s, when IBM decided to enter the home computer market, it knew that it had to come up with a competitive machine in a very short time. IBM’s traditional procurement and manufacturing channels would not be able to respond quickly enough for this new, volatile market so instead it set up a special, small-scale task force. They decided that the only option was to buy most of the component parts of the PC off-the-shelf. Other companies soon realised that they could do the same, and so the PC ‘clone’ was born One of the big benefits of component-based construction is that manufacturers can specialise in what they know best.
Contrast this with the software industry. Most software is constructed from the ground up by a single company: either the end-user’s own IT department or an independent software house. Third-party tools may be used to construct the program – compilers, debuggers and the like – but the component parts of the application itself are rarely brought in. The development team may re-use code from earlier projects, but only if it is properly documented or the original programmer can remember sufficiently well how it functions.
So how can the [components] benefits be brought to the software world? The key ingredient is an accepted framework determining how components locate, identify and communicate with each other. Once the software industry accepts the software equivalent of the PCI bus or the SCSI interface then companies can start building components that conform to the standard, confident that they will be used within a framework that allows them to cooperate with other components built by other companies.