About us
An independent advisory practice for technology decisions
MOUNTAIN ADVISORY GmbH advises organisations on infrastructure, cloud platforms, security, software architecture and data. We are a consulting practice rather than a reseller or an implementation contractor, and our value comes from judgement, analysis and clear documentation rather than from products sold alongside advice.
Our mission
Our mission is to help organisations make technology decisions they can defend — to their engineers, their leadership, their auditors and themselves. That means replacing assumption with evidence, describing trade-offs honestly, and leaving behind documentation that remains useful long after the engagement ends.
We measure our contribution by whether an organisation understands its own estate better after working with us, and whether it can carry the next decision without external help.
Our vision
We want technology advice to be judged the way engineering is judged: on whether it holds up under scrutiny and under load. Our vision is a consulting relationship in which recommendations are written down with their assumptions visible, revisited when conditions change, and never dependent on the presence of the consultant who made them.
We would rather be the practice an organisation calls occasionally and deliberately than one it becomes structurally dependent on.
Operating principles
- Independence is structural, not stated
- We hold no reseller position and take no commission on technology selection, so the incentive to recommend a particular platform simply is not present.
- Scope is written before work begins
- Objectives, deliverables and end points are agreed in writing. Open-ended engagements make it difficult for a client to judge value.
- Findings go to the people accountable
- Analysis is presented to both technical and non-technical stakeholders in the same language, without a separate softened version.
- Uncertainty is reported, not smoothed over
- Where evidence is incomplete, we state what is unknown and what it would take to know it, rather than presenting a confident guess.
- Confidentiality is treated as an obligation
- Architecture, security and operational information is handled on a need-to-know basis under the confidentiality terms agreed in advance.
- Advice is proportionate
- Recommendations match the organisation's scale, budget and available skills. Complexity is only introduced where it earns its cost.
Consulting philosophy
Good consulting is mostly listening, reading and checking. Before we produce an opinion, we spend time in the material: configuration, architecture records, incident history, contracts, and the informal knowledge held by the people who keep systems running. Much of what matters is not in the documentation.
We then work in options rather than verdicts. Most technology questions have several defensible answers with different cost, risk and staffing profiles. Our task is to make those differences explicit so the organisation chooses knowingly — and to record why the chosen path was preferred.
We avoid recommending change for its own sake. Stability has value, and a system that is unfashionable but well understood is often a better foundation than a modern replacement nobody yet knows how to operate.
How we approach technology decisions
A decision is only as durable as the reasoning behind it. We work through a consistent sequence so that recommendations can be re-examined later without reconstructing the entire analysis from memory.
- Step 1
Define the decision precisely
Many technology debates persist because the actual question is unstated. We write it down first, including what is explicitly out of scope.
- Step 2
Establish constraints
Regulatory obligations, contractual commitments, integration dependencies, available skills and budget boundaries frame the space of viable answers.
- Step 3
Gather evidence
Configuration, logs, architecture records and interviews. Where measurement is possible, we prefer it to recollection.
- Step 4
Compare realistic options
Each option carries its operating cost, its risk profile, the skills it demands and the reversibility it offers.
- Step 5
Document the reasoning
The recommendation, the rejected alternatives, the assumptions relied on, and the signals that should trigger a review.
Quality and security mindset
Quality in advisory work is traceability: every conclusion should be followable back to the evidence that produced it. We keep that chain intact, review our own findings internally before presenting them, and correct the record when new information contradicts an earlier statement.
Security is handled the same way. Access to client systems is requested at the minimum level required and for the shortest period useful. Sensitive material is kept within the boundaries agreed in the engagement. Where our own recommendations introduce new exposure, we name it rather than leave it for a later audit to find.
How we work with organisations
We work alongside internal teams rather than in place of them. In practice that means joining existing forums instead of creating parallel ones, reviewing work in progress rather than only at completion, and making sure someone inside the organisation owns each recommendation before the engagement closes.
Engagements vary in shape: a bounded assessment of one platform, an architecture review before a procurement decision, ongoing advisory support during a modernisation programme, or a second opinion on a proposal already on the table. In every case the scope, deliverables and end point are agreed in writing first.
We also work with an organisation's existing suppliers. Being independent does not mean being adversarial; it means asking the questions a supplier has no incentive to raise.
Responsible and sustainable technology
Technology decisions have consequences beyond the balance sheet. Oversized infrastructure consumes energy that no workload requires. Data retained without purpose becomes both a cost and a liability. Systems designed without accessibility in mind exclude people who need them.
We factor these considerations into ordinary advisory work rather than treating them as a separate initiative: right-sizing capacity instead of provisioning for imagined peaks, questioning retention periods that exist only by default, favouring designs that extend the useful life of existing hardware and licences, and raising accessibility and data-minimisation questions during design rather than after release.
Sustainability in IT is largely a discipline of restraint — building what is needed, retiring what is not, and measuring rather than assuming.
- Company
- MOUNTAIN ADVISORY GmbH
- [email protected]
- Website
- mountainadvisorygroup.com
- Practice
- IT consulting and technology advisory
- Language
- English