Highlights of Cloud Europe Expo Conference (London Barbican, 20-21st May 2009)
Executive Summary:
Cloud computing has the potential to significantly lower the time-to-value (TtV) and economic barriers to acquiring enterprise IT resources.
Cloud computing can reduce TtV by reducing the time between ordering a server and it being deployed from a few weeks to a few minutes. This is achievable due to virtualisation technologies that allow companies to create virtual machines in a matter moments and thus resell computing resources to customers in a convenient package.
Cloud computing significantly changes the economics of information systems as shifts IT resource acquisition from a high upfront capital investment to that of a 'pay-as-you-go' service. This shift in economic model has been arguably made possible by changes to revenue generation models of operating system vendors. Revenue models seem to shifting from a large one-off upfront licensing model towards a zero up-front licensing model with product development supported by revenue generated from maintenance and consulting services. The convergence of almost instant server delivery and a 'pay-as-you-go' charge model is a highly elastic IT infrastructure that can be cost effectively expanded and contracted within minutes.
Cloud computing is a promising enterprise technology for the reasons mentioned above however when undertaking such a project many issues need to be taken into account. Most notably cost of bandwidth, suitability of performance, sustainability of providers, the lack of financial liability written in current SLAs, migration, lock-in, data security and operational & governance risks. If convincing answers to these issues can be found then a move to cloud could be a good business decision.
The following sections contains highlights from speakers at the Cloud Expo Europe Conference (London Barbican, 20-21st May 2009) http://www.cloudexpoeurope.com/
1. Adam Afrigie (Shadow Minister for Innovation Universities and Skills)
Afrigie argues that cloud technologies are as transformational as the PC. He holds a vision that cloud computing & web 2.0 will play a significant role in tomorrow's politics as they will enable the railing back 'big' government and empowerment of citizens. He suggests that today's young, tomorrow's future voter/citizen, will be keen to participate in electronically mediated government. Furthermore he laid out the conservative party's vision for Open European standards and technologies. He also suggested that value could be unlocked from government datasets by making them publicly available for exploitation by industry and academia.
2. Inna Kuznetsova (IBM)
Kuznetsova argues that the financial crisis is a massive opportunity for businesses to exploit the value of Linux at an infrastructure and desktop level. She states that Linux has a lower cost of ownership than other operating systems due to its pricing model. e.g. No licensing costs merely maintenance contract costs. She also argues that Linux has lower hardware requirements than rival enterprise operating systems such that a new version of Linux does not require an accompanying hardware upgrade. Linux, she argues, also complements the cloud as it has no upfront costs due to its pricing model therefore experimenting is low cost unlike with other systems. Overall Linux amplifies the benefits of cloud as it removes fixed costs and has open technologies that enables rapid innovation.
3. Derek Kay (Deloitte)
Kay provided an overview of cloud technologies from a CEOs perspective. He identifies cloud as SaaS (e.g. Zoho, Salesforce, Basecamp), as a Development Platform (e.g. Azure, Google Apps Engine, Aptana cloud), and as an Infrastructure (e.g. Prophet, amazon). It is suggested that the benefits of Cloud technology are: Fast start up, scalability, agility, faster product development, no capital expenditure. It is suggested the weaknesses are: cost of bandwidth, performance, human capital, portability, sustainability of providers, SLAs, data security and operational & governance risks.
4. John Darlington (Imperial College - Social Computing Group)
Darlington argued that openness and composability is vital for the future of computation and that this is the key to realising the value of cloud computing as this unlocks the processing power and storage capacilities of cloud.
5. Miranda Mowbray (HP)
Illustrates that there are legal issues that need to be clarified regarding the governance of cloud services. Considerations need to be given to countries in which data is stored as different countries have different laws regarding data privacy. Another consideration is the quality of current SLAs. At present cloud providers take no financial liability for losses due to down-time or service degradation. It is suggested that lawyers create a language of cloud SLAs similar to those of network infrastructure outsourcing thereby removing risk from the user and shifting it to the provider. Another issues for consideration is that of sub-contracting in different juristrictions; questions are raised such as who is responsible and who should pay when two microservices don't combine? Can unpaid subcontractors keep data as an asset until payment is made? Consideration of who can use what data and for what purpose? Also as part of a standard contract Cloud providers are usually allowed to process their customer's data for business gain as long as data is in an anonymised form. This raises concerns such as are businesses happy for their data to be processed to create metadata? How about when it has been shown by researcher that anonymous data can be de-anonymised? She argues that consideration of lock-in is also important. For example, Salesforce uses custom languages and custom objects which makes migration very difficult thus locking in their customers. Consideration should also be given to criminals exploiting the concentration of services. e.g. Susceptability to DoS attacks, data theft and insider theft from rogue providers and subcontractors.
6. Rik Ferguson (Trend Micro)
Ferguson argues that Data theft is a serious issue and that the threat is evolving. Threats are now mostly from the net and are now mainly due to web based malware. The current AV model is fundamentally flawed because cyber criminals use multivariant attacks which signature technology cannot detect or prevent. Currently, 2000 new signatures are required per hour this is predicted to 22,000 by 2015. One solution is a 'smart protection network' which detects malware not just at end-point but also through-out infrastructure (e.g. email, point of network entry) and acts upon observations of suspicious activity
7. Mitch Lieberman (SugarCRM)
Lieberman argues that cloud computing is made possible by a convergence of opensource software and open standards. It is suggested that Opensource began at the OS level, followed by DB and subsequently applications. He argues it is the availability of these open technologies that are highly and readily customisable along with the open-source pricing model that enables the extensive use of virtualisation and cloud computation. In other words open-source values of low barrier to entry and open standards enable virtualisation and cloud to be experimented with and then widely adopted within business. Lieberman also argues that the value of cloud is not just about saving costs and swapping capital expense for operational expense. It fundamentally changes computing as it enables open and extensible computing which is highly scalable. The key principles are 1) openness as this enables rapid innovation (e.g. mash-ups) and 2) scalability as this allows services to rapidly meet demand if they take off.
8. William Fellows (The 451 Group)
Fellows provided an overview of Cloud technology, its drivers and barriers to adoption, what users are doing with it today and the 'future' of cloud technologies. It is suggested that cloud computing can be viewed as a stack: SaaS (Software); PaaS (Platform); and IaaS (Infrastructure). According to 451 Group research today internet applications, databases, Application testing and disaster recovery are the main uses of Cloud computing. Similarly the main drivers for adoption are 1. Flexibility, 2. Economics, and 3. Time to market. The barriers to adoption trust in security, availability, lack of SLA's with substantial financial liability, issues surrounding regulatory compliance, migration and integration issues surrounding physical to virtual migration, lock-in & interoperability standards,extent of cost savings and software licensing issues. It is suggested that today's cloud technology is mature for use in low bandwidth, 99% up-time, latency insensitive applications where security is not paramount. It is suggested that the near future for cloud computing is the uptake of private clouds of enterprises. The main reasons for this will be realisation of cost and energy savings. The real threat to the future of cloud computing is not lack of standards but bad pricing models.
9. Christian Baun (Forschungszentrum Karlsruhe)
Baun provided an introduction to Eucalyptus which is an opensource cloud architecture that supports the EC2 APIs and interfaces. In otherwords it is an opensource version of cloud that is EC2 compatible in the sense it can be managed using the same tools as Amazon EC2. Eucalyptus stands for Elastic Utility Computing Architecture for Linking Your Programs to Useful Systems. The architecture of Eucalyptus is based upon a three tier structure: API; cloud controller; and node controller. Interestingly eucalyptus performs on par or significantly better than amazon cloud in empirical tests. Eucalyptus may be deployed from binary onto the following environments where Xen hypervisor or KVM are are installed: CentOS, SUSE, Debian, and Ubuntu. Once installed using Eucalyptus is as simple as registering an image. Another interesting opensource development that is complementary to Eucalyptus was highlighted. The App Scale project, part funded by Google, is an open source implementation of Google AppEngine. This provides an opensource PaaS that executes transparently over the cloud.
10. David O'Dwyer & Peter Brownell (School of Everything)
This presentation described the thought processes required to migrate from a traditional architecture to a scalable cloud architecture using the casestudy of a start-up migrating from a drupal based website running on 'traditional' hardware to a scalable version running in the cloud. The scalable version was implemented using Debian, MySQL, MySQL proxy, GusterFS and load balancing was achieved using DNS round-robin. According to this approach 'being good at cloud is being good at dynamically adding and subtracting servers on the fly'. It was recommend that a cloud architecture should be developed from the perspective of 'Disaster Recovery' and the 'Noah's Ark Principle'. The Disaster Recovery principle is that 'in the event of a total failure the system can be rebuilt rapidly and automatically(ish)'. Noah's Ark principle is that for reasons of dependability there should be two of everything or at minimum 'the ability to rapidly be running two of everything'. These principles are particularly important in cloud environments due to the 'non persistence of data' when an EC2 server is powered down (or fails). Another recommendation was the monitoring of hardware and system. It was suggested that the early signs of trouble can be detected and acted upon if proper monitoring is used further reducing the likelihood of failure. In practical terms it was suggested than the smaller amazon servers are more cost effective, any form of dependency should be avoided (loose coupling) and that MySQL proxy is an effective tool to make clusters of MySQL servers transparent to applications.
11. Simone Brunozzi (Amazon)
Brunozzi provided a broad brushed summary of the Amazon AWS offering (e.g. EC2, S3, ...) which was targeted to a non-technical audience. The Amazon offering was described using 7 key terms: Designed for failure; Loose coupling; Design for dynamism; Security everywhere; Don't fear constraints; Many storage options; AWS Ecosystem. Designed for failure describes the architecture of the S3 storage platform where data is distributed across multiple sites such that if one data-centre is destroyed no data will be lost and it will be automatically mirrored at another. Loose coupling referred to the fact that all of Amazon's services are discreet in the sense they are not tied together but may be deployed and configured in multiple ways. Design for dynamism means the services are designed not assume the health or availability of any services therefore they may be dynamically reallocated thus adding another layer of dependability. Security everywhere describes that Amazon provides physical and network level security. Don't fear constraints describes the highly reconfigurabe nature of EC2 such that constraints such as lack of RAM or storage are an thing of the past using EBS and S3. The ecosystem describes the community that has built up around AWS such that help is always at hand and not necessarily paid for.
Thursday, May 21, 2009
Tuesday, May 12, 2009
Understanding & Defining Time to Value - A powerful metric for Enterprise IT Success
Time-to-Value (TtV)
Executive Summary:
'Time to value' (TtV) is an important metric for measuring the performance of investments in Enterprise Technology. It is important as it recognizes that in today's modern dynamic business environment a rapid response to changing market forces or environmental demands is critical to survival. Applying TtV to Enterprise IT is an important part of any strategy designed to manage these environment conditions as it incentivises the rapid realisation of the value that can be achieved by the use of responsive acquisition and development methods that focus on delivering business value as soon as possible rather than mere functionality.
In essence TtV measures the responsiveness of a request for value. It is measured from the point a request is made to when the value is realised. Value can be either tangible or intangible. ‘Tangible value’ is the supposed worth, usefulness or importance of something that can be easily or precisely measured. ‘Intangible value’ is the supposed worth, usefulness or importance of something that cannot be easily or precisely measured. Value should be thought of as the antecedent to a benefit - in otherwords the ingredients to a competitive advantage. For example, I may create a website that increases customer loyalty by 20% and this may be of value (worthy, useful, important) however it is not an advantage, in any real sense, unless it makes a difference to my company’s ability to compete. E.g. Generate more sales, or increases the profitability of each sale, or variations of. However increasing customer loyalty may be an ingredient of increasing profitability and when combined with a new product offering it would realize an advantage.
Full Post:
Time-to-value (TtV) is a term that is commonly used in business and to a lesser extent in the academic study of information systems. Whilst its use is common there appears to be no standard definition as author’s definitions commonly vary in demarcation of the point of value and demarcation of the point to begin counting to the point of value. These points typically vary because of variations in what counts as ‘value’ and the point to begin measuring from is often under-determined. This blog offers an analysis of existing definitions and offers a more considered definition of TtV.
Below are three definitions of TtV:
1. (IBM Unknown) states that TtV is the time taken to realise benefits from new strategies, programmes or technologies.
2. (Somerville 2008) states that TtV “is the time after deployment when the system is fully operational and delivering value to the company”.
3. (Ashley 2007) states that TtV “is the effort, barriers, time, resources, planning, change, etc., that the customer goes through before they first see tangible business value from a product or service.”
These three definitions disagree on the demarcation of the point of value. Definition one implies that the point of value is the point where tangible or intangible ‘benefits’ are realized. Definition two suggests the point of value is where the system is (a) fully operational and (b) it is delivering ‘value’. Definition three suggests the point of value is where tangible business ‘value’ is delivered.
The importance of the difference between ‘value’ and ‘benefit’
Interestingly whilst definition two and three use the term ‘value’ to demarcate the point of value, definition ones uses the term ‘benefit’. According to (OED 2009) the term ‘value’ can be defined as something of “real or supposed worth, usefulness, or importance” whilst ‘benefit’ can be defined as “advantage, profit, good”. Which means definitions two and three measure to the point that something of supposed worth, usefulness or importance is produced whilst definition one measures to the point where an advantage or profit is generated. It is clear that these are two different points as something of actual/supposed worth, usefulness or importance is the antecedent to an advantage or profit but not necessarily an advantage/profit in and of itself. For example, I may create a website that increases customer loyalty by 20% and this may be of value (worthy, useful, important) however it is not an advantage, in any real sense, unless it makes a difference to my company’s ability to compete. E.g. Brings me more sales, or increases the profitability of each sale, or variations of. However increasing customer loyalty may be an ingredient of increasing profitability and when combined with a new product offering it would realize an advantage.
The important difference between ‘tangible value’ and ‘intangible value’
Interestingly definitions one and two imply that the point of value is where both tangible and intangible ‘value’/‘benefits’ are realized/delivered whilst definition three only recognizes tangible value. The (OED 2009) defines intangible as “which cannot easily or precisely be measured.” Therefore on the basis of the previous definitions:
• ‘Tangible value’ is the supposed worth, usefulness or importance that can be easily or precisely measured.
• ‘Intangible value’ is the supposed worth, usefulness or importance that cannot be easily or precisely measured.
Whether TTV should be limited to only tangible value, as definition three suggests, is a difficult question as it depends on an organization’s tacit philosophical stance. Some organizations may take an evidence based management (logical positivistic) approach and disregard ‘intangible value’ arguing that if a factor cannot be empirically measured and verified it is meaningless to manage or control because the success/failure of the intervention cannot be known. Other organizations may take the opposite stance arguing that even if an entity cannot be empirically measured and verified its effects may be indirectly perceived and therefore the success/failure of the intervention whilst not known can be tentatively inferred. There is no right or wrong answer to this philosophical debate however I suggest that TtV should not exclude intangible value outright, another concept ‘Time to Tangible Value’ (TtTV) should be used by those of an evidence based (logical positivistic) persuasion.
The importance of defining a start point
We can also see that two of these three definitions under-determine the concept of TtV as the they do not specify from when to begin measuring time. Definitions 1 & 3 do not specify the point to begin measuring value whilst definition 2 suggests it should be measured from time of deployment. I believe this is incorrect as TtV makes more sense as a measure of the time period between a request for value and the beginnings of the delivery of value. For example, the time to value of a car is the time from when it is ordered to the time I can begin getting value from it (e.g. using it). Similarly for a website it is the time between me typing in the web address and the site delivering me something of value e.g. new ideas or soothing images. In the context of Enterprise IT systems, TtV may be more meaningfully measured from the point of project initiation to the point the project is realising value e.g. increasing employee satisfaction.
Are other conditions necessary to express TtV
It is suggested by definition 2 that a system being ‘fully operational’ is a condition for the point of value. This is wrong as it ignores the fact that value can be delivered by partially implemented systems. Take for example any form of iterative development where a partial set of the functionality is delivered each iteration. The system can not be said to be fully operational however it can be said to deliver value otherwise this would erode the whole purpose of iterative development.
Redefining Time to Value
Time to Value (TtV) is the period of time between t1 (where a request for value is made e.g. A project is initiated) and t2 (the point where value is delivered e.g. project delivers value). Value is defined as something tangible, or intangible, of supposed worth, usefulness or importance. In other words value is a placeholder for what you want the system to deliver e.g. create a culture of cooperation, reduce the time it takes to process claims by x seconds, or anything else of perceived worth, usefulness or importance.
Summary
Time-to-value (TtV) is a term that is commonly used in business and to a lesser extent in the academic study of information systems. This post analyzed three definitions of TtV and highlighted general issues with the terms used. Using insights from the analysis it proceeded to offer a new definition that built upon those analyzed. It was also suggested that a new concept of Time to Tangible Value (TtTV) may also be worthy of investigation as this would fit more evidence based management approaches.
As always your comments, thoughts and criticism are most welcome.
References:
Ashley, M. (2007). "Product Bistro: The concept of Time-To-Value." Retrieved 09/05/09, 2009, from http://www.theconvergingnetwork.com/2007/10/product-bistro-.html.
IBM. (Unknown). "Driving ‘Time to Value’ With the Agility of the Midsize Enterprise." Retrieved 09/05/2009, 2009, from http://www-935.ibm.com/services/uk/bcs/pdf/mms_solution_provider.pdf.
OED (2009). Oxford English Dictionary Online, Oxford Univeristy Press.
Somerville, I. (2008). Fitting Software to the Organization: Reducing Time to Value for New Software Systems. Proceedings of the 19th Australian Conference on Software Engineering, IEEE Computer Society.
Executive Summary:
'Time to value' (TtV) is an important metric for measuring the performance of investments in Enterprise Technology. It is important as it recognizes that in today's modern dynamic business environment a rapid response to changing market forces or environmental demands is critical to survival. Applying TtV to Enterprise IT is an important part of any strategy designed to manage these environment conditions as it incentivises the rapid realisation of the value that can be achieved by the use of responsive acquisition and development methods that focus on delivering business value as soon as possible rather than mere functionality.
In essence TtV measures the responsiveness of a request for value. It is measured from the point a request is made to when the value is realised. Value can be either tangible or intangible. ‘Tangible value’ is the supposed worth, usefulness or importance of something that can be easily or precisely measured. ‘Intangible value’ is the supposed worth, usefulness or importance of something that cannot be easily or precisely measured. Value should be thought of as the antecedent to a benefit - in otherwords the ingredients to a competitive advantage. For example, I may create a website that increases customer loyalty by 20% and this may be of value (worthy, useful, important) however it is not an advantage, in any real sense, unless it makes a difference to my company’s ability to compete. E.g. Generate more sales, or increases the profitability of each sale, or variations of. However increasing customer loyalty may be an ingredient of increasing profitability and when combined with a new product offering it would realize an advantage.
Full Post:
Time-to-value (TtV) is a term that is commonly used in business and to a lesser extent in the academic study of information systems. Whilst its use is common there appears to be no standard definition as author’s definitions commonly vary in demarcation of the point of value and demarcation of the point to begin counting to the point of value. These points typically vary because of variations in what counts as ‘value’ and the point to begin measuring from is often under-determined. This blog offers an analysis of existing definitions and offers a more considered definition of TtV.
Below are three definitions of TtV:
1. (IBM Unknown) states that TtV is the time taken to realise benefits from new strategies, programmes or technologies.
2. (Somerville 2008) states that TtV “is the time after deployment when the system is fully operational and delivering value to the company”.
3. (Ashley 2007) states that TtV “is the effort, barriers, time, resources, planning, change, etc., that the customer goes through before they first see tangible business value from a product or service.”
These three definitions disagree on the demarcation of the point of value. Definition one implies that the point of value is the point where tangible or intangible ‘benefits’ are realized. Definition two suggests the point of value is where the system is (a) fully operational and (b) it is delivering ‘value’. Definition three suggests the point of value is where tangible business ‘value’ is delivered.
The importance of the difference between ‘value’ and ‘benefit’
Interestingly whilst definition two and three use the term ‘value’ to demarcate the point of value, definition ones uses the term ‘benefit’. According to (OED 2009) the term ‘value’ can be defined as something of “real or supposed worth, usefulness, or importance” whilst ‘benefit’ can be defined as “advantage, profit, good”. Which means definitions two and three measure to the point that something of supposed worth, usefulness or importance is produced whilst definition one measures to the point where an advantage or profit is generated. It is clear that these are two different points as something of actual/supposed worth, usefulness or importance is the antecedent to an advantage or profit but not necessarily an advantage/profit in and of itself. For example, I may create a website that increases customer loyalty by 20% and this may be of value (worthy, useful, important) however it is not an advantage, in any real sense, unless it makes a difference to my company’s ability to compete. E.g. Brings me more sales, or increases the profitability of each sale, or variations of. However increasing customer loyalty may be an ingredient of increasing profitability and when combined with a new product offering it would realize an advantage.
The important difference between ‘tangible value’ and ‘intangible value’
Interestingly definitions one and two imply that the point of value is where both tangible and intangible ‘value’/‘benefits’ are realized/delivered whilst definition three only recognizes tangible value. The (OED 2009) defines intangible as “which cannot easily or precisely be measured.” Therefore on the basis of the previous definitions:
• ‘Tangible value’ is the supposed worth, usefulness or importance that can be easily or precisely measured.
• ‘Intangible value’ is the supposed worth, usefulness or importance that cannot be easily or precisely measured.
Whether TTV should be limited to only tangible value, as definition three suggests, is a difficult question as it depends on an organization’s tacit philosophical stance. Some organizations may take an evidence based management (logical positivistic) approach and disregard ‘intangible value’ arguing that if a factor cannot be empirically measured and verified it is meaningless to manage or control because the success/failure of the intervention cannot be known. Other organizations may take the opposite stance arguing that even if an entity cannot be empirically measured and verified its effects may be indirectly perceived and therefore the success/failure of the intervention whilst not known can be tentatively inferred. There is no right or wrong answer to this philosophical debate however I suggest that TtV should not exclude intangible value outright, another concept ‘Time to Tangible Value’ (TtTV) should be used by those of an evidence based (logical positivistic) persuasion.
The importance of defining a start point
We can also see that two of these three definitions under-determine the concept of TtV as the they do not specify from when to begin measuring time. Definitions 1 & 3 do not specify the point to begin measuring value whilst definition 2 suggests it should be measured from time of deployment. I believe this is incorrect as TtV makes more sense as a measure of the time period between a request for value and the beginnings of the delivery of value. For example, the time to value of a car is the time from when it is ordered to the time I can begin getting value from it (e.g. using it). Similarly for a website it is the time between me typing in the web address and the site delivering me something of value e.g. new ideas or soothing images. In the context of Enterprise IT systems, TtV may be more meaningfully measured from the point of project initiation to the point the project is realising value e.g. increasing employee satisfaction.
Are other conditions necessary to express TtV
It is suggested by definition 2 that a system being ‘fully operational’ is a condition for the point of value. This is wrong as it ignores the fact that value can be delivered by partially implemented systems. Take for example any form of iterative development where a partial set of the functionality is delivered each iteration. The system can not be said to be fully operational however it can be said to deliver value otherwise this would erode the whole purpose of iterative development.
Redefining Time to Value
Time to Value (TtV) is the period of time between t1 (where a request for value is made e.g. A project is initiated) and t2 (the point where value is delivered e.g. project delivers value). Value is defined as something tangible, or intangible, of supposed worth, usefulness or importance. In other words value is a placeholder for what you want the system to deliver e.g. create a culture of cooperation, reduce the time it takes to process claims by x seconds, or anything else of perceived worth, usefulness or importance.
Summary
Time-to-value (TtV) is a term that is commonly used in business and to a lesser extent in the academic study of information systems. This post analyzed three definitions of TtV and highlighted general issues with the terms used. Using insights from the analysis it proceeded to offer a new definition that built upon those analyzed. It was also suggested that a new concept of Time to Tangible Value (TtTV) may also be worthy of investigation as this would fit more evidence based management approaches.
As always your comments, thoughts and criticism are most welcome.
References:
Ashley, M. (2007). "Product Bistro: The concept of Time-To-Value." Retrieved 09/05/09, 2009, from http://www.theconvergingnetwork.com/2007/10/product-bistro-.html.
IBM. (Unknown). "Driving ‘Time to Value’ With the Agility of the Midsize Enterprise." Retrieved 09/05/2009, 2009, from http://www-935.ibm.com/services/uk/bcs/pdf/mms_solution_provider.pdf.
OED (2009). Oxford English Dictionary Online, Oxford Univeristy Press.
Somerville, I. (2008). Fitting Software to the Organization: Reducing Time to Value for New Software Systems. Proceedings of the 19th Australian Conference on Software Engineering, IEEE Computer Society.
Subscribe to:
Posts (Atom)
