Master Data and Façades
Lots of Master Data is locked in legacy systems. We need a migration path to release the data.
This post is eleventh part in a series about building and adopting a modern streaming data integration platform. In this post I will discuss how to think about development and maintenance costs in various parts of the architecture.
As a rule of thumb, maintenance may take up to 80% of the total cost of applications during its life cycle 1. In practice, the actual percentage depends heavily on many things, especially on the life cycle of the system.
Customer-facing web and mobile applications might even need a rewrite every five years, just due to the technological progress. There are web frameworks du jour, and if you are using outdated technology, it is difficult to attract and keep talent, sometimes even consultants. It may also be important that customer-facing applications have a modern feel. Core business systems on the other hand have much longer life cycle. In some industries thirty years is a typical life span for a core business system. Data may need to be stored for even longer, even 100 years.
Regardless of how software development is budgeted in practice, business people often mentally make a difference between capital and operational expenses (CapEx and OpEx). If you look at things from high enough vantage point, the maintenance costs are usually operational expenses, because they are about keeping the current business running, not investment in the new growth. Of course the line is drawn in sand.
The two diagrams above show how the cost of the initial investment plays more significant role for systems that have short life cycle (5 years) than for systems that have a longer life cycle (10+ years). The difference becomes even more dramatic when the systems have a really long life cycle (30+ years).
The practical consequence is that often you should optimize development costs in customer-facing applications and operation and maintenance costs in core business systems. It often makes sense to take this into account when organizing the development efforts. This often has an impact on technology choice as well.
To keep the application development costs low, the application development should be as easy and fast as possible. This means that much of the implementation logic should reside on the core system side. We can call these core systems “the platform”, and should have an corresponding platform API to support the development of applications. The platform API should be of high quality and well-productized.
If you need consulting related to system architectures in general, or data integrations in particular, please do not hesitate to contact Mikko Ahonen through the contact page.
Jeff Hanby at Lookfar blog has collected some estimates about the maintenance costs from research (Daniel D. Galorath — 75%, Stephen R. Schach — 67%, Thomas M. Pigoski — >80%, Robert L. Glass — 40% — 80%, Jussi Koskinen — >90%) ↩