GMM Music Publishing International
From first visit to renewal: designing GMM MPI’s licensing CRM
- UX/UI Design & User Research
- Business Process Management
- Solution Architecture
Digital Strategy & Discovery
Solution Architecture
We work out where component boundaries sit, how systems talk to each other, which system owns each piece of data and what happens when one fails. Each decision is recorded with its reasoning before building starts.
Solution architecture is the set of technical decisions that are expensive to change later: component boundaries, integration patterns, data ownership and behaviour when a dependency fails. We settle those before development starts and record the reasoning.
We designed an on-site charge control system over OCPP for EVolt, the architecture, APIs and data design for a Thai music company's content management system, and the API specification and permission matrix for GMM Music Publishing's sales CRM.
Is this the right fit?
The situations this work is built for, and what you get at the end of it.
You may need this if
A large build starts soon
The budget is approved, but nobody has written down how the main parts of the system fit together.
Your team is split on the design
Senior engineers disagree on the approach and the decision needs an outside view.
Several systems hold the same data
Customers or contracts exist in more than one system, and nobody has decided which copy is authoritative.
Someone else designed the architecture
You want a vendor's design checked against your constraints before committing budget.
What we deliver
Component boundaries
What each part of the system owns and where it ends, which decides how hard later changes are.
Integration patterns
Synchronous, event-driven, batch or file-based for each interface, chosen against its coupling and failure requirements.
Data ownership
Which system is the source of truth for each entity, and how the other systems learn about changes.
Failure handling
What the system does when a dependency is slow or down, including timeouts, retries and queued work.
Decision records
Each significant choice recorded with the options considered and the reason, so a later team can follow it.
How we work
Every engagement runs through the same six-stage fitting process, from the first consultation to long-term care. The stages stay in the same order; how deep each one goes depends on the project.
See the full fitting process- ConsultationDiscover
- MeasureAnalyze and architect
- PatternDesign
- FittingBuild with you
- FinishingHarden and launch
- AftercareMaintain and support
How we make and record architecture decisions
We start from the constraints: the systems in place, the quality of their data, PDPA duties and what your operations team can run. A design that assumes clean data from a legacy system, or an integration nobody on your side can operate, breaks down once the build starts.
Most of the effort goes into the few decisions that are expensive to reverse. Frameworks and libraries can be changed later at modest cost, so we leave those open where we can. For each expensive decision we set out two or three workable options with their cost and risk.
Each decision record states what was chosen, what was rejected and why, so a team picking up the system years later can see which trade-offs were deliberate.
Where the risk is high, we test the design first by building a thin slice end to end or proving the riskiest integration.
Organizations we work with
Engagements span build, integration and long-term support. Named with permission; clients under NDA are not listed.
Related services
- Digital Transformation Consulting: when the business direction is still being decided.
- System Integration & API Development: when the work is mainly building interfaces between systems.
- Application Modernization: when an existing system is the constraint.
- Enterprise Software Development: when the architecture is agreed and you are ready to build.
Frequently asked questions
How much does solution architecture work cost?
It depends on how many systems and integrations are in scope, whether we review a design or produce a new one, and whether you want a thin slice built to test it. We give a written estimate after a short scoping call, or price against the TOR for public-sector work.
Do we need this if we already have a technical team?
Often not for day-to-day design. It helps when a decision is large and hard to reverse, when internal opinion is split, or when your team knows the current system well but has seen fewer examples of how similar problems are solved elsewhere.
Will you recommend microservices?
Only if the case for them is clear. For a system run by one team, a single well-structured application with clear internal boundaries is usually easier to build and operate. Microservices add operational work that pays off only with a larger team and mature operations.
How is this different from a vendor's pre-sales architecture?
A vendor's pre-sales design is shaped around the products that vendor sells. That is normal, and it means the design is unlikely to conclude that you should buy something else. Architecture commissioned as separate work can reach that conclusion when the evidence supports it.
Can you review an architecture someone else designed?
Yes. It is a common request before a budget is committed. We assess the design against your constraints and report what we find, including the parts we think are sound and the risks we would deal with before building. Your own architects can check each point.
Related work
EVolt
The live charger data behind EVolt’s station map
- Web Application Development
- System Integration & API Development
- UX/UI Design & User Research
Media & Entertainment (name withheld under NDA)
From catalogue to streaming platforms: designing a music CMS
- UX/UI Design & User Research
- Solution Architecture
- Data Migration
Next step
Start with a conversation
Tell us about the problem you are trying to solve. A senior person reads every inquiry and replies with our view of fit, scope and cost, including when another option would suit you better.