No matter how much technology we have, everything is about people. Even the best tools and automation can fail if the people operating them are not good at IT. Often we buy tools to fix problems, only to find that the tool is not the solution. The problem is not with the tool: more often, there is a problem with the people who operate the tool. Many times, there is also a problem with the people who manage the people who operate the tools.
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.
The plain fact is that no matter how hard one entity is to deal with, it’s exponentially harder to deal with more than one. Everything is more complex when you go from one thing to more than one thing. The additional complexity may not be visible, or detectable, or appear to cause problems, but it’s still there and needs attention paid to it. At some point, when scaling begins to bite, problems inevitably appear.
Will 2017 be the year of the self-healing data center? One might consider this to be the holy grail of IT operations: having an infrastructure that can, to a certain level, maintain and resolve issues as they arrive.
I’ve written before on the importance of an enterprise architecture, but during the engagement that is driving this series of articles (Notes from the Field), it has come to my attention that this topic really needs to be revisited. I’m going to cover some topics I’ve written about before, and in a later post I’ll fold in some content on developing an enterprise architecture. This will tie together with another article I’m working on with the principles and design rules for my customer’s new adaptive/extended enterprise. Thanks for bearing with me.
Application refactoring, or “app refactoring,” as it became more widely known, is a procedural concept that was earmarked as a growth area over the last few years. According to TechTarget, app refactoring is “…the restructuring of existing computer code to improve its performance, readability, portability, or code adherence without changing the code’s intended functions.” As far as EUC was concerned, the major focus of this was to take older, business-critical applications and port them to mobile devices in a way that maintained application usability on the new form factor.
One thing can be said about the world of consulting: the conversations you have with customers never cease to be diverse. My current engagement with a large multinational enterprise that contains multiple business areas with multiple business units is the epitome of that descriptor. We go from high-level, esoteric conversations about economics, value exchange, and business models, to deep in the weeds technically, such as hyperconvergence, and then back to the Middle Earth that is the analysis of technologies that can help achieve their goals.