Service /4
Software architecture: consulting in Salzburg, before anything is built.
The plan comes before the first line of code. We review it, and where none exists yet, we draw it up.
Software architecture is the set of decisions that can later be changed only at high cost. Which systems talk to each other and by which route. Where data is held and who may change it. What has to run as one unit and what can be operated separately. These decisions are taken in the first weeks of a project and determine the costs of the years that follow.
In most projects they are taken in passing. The reason is deadline pressure: the first thing built is what can be shown. The architecture then emerges as a by-product of many individual decisions, each of which was reasonable in itself.
We offer this service in two forms. As a review of an existing or planned system, with written findings and a fixed end. And as ongoing support across a running project, in which we remain available from planning through implementation to integration without taking over the implementation ourselves. Both can be commissioned even if your software comes from another provider or is developed in house.
The comparison that has applied here since 2003
With a building, nobody would even consider it.
Nobody has an office building erected by asking bricklayers and electricians simply to start. There is a plan that brings together structural engineering, service routes and use, and that plan is made before the first load of concrete arrives. It costs a fraction of the build and prevents the mistakes that can no longer be corrected once the shell is standing.
With software the same step is regularly skipped, because the construction is invisible. You cannot tell from a running system whether it is built to carry load. You only notice when another area is to be added and the structure does not cooperate.
The difference from a building is treacherous: a poor software architecture does not collapse. It simply becomes a little more expensive every year, and because the increase creeps in, it is booked as normal growth.
How you recognise that the architecture is holding you back.
All four signs can be recalculated from your own effort figures.
- Sign 1
- Every change takes longer than the last. The effort for comparable requirements rises over the years. That is the most reliable sign, because you can read it in your own effort figures.
- Sign 2
- Small changes force large tests. An adjustment in one place makes a full test run necessary, because nobody can rule out what else is affected. The testing costs then regularly exceed the development costs.
- Sign 3
- The same information sits in several places. Customer master data, prices or stock levels are maintained in several systems and drift apart. Reconciliation happens through a nightly batch run, through a spreadsheet or not at all.
- Sign 4
- New projects fail at the connection. A portal, a report or an AI application is undisputed in business terms and still cannot be implemented, because the data does not come out in a usable form.
These signs are measurable, and that is exactly where their value for the internal discussion lies. You do not have to convince anyone of a feeling if you place the effort figures for comparable requirements from three years side by side. If the curve rises, there is a cause in the structure, and the structure can be changed.
Who carries out the review
The architect carries out the review himself.
The review is carried out personally by Walter Raboch, managing director and software architect. He founded ingen in 2003 and has since been responsible for projects for mid-sized companies, corporate groups and public sector clients, from planning through implementation to integration into grown landscapes.
That is the difference that matters for this service: you speak with the person who produces the assessment, not with a sales department that passes it on to a team afterwards. Follow-up questions about a recommendation are answered by the same person who made it, even two years later.
Someone who has built systems for more than twenty years that are still running today judges a design differently from someone who only knows the construction phase. The questions that come first rarely concern the technology. They concern operations: who keeps this running in five years, and how do they notice when something is wrong?
Managing director and software architect
The architecture review as a defined service.
Not open-ended consulting billed by the hour, but an assignment with a fixed scope, a fixed result and a fixed end.
- Subject
- An existing system, a planned new build or the architecture of a running project that has stalled. A legacy system is no precondition. The most common occasion is a decision with long lasting effect: a new development, a replacement, a further connection.
- Duration
- For a mid-sized system, two to four weeks from the point at which the documents are provided. Your own effort amounts to about two or three meetings of two hours each.
- Basis
- Source code, data model, interface overview, operating environment and conversations with the people who use and maintain the system every day.
- Result
- A written set of findings: the load bearing structure, risks ordered by impact, recommendations with effort classes and a reasoned sequence for the next twelve months.
- Presentation
- A presentation of the findings for management and IT leadership together, in language that both sides can check.
- Not included
- Implementation. The review assesses and recommends, it does not build. The separation is deliberate.
A review is therefore a completed piece of work with a beginning and an end. You know in advance what it costs, how long it takes and what will be on the table at the end. For procurement offices and for management teams that have to justify an expense, that is precisely the decisive difference from consulting billed by the hour.
What happens afterwards.
The findings belong to you, in full and without restriction. They are written so that another provider can implement them as well: no internal shorthand, no references to tools only we can operate, no passages that force a follow-up contract.
That is the condition under which the assessment stays independent. A review is billed the same here whether or not a follow-up contract comes out of it. If the right recommendation is to leave the existing system alone or to buy a standard product, then that is what the findings say.
A review is often followed by a step by step replacement of the existing system. That replacement then begins with an assessment which builds on the findings instead of repeating them: the review says whether and in which direction, the assessment says which of the four paths carries the specific legacy system and where the first cut lies. Just as often nothing follows at first, because the result reads: the structure holds, the pain lies elsewhere. Both are useful results for the price of a review.
If an implementation does follow, the findings are at the same time the basis for the tender. You can present them to providers and receive offers that can be compared, because all of them price the same scope. That is rare with software projects and a good part of the value a review delivers beyond the assessment itself.
Frequently asked questions about architecture consulting.
The questions that are regularly asked before a contract is placed.
What exactly does an architecture review deliver?
A written set of findings. It states the load bearing structure of the system, the risks ordered by their impact, recommendations with effort classes and a reasoned sequence for the next twelve months. In addition there is a presentation for management and IT leadership together. The findings are written so that another provider can implement them as well.
Is a review worthwhile for small systems too?
It is worthwhile whenever a decision with long lasting effect is due: a new development, a replacement, a connection to a further system. For an application with few users and no connections, a full review is usually too large. In those cases a single meeting is often enough, and we say so beforehand.
What does an architecture review cost?
The price depends on the size and age of the system and on how much documentation exists. Because the assignment has a fixed scope and a fixed end, we name a fixed price before the contract is placed rather than an open-ended hourly budget. You learn the order of magnitude in the initial consultation, without having to hand over any documents.
Are you independent if you offer the implementation afterwards?
Review and implementation are separate assignments, and the review is complete without the implementation. The findings are free to conclude that nothing needs doing or that a standard product would be the better choice. You can also present them to any other provider, because they contain no passages that only we could implement.
Who carries out the review?
Walter Raboch, managing director and software architect, personally. He founded ingen in 2003 and has since been responsible for projects for mid-sized companies, corporate groups and public sector clients. So you speak with the person who produces the assessment, not with a sales department.
How much time do we have to contribute ourselves?
Expect two or three meetings of two hours each, plus providing the source code, data model and interface overview. One person from IT and one person from the business side should take part, because many risks only become visible when the two views are compared.
When do I need a legacy assessment instead?
When the system to be replaced is already settled and the decision to modernise has been taken in principle. The question of whether the structure carries load is then already answered, and what remains open is which of the four replacement paths is right for this system and where the first cut lies. That is what the assessment on the legacy modernisation page answers, and for it we go deeper into the data model and the nightly jobs. The review is the stage before: it assesses the structure, orders the risks and sets a sequence for twelve months, including for systems that will never be replaced.
Have the plan reviewed.
A review is a defined service with a fixed end and a result that belongs to you. In the initial consultation we clarify within half an hour whether the effort is worthwhile for your system.
