Commissioning and core configuration
Turn installed infrastructure into an operating environment through configuration, testing and commissioning.
EvidenceConfigured and tested service baseline
CASE STUDIES
Proof, not promises.
MiCiS case studies show how we design, deliver and support technology when several systems and providers need to work together. Each story makes the starting context, scope, dependencies and verified result visible.
Client names, evidence and operational detail are published only with approval and with sensitive information removed.
Case study evidence model
Evidence-led
From operating context to a verified result
Featured case study
Botanic Gardens of Sydney
Managed network across a public, scientific and event precinct
01
ContextEnvironment, users, sites and operating need
Define02
ChallengeWhat was fragmented, changing or at risk
Frame03
DeliverySystems, services, interfaces and ownership
Deliver04
EvidenceTesting, records, acceptance and ongoing operation
Verify
Verified outcome
What changed—and what remained supportable after handover
A case study is not a promise that every environment has the same scope, products, constraints or outcome.
FeaturedBotanic Gardens of SydneyRoyal Botanic Garden Sydney and The Domain.
Environment40 smart nodesAcross a public, scientific and event precinct.
RelationshipSince 2017From commissioning into ongoing managed operation.
SupportContinuous monitoringFault escalation and event-specific support under agreed arrangements.
FEATURED CASE STUDY
One managed network, from daily operations to major events.
At Royal Botanic Garden Sydney and The Domain, MiCiS helped commission and then operate the connected environment around ENE.HUB smart-node infrastructure. The role developed into an ongoing service spanning the managed core, carrier services, Wi-Fi, monitoring, fibre and data maintenance and event-specific support under agreed arrangements.
Engagement context
MiCiS was initially engaged through ENE.HUB to commission the smart-node environment. The relationship later expanded into ongoing work with Botanic Gardens of Sydney and continued collaboration with ENE.HUB. Exact responsibilities have evolved over time and remain scope-specific.
Managed network case study
Ongoing service
Botanic Gardens of Sydney
Royal Botanic Garden Sydney & The Domain
40 smart nodes
Public · scientific · event precinct
Commissioned in 2017
01
ENE.HUB smart-node infrastructureActive infrastructure distributed across the precinct
02
Internet and carrier servicesExternal connectivity into the managed environment
Commission · configure · monitor
MiCiS-managed operating layer
Core fibre switching · firewall · routing · service separation
Configuration, testing, monitoring, maintenance, escalation and change context
01Science and operationsDay-to-day organisational services
02Public connectivityVisitor-facing Wi-Fi and network services
03Security-related servicesSeparated services supported by the managed core
04Major eventsChanging connectivity and support requirements
Invictus Games Sydney 2018Handa Opera on Sydney HarbourVivid SydneyWestpac OpenAir
Conceptual service view—not a physical network topology or disclosure of sensitive configuration.
THE OPERATING CHALLENGE
The network had to support different users, services and events without losing separation or accountability.
Installed infrastructure was only the starting point. The environment needed to support organisational teams, public connectivity, security-related services and changing event requirements while keeping the managed core visible, maintainable and easier to escalate.
- ✓
Keep services separated. Organisational, public, security-related and temporary event requirements needed distinct operating paths.
- ✓
Keep the core visible. Monitoring, fault evidence and escalation needed to remain available across changing site and event conditions.
- ✓
Keep change supportable. Temporary connectivity, authorised access and later network work needed to fit the existing environment rather than bypass it.
Operating requirement map
Dependency-ledSeveral service paths sharing one managed core
01Organisational usersScience, operations and internal services
02Public servicesVisitor connectivity across the precinct
03Security and eventsControlled access, temporary demand and authorised interfaces
Separate + observe
S
Service separationKeep traffic, access and operating responsibilities distinct
SegmentV
Visibility and evidenceMonitor the managed environment and preserve useful fault context
ObserveC
Controlled changeStage event, maintenance and new-connection work around the live precinct
ChangeDaily operationsStable organisational service
Public accessVisitor-facing connectivity
Event readinessTemporary needs within agreed scope
The exact architecture, access controls and service responsibilities are not published and remain specific to the client environment.
WHAT WAS DELIVERED
A connected service path across active network infrastructure, carrier services and ongoing support.
The scope developed over time. The case study shows how commissioning, active-network operation, connectivity, event support and maintenance can remain connected instead of becoming isolated work packages.
Core fibre switching
Operate the active switching path around the distributed node environment and maintain network context.
EvidenceManaged core and fibre path
Firewall, routing and service separation
Maintain the controlled paths that allow different users and services to share the environment safely.
EvidenceDocumented operating boundaries
Internet and carrier services
Coordinate external connectivity and the carrier dependencies that feed the managed environment.
EvidenceConnected service path
Wi-Fi and event connectivity
Provide or support approved connectivity paths for public use and event-specific requirements.
EvidenceTested temporary or recurring service
Monitoring, maintenance and escalation
Maintain fault visibility, coordinate fibre and data work, and retain an operational escalation path.
EvidenceOngoing support context
DAILY OPERATIONS TO MAJOR EVENTS
The same managed core had to adapt to recurring events and temporary operating requirements.
Event delivery sits inside a live public precinct. Each event can change the connectivity, access, support and escalation requirements without changing the need for controlled ownership.
Selected approved examples
Scope agreed per eventChanging event requirements supported by the same managed environment
Invictus Games Sydney 2018
Event network, Wi-Fi, fibre support and onsite assistance were delivered around the approved event requirements.
Temporary connectivity + supportHanda Opera on Sydney Harbour
Connectivity and event support were coordinated within the wider live precinct and its operating constraints.
Recurring event environmentVivid Sydney
MiCiS provisioned and tested authorised live CCTV access for public-safety coordination.
Authorised access + testingWestpac OpenAir
Recurring event connectivity was supported through the existing managed network and agreed event arrangements.
Event connectivity + continuityEvent support is not a fixed package. Access, equipment, support windows, providers, testing and responsibilities are confirmed for each event.
WHAT REMAINED AFTER DELIVERY
The outcome is not a one-off installation—it is an environment that remains operable as needs change.
The long-term value sits in retained context: what is connected, who owns each boundary, how a fault is escalated and how temporary or permanent change is introduced without starting again.
- 01
One operating contextCore network, carriers, site infrastructure and event needs remain connected in the service record.
- 02
Visible escalationFault evidence and the next accountable action can be retained as an issue crosses providers.
- 03
Supportable changeNew connections, maintenance and events can be assessed against the existing environment.
Verified case-study result
OngoingOne managed core and one operational contact across daily services and major events
✓
Continuous monitoring with fault escalation, on-call engineering and event-specific support under agreed arrangements.The exact service windows, escalation responsibilities and event scope remain defined by the applicable engagement.
01
Current network contextKnown systems, services and provider interfaces
Current02
Monitoring and fault evidenceUseful alerts, tests, changes and escalation references
Visible03
Event-specific scopeAccess, equipment, support windows and responsibilities
Agreed04
Maintenance and new connectionsFibre, data and active-network work within the live environment
Controlled05
Operational ownershipThe next action remains named when dependencies cross boundaries
OwnedA verified result describes the approved evidence and operating outcome—not a guarantee that another environment will use the same products, architecture or scope.
WHAT A CASE STUDY SHOULD PROVE
A useful case study makes context, boundaries, evidence and the lasting operating result clear.
The objective is not to make one engagement sound universal. It is to show what was actually required, what MiCiS owned, what other parties influenced and how the published outcome was supported.
Case study evidence framework
Operating context
Who uses the environment, where it operates and what business or site outcome matters.
Question answeredWhat had to keep working?
Operational challenge
The visible gap, dependency, risk or change that made the existing path difficult to operate.
Question answeredWhy was a different approach needed?
Scope and boundaries
The services, systems, third parties, exclusions and responsibilities that formed the agreed engagement.
Question answeredWhat did MiCiS actually own?
Connected dependencies
The carrier, cloud, network, site, vendor or project interfaces that affected the result.
Question answeredWhat else shaped the outcome?
Evidence and acceptance
Testing, records, commissioning, operational use or client confirmation that supports the published result.
Question answeredHow was the result checked?
Supportable outcome
What remained easier to operate, own, support or change after delivery and handover.
Question answeredWhat value remained after go-live?
FREQUENTLY ASKED QUESTIONS
Questions to settle before a case study, reference or similar engagement is discussed.
A credible case study should remain clear about client approval, evidence, sensitive detail, service boundaries and the fact that each environment has its own constraints.
Evidence without exposing sensitive detailClient approval, security, privacy, contractual boundaries and operational risk determine what can be published.
Case studies FAQ
Answers before a case study or reference is discussed
01How are MiCiS case studies selected?
MiCiS selects engagements that illustrate a real operating challenge, a clearly documented scope and an outcome supported by project, service or client evidence. Publication still depends on client approval and the removal of sensitive or unnecessary detail.
02Are client names, logos and event references always published?
No. Names, logos, photographs, event references and attributable testimonials are used only where approval exists. A case study can also be anonymised or limited to a high-level operating pattern.
03Does a case study represent a standard package?
No. It describes one approved engagement. Products, architecture, providers, support windows, access, site constraints, responsibilities and outcomes are confirmed separately for each client.
04How are published outcomes verified?
Depending on the engagement, evidence can include commissioning records, test results, acceptance, service records, operational use, event delivery evidence and client confirmation. The published wording is kept proportional to the evidence available.
05Are network, cybersecurity or physical-security details disclosed?
Not where disclosure would create unnecessary security, privacy or operational risk. Case-study diagrams are conceptual unless explicitly stated otherwise, and credentials, detailed topology, vulnerabilities and sensitive access arrangements are excluded.
06Can MiCiS work with existing carriers, vendors, builders or internal teams?
Yes. Many engagements involve several providers or internal owners. The service or project scope should identify who owns each system, interface, approval, escalation and next action.
07Can a similar approach be assessed for our environment?
Yes, but the first step is to understand your operating outcome, systems, sites, existing providers, constraints and current ownership. MiCiS can then identify the useful starting scope and the evidence required to verify it.
Have an environment where the result depends on several systems, sites or providers?
Describe what needs to keep working, the providers already involved and where ownership or evidence is breaking down. MiCiS will help identify the practical starting scope, the dependencies to confirm and the next accountable step.