REF·0481 / ENTERPRISE ARCHITECTURE TARGET STATE · PATH TO GREEN
Enterprise Architecture & IT Turnaround Advisory

Don’t let your IT cost you the deal.

Technology that holds up in due diligence.

Buyers, boards and deal teams all go through the systems, and the price moves on what they find. I look first, independently, and fix what they would find.

ISelling or buying a companyKnow what the other side will find before they find it. IIPE portfolio or post-mergerFind out what you bought, what it costs, and what to switch off. IIICTO needing senior architectureA few days a week on the decisions too large to get wrong.
Get a second opinion Take the Risk Assessment
AUDIT · RATIONALIZE · REMEDIATE · GOVERN SCHONING.COM
Why it keeps happening

The problems that cost you the deal are usually in the architecture, and only rarely in the software itself.

Whether you are selling, integrating an acquisition or watching a transformation slow down, the developers, the vendor or the integrator are usually the first to be blamed and rarely the root cause. The root cause is nearly always how the systems, the data and the teams were put together in the first place.

Another integrator will not fix this, because they get paid to build more. You need somebody independent to look at the whole landscape, say plainly what is costing money for no return, and design something you can run, scale and hand over.

What a buyer’s advisors will find FINDINGS · 04
  • You are paying license and support fees for several applications that essentially do the same thing.
  • Decades of business logic sits in one system that only one or two people still understand.
  • Customer and financial data lives in places nobody has fully mapped, which becomes a due diligence question very quickly.
  • Several key contracts are in the owner’s name or cannot be transferred with the company.
What the board is being told, and what is actually true FINDINGS · 04
  • Two or three systems integrators are each blaming the other for the delays.
  • Decisions about systems are being made for political reasons rather than technical ones.
  • The transformation reports green every month and has not shipped anything a customer can see in a year.
  • AI projects are being started without any governance, which in a regulated business is a compliance problem waiting to happen.

Not sure how bad it actually is? The Technology Risk Assessment takes about ten minutes and gives you a score across architecture, governance and delivery. It is free, and you can bring the result along to our first conversation.

Take the Risk Assessment
The Practice

What I do

These are the three ways I work on the problem above, and each one lines up with one of the situations at the top of the page.

I

Enterprise Turnarounds & M&A Restructuring

For PE-backed companies, post-merger integrations and IT landscapes that have got out of hand.

  • Enterprise IT Landscape Turnaround: A structured review of an IT landscape that has grown beyond what anyone can explain, usually after several acquisitions. The main output is an application rationalization list, i.e. which systems to keep, which to merge and which to switch off, together with what each of those decisions saves in run costs.

  • Post-Acquisition Architecture Debt Diagnostic: A 14 to 21 day audit of a newly acquired company’s systems, so that you know about the legacy risks and hidden costs before they turn up in the exit valuation rather than after.

Assess the landscape risk
II

"Red Project" Rescue & Risk Diagnostics

For transformations that have stalled, cloud migrations and legacy system retirements.

  • "Red Project" Architecture Rescue: For projects that are well over budget or have essentially stopped moving. I put a hold on further architecture changes, find out what is actually wrong (it is usually two or three things, not twenty), and then agree a remediation plan that the teams and the vendors are held to.

  • Legacy Logic Preservation (COBOL/Mainframe): Before a mainframe is switched off, somebody has to work out what business rules are hidden in it, because after 30 or 40 years there are generally quite a few that nobody has written down. I assess that risk and design a modernization approach where the new system produces the same outputs as the old one.

  • AI Architecture Risk Audit: A review of AI initiatives before they go into production in a regulated environment, looking at hallucination, data leakage and compliance risks. Keep in mind that most of these risks are cheap to fix before go-live and very expensive afterwards.

Score the project’s risk
III

Fractional Enterprise Architecture & Interim Leadership

For CTOs who need a senior architect a few days a week, and for organizations that have grown faster than their IT governance.

  • Fractional Enterprise Architect: I work alongside you as your architect for two or three days a week, usually for six to twelve months, so that the large decisions (platform choices, integration approach, what to retire and when) get a senior opinion without you adding a permanent head to the payroll. Keep in mind this only works if you actually let me into the decisions; a fractional architect who is consulted afterwards is not much use to you.

  • Interim Chief Architect: I lead your architecture practice for a fixed period, typically six to twelve months, put proper governance in place and stabilize the projects already in flight, while you take the time to find the right permanent hire.

  • EA Repository & Governance Implementation: Most organizations have their architecture spread across dozens of diagrams that disagree with each other. I set up a single repository, define the metamodel, establish an Architecture Review Board and introduce stage gates, so that future IT spend has to pass a review before it happens.

Score your governance risk
IV

Sale Readiness & Transferability

For owner-led businesses that are 6 to 24 months away from a sale or succession, and for the brokers, exit planners and accountants who advise them. A buyer will look at how dependent the business is on you, how well the processes are documented and what state the systems and data are in, so I help you find those issues first and fix the ones that are actually worth fixing before you go to market. Generally that is a shorter list than people expect.

Explore Sale Readiness Take the Sale Readiness Assessment USA + GERMANY · AUCH AUF DEUTSCH
The Methodology

How an engagement usually runs

I work in fixed, time-boxed stages with a defined output at the end of each one, so you know fairly early what you are dealing with and can stop after any stage if you want to.

SEQUENCE · 01 → 03
01 Days 1–14

Systemic Triage

I look at the architecture, the legacy systems and the projects in flight, and I talk to the people doing the work rather than only to their managers, because that is usually where the real picture is. At the end of two weeks you get a list of the critical failure points and of where money is being lost right now.

02 Days 15–30

The Rationalization Blueprint

This is the plan, and it is specific: which systems to switch off and when, which legacy platforms to leave alone for now but ring-fence, and how the vendor integrations need to be restructured. Also what each of those decisions costs and saves, so the board can make the trade-offs with real numbers.

03 Ongoing

Execution & Governance

A plan on its own changes nothing, so in most engagements I stay on as interim chief architect to see it through. That means holding internal teams and external vendors to the blueprint, and being the person who says no to keeping an old system alive just because somebody is attached to it.

Franz Schöning, Principal Enterprise Architect
PRINCIPAL · ENTERPRISE ARCHITECT
About the Architect

Franz Schöning

Principal Enterprise Architect & Turnaround Advisor

I have spent several decades in enterprise IT, most of it in regulated financial systems, enterprise Java and COBOL/mainframe modernization, and more recently in AI governance. These days I mostly advise CIOs, CTOs and Private Equity operating partners.

The work I get called in for is usually the awkward kind, e.g. systems that have to be merged after an acquisition, transformations that have stalled, or legacy logic that has to be modernized without breaking the business that runs on it.

I am comfortable in the boardroom and in the code, and having done both for a long time I know that the gap between the two is where most of the expensive mistakes are made. If your problem is not on this page, I will tell you so in the first conversation and, where I can, point you to somebody better suited.

Engagement

If any of this sounds familiar, let us talk.

The first call is confidential and there is no charge for it. Tell me what is not working and I will tell you what I would look at first, and whether I am the right person for it.