?
A number of years ago, HP had transformed its IT environment and achieved great success in doing so. That?s when HP realized there was a large IT base that had been left untouched?in other words, all the computers under the desks of the engineers. Indeed, our R&D engineers used a variety of tools during the development of new products, hardware and software alike. They kept rebuilding those systems so they provided them with the right tools at every step in the development process. And most engineers, not trusting anybody, had the systems literally under their desk.
?
HP Product Development & Engineering IT Transformation
A painful transformation started. How would we get those systems away from under the engineers? desk in a datacenter where they could properly be managed? In the mind of the project team this would have several benefits:
- Standardize the toolset used by the engineers
- Focus the engineers on what they do best, development of new products, and relieve them from system management and configuration tasks
- Ensure security, back-up and disaster recovery, so information and intellectual property would be better protected
That stated, the engineers would start doing things in a standardized way. But how do you achieve that with people whose creativity you want to stimulate? You ask them to be as creative as possible in the design of their product, while you streamline them to use standard processes. It?s an oxymoron. Transforming the engineering environment requires careful change management. You must constantly demonstrate the added value to engineers of handing in their servers and software which requires depending on a central team to deliver what they need. The interesting part is the savings HP has experienced from doing this transformation. Actually, if you are interested in understanding more about this transformation you may want to read ?Transforming product design and engineering to save time and money in the electronics industry.?
?
Researching for this blog entry, I ran into a post from my friend Gareth Evans dated from 2009, but in which he describes the benefits HP got from this exercise. HP?s PD&E IT transformation freed up 10-20 percent of engineering resources to go back to performing core productive work that adds up to potentially more successful, higher quality offerings consistently delivered at ever deceasing cost points and competitive time-to-market. The environment can also be kept current in a systematic and organized way going forward. So in a nutshell following benefits can be achieved:
- 10-20 percent more engineering productivity resulting in better products delivered with shorter time-to-market
- Better utilization of the R&D IT environment
- Better management of tools licenses, which can result in the need for less licenses
- Standardization of tools used (improves compatibility between projects and potentially component re-use)
- Increased protection of intellectual property
The question is obviously how these benefits are expressed in monetary terms and whether they can help you justify the migration to cloud. The Engineering IT transformation will not just give you the benefits I discuss above, but will also make you more agile, which in turn brings its own benefits with it.
?
Software Development
What is true for PD&E is also true for software development. Mostly software development is done in an artisanal way. As we discussed, the increasing importance of digitization in general and the associated software development in particular, standardizing and optimizing the way software is built is critical. One way to address this is to migrate to PaaS environments, and we see many start-ups actually doing just that. They jumped from the traditional approach to public cloud based PaaS environments all together.
?
Larger enterprises may not be ready for that. However, streamlining software development, standardizing the processes and improving the use of the development platforms are critical for enterprises to invest their money wisely and improve their agility. Four components are key to achieve this objective:
- A well-established project governance supported by tools allowing a thorough visibility of the requirements, progress and budget constraints. To achieve this, we use a tool called Project and Portfolio Management
- An environment in which you can manage and track every step in the development process, regardless of the platform you use (as larger projects will most probably combine multiple development platforms). That environment will gather information on the product through the different development steps. We call that Application LifeCycle Management.
- A cloud environment allowing your development engineers to quickly get access to the appropriate infrastructure and tools required at each step of the development. I?ll come back to this in a minute.
- Closer integration between development and operations to ensure a seamless production start-up. As I described in an earlier blog entry, we should learn from design for manufacturability and involve operations people throughout the development process to ensure compatibility between the application being developed and the environment on which it will run.
Let me come back to what we call the ?dev/test? cloud. During the different steps in the development process, multiple environments are required and the amount of compute power needed will vary drastically. So the question really is whether we use the public cloud for all development steps or whether we do some things internally while using public cloud for others. Dev/Test is truly a converged cloud use case.
?
Stress testing an environment with anonymized data is definitely something we?ll do in a public cloud, but it will be interesting to see how public cloud-based PaaS environments will be adopted by developers of larger enterprises. Ideally what you would like is to be able to develop your application completely in the public cloud and then be able to take it back in-house without having to adapt it for a different cloud environment. Here again the concepts of converged cloud apply.
?
Conclusion
Whether it is engineering or software development, centralizing the development resources (hardware, software) and making them easy to provision, frees engineers up and allows them to spend more time on developing the product or software. This is value to the bottom line as it allows projects to run faster and smoother, delivering results earlier and improving agility.
?
But there are side effects. Standardizing the processes and documentation makes re-use of components easier, centralized management of tool licenses reduces cost while facilitating compliance and central back-up/recovery of information protects key assets of the enterprise. The real question is how the last three elements are represented as financial benefits, facilitating the ROI calculation of cloud investments.
?
So, how much time do your users spend setting up IT environments, trying to get access to them, finding the right connections etc.? How much are your users spending time and effort finding the appropriate ?shadow-IT? tool because IT does not deliver them what they are looking for? Ask yourselves those questions, think about how cloud computing could help and use the results of your investigations to justify your move to cloud.
project runway all stars elin nordegren tangled ever after kansas state last house on the left last house on the left rich forever mixtape
কোন মন্তব্য নেই:
একটি মন্তব্য পোস্ট করুন