Every organization has a unique technical architecture “fingerprint,” characterized not only by the products it has chosen to deploy, but also by the organization’s business culture and its impact on the technical evolution of the enterprise.

Even organizations using identical collections of products are likely to have disparate technology fingerprints. These differences can arise because: network configurations require varying degrees of customization; the way a product is used can differ substantially from one organization to the next; and network-monitoring practices range from the obsessive to the negligent.

When it comes to the technology of his enterprise, the CIO must be both a geneticist and a sociologist. He must have a firm grasp of the “DNA” of his network, and he must understand the societal framework in which his technology is used. In addition to understanding the core components of his network, the CIO must understand the people and practices that put the “ridges” in his technology fingerprint. He must understand what his users need from his technology, what their emotional responses to his system are. And his understanding must not be limited to a snapshot of the present moment. His understanding must have an historical basis: to do his job properly, he must understand how his users’ needs and responses to the technology have changed over time.

In my 25 years as a practicing Critical Problem Resolution specialist, I have diagnosed hundreds of debilitating network problems. When I arrive on-site, the root cause of a major network issue has rarely been identified, much less remediated. As we perform active and passive system analysis, facts begin to emerge. We compare what we have discovered to the theories that guide our work; the incongruities between observed fact and known theory help us to identify possible causes of the debilitating issue. We can then propose a mitigation plan, which we validate before implementation.

Our ability to rectify these debilitating problems is rooted in two primary factors. First, our efforts have uncovered new information integral to the resolution of the problem; and second, we interpreted that information in such a way that we could recommend a paradigm shift that would remedy the debilitating issue.

After such an arduous adventure, thinking clients often ask, “How can we keep this from happening again?” In the past 25 years, we’ve been asked that question a lot, and our response is always the same. We offer them the following set of best practices: the five pillars of Technical Systemization™:

1. Architecture Ownership
2. Business / Technology Integration
3. Problem / Change Management
4. Decision Support Metrics
5. Application Development Optimization

Our Technical Systemization™ methodology is fully supported and compatible with Internet, IT Architecture, ITIL, and ISO standards and principles. It works for organizations of all types and sizes – without altering your organizational structure. We assemble multidisciplinary, virtual teams that deliver training, create artifacts, and implement best practices across both technological and organizational lines, collaborating in a manner similar to the one used by our divers intelligence agencies as they span the demarks between governmental silos to execute coordinated responses to terrorist threats.

Over the coming weeks, I’ll be writing quite a bit about the things the issues that are most relevant to your ongoing efforts as a senior IT Professional. Stay tuned, and please feel free to comment on our posts; there’s a lot we can learn from each other.

Share This