In base allo stato cliente, dal tuo account Red Hat puoi accedere al profilo personale, alle preferenze e ai seguenti servizi:
Non ti sei ancora registrato? Ecco alcuni motivi per cui ti consigliamo di registrarti:
- Per poter consultare gli articoli della Knowledgebase, gestire i casi con il supporto tecnico e le sottoscrizioni, scaricare gli aggiornamenti e altro ancora da un'unica posizione.
- Per poter visualizzare gli utenti all'interno dell'azienda e modificarne le informazioni di account, le preferenze e le autorizzazioni.
- Per poter gestire le tue certificazioni Red Hat, visualizzare la cronologia degli esami e scaricare logo e documenti relativi alle certificazioni.
In base allo stato cliente, dal tuo account Red Hat puoi accedere al profilo personale, alle preferenze e ad altri servizi.
Per tutelare la tua sicurezza, se stai usando i servizi Red Hat da un computer pubblico, assicurati di disconnetterti.Esegui il log out
As a Solution Architect I see my job as many things, from supporting customers in adopting Red Hat technology, educating organisations about using open source technologies and the benefits it brings, to thinking of ways to solve business challenges using technology and culture change. However, these are all generally in the space of "green field" app development. But what about all the systems keeping the business going today?
The challenges businesses face in dealing with these "legacy" systems are complex, multi-faceted, involve many teams, and often businesses face knowledge gaps in how everything works together.
In the public sector, where I work, this problem of legacy systems is arguably larger and more challenging, with the need for organisations to share information, outlined by things like Digital Service Standard. But, it’s worked that way for years, so why change it?
Because the old way of doing things may limit your ability to adapt. How do you expect your business to be agile, to adapt quickly and deliver quicker if you have old systems that are holding you back?
In the same way, if you were moving house, you wouldn’t do it without packing up things you need, organising it, throwing old things away and replacing where you need to.
If you’ve lived somewhere for 20 years, you’re bound to have accumulated a lot of stuff, some of which you hardly use, some of which you know needs to be replaced, and other stuff which you frankly don’t even know how you got or who uses it.
Now it’s time to sort it out because you do not want to take all of that to your shiny new house, just like you don’t want to take that old technology stack that’s unsupported and insecure to your new platform. You need to have a plan, and have the right tools and the right people in the right teams - you wouldn’t get your kids to pack up your fine china when moving house, bad things are bound to happen, so why get just anyone to look at a large scale app migration?
You would discuss the need to move house with your family, explore what needs you have, and understand what you want to bring with you (and what you can leave behind), right? Likewise you should do something like this when moving applications to a new platform.
Moving companies have their own processes to get you from your old house to your shiny new home. The same needs to be done for moving from legacy systems to your new platform, by using a standard, proven, modular, repeatable and pragmatic methodology: discover, design, deploy.
The discover phase is an initial look at the estate and application(s) to understand what the requirements are and discuss the target platform(s) and technologies being used. Here is where you simply start looking for your new home - how big does it need to be, where will it be located, how much will it cost you.
The complexity and any initial "red-flags" can be questioned and put forward for the design phase, where you’d work towards making the changes needed and running pilots for applications that may perhaps be more of a high risk or show any technical challenges.
When you move house, you work with experts to help you move from estate agents and solicitors to removal companies. You would do the same when migrating your applications - work with partners that will help you create a central knowledge-base with a view to migrating applications faster as you get closer to the deploy phase. Taking a phased approach so you understand clearly the risks and challenges in order to solve them for the whole migration and modernisation effort and not just one application, one business owner, or one team.
Whatever the challenge in terms of wanting to migrate and modernise, if the end goal is to move to a more open way of working using open source technology that allows your business and IT teams to work closer and be more agile and provide more value, be sure to make a plan to develop the right skills, use the right tools and arm your teams with the goal of collaboration and knowledge sharing as the road to success, whatever "success" means for you.
Moving house? Call a removal company. Moving apps? Create an application migration team based around experts.
About the author
As a solutions architect at Red Hat, Mustafa Musaji works with with large UK public sector customers in areas around cloud native software adoption and application migrations to the cloud. This involves the technical side of container adoption and orchestration--using tools like Kubernetes--as well as looking at the people and processes involved in using such technology.