One of the troubles of working in the IT industry is that no-one ever agrees on what the next big thing means. This is partly because software terms tend to run out from between your fingers when you try to grab them, just like soft putty - want to try defining ‘blogging’? One example I’m thinking about a lot at the moment is SOA (Service-oriented architecture). The problem isn’t just that people don’t know what SOA means, but that there isn’t a single definition - every software vendor has a subtly different message.
ZDNet Asia recently discussed SOA. I noticed that they mentioned that SOA was built on Web Services. This is often true, but the IBM product I work on, WebSphere ESB, allows one to build an SOA entirely without Web Services if desired - for example, you could use it to build one based on JMS messaging. A wide and generous definition of SOA is probably the only one that makes any sense. Some of IBM’s recent SOA products are built on SCA, which allows for a clearly-defined component model for SOA, but this doesn’t have to be used either: you could build an SOA with Visual Basic, a printer, and a minimum-wage employee to enter data, although your response time might suffer somewhat. The only requirement is that the architecture has to be oriented around services (hence the name).
Some might argue that this model is so simple as to be useless, and that might be true if organisations stuck to the widest definition, but if you’re able to adopt a particular type of technology (for example, going the WebSphere/SCA route), there is the possibility to begin to reap the benefits of reuse, adaptability, etc.
So be generous with the definition, but specific in the implementation.