In my current engagement, there has been a lot of talk lately about “future-proofing” the overall organization. I find this puzzling, because the basic definition of that term has not been identified. As the economy becomes increasingly connected, this customer stands at the threshold where the fundamental processes of value exchange are being transformed. The sheer abundance of information has led to a surfeit of alternatives for consumers and has reversed the signaling mechanisms that influence the very nature of supply and demand.
Transformation & Agility
Transformation & Agility concerns the utilization of the technical agility derived from the benefits delivered by virtualization and cloud computing, coupled with Agile Development practices that improve business agility, performance, and results. This includes the agility derived from: (Read More)
- The implementation of Agile and DevOps methodologies
- The application and system architectures
- The implementation of IaaS, PaaS, and SaaS clouds
- Monitoring of the environment, coupled with processes for resolving problems quickly
- Having continuous availability through the use of high-availability and disaster recovery products and procedures
Transformation covers the journey from A to Z and all points between: how you get there and the roads you will travel; how decisions made on day zero or one, or even day three, will affect later decisions; and what technical, operational, and organizational pitfalls can be associated with an implementation. We examine what tool sets are required for Agile Cloud Development, and it delves into other aspects of Agile Development that integrate with cloud computing, SaaS, and PaaS environments, including DevOps, Scrum, XP, and Kanban.
In considering simplification, I’ve been thinking about policies. I love the idea of policy-based management and IT systems that implement policy. But isn’t there a risk of policy sprawl? If we allow free reign on policy configuration, we will end up with a huge number of policies. Will we end up with so many possible policy combinations that we have more policies than configuration settings? One way to reduce the possible load from managing policies is to reduce the options within each policy area. Maybe vendors should be defining standard policies and simply letting customers assign those policies. Fewer options lead to less time spent selecting what policy settings to use.
I stated in my last article that an adaptive enterprise—or, as this customer likes to call it now, an extended enterprise—is built, not bought. It is a transformational process, and every enterprise arrives at the task of transforming itself with a different history and different goals, priorities, and needs.
Oracle have been quietly building out their next generation cloud environments, building up a cloud practice with seasoned professionals that includes Ex-VCE, VMware and AWS personal. They have released a completely new version of their IaaS layer cloud. Dipping into their not insignificant loose pocket change to make several key purchases or acquisitions this year.
Now in what should be their last acquisition of 2016 they have now acquired Dyn for an undisclosed amount; but according to Dan Primack, a former senior editor at Fortune it is expected to be in the region of $600million.
Recently, I made two interesting support requests, each to a different company. Both companies asked for the output of many different commands and log files. Both balked once I explained my organization’s security policy. The policy reads simply:
No anonymized data shall be delivered to a 3rd party.
It is a simple statement, but it has a powerful effect on all data being delivered to third parties, even for support. It implies that all user, machine, and service identifiers must be tokenized, encrypted, or outright removed. What must truly remain anonymous within our data? This is not simply a support question, but rather a major issue with all data today. Do we even know what is in our data? Do you?
There is no doubt that the pace of business change is not slowing. With this business rate of change comes the need for business applications to change at great speed. What may be less visible is the direct relationship between the speed of application change and the need for new application architectures.