IT people are always being encouraged to become knowledgeable about the world of business. This is a concept I have been preaching about for over a decade! Most of them work in some sort of business, and there’s no denying that an understanding of how commerce works can help IT personnel do their job better, whatever industry they work in. But what about the flow of knowledge from IT to business? Is there anything in IT which is even applicable to business? After all, to the layperson, IT usually seems to be a world of confusing acronyms, incomprehensible jargon, and thoroughly uninteresting technical detail. However, most business people have only experienced the sharp end of IT—real, physical contact with machines and software—and not the ideas and concepts that underpin all that technology and the way it works.
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.
One of the intriguing things about IT is just how much success is driven by nontechnical factors. For me, another fun part is looking at how the technical parts can shape the nontechnical parts. The decision to develop applications in a microservices architecture is a technical decision. There are a number of nontechnical results that can lead to better software development and greater business value. I wrote about how the pace of business change is the cause of microservices architectures. While I was thinking that through, it occurred to me that microservices lend themselves to more productive teams. They also deliver greater developer satisfaction. Even if we didn’t want microservices-based applications for agility, we might want them for productivity.
I just returned from a week in Las Vegas at AWS re:Invent, Amazon Web Services’ annual conference. I have either attended or watched the live stream every year for the past several years, and I am continually amazed at the number of new services and features that AWS cranks out annually. During the course of each year, I keep reading about how the other public cloud providers are gaining ground on AWS. However, I am not seeing that. Amazon is dominating with large enterprises and Fortune 500 companies. Many of the big wins from the other cloud providers are in companies looking at multicloud strategies or targeting specific workload types (e.g., Google for big data workloads).
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.
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.