image

History can teach lessons for our modern times. Telephone switchboard operators were a necessary part of routing phone calls to customers. Their role lasted for over one hundred years. Women primarily performed this important function required to hold telephone conversations. The job entailed more than simply connecting a plug into a jack. Operators had to think quickly. Lights on a switchboard gave the operator feedback to know the status of a connection. Speed and accuracy were key attributes for an operator.

Disruptive automatic exchange technology removed the operator from the conversation. The transition was slow covering decades of time. Physical hardware, cost, and other technical constraints slowed the transition. Today, we take for granted how fast software configuration can move progress along.

Information Technology (IT) groups in established companies struggle with change. Over the course of time, it can be difficult to choose technologies in an organization. The goal is to install methodologies and toolsets that endure over of time. Vendor volatility and shuffling of senior management increases risk in the selection.

Think back to the Smalltalk language in the late 1990’s. Object Oriented Programming (OOP) was all the rage. Some companies chose Smalltalk over Java for their development language. Smalltalk lost its popularity fast. The maturity of the Java platform accelerated the decline. Companies had the expense of removing Smalltalk a few years later. Training staff in Java related technologies added to the expense. Choosing wisely can be extremely challenging.

Adopting new technologies continues to be challenging. Predicting the future is a fool’s quest. Keeping visionary plans in line with marketing hype is a science in itself. But, paradigm shifts in our way of thinking can reap large rewards. Reexamining common paths in the software development life cycle is key.

The reorganization of software configuration information can be a powerful step forward. This simple concept can be a game changer for legacy IT groups. Most established corporations follow an outdated way of capturing and maintaining data. Data rests in Excel spreadsheets, IT ticketing systems, and text files on individual PC’s. Scattering related information across unrelated data stores creates points of friction and bottlenecks. An Agile team may halt productivity by one person being on vacation. Manual steps can add days and weeks to even the simplest of projects. The versioning of disjoint information can be problematic. This raises artificial problems in staff operations adding to business confusion. Frustration in upper management with time delays can create a toxic work environment.

Proper organization of configuration code settings is vital. Policy driven containment is a must. Policy in this context includes roles and permissions to protect resources. Resources include IP routing between systems (port mapping) and access to data stores. A policy can apply to any restricted artifact. The theme is defining a set of policies in a centralized location close to the software bundle.

Let us revisit the previous discussion about telephone switchboard operators. Staff attempting to enforce policies play the role of a switchboard operator. The root of the problem is having people act as “gatekeepers” of the configurations. Large organizations need governess over policy and standards. Enforcement through software is the industry standard. Let the “automatic exchange” handle the switching not the “switchboard operators.”

The gatekeeper can outline the boundaries, rules, naming conventions, and standards. Software must enforce the set of constraints. The gatekeeper role should be like a referee in a sport. While a game is being played a referee steps in when players are outside of the game rules. The gatekeeper should only step in when a new rule needs created or enforced. The referee has the power to throw a player out of the game. Rule violation leads to the gatekeeper stepping in to halt the software process or game. Correct the violation then let the game continue.

Progressive companies like Facebook, Twitter, Google, and Amazon (AWS) operate on this theme. These companies have created technologies that drive the highest system availability and durability. Vital to serve their customers. Their software stacks rely on self-contained software configuration. Containerization and the immutability of their configurations enable their success. Removing people from the process is key. Their core methodologies do not allow for “switchboard operators” to exist.

The following shouldn’t need manual intervention:

  • Setup of software pipelines to migrate code to a development, stage, and production
  • Migrating code to production should be a simple stressless action
  • Creation and administration of code repositories by development teams
  • Modern code repository tools allow for setting up users in groups. User roles are a well established way to control access. Constrain users by policies on projects/repositories. Permissions include creating repos, add/removing people, promoting code, etc.
  • Software hooks enforce naming standards for repository names. For instance, git has hooks that can fire whenever someone checks in code. The software hook could fail a commit or remote push if it violates a naming standard. Perform enforcement of new repositories in a similar way.
  • In continuous integration flows (Jenkins), build can fail based upon software defined rules.
  • The creation of persistent data stores (SQL/NoSQL based) can be policy based. Delegating artifact creation (SQL tables and NoSQL dynamic schemas) to developers. The facilitation of namespace separation with policy governance. The art of defining SQL tables is a common skill in today’s world. Developer tools and IDE’s automate this task.
  • Faster release cycles demand repetitive tasks to be software driven. Altering tables and rebuilding indexes defined with configuration lets the game play. No one should halt game play.
  • The creation of platforms for development, testing, staging and production
  • A repeatable way to create software stacks should exist based upon centralized configuration
  • Cloud native concepts applied to on-premise hosting. The Twelve-Factor App method can be very powerful in self-hosted organization.

The removal of the switchboard operator mindset in an IT organization is a key paradigm shift. While the concept is simple, implementation can be difficult. But, it is necessary for modern software release cycles. The key is to move staff who adhere to the switchboard operator mindset to other functions. This forces the adoption of software configuration. Identify technical minded people who have the skills and vision to automate repetitive tasks. In the long run, an IT organization will be stronger.