"Futureproof" is an interesting term. A lot depends on what you mean by it.
In reality, there's no such thing.
Architectures and technologies evolve, become deprecated, get replaced by newer iterations or simply better versions. Possibly more significant than that, vendors develop new products and new versions of products, which have different platform requirements, and stop supporting old ones. Operational skills evolve and older skills become scarce (e.g. COBOL). When you implement a commercial product, its future is limited from the day you install it. Bear in mind a lot of platforms have artificial lifetime limitations based on licences, support contracts, and commercial costs.
Obviously there are things you can do to mitigate this, but there are no magic bullets. The only approach that really works is a long-term plan that understands the status of the platform and which includes plans (and budget) for platform changes, upgrades and migrations. That may include significant "fork-lift" upgrades of parts of the platform at some point in the future. If you have done it right, that should be at least 5-10 years away.
The absolute worst thing you can do with any platform is to assume that what you have is "futureproof", and to not plan for upgrades and changes. In that way, any platform will "rot" and is likely to become an operational burden. It is also more likely to require a complete change out at some point.
This may all seem obvious but, in my experience, actually doing this is rare, because businesses don't understand the life-cycle of IT and just see it as an unnecessary cost to the business.
Other things I would recommend you should consider: look at "Cloud" technologies. By this I'm talking about things like Openstack, Kubernetes, and microservices. These are designed to support development of flexible services on low-cost commodity hardware. You can either deploy the hardware stack yourself, use an external private or public cloud provider or, if you've done it well, use a mixture of these as the needs of the business dictate. This gives you massive flexibility in terms of platform suppliers as you can, relatively easily, move services between platforms (whether that is hardware vendors, or commercial cloud providers).
The bad news is, if you are looking at commercial solutions, there aren't many which will run natively in such an environment, although there's a great many that will.
Note that such an environment will have a design and operational requirement which is, IMO, best served by building an small in-house team of experts who are responsible for the design, and the ongoing strategy including platform upgrades and changes. This fits in with my statements above. IMO this really can't easily be outsourced as almost all of the places you could outsource this sort of thing really aren't very good at it in the long term (I say this having worked with and for such companies).
The big advantage of your own in-house team is it gives you the opportunity to use more Open Source in your stack. This has the advantage that the support is down to you.
This may sound like a disadvantage, but it really isn't: if you want to continue supporting and patching an older version of an application and have the in-house skills, you can choose to do so and it's not really going to cost you anything; if you want to trial the latest version of something, you can do so without having to purchase or negotiate licences, and without having salesmen hassling you; if something isn't quite working the way you want, you can make changes yourself (or sponsor a change) and it will happen far more quickly and cost far less than trying to get changes made to a commercial system.
And, as a final note, the biggest thing you can do to extend the life of your IT architecture: do not sign any Enterprise wide IT deals.
The commercial people love these because they look good on their CVs and often drive their bonuses, but the reality is these are harmful to the business: they lock you into a vendor who can never 100% meet your IT needs (if you are lucky they might meet 30-40%) and the rest gets done badly if at all. The best approach is to have a skilled and knowledgeable technical team who can chose from multiple suppliers and who can mix and match technologies and vendors as they develop and evolve the architecture.
Best of luck,
Keith
------------------------------
Keith Milner
Superlative Solutions Ltd.
------------------------------
Original Message:
Sent: Dec 28, 2018 06:19
From: Stefano Gufi
Subject: Modelling a future proof OSS Physical Inventory
Hy,
i'm working on a large OSS Transformation to provide future proof capabilities and service. We're migration the legacy physical inventory to a brand new inventory ( Physical equipment hierarchy, cableing, Outside Plant Infrastructure, geographic places, etc).
Which's in your opioning best model for the physical resources hirarchies? Do you know best practices, standards can help me?
Thanks in advance
#TMForumGeneral
------------------------------
Stefano Gufi
Accenture
------------------------------