IT Chaos Theory: The PeopleSoft Effect

#cloud #devops A robust integration ecosystem is critical to prevent the PeopleSoft effect within the network

In chaos theory, the butterfly effect is the sensitive dependence on initial conditions, where a small change at one place in a nonlinear system can result in large differences to a later state. The name of the effect, coined by Edward Lorenz, is derived from the theoretical example of a hurricane's formation being contingent on whether or not a distant butterfly had flapped its wings several weeks before.

-- Wikipedia, Butterfly Effect

Many may not recognize the field of IT chaos theory (because technically I made it up for this post) but its premise is similar in nature to that of chaos theory. The big difference is that while Chaos Theory has a butterfly effect, IT Chaos Theory has a PeopleSoft effect.

In IT Chaos Theory, the PeopleSoft effect is the sensitive dependence on initial integrations between operational components where a small change in one place results in large amounts of technical debt when any single component is upgraded. This name was chosen due to the history of PeopleSoft implementations in which even small customizations of one version generally leads to increasing amounts of time and effort being expended to reproduce after upgrades which obliterated the original customizations.

Lest you think I jest with respect to the heartache caused by PeopleSoft in the past, consider this excerpt from an article on PeopleSoft Planet regarding customization of the software:

Although you are currently succeeding in resisting the temptation to customize the software, your excuse of “let’s get the routine established first” is losing ground. Experienced users can imagine countless ways to “tweak” the system to do everything the previous solution did, plus take advantage of all the features that were why you purchased this software originally. In truth, you have already made a few customizations, but those you had to do. Nagging you is the persistent worry that once you customize, that your options to upgrade will be seriously jeopardized, or at least the prospect of a relatively simple, smooth, even seamless upgrade is reduced to a myth. How can you guarantee that when you upgrade, your customizations will not be lost? That days of productivity will not be compromised? Yet, if you do not make a few more concessions, how many man hours will be spent, attempting to recreate the solutions you had previously?

There is a reason there is an entire sub-market of PeopleSoft developers within the larger development community. There are legions of folks out there who focus solely on PeopleSoft and whose daily grind is, in fact, to maintain and continually update new versions of PeopleSoft. If you’ve worked within an enterprise you will recognize these dedicated teams as a reality.

These are the kinds of situations and realities we want to – nay, must – avoid within operations. While integration of infrastructure with automation frameworks and orchestration systems is critical to the successful implementation of cloud computing models, we must be sensitive to the impact of customization and integration downstream.

The reason for this is the technical debt incurred by each small change grows non-linearly over time. As this becomes reality, rigidity begins to take hold and agility begins to rapidly decline as operations becomes increasingly aggressive towards changes in the underlying integrations. Rigidity of the systems takes root in the slowness or outright refusal to enact change in the system by those reluctant to take on the task of identifying the impact across an ever broadening set of integrated systems.

AVOIDING the PEOPLESOFT EFFECT: A ROBUST INTEGRATION ECOSYSTEM

One of the ways in which IT can avoid the PeopleSoft effect is to take advantage of existing integration ecosystems whenever possible so as to minimize the amount of custom integrations that must be managed.

One of the benefits of automation and orchestration – of cloud computing, really – is to reduce the burden on manual procedures and processes. Which in turn reduces the already high burden on IT operations – on admins. A recent GFI stress survey found that IT admins are a particularly stressed-out lot already, and anything that can be done to reduce this burden should be viewed as a positive step. Automation and orchestration enhances the scalability of the processes as well as the speed with which they can be executed, and has additional benefits in the form of reducing the potential for human error to cause delays or outages. And perhaps it’s the thing that ensures those 67% of admins considering switching careers due to job stress don’t actually follow through.

A mixture of pre-packaged integration for automation purposes affords operations the ability to focus on process codification via orchestration engines, and not on writing or tweaking code to fit APIs and SDKs. Codification of customization should occur as much as possible in the processes and policies that govern automation, not in the integration layer that interconnects the systems and environments being controlled. Taking advantage of pre-existing integrations with automation frameworks and provisioning systems enables IT to alleviate the potential PeopleSoft effect that occurs when APIs, SDKs or frameworks invariably change.

Cloud is ultimately built on an ecosystem: a robust integration ecosystem wherein the focus lies on process engineering and policy development as a means to create repeatable deployment processes and automation objects that form the foundation for IT as a Service.

When evaluating infrastructure, in particular, pay careful attention to the integration available with frameworks and orchestration engines and in particular those upon which you may have or may be considering standardizing:

Popular frameworks and orchestration managers include:

Some customization is always necessary, but application integration nightmares involving integration have taught us that minimizing the amount of customization is the best strategy for minimizing the potential impact of changes later on. This is especially true for cloud computing environments, where integration and the processes orchestrated atop it may start out simple, but rapidly grow more complex in terms of interdependencies and interrelationships. The more intertwined this systems become, the more likely it is that a small change in one part of the system will have a dramatic impact on another later on.