Solution architecture
How the parts play together: systems, modules, interfaces and data flows, documented and justified.
Solution architecture and requirements
Sound architectures and requirements you can actually build. So your SAP programme stands on a foundation, not on assumptions.
Many problems that surface in testing or after go-live are created much earlier: in unclear requirements, silent assumptions and architecture decisions that were never made explicitly. That is exactly where we start.
We design solution architectures that fit the system landscape and the organisation, and translate business requirements into specifications that consultants and developers can work with without follow-up questions. This includes solid concepts for data transfer and migration.
Why clients get in touch
- Two concepts contradict each otherEvery workstream documented its part, but nobody has laid the concepts side by side.
- The requirements are a wish listA hundred backlog items, but nobody knows which of them the standard already covers.
- Migration is the critical pathGo-live depends on the data transfer, and the concept for it exists only as bullet points.
- A concept needs a second opinionThe implementation partner has delivered, and you would like an independent review.
Scope
What we deliver
From a single concept to end-to-end architecture accountability in a programme.
Requirements analysis
We collect requirements where they arise: in the departments. And separate wish, need and standard.
Specifications
Precise inputs for customising and development that your department can read and a developer can build from.
Data transfer and migration
Migration concept, mapping rules and validation that still hold on the fourth test run.
Integration architecture
An interface landscape with clear responsibilities, error handling and monitoring.
Architecture review
An independent look at existing concepts before the build gets expensive.
How we work
From understanding to a buildable concept
-
Step 1UnderstandTake in processes, system landscape and goals, together with the people who work with them daily.
-
Step 2DecideArchitecture options with pros and cons on the table, decisions documented instead of assumed.
-
Step 3SpecifyDescribe requirements and concepts so the build can start without room for interpretation.
-
Step 4AccompanyReview the build against the specification and adjust where practice shows something new.
What you get
How we approach architecture
Decisions instead of assumptions
Every important decision is made explicitly and justified. That saves the expensive discussions during testing.
Business and IT at one table
Good requirements come out of conversations, not forms.
Buildability as the yardstick
A specification is finished when someone can build from it without follow-up questions.
Questions
Frequently asked
When is a solution architect worth it?
As soon as more than one system or more than one team is involved. The architecture questions arise anyway. The only question is whether they get answered deliberately or in passing.
Do you also work purely as a review body?
Yes. An architecture or concept review takes a few days depending on scope and shows where the risks sit before the build starts.
How detailed are your specifications?
As detailed as necessary, as lean as possible. A standard process needs two pages, a complex custom development considerably more. What matters is that nothing important is left to interpretation.
Contact
Is a concept or architecture decision coming up?
Send us the starting position. A first look often already shows where the critical decisions lie.
Discuss your concept