This page is intended for IT professionals, technical managers, and others who have been asked to evaluate T. L. Cummings as a potential technology advisor partner, managed services provider, or project resource.
It assumes technical fluency.
If you were not asked to review us in a technical capacity, you may find this page unnecessarily detailed.
We approach IT as a business-supporting discipline, not merely a collection of tools.
Our work begins with understanding:
- The operational context
- The organization’s tolerance for risk and disruption
- The consequences of failure
- The organization’s ability to maintain and recover systems
We do not optimize for novelty, vendor preference, or theoretical best practices.
We optimize for defensible decisions—ones that can be explained, maintained, and supported over time.
We favor architectures that are:
- Simple enough to understand
- Documentable without excessive effort
- Supportable by more than one individual
- Proportionate to the organization’s scale and risk profile
Single points of failure are identified explicitly and addressed deliberately.
Redundancy is added where it is justified by business impact, or when requested by the client and supported by measurable business value.
We are cautious about introducing complexity that cannot be operationally justified or realistically maintained.
We favor architectures that are:
- Simple enough to understand
- Documentable without excessive effort
- Supportable by more than one individual
- Proportionate to the organization’s scale and risk profile
Single points of failure are identified explicitly and addressed deliberately.
Redundancy is added where it is justified by business impact, or when requested by the client and supported by measurable business value.
We are cautious about introducing complexity that cannot be operationally justified or realistically maintained.
We are vendor-agnostic by design.
We use products and platforms that:
- Have demonstrated operational reliability
- Are well supported and well documented
- Fit the environment they are being deployed into
- Can be reasonably handed off or supported by others if needed
We avoid tool sprawl.
We avoid introducing dependencies that only we can manage.
If a simpler solution meets the requirement, we will recommend it—even if it reduces billable work.
We are comfortable working alongside internal IT staff, external consultants, and existing service providers.
Our role may include:
- Providing a second opinion on architecture or vendor recommendations
- Assisting with planning, documentation, or risk assessment
- Supporting discrete projects or transitions
- Serving as a technical sounding board for complex decisions
We do not seek to displace internal IT.
We aim to complement existing capabilities and reduce decision risk.
For clarity, there are several things we intentionally avoid:
- We do not oversell security products or frameworks
- We do not design environments that depend on constant intervention
- We do not obscure risk behind jargon
- We do not push clients toward unnecessary complexity
- We do not treat stated requirements as immutable when deeper analysis reveals gaps, conflicts, or unaddressed risks. Business requirements are documented carefully and, when appropriate, recommendations are made that better satisfy the underlying need—even if they differ from the initial request.
- We do not create dependency as a business model
If a recommendation cannot be explained clearly to a competent technical peer, we revisit it.
If you are evaluating us, you are likely balancing technical soundness with business reality.
Our goal is to support decisions you can stand behind—technically, operationally, and professionally—long after the engagement itself has ended.