devopsy.kinsta.cloud

Author: Aditya Vadaganadam

Decentralized Autonomous Organizations (DAOs): Org-as-Code
We are all familiar with ‘everything-as-code’—a pattern that started with infrastructure-as-code and has now extended to other areas such as architecture-as-code, security-as-code and more. However, all the incarnations we have seen so far have been less than ambitious! The dawn of cryptocurrencies and the underlying blockchain technology is moving us firmly toward organization-as-code. Org-as-code is the most disruptive evolution we have seen so far. The crypto world uses a different term for it: decentralized autonomous organization (DAO).

Before you freak out because, “OMG crypto!” let me assure you that I am not trying to sell you any of the 9,000 (at last count) cryptocurrencies. Undoubtedly, crypto has polarized public opinion. There are crypto maximalists who believe that crypto is the solution to everything. You often hear, “Bitcoin solves it!” Then, there are the crypto skeptics who dismiss the movement as simply digital tulips—a Ponzi scheme at scale for the internet age. Only time will tell if they are right.

Now, my opinion falls in the gray area in between, where some groundbreaking new ways of working are evolving. People across the globe are collaborating in decentralized, efficient, democratic and non-hierarchical ways in the world of crypto. Radical new constructs for the internet age are being piloted—DAOs, smart contracts, pseudonymous identities, tokenomics, etc. just to name a few.

This post is firmly focused on DAOs.

So, What is a DAO?

A DAO is a way to work with like-minded folks around the globe where the business (the org) is owned and managed by its members in a democratic way.

“In traditional organisations, people are at the core and automation is at the edge; whereas in DAOs, automation is the core and people are at the edge.” – Vitalik Buterin

As opposed to traditional organizations that are structured in a top-down hierarchy, with many layers of management and bureaucratic coordination, DAOs provide an operating model for people and institutions that do not know nor trust each other, who might live in different geographical areas, speak different languages and, therefore, are subject to different jurisdictions. Instead of legal contracts managing the relationships between people, computer code enforces the rules.

Some of the key features of a DAO are:
1. An organizational setup based on rules and policies that are encoded as computer code.
2. The rules are transparent and controlled by members, not a central authority; usually, on a public blockchain.
3. Rules are executed by a set of smart contracts independent of human (not even the creators!) involvement.
4. Built-in treasury that no one has the authority to access without the approval of the group/community.
5. Decisions and ideas are governed and funded by proposals that are voted on and managed through voting by token holders.
Colony.io is one startup that helps set up DAOs. A screenshot below from their site gives you an idea of the elements of organizational design that can be (re)defined in the radical new DAO world.

Do We Really Need DAOs ?

Here are a few challenges that DAO attempts to resolve that you often see in conventional centralized organizations:
- Good ideas struggle to reach the top.
- The system incentivizes authoritarian leadership.
- Failure to tap into the wisdom of the crowd.
- There is a higher probability of spectacular failures driven by the greed of a few, as evident from examples such as Enron or the 2008 financial crisis.
- There is usually a lack of transparency in decision-making.
- Good policies exist—usually on paper or hidden away in by-laws—but are not executable.
- Single points of failure are natural due to the asymmetry in organizational structure.
Examples of DAOs

Before you dismiss this as utopian and unrealistic, here are a few real-world of examples of DAOs in play
1. Nexus Mutual—A decentralized ‘people-powered’ alternative to insurance which operates as a DAO. It is run entirely by its members. Only members can decide which claims are valid. All member decisions are recorded and enforced by smart contracts on the Ethereum public blockchain.
2. DAI and MKR—A stable decentralized currency (DAI) and platform for decentralized finance apps (with a market cap of about $5 billion).
3. The DAO ( Đ)—A form of venture capital that started as a crowd-funded token sale. There was no conventional management structure or board of directors. But it got hacked in 2016, and a third of funds were siphoned off. (This is a key example to remind ourselves that if the org is code, then security issues can be near-fatal.)
4. DASH —A digital cryptocurrency. A DAO run by a subset of users called masternodes, which perform standard node functions like hosting a copy of the blockchain, relaying messages and validating transactions on the network, and which, in addition, act as shareholders, voting on proposals for improving DASH’s ecosystem.
5. Flamingo DAO—A DAO that deals in digital art via NFTs. NFTs are non-fungible tokens, not non-functional testing!
6. Gitcoin —Uses DAO to fund digital public good projects ( $24 million funded so far using a quadratic funding model)
These are just a few examples. Adoption is exploding, and stretching into areas like charities, freelancer networks, venture funds, investment clubs and more.

DAOs are still emerging, and there are many aspects that are yet to be fully explored, especially around legal status, regulatory frameworks and compliance. It is, however, only a matter of time before the DAO way of working becomes mainstream.

In my view, it is not a binary question between DAOs and conventional organizations. Adopting many of the practices of DAOs will strengthen traditional organizations and reduce some of the weaknesses we touched on earlier.
July 9, 2021
Does Agile Methodologies Work for IT Infra?

Recently, I had a fascinating conversation with my old friend Joe–the name has been changed but the conversation is real and unedited–an IT Infrastructure program manager from a large IT service provider.

After a bit of chit-chat on weather and football, we started talking about infrastructure in a typical large enterprise.

Joe: I am not sure how agile applies to infra space, I can understand it works well for software development, but not in IT Infra space.

Me: OK, why do you think so?

Joe: Well, we have lots of coupling between components, infra projects tend to be big migration or upgrade moves and highly risky. I know many large enterprises in Europe that we work for and many of them haven’t looked at agile in the infra space.

Forty minutes and couple of beers later…

Joe: I have to send four reports every Friday afternoon on status, risks, issues.

Me: Why do you need so many reports?

Joe: I can’t share all the same info to the client that I share internally. There are some risks that we manage internally. My client wants the info on Jira and confluence. My regional manager wants it on an internal tool (some five-word acronym that I forget!). My account manager wants it as a PPT, as this is an important account and he says this needs to be tracked closely. My global manager wants it on a different tool, inherited from a previous merger as my employer was recently acquired by another service provider.

Basically, most of my Friday is spent copy pasting information across these reports. Then I spend most of Mondays reconciling the numbers and responding to follow-on queries, and Tuesdays justifying the cost of resources, change in resource costs because many projects are usually in Amber or Red. I think it usually works well if I have a good PMO.

Me: How many people do you have on the current programme?

Joe: We have four PMs and seven infra resources on this infra upgrade and migration programme. There is a different provider who looks at the application changes and they have a team of managers and developers etc. The seven infra resources I referred to are also busy with BAU work.

Me: So, you have seven part time infra people who are the actual doers, one programme manager, four PMs and PMO, client side vendor manager(s) and you are running half a dozen projects.

Joe: Yes, as you can see, we can’t be agile in infra.

Me: Why do you need projects? And, why do you need so many of them?

Joe: What? No projects? Surely, that’s how it is always done! How do we ensure control, governance?

— Aditya Vadaganadam

September 18, 2019
Don’t Let Your DevOps Transformation Be a Parade of Tools
Choosing the right DevOps tools should be a careful, thoughtful process.

On May 12, 1848, a store owner named Sam Brannan held a “one-man parade” to announce the start of the San Francisco Gold Rush. “Gold! Gold from the American River!” Brannan shouted up and down the market street in San Francisco. He held his hat in one hand and waved a bottle of gold dust in the other. San Franciscans had received false news of gold before. But by all accounts, Brannan’s performance sent residents running in search of riches.

Brannan had a good reason for spreading the news rather than panning for gold himself. The canny entrepreneur owned a general store that served the workers, and in the week between learning about the discovery and yelling about it in San Francisco, he’d bought all the picks and shovels in the city. Brannan’s announcement helped spur a seminal event in California’s history. As Brannan raked in money selling mining supplies, his actions also, years later, led to the coining of a famous maxim. (source)

During a Gold Rush, Sell Shovels

In the current age of DevOps and Agile rush of enterprises, there is a lesson to be learned from the gold rush: Don’t let your DevOps transformation become a parade of tools. While automation is critical for the success of modern ways of technology delivery and operations, the wide range of tooling choices can often lead to wrong decisions—especially well-intentioned, top down purchase of tools, duplication in toolsets and, most importantly, ignoring the voice of the teams on the ground.

With such variety of tools available in the market today, we all have opinions regarding the tools that we would like to use. Our preferences are based on either our history of using certain tools, because we have invested time and effort to learn a tool, or partnerships your service vendors might have with tooling vendors.

This leads to two general attitudes toward tooling adoption, with each having their own advantages and disadvantages:

Autonomy for teams: Let teams decide the tools they feel are suitable for their context.

The advantage is that teams can experiment and pick a tool that suits their context better. The disadvantages can, potentially, include security risks due to lack of patching and maintenance, and limited cross-team collaboration and sharing of tooling skills and know-how.

Standardized tool suite: A centralized way of dictating tooling choices.

The advantage is that it allows for capacity planning, integration between tools, larger pool of community for collaboration and create platforms-based solutions.The disadvantage is that this method at times prevents teams from using tools that best suit their unique needs and creation of avoidable dependencies on centralized tooling teams in the organization.

These contrasting views lead to debates at every level for the choice of tools and, in some cases, slowing down decision-making—or even leading to the purchase of tooling licenses without input from technical teams on the ground. The decision-making process must be improved, and the need for autonomy must be balanced with standardization and optimization. Also, the two approaches of “autonomy for teams” and “standardized tool suite” do not always have to be binary and will change depending on the context of the team needs and area.

By considering desirability, viability and feasibility of the DevOps tools, we can help achieve the balance between autonomy and alignment.

Here are some tips to help ask the right questions:

Desirability
- Do teams want this? or is this a solution chasing a problem?
- Do you anticipate that teams will need this in the near future?
- Does this help improve team productivity and effectiveness?
Viability
- Does this make commercial sense?
- Have we considered maintenance costs and total cost of ownership?
- Do we have existing license arrangements with the tooling vendors?
- Do we have comparable tools already in use and that can do the job?
- Do we need to purchase licenses throughout the enterprise?
- Are there any open source alternatives?
Feasibility
- Can we implement this in the enterprise IT landscape?
- Have we considered the ease of setup and configuration of the tool?
- Does it scale across the enterprise? Does it have to scale across the enterprise?
— Aditya Vadaganadam
January 7, 2019
Let’s Bury Bimodal Thinking in Enterprise IT
We still hear a lot about mode-1 and mode-2 in enterprise IT. Like many other large enterprises, you might have adopted the terminology introduced by Gartner and use it every day to shape the way you deliver and operate technology. However, I have always been uncomfortable with the idea of bimodal, as it ignores architectural reality of tightly coupled systems that we have today and the cultural factors. There is also the cultural dimension that is emerging a lot in the transformations that I help clients with.

The cultural problem with Gartner’s bimodal IT view is that it relegates legacy systems such as mainframe (Z series) or I-series to mode 1 and discourages the new generation of professionals from working on these platforms. If you are in mode 2, you get access to the latest tools and training opportunities, and if you are not, then you are relegated to the end of the queue!

What do you think? Is bimodal creating two classes of people? Or am I being too harsh in my judgment?

In a recent article by BMW CIO Klaus Straub, he went on record and said bimodal IT doesn’t work due to cultural issues. As he said in the article, “Until September of last year, I also had a bimodal world in my head—but then the concept was incomprehensible to me. However, it is not suitable for permanently structuring an IT department.”

BMW is not alone. Other enterprises are joining the voices, such as Peter Jacobs, the CIO of ING Bank Netherlands, who also has expressed similar views on bi-modal. To quote Jacobs: “I would rather work agile at my core bank system than at the channels.”

The full interview of Straub is below. Unfortunately, the article is in Dutch, so you will need to translate the article to read it: https://www.cio.de/a/amp/bmw-cio-haelt-bimodal-it-fuer-einen-irrweg,3562374

A few other relevant and interesting articles are below:
1. https://www.cio.com/article/3193793/cio-role/in-the-digital-era-cios-not-buying-this-bimodal-crap.html
2. https://www.cio.com/article/3191810/it-industry/why-bi-modal-it-doesnt-really-work.html
— Aditya Vadaganadam
October 31, 2018
Where is the Next Generation of Mainframe Talent?
Are we potentially facing a shortage of mainframe talent?

“Three of us set up this tool in 1989. One is retired, and the other person is somewhere in heaven!”

That was the remark of Alf (name changed), the senior mainframe architect at a large European enterprise, as he pointed toward the ceiling of the meeting room. Everyone else in the room let out a half-nervous smile, unsure how to react to the statement and hoping for some visual cues from Alf. We were all talking about a specific version control and packaging tool on the mainframes, which was heavily customized to suit this particular enterprise. The attendees were a mix of DevOps enthusiasts and mainframe architects and engineers with the purpose of re-evaluating the existing tooling stack on mainframes with a view to modernize them as part of a wider agile/DevOps initiative. Alf’s remark in the meeting has stayed with me ever since.

Later that week, I was having lunch with a group of new joiners in the technology department, who were all part of a greenhouse initiative to in-source digital skills. During the conversation, I asked which areas where they focused on and the career direction they had in mind. The answers were predictable: data science, python, Nodejs, UX, blockchain, JavaScript etc. If all the new kids on the block are learning the newer technologies, then who will take over from mainframe people over the next few years when they retire?

The reality is that 96 of the world’s top 100 banks, 23 of the 25 top U.S. retailers and 9 out of 10 of the world’s largest insurance companies run IBM’s System z mainframes. Most digital transformations have barely scratched the surface of the legacy stack.

Like many other enterprises, this enterprise had outsourced most of its application estate to IT service providers. In few years’ time, Alf will move to a well-deserved, retirement phase of his life and take his mammoth knowledge base that the enterprise had always taken for granted. There are many more Alfs across various enterprises today with significant mainframe know-how who are set to disappear from workplace over the next few years, making these enterprises entirely dependent on external service providers—so much for those bold visionary statements for the CXOs such as, “Technology is business and business is technology.”

Most enterprises today have ambitious digital transformation agendas, investing millions on various initiatives ranging from digital, DevOps, agile, UX and blockchain. This will manage to “DevOpsify” the enterprise skin (aka front end, customer experience layer, or mode 2 apps) and, in many cases, possibly, their non-legacy middle-end system as well. However, the majority of the back-end stack, especially in financial services, remains in the legacy world (zSeries or iSeries).

One might argue with a seemingly coherent logic that, “Well, we won’t have mainframes in a few years as we will move to newer platforms soon.” But it helps to remember Mark Twain’s quip, “The rumors of my demise are greatly exaggerated,” applies so well to the mainframe world!

In simple terms, your enterprise most likely will adopt a combination of the following strategies to deal with the legacy challenge:
- Retire mainframe app, in some cases.
- Extract business logic and move it to distributed platforms.
- Componentize the monolithic mainframe code and hook them to APIs for external consumption.
- Build new platforms to replace legacy apps.
There is one least common denominator for any of the above strategic direction that your enterprises take: ever-diminishing mainframe knowledge! So, I ask again: Where is the next generation of mainframe talent?

— Aditya Vadaganadam
October 25, 2018
Picking a Git for the Enterprise
Some of my Agile and DevOps transformation work, not surprisingly, involves helping clients with tooling adoption—to set up, scale and operate across the organization. This blog piece is about a recent experience of setting up Git across a client organization.

Git, as most of you are aware, is a fundamental building block for many of the modern engineering practices associated with Agile and DevOps. Software configuration management tools such as Git, in simple words, allow you to track and manage your software code and configuration changes in the most-effective, efficient and distributed way. Git, as the choice of source control, has remained steadfast over the years, while other tools across various categories of DevOps tools have seen their fortunes go up and down with the ever-changing technology landscape of DevOps tools. In fact, one new buzzword is GitOps—some even calling it the next stage of evolution for DevOps.

Origins of Git

More than a decade ago , the Linux community faced a challenge because none of the existing revision control tools met their need for a distributed version control tool. And from that need Git was born. In the words of the creator of Git, Linus Torvalds, “The main issues with SCMs is the politics around who can make changes.” Ever since its creation, Git has radically changed the notion of software configuration management (SCM), by enabling engineers to work remotely and autonomously. (If you are new to Git and interested in exploring more about Git and its features, Atlassian has a tutorial and GitHub has a list of resources.)

Git and More

While Git as the core product is fundamentally the same whichever flavor your prefer—GitHub, GitLab or Bitbucket—the wrapper around it determines the important non-functional characteristics such as operatability, security, usability and maintainability. Our quest for an enterprise-scale Git focused on the wrapper and not the core product itself, as much has been written, debated and documented on the core product of Git itself already. The value and relevance to enterprises is in the wrapper that these productsplatforms provide.

We looked at the core product and related offerings; as you can imagine, the three tooling vendors have different positioning and taking different directions with the future road map for their respective tools. Bitbucket’s strength lies in the fact that Atlassian is bundling the product with the omnipresent Jira Software and Confluence. GitLab’s road map seems to be taking the product beyond Git and into the idea of a single product for your entire pipeline automation, from concept to cash. GitHub, which is being acquired by Microsoft, is increasingly relying on the strength of integrations with other tools and the workflow capability the company is bundling with it.

(I avoid an overemphasis on the commercial aspect in this blog; however, I’m not ignoring it completely. Part of the reason is due to the fact that enterprise pricing is not entirely transparent and may vary wildly depending on organization’s negotiating capability, the scale of usage, future potential and marketable track records as perceived by the tooling vendors. This blog is also not meant to be a feature by feature comparison, as this is something you can Google and find out yourself very easily.)

The Verdict

Image1; Github Enterprise – Pros and Cons

Image 2: Gitlab Ultimate – Pros and Cons

My Recommendation: It Depends
1. I liked the vision of GitLab as a single-stop tooling platform for continuous integration/continuous delivery (CI/CD), which goes beyond source control. I think the tool is simple and intuitive to use and great for small to midsized setups or even large enterprises that are focused on having smaller and autonomous teams.
2. GitHub seems to be well-suited for large and complex enterprises with significant outsourced and offshore-based technology teams.
I would love to hear your views on what has been your thinking with regards to choosing a Git-based product for your enterprise or teams. Meanwhile, here are some links you might find useful in your decision-making:
1. Why and how GitLab abandoned Microsoft Azure for Google Cloud – https://venturebeat.com/2018/04/06/why-and-how-gitlab-abandoned-microsoft-azure-for-google-cloud/
2. Tooling integrations of GitLab – https://docs.gitlab.com/ee/integration/README.html#doc-nav%20for%20list%20of%20integrations
3. GitHub add-ons are listed at Addons are listed at https://github.com/marketplace
4. Security and scalability info of GitHub is at https://github.com/jonico/github_security_and_scalability_overview
5. Products that integrate with GitHub platform – https://github.com/works-with
6. Pricing of GitLab – https://about.gitlab.com/pricing/
— Aditya Vadaganadam
June 18, 2018
Has DevOps Caused the Re-emergence of Shadow IT?
Shadow IT is back, and this time, it’s in the DevOps toolstack

“One of our clients conducted an audit and found more than 10,000 Jenkins instances across their IT landscape!” This remark from a tooling vendor that helps enterprises centralize their continuous integration infrastructure really took me by surprise. For starters, I was impressed how the company had unleashed creativity at this scale—if the number of Jenkins instances in an organization is an indicator of DevOps. Clearly, its employees have taken the saying, “Don’t ask for permission, ask for forgiveness,” very seriously.

However, there are certain risks with this approach, especially security risks if teams haven’t considered the long-term implication of their decisions. For instance, how do you handle another major security flaw such as the OpenSSL Heartbleed bug? You may have to send hunting squads to track down all the instances of Jenkins (in this case) across your IT estate—including the Linux server hidden away under the desk of the engineer—and patch them. If you are lucky, you can audit all the virtual machines on your chosen cloud where all your tooling instances reside. And if you are really lucky, the entire DevOps tooling infrastructure would have been set up in a DevOps way, using infrastructure-as-code principles with automated patching capability.

Consider the nightmare scenario for IT compliance, security and governance teams: The spectre of shadow IT is amplified due to poor adoption of DevOps! Shadow IT in the application stack has always been a big headache for CIOs; the use of IT systems within an organization without the approval, or even the knowledge, of corporate IT has never gone away. Shadow IT has been historically associated with business users who made the purchase, but did not have the expertise to maintain and upgrade the software to make sure there were no risks to the wider organization. Much has been written about the problem in the application stack and how DevOps ways can help resolve the issue.

However, with the proliferation of DevOps tools in a localized way, the shadow IT problem is now manifesting itself in the tooling architecture of enterprises. With the increasing adoption of DevOps practices and tools in the enterprise, teams have started installing various DevOps tools in a localized and autonomous way. This is leading to the shadow IT problem in the tooling landscape of enterprises. It’s slightly different than the problem that originated in the application stack, but with similar risks and challenges. Access to cloud in the enterprise has made it easier for teams to set up their own localized DevOps tool sets. A sizable program of work in its full DevOps glory can easily use dozens of tools and need to consider aspects of security such as:
1. What is the patching policy ?
2. Are your DevOps tools critical to the business due to the dependency on them for the build and deployment of critical services that the business requires?
3. How resilient is the tooling infrastructure ?
4. Is there enough knowledge in the enterprise to handle this change?
Essentially, there are four risks of shadow IT due to DevOps tooling, based on a pertinent classification by Computer Weekly:
1. Software asset management: The risk of discovering unapproved and unlicensed software is huge and the CIO could be potentially jailed for sanctioning usage of unlicensed software.
2. Compliance with industry and government standards to demonstrate quality to customers.
3. Lack of testing and change control: Managing cycle of change and releases becomes complicated when there are dependencies on third-party SaaS.
4. Configuration Management: IT teams rely on the veracity of information in the configuration management database CMDB and shadow IT compromises it.
Organizations typically respond to the problem of shadow IT with rationalization, migration or even sunset of the targeted applications—most of which are reactive measures. In the context of DevOps tools, an extreme way to deal with the problem is by taking control of all tools with an “iron fist” and shutting down everything—at the risk of killing off innovation in the enterprise. In the short run, teams do achieve higher levels of productivity by deploying tools in the way that suits their business context and experience of the engineers in the team. However, over time I find that the teams are overburdened by the maintenance overhead of DevOps tooling and maintaining a tooling stack in addition to their software application stack. At times, if they are early adopters in their organization, they tend to be victims of their own success: by supporting other teams with their tooling solutions, almost becoming a tooling platform provider internally, and diverting their attention away from their core purpose of delivering value to their business partners.

One pragmatic way to resolve this is to add an element of centralization or “platformization” of the tooling infrastructure.

Autonomous teams understandably fiercely resist any attempt to centralize services in the enterprise. A few useful ways to gain a balance between innovation and control include:
1. Provide a responsive tooling platform: “You can have any color as long as it’s black” approach to DevOps tooling will only lead teams to finding their own unique solutions.
2. Anticipate tooling needs and build them: Think ahead, track the trends and procure the tools that you expect teams to achieve. For example, if a few teams are already playing with docker and containers, then think a step ahead and look at Kubernetes to manage the containers.
3. Focus on user experience: Think about the ease of subscribing to tools, installation, billing … the entire life cycle
4. Offer help to transition to the tooling platform.
5. Run an internal communications campaign on the tooling capabilities that are available to teams.
Ultimately, a well-thought-out DevOps approach and implementation can actually help resolve the challenge of shadow IT that organizations face, instead of accentuating the problem.

— Aditya Vadaganadam
May 30, 2018
Enterprise Infrastructure: Adapt or Face Extinction
In my previous blog, I explored how new ways of working—DevOps, Agile, cloud and startup thinking—have brought in a tectonic shift in the ways of working of enterprises. For infrastructure leadership and management, this is nothing short of a perfect storm that they need to navigate.

While these new ways have impacted every aspect of technology including development, testing and project management, infrastructure and operations have remained the last bastions of traditional thinking, practices and approaches. Even with the rapid rise of DevOps practices in the recent years, we have just seen pockets of change in the infrastructure space, be it adoption of infrastructure-as-code practice, cloud in its numerous variants (private, public or hybrid) or containers and cloud-native technologies. But these changes all fall short of an enterprise-scale change that matters. What is missing is a systemic view of infrastructure as a value stream and transformation that ventures beyond the skin-deep changes limited to a few front-end digital capabilities.

Infrastructure Transformation on the Horizon

However, this is changing now; one by one, the barriers to infrastructure agility are breaking down. To put it simply, there are four dimensions of this change, based on various enterprise transformation initiatives that I have been involved over the years

Radical new Operating Models

New operating models are emerging to meet the business demand for infrastructure agility. There are primarily five patterns or a combination that enterprise are espousing in the operating model space:
1. Shared service: This typically involves applying lean, value-stream mapping and Kanban techniques—in simple terms, the emphasis is on transparency, business-aligned prioritization of work and limiting work in progress.
2. Responsive shared service: In this model, specific infrastructure members are “seconded” to application squads for more responsive service. However, there are limits to secondment model, in the ability to scale beyond a few iconic programs of work.
3. Cross-skilling: This model involves infrastructure and application team members learning skills across each other’s disciplines with the goal of making delivery teams self-reliant.
4. Disrupting with cloud: As the name suggests, enterprises are disrupting their own traditional infrastructure capabilities by aggressively pursuing private, public and hybrid cloud capabilities.
5. Insourcing: Increasingly, there is a trend to insource responsive cloud and DevOps-based services to near-shore locations. “Almost twice as many CEOs are intent on building up in-house technology and digital capabilities as those plan on outsourcing it (57 percent and 29 percent, respectively),” according to Gartner’s survey of CEOs in 2017.
Reimagining the Legacy Technology Stack

Legacy systems based on technologies such as the AS400 or mainframes have been the bedrocks of technology for decades, but they also have been blamed for constraining agility. Many organizations have realized that replacing legacy systems with open system stacks is not an easy feat. Consider the fact that IBM continues to report an increase in mainframe sales over the last few years, including Q4 2017. This points to the fact that legacy will be part of the enterprise landscape for years to come—as such, incumbents need to be able to leverage the legacy stack to compete with digital challengers who are unencumbered by similar technology constraints.

However, it is not all somber. There is a new wave of optimism driven by old guards, including CA and IBM, and new, including Compuware and ARCAD, that are bringing modern engineering practices such as continuous integrationcontinuous delivery (CI/CD), automated code analysis, virtualization, lightweight integration and test automation to these platforms. These new practices not only give these systems a new lease on life, but they also enable modern enterprise systems to be built iterative and incrementally—and not be handicapped by legacy constraints anymore.

Intelligent Enterprise Resource Planning Software

ERP software such as SAP/R3 are the backbone of many enterprises across industries. Historically, ERP software products have not kept up to speed with modern engineering practices and flexible architecture, which are fundamental to agility. The good news is that the ERP landscape is changing as product vendors are embracing cloud and API-led integration—IDC calls this “intelligent ERP” or “i-ERP.” Consider this: In 2025, SAP/R3, the largest ERP product in use, will no longer be supported officially, and enterprise planning programs (albeit, in a waterfall way) will move to SAP HANA Enterprise Cloud, the company’s new generation ERP platform.

Culture and People

Years of the drumbeat of Lean, Agile and DevOps ways is yielding results, especially in those organizations that see this as a people change as much as technology change. People in the infrastructure world are changing from operating being behind a queue toward being customer-focused, collaborative and value-seeking. Organizations need to address the structures that restrained it from moving forward on the journey. Traditional organizational structures don’t account for team strengths, nor do they give everyone fair input in regards to overall direction. Rather, structures should be set up that allow managers to empower teams instead of teams living to carry out management demands.

Ultimately, the key to creating agile and responsive infrastructure in organizations starts at the top, from the CXOs who need to realize the scale of change and inspire their teams on the need for change—or face extinction.

— Aditya Vadaganadam
April 25, 2018
Time to Rethink Infrastructure Operations in Enterprises

“Business is technology and technology is business” seems to be the new mantra as the rules of corporate strategy are being rewritten across industries. According to IDC’s survey in 2017, “Two-thirds of global CEOs will have digital transformation as part of their corporate strategy.” That’s CEOs—not CIOs—who will have digital transformation as part of their corporate and, not IT, strategy.

While digital transformation is not a new phenomenon, making digitization core to the corporate strategy is a fundamental shift for technology teams. Delivery units, or “change the enterprise” teams, have warmed up to new ways of working over the last few years and are already on the learning journey. Most enterprises today have digital or agile transformation initiatives that tend to focus on the “change” aspect significantly. However, the less glamorous “run the enterprise” dimension tends to be forgotten or side-lined in these initiatives.

The rise of DevOps was meant to bridge the gap between “change” and “run.” However, many DevOps transformation initiatives seem to be taking the same old path of least resistance that agile transformations have historically adopted: by focusing on the “change” and delivery teams.

As a consequence, the infrastructure and operations teams—or, “run the enterprise” units—are now waking up to the new reality and have far less time to adapt than their “change” counterparts. The big question really is, What does it mean to infrastructure and operations teams when the CEO is now embracing digital transformation?

This means that the technology infrastructure required to support business strategy requires a combination of the usual consistency and quality that infrastructure and operations have historically focused on—but only with greater speed, innovation, flexibility and customer intimacy. For the first time, business is looking at infrastructure as equal partners on this journey, not as a subservient IT function.

What Caused This Shift in Thinking?

Since 2001, there have been four game-changers in technology that have caused this shift in thinking: the Agile Manifesto of 2001, adoption of Cloud by enterprises, rise of startups and the DevOps movement. The world of technology as we know has been going through a tectonic shift as a consequence of these overlapping waves of change.

Agile and DevOps

Version One’s 11th “State of Agile” report highlights that 71 percent of organizations have current or planned DevOps initiatives in 2018. While Agile ways focus on effective team structures, value focused mindset and greater business alignment, DevOps has taken the principles to the logical next steps of delivering value by focusing on flow, amplified feedback loops and building a culture of learning and innovation. In addition, full stack automation covering infrastructure, application delivery and release orchestration has really catapulted DevOps into the top initiatives in organizations. In terms of architecture, new constructs such as evolving design, microservices, containers and serverless computing are all redefining technology infrastructure. The rise of these new ways of working is only piling immense pressure on traditional infrastructure organizations to reform and rethink every aspect of their operating model and challenge processes built on a foundation of perceived stability.

The Startup Way

Enterprises increasingly are being influenced by the ways of startups and how they are driving rapid innovation. There is a cross-fertilization of people moving to enterprises who are challenging the thinking in these enterprises, especially infrastructure area. Teams are now embracing once considered absolutely alien, if not impossible, concepts such as chaos engineering and anti-fragility.

Cloud

The recent RightScale “State of Cloud” report reveals that 97 percent of enterprises are using cloud in 2017. However, only a small share of their workload has actually been moved to cloud, indicating the potential for cloud in the enterprise context. This indicates that enterprises are past the quick wins such as digital front-ends and will now struggle with the difficult areas of their applications—the bulk of the enterprise apps where the traditional infrastructure constraints and mindset rules. Enterprises can tackle this by truly embracing change, thinking big but starting small with experiments and continuous refinement of the every single dimension of the way infrastructure teams operate.

“Nothing is permanent but change.” The wise and timeless words of Confucius ring true!

— Aditya Vadaganadam

April 18, 2018
DevOps in Legacy Systems: A Mission Impossible?

The word “legacy” evokes mixed reactions from the IT and business crowds alike. For those who depend on legacy systems such as the zSeries and iSeries platforms, it is a way to deliver stable and reliable applications into production. Business stakeholders who may not know the intricacies of the technology often take a view of, “Why fix it when it ain’t broken?”

On the other hand, for those who haven’t experienced the joys and pains of legacy systems , legacy world will continue to defy their logic and assumptions because their view of the world is shaped by the open system world which has completely different characteristics: being more malleable to change and easy to maintain etc. Hence there is this great divide between the legacy and new worlds. Add Agile and DevOps to the equation with the lofty goals of increased release frequency and reduced lead times, we end up with a divide that is too far to bridge.

The likes of Gartner have come up with constructs such as two-speed delivery to help deal with this legacy challenge. In my view, there is a problem with the idea of dual-speed because it is based on a wrong analogy to start with — that of allowing vehicles to move at different speeds depending on whether you are on the motorway or a city road. That analogy works well for traffic management scenarios but not for complex IT architectures we see in the enterprise. The dependencies across the systems in the enterprise landscape are just too intricate and too tightly coupled to be defined using such a binary logic. In my experience, I find that many Agile and DevOps transformations hit the roadblock and never achieve the desired levels of productivity and effectiveness because of an oversimplified view of these complex dependencies across legacy and open systems.

The three biggest challenges that prevent a legacy DevOps transformation are mindset problems, architectural constraints and tooling limitations.

The Mindset Problem

“There are no legacy systems, just legacy thinking.” That’s a great quote I heard recently from an engineer in a large organization trying to adopt DevOps at enterprise scale. The initial resistance from teams to move into DevOps ways is due to reluctance to change, emerging from an inertia of doing things a certain way for years if not decades. The mindset problem is as much a problem for those outside the legacy world as those inside. The “outsiders”—typically leadership, management team and consultants—tend to oversimplify the problem and, too often, rely on examples from the open systems world. This just alienates the incumbent legacy teams and makes them even more skeptical of DevOps driven change. The outsiders need to have a genuine appreciation of the challenges with legacy architecture and need to work in collaboration with the legacy teams if they really want to transform their organization.

Architectural Constraints

Legacy systems have certain characteristics such as being static, tightly coupled and monolithic blocks of procedural code. These systems were not built for the modern Agile workflows that focus on incremental and iterative deliveries. A significant majority of these systems are written to operate in batch mode.Testing the systems requires cycling through multiple business days, which simply limits the level of agility you want to introduce in the organization. I am currently working with a legacy engineering team in the financial services space where you have to cycle through a minimum of 20 business days to simulate even 70 percent of the test scenarios. However, there are a number of solution options to overcome the architectural challenges; they range from killing applications to migrating to modern platforms or re-engineering legacy code. Not surprisingly, the right approach depends very much on your context.

Tooling

Tooling in the legacy world to support a DevOps ways of delivery has always been a challenge. But it is fast changing now, thanks to a number of startups and even old-school IT product companies investing in this space. If you consider zSeries as an example, there are better IDEs (integrated development environments) such as RDz that can replace traditional code editors typically based on “green screens.” These IDEs provide great features such as better navigation, debugging, split views and searches on the legacy code. One of the CIOs I worked with made it clear to his team that he wanted to get rid of “green” screens from the IT floor. There are tools such as SmartBear Collaborator that support a great peer review experience and help bring one of the original XP practice of pair programming to the legacy world. There are tools such as endeavor from CA that promise automated build and deployments in the z-series world. Similarly, there are tools that support test automation of mainframe applications and tools for code coverage and code quality checks on legacy programming languages like COBOL. XATester looks like a promising tool for unit test automation from a Danish startup called Xact.

While this write-up is not intended to be a compendium of all DevOps and engineering tools, the central message is that there are a number of DevOps tools emerging on the legacy landscape which can help your legacy delivery teams get on to the DevOps and Agile journey.

What is more important is for organizations to realize that many of these legacy systems will remain part of their IT landscape for the next foreseeable future and it is time to invest in these core systems. They may not look as appealing as the digital platforms, but they are fundamental for businesses and you cannot ignore them on your DevOps journey. DevOps in the legacy world is not going to be smooth, but it is certainly not a mission impossible!

— Aditya Vadaganadam

March 17, 2017