It turns out that laptop's are over 2500 years old! As the picture on the right proofs, the old Greeks invented the laptop already around 500 BC. The picture is a painting by the ancient Greek Douris is displayed in the Museum of Berlin. It shows a man holding a folding tablet.
I just had to include this in my blog. I used the title Plato's Revenge (see my first blog post) because we live more and more our lives through the virtual world of more or less mobile computers.
Thanks to Tom Worthington who presented this at Cebit 2010 in Sydney as part of his presentation on Optimising Sites for Mobile Devices and Search Engines. Further information can also be found on Wikipedia.
IT Management Blog: my thoughts about putting the "i" in IT
The house that never was
A long time ago, I received an email about a story where a man instructed a builder to build a house for him. He gave his requirements but also said to talk to his wife and kids to consider their needs. The whole story was rather funny and obviously you could see that the house to be built became basically impossible. It was an anecdote for the business requirements gathering process. I am currently faced with a situation that I thought could best be expressed in a similar way, though somehow I couldn’t get the funny bit in.
Business Manager: I need a two story house with a drive in garage to live in.
IT Manager: That will cost you a $.
Executives: Sorry too costly, you can have something for a ½ $
Business Manager and IT Manager: OK, let’s make a bungalow without a garage.
Some time goes by ….
Business Manager: Can we finish off the house and put that second story on top and put that garage in?
IT Manager: Yes, it will cost you ¾ $ because we need to rebuild part of what you already have.
Executives: Sorry, too expensive.
Some times goes by …
Business Manager: Can’t we do something about it? We need some expansion. It’s too small. I’ve got a few cents left over.
IT Manager: I can start building some small improvements for a room on top during the weekends. It will take more time. I can throw in a few cents of my own as well to help you out. However we must be wary of the fact that the foundation wasn’t built to have a second story on top. So we have to be careful and it won’t be the most solid construction.
Business Manager: Please do it, we need the extra space and every little bit helps.
Some construction work goes on. Not is only one room added, but later another one. Also an extra shower is added to the top floor. Over time quite some cents are poured into the expansion of the house, all adding up to the ½ $. But since it is done each time by other builders and without an overarching plan, the result is not very solid and not very elegant.
Business Manager: You know, this house that we’ve got, actually it is not really what we need. These days, we’re using it more as an office and sometimes also as a little factory. And we need to be able to park that car somewhere. The rooms on the ground floor to are too small, can’t you make something so we can park upstairs?
IT Manager: Sorry. No. That would be such a radical reconstruction that we would be better to knock it down and rebuild from scratch. With what I think you want, it’s going to cost you a $. However, I suggest you rethink whether you want a home, an office or a factory because once built, it’s not easy to change it. Why don’t you consult a fortune teller?
Business Manager: OK, I’ll get that fortune teller to advice us on what we need. I’ve already asked for that $ you said that was required. But all this is going to take some time, can we still make some more smaller improvements?
I am curious what will come next…
Sometimes you have those legacy systems that grow and grow. When the business processes slowly change over time, after a while it becomes very inefficient or even impossible to adapt the system to the changed needs. Because the core design of the system does not align anymore with the business process, users will come back for more and more smaller changes while never really being satisfied. The developers run into limitations and certain changes just can’t be made anymore.
There are only two options. Accept the limitations of the system and stop investing in more system changes or do a proper business analysis, redesign the business processes where required and subsequently design and build a complete new system accordingly.
Business Manager: I need a two story house with a drive in garage to live in.
IT Manager: That will cost you a $.
Executives: Sorry too costly, you can have something for a ½ $
Business Manager and IT Manager: OK, let’s make a bungalow without a garage.
Some time goes by ….
Business Manager: Can we finish off the house and put that second story on top and put that garage in?
IT Manager: Yes, it will cost you ¾ $ because we need to rebuild part of what you already have.
Executives: Sorry, too expensive.
Some times goes by …
Business Manager: Can’t we do something about it? We need some expansion. It’s too small. I’ve got a few cents left over.
IT Manager: I can start building some small improvements for a room on top during the weekends. It will take more time. I can throw in a few cents of my own as well to help you out. However we must be wary of the fact that the foundation wasn’t built to have a second story on top. So we have to be careful and it won’t be the most solid construction.
Business Manager: Please do it, we need the extra space and every little bit helps.
Some construction work goes on. Not is only one room added, but later another one. Also an extra shower is added to the top floor. Over time quite some cents are poured into the expansion of the house, all adding up to the ½ $. But since it is done each time by other builders and without an overarching plan, the result is not very solid and not very elegant.
Business Manager: You know, this house that we’ve got, actually it is not really what we need. These days, we’re using it more as an office and sometimes also as a little factory. And we need to be able to park that car somewhere. The rooms on the ground floor to are too small, can’t you make something so we can park upstairs?
IT Manager: Sorry. No. That would be such a radical reconstruction that we would be better to knock it down and rebuild from scratch. With what I think you want, it’s going to cost you a $. However, I suggest you rethink whether you want a home, an office or a factory because once built, it’s not easy to change it. Why don’t you consult a fortune teller?
Business Manager: OK, I’ll get that fortune teller to advice us on what we need. I’ve already asked for that $ you said that was required. But all this is going to take some time, can we still make some more smaller improvements?
I am curious what will come next…
Sometimes you have those legacy systems that grow and grow. When the business processes slowly change over time, after a while it becomes very inefficient or even impossible to adapt the system to the changed needs. Because the core design of the system does not align anymore with the business process, users will come back for more and more smaller changes while never really being satisfied. The developers run into limitations and certain changes just can’t be made anymore.
There are only two options. Accept the limitations of the system and stop investing in more system changes or do a proper business analysis, redesign the business processes where required and subsequently design and build a complete new system accordingly.
Software licenses should be based upon intensity of use
Similarly as the music industry that needs to find different ways to charge people for music, software vendors should simplify their licensing. After having gone through some dramas around Oracle's licensing, I had to laugh when I read this part of Microsoft's explanation of their SQL-server license structure.
Simplification of the licensing structures is my opinion inevitable. Due to changes in relation to virtualisation and the cloud computing, traditional concepts such as servers, CPU’s or individual installations will have complete new meanings.
Putting the software in the cloud and letting people and businesses pay per usage is one way licensing will change. When using it as a service you can't really talk about licenses per processor or per PC anymore.
In the past I used IBM's Rational software. The software was locked to a specific PC and you needed to register the PC online with the vendor. This gave the vendor optimal control over the usage of the software but made it practically unworkable for you as the customer. As soon as you wanted to use another PC, you had to go through the drama of releasing the lock and then allocating it to another PC.
Licensing per individual user or per processor doesn't make sense anymore in this day and age. “Concurrent users” was the answer to having a larger but low intensity user group of users. But if you don't let the software block access when you have reached this limit there is no way to control the usage according to the agreement. The IT department wouldn't even know if there would be such occurrences of temporary over-usage.
When the web came along, in those early days I noticed that it took a little while for software vendors to respond to the undefined number of users coming in from the Internet.
Now we have the challenge of virtualisation where for example Oracle ignores the whole concept and just lets you pay for the physical underlying hardware, unless you buy their own virtualisation technology.
I think it is time licensing is simplified, for example based upon volume of data processed or frequency of use – the intensity of use.
Frequency of use (occurrences per annum) is ideal for software where end-users directly interact with it such as desktop software. Heavy users pay more and if you only intermittently use it, you pay less. There should be no problem to register each occurrence of use in a central register that can be audited by the IT department and the vendor alike. Automatic alerts could be send to the IT department (or even the vendor) when the usage reaches a certain threshold.
For databases, application servers and the like you can easily measure the amount of data being transacted (inserted or retrieved) and base the licenses upon that. This automatically solves the issue around licenses for standby and failover systems (though Microsoft’s approach to provide this for free is even better). If the amount of transactions stays below a certain threshold (and provided you already have somewhere a license), you should be able to use the software “for free”. In case you need to activate your standby system, you basically transfer the volume of transactions and therefore there would be no costs involved. A logic that some vendors luckily already have adopted.
For operating systems, the story is a bit trickier but for PC’s the license is mostly already sold as part of the device. For servers a simplification should be possible as well. You can’t rely on the definition of a server or a CPU anymore, so I belief that the answer should also be sought in something like a transaction volume or data volume based pricing model.
I am not the first one to come up with this idea and there will be a bit more to consider as I describe here, but I don’t belief that in the long run the current license models are sustainable. Organisations need to be able to move their systems around within their own cloud without running the risk suddenly to be in breach of the license agreement. Don’t forget that IT and software is all about virtualisation. It does not live in the real world. So far the operating system was aware of the physical hardware but that has gone by now as well. Software runs somewhere. You don’t know anymore exactly on which server or CPU. It shouldn’t matter. The only thing that remains is the intensity of use.
Just as in the music industry, the software vendors will resist as much as possible but eventually Plato’s revenge will also come over Larry Ellison.
Some further reading:
Microsoft has been driving thought leadership in this area by charging the same amount per processor, regardless of how many cores are in the processor. In contrast, Oracle asks customers to multiply each “core” by different factors depending on processor type. IBM has a dual policy where customers with x86 platforms are charged per processor and customers on IBM’s POWER5-based systems are charged per core.
[From: SQL Server 2008 pricing and licensing, July 2008]
Simplification of the licensing structures is my opinion inevitable. Due to changes in relation to virtualisation and the cloud computing, traditional concepts such as servers, CPU’s or individual installations will have complete new meanings.
Putting the software in the cloud and letting people and businesses pay per usage is one way licensing will change. When using it as a service you can't really talk about licenses per processor or per PC anymore.
In the past I used IBM's Rational software. The software was locked to a specific PC and you needed to register the PC online with the vendor. This gave the vendor optimal control over the usage of the software but made it practically unworkable for you as the customer. As soon as you wanted to use another PC, you had to go through the drama of releasing the lock and then allocating it to another PC.
Licensing per individual user or per processor doesn't make sense anymore in this day and age. “Concurrent users” was the answer to having a larger but low intensity user group of users. But if you don't let the software block access when you have reached this limit there is no way to control the usage according to the agreement. The IT department wouldn't even know if there would be such occurrences of temporary over-usage.
When the web came along, in those early days I noticed that it took a little while for software vendors to respond to the undefined number of users coming in from the Internet.
Now we have the challenge of virtualisation where for example Oracle ignores the whole concept and just lets you pay for the physical underlying hardware, unless you buy their own virtualisation technology.
I think it is time licensing is simplified, for example based upon volume of data processed or frequency of use – the intensity of use.
Frequency of use (occurrences per annum) is ideal for software where end-users directly interact with it such as desktop software. Heavy users pay more and if you only intermittently use it, you pay less. There should be no problem to register each occurrence of use in a central register that can be audited by the IT department and the vendor alike. Automatic alerts could be send to the IT department (or even the vendor) when the usage reaches a certain threshold.
For databases, application servers and the like you can easily measure the amount of data being transacted (inserted or retrieved) and base the licenses upon that. This automatically solves the issue around licenses for standby and failover systems (though Microsoft’s approach to provide this for free is even better). If the amount of transactions stays below a certain threshold (and provided you already have somewhere a license), you should be able to use the software “for free”. In case you need to activate your standby system, you basically transfer the volume of transactions and therefore there would be no costs involved. A logic that some vendors luckily already have adopted.
For operating systems, the story is a bit trickier but for PC’s the license is mostly already sold as part of the device. For servers a simplification should be possible as well. You can’t rely on the definition of a server or a CPU anymore, so I belief that the answer should also be sought in something like a transaction volume or data volume based pricing model.
I am not the first one to come up with this idea and there will be a bit more to consider as I describe here, but I don’t belief that in the long run the current license models are sustainable. Organisations need to be able to move their systems around within their own cloud without running the risk suddenly to be in breach of the license agreement. Don’t forget that IT and software is all about virtualisation. It does not live in the real world. So far the operating system was aware of the physical hardware but that has gone by now as well. Software runs somewhere. You don’t know anymore exactly on which server or CPU. It shouldn’t matter. The only thing that remains is the intensity of use.
Just as in the music industry, the software vendors will resist as much as possible but eventually Plato’s revenge will also come over Larry Ellison.
Some further reading:
- An argument in relation to processing capacity
by Devon Hillard - Discussion on CIO.com by Thomas Wailgum: The End of Traditional Software Licensing? Not So Fast
- Holger Kisker from Forrester: Traditional Software Licensing Comes To An End
System implementations that must fail: MS SharePoint
Sometimes you have those systems of which the first implementation always need to fail. From experience and what I read from other organizations, typically CRM and enterprise Intranet (including document management such as with MS SharePoint) implementations suffer from this.
Fail is a bit of a harsh word for it because if you look at the characteristics of those projects, realistically you know that success will only come in subsequent phases. Though I do belief that if you do everything right first time, success can be achieved in the first round.
So how come that there are so many (perceived) failures?
The systems and projects I refer to have some common characteristics that make it difficult to get it perfect in the first attempt.
First of all they are shared systems for the enterprise and not for a single department. It means that there are many stakeholders and that the system is to be used by virtually everyone in the organisation. There is not one single business owner but many. You will end up with a steering committee where each member will be an expert in the subject as well. Even if your project team might have all the right insights and have the right plan for success, the steering committee might want to send you in the wrong direction. Your plan will be modified and the delicately constructed approach falls apart like a card house.
This, given you were able to come to such a plan in the first place. In scenarios where your team members also become end users, you run into the challenge of having a team full of business owners and subject matter experts.
Specifically with something like SharePoint everyone is an expert when it comes down to requirements, design, usability and change management. Even your expensive consultants might not be too much of a help. The tool has many great new features but it would make a too large a culture and even intellectual challenge to implement it according to the theoretical ideal design as the tool prescribes it. You need to be cautious to implement a solution as a software vendor sees the world. Your consultants probably tell you to go all the way, but due to the big paradigm shift I don’t think it is wise to take too many steps at once.
When using SharePoint for managing documents and you want to enforce the recording of a certain set of meta data for compliance purposes you are bound to make life difficult for your end users. People need to perform tasks in the system for which there is no direct benefit for them. This is a general recurring theme with many enterprise systems where people need to administer information where they can't immediately see how and where it will be used. You will get resistance and as a minimum you will find that people are slack with respect to the quality of the data.
Systems like SharePoint where you mix a new paradigm to managing documents and files with improved collaboration, require a significant change in the thinking and behaviour of people. As I described in a previous post about my friend who for the first time got in contact with a PC and MS DOS, this can be challenge. I see many people still struggling with concepts such as versioning and check-in/check-out, not unlike my mother still struggling with the basics of her windows XP.
I found that no matter how long you wait until the technology has matured you will always feel disappointed with some set of lacking features during your first implementation.
When I first saw a demo of SharePoint in 2001 I got really excited and ran a pilot project. We found that the tool did not live up to the expectation and put it to the side. When in 2008 I thought the product had matured enough and we decided to go ahead with the implementation, I found that many aspects are still cumbersome. For example moving attachments out of email into SharePoint and vice versa in combination with enforcing meta data does not go smoothly. Third party solutions are available and the 2010 release promises improvements, but the fact remains that basic office integration is in the 2007 release not a finished product.
Collaboration is probably one the reasons you will have selected SharePoint. The 2007 release promised much on the subject but functionality for things like wikis an blogs is still primitive. In a context where uptake of the system goes difficult you might better wait with implementing those features until you are ready to implement the new release.
Besides the intellectual challenge of working with a new system, there is the cultural challenge. Sharing your data with others requires a different mindset. When I realised that it would be easier to grant the legal team access to my contract folders, I noticed within myself some resistance. It took me a few days before I actually did it. But taking the next step and giving full ownership of all my IT contracts to the legal team is something haven’t got around to yet.
Besides the issue of identifying whether your contract documents better sit with your project documentation or in a site of the legal team, it raises a few more questions. Specifically in relation to retention of the data on the longer term, different teams look at the data from a different perspective. The one team might easier decide to archive or destroy documents than the other. It might not be that you want to keep it all, but there are always some documents that you would like to retain for historical purposes. A proper archiving solution, usually one of the reasons to implement a Document Management system in the first place, should give people peace of mind on that subject but the fact remains that working together and trusting each other does not come easily.
All four characteristics regarding project management, design, end user adoption and maturity of the technology make it difficult to get your implementation right the first time.
Even if you are aware of all this and count on some stormy waters, put a lot of effort in stakeholder management, make your managers aware that it requires a lot of stamina and plan your change management in detail, the message that the benefit is for the organisation as a whole and that this can only be achieved on the long haul gets diluted over time in the waves of frustration.
The solution to this is to continue preaching the rationale behind the system, accept a few blows and keep pushing the project forward against the wind. Continue to implement improvements and continue with handholding staff using the system. The combination of getting used to the system, learning to think in new concepts and continuous improvement of the functionality will gradually improve the user experience and slowly make that the system gets accepted. That is the point that you will finally start reaping the benefits and can start introducing new concepts in terms of collaboration.
It simply is not easy to implement these type of systems. The stakeholders quite often all have a valid point and there are many paths to come to an envisaged end result. And what this end result will be is not easy to model beforehand. Usually you know what it is or could be once you have gone through the first implementation phase. That’s why I don’t want to go to hard on everyone involved and just see the failure more as perceived failure. People have different expectations and we cannot really see in each other’s heads what those are. Human kind is all about making progress and if you can prove that you made progress according to the original plan (but maybe not according to unwritten expectations), you should be proud of having taken that big step.
It is a big step because you have laid the foundation for the organisation to come to a new level of working and brought people to work and think on a different level of abstraction. A document is not just a file, but is data with history and versions, with different levels of access for different people and with different meta data which mean that over time different actions will be performed on that data. It is not easy to constantly have these aspects in the back of your mind each time you touch the document or talk about the document with others.
In the first instance much of these changes have no direct benefit to the users. Only when you can transform this into true collaboration they will experience the benefits. Social media concepts will help to transform this world of collaboration and this is already happening.
Fail is a bit of a harsh word for it because if you look at the characteristics of those projects, realistically you know that success will only come in subsequent phases. Though I do belief that if you do everything right first time, success can be achieved in the first round.
So how come that there are so many (perceived) failures?
The systems and projects I refer to have some common characteristics that make it difficult to get it perfect in the first attempt.
First of all they are shared systems for the enterprise and not for a single department. It means that there are many stakeholders and that the system is to be used by virtually everyone in the organisation. There is not one single business owner but many. You will end up with a steering committee where each member will be an expert in the subject as well. Even if your project team might have all the right insights and have the right plan for success, the steering committee might want to send you in the wrong direction. Your plan will be modified and the delicately constructed approach falls apart like a card house.
This, given you were able to come to such a plan in the first place. In scenarios where your team members also become end users, you run into the challenge of having a team full of business owners and subject matter experts.
Specifically with something like SharePoint everyone is an expert when it comes down to requirements, design, usability and change management. Even your expensive consultants might not be too much of a help. The tool has many great new features but it would make a too large a culture and even intellectual challenge to implement it according to the theoretical ideal design as the tool prescribes it. You need to be cautious to implement a solution as a software vendor sees the world. Your consultants probably tell you to go all the way, but due to the big paradigm shift I don’t think it is wise to take too many steps at once.
When using SharePoint for managing documents and you want to enforce the recording of a certain set of meta data for compliance purposes you are bound to make life difficult for your end users. People need to perform tasks in the system for which there is no direct benefit for them. This is a general recurring theme with many enterprise systems where people need to administer information where they can't immediately see how and where it will be used. You will get resistance and as a minimum you will find that people are slack with respect to the quality of the data.
Systems like SharePoint where you mix a new paradigm to managing documents and files with improved collaboration, require a significant change in the thinking and behaviour of people. As I described in a previous post about my friend who for the first time got in contact with a PC and MS DOS, this can be challenge. I see many people still struggling with concepts such as versioning and check-in/check-out, not unlike my mother still struggling with the basics of her windows XP.
I found that no matter how long you wait until the technology has matured you will always feel disappointed with some set of lacking features during your first implementation.
When I first saw a demo of SharePoint in 2001 I got really excited and ran a pilot project. We found that the tool did not live up to the expectation and put it to the side. When in 2008 I thought the product had matured enough and we decided to go ahead with the implementation, I found that many aspects are still cumbersome. For example moving attachments out of email into SharePoint and vice versa in combination with enforcing meta data does not go smoothly. Third party solutions are available and the 2010 release promises improvements, but the fact remains that basic office integration is in the 2007 release not a finished product.
Collaboration is probably one the reasons you will have selected SharePoint. The 2007 release promised much on the subject but functionality for things like wikis an blogs is still primitive. In a context where uptake of the system goes difficult you might better wait with implementing those features until you are ready to implement the new release.
Besides the intellectual challenge of working with a new system, there is the cultural challenge. Sharing your data with others requires a different mindset. When I realised that it would be easier to grant the legal team access to my contract folders, I noticed within myself some resistance. It took me a few days before I actually did it. But taking the next step and giving full ownership of all my IT contracts to the legal team is something haven’t got around to yet.
Besides the issue of identifying whether your contract documents better sit with your project documentation or in a site of the legal team, it raises a few more questions. Specifically in relation to retention of the data on the longer term, different teams look at the data from a different perspective. The one team might easier decide to archive or destroy documents than the other. It might not be that you want to keep it all, but there are always some documents that you would like to retain for historical purposes. A proper archiving solution, usually one of the reasons to implement a Document Management system in the first place, should give people peace of mind on that subject but the fact remains that working together and trusting each other does not come easily.
All four characteristics regarding project management, design, end user adoption and maturity of the technology make it difficult to get your implementation right the first time.
Even if you are aware of all this and count on some stormy waters, put a lot of effort in stakeholder management, make your managers aware that it requires a lot of stamina and plan your change management in detail, the message that the benefit is for the organisation as a whole and that this can only be achieved on the long haul gets diluted over time in the waves of frustration.
The solution to this is to continue preaching the rationale behind the system, accept a few blows and keep pushing the project forward against the wind. Continue to implement improvements and continue with handholding staff using the system. The combination of getting used to the system, learning to think in new concepts and continuous improvement of the functionality will gradually improve the user experience and slowly make that the system gets accepted. That is the point that you will finally start reaping the benefits and can start introducing new concepts in terms of collaboration.
It simply is not easy to implement these type of systems. The stakeholders quite often all have a valid point and there are many paths to come to an envisaged end result. And what this end result will be is not easy to model beforehand. Usually you know what it is or could be once you have gone through the first implementation phase. That’s why I don’t want to go to hard on everyone involved and just see the failure more as perceived failure. People have different expectations and we cannot really see in each other’s heads what those are. Human kind is all about making progress and if you can prove that you made progress according to the original plan (but maybe not according to unwritten expectations), you should be proud of having taken that big step.
It is a big step because you have laid the foundation for the organisation to come to a new level of working and brought people to work and think on a different level of abstraction. A document is not just a file, but is data with history and versions, with different levels of access for different people and with different meta data which mean that over time different actions will be performed on that data. It is not easy to constantly have these aspects in the back of your mind each time you touch the document or talk about the document with others.
In the first instance much of these changes have no direct benefit to the users. Only when you can transform this into true collaboration they will experience the benefits. Social media concepts will help to transform this world of collaboration and this is already happening.
- Further reading: IT failure and collaboration: Ten big symptoms
- To find the right business owner for a CRM
GXZDRSBCUCS2
Subscribe to:
Posts (Atom)