Ignore the hype, but think about getting AI ready

Posted on By Mark Wilson

AI. AI. AI. It’s everywhere. And I’m sorry, this is another Artificial Intelligence post, but it’s more a “hold your horses” sort of post…

You see, yesterday, I was helping a colleague review slides for an upcoming AI presentation. He wanted to make sure he gets past the hype, but was suggesting we’re coming out of that phase now as we’re seeing some negative press about generative AI.

I disagreed. Generative AI in particular feels like it’s right at the peak of inflated expectations…

Why I think generative AI is at peak hype right now

I know Gartner is just one (albeit influential) analyst firm, and Hype Cycles aren’t everything, but their Hype Cycle for Emerging Technologies (Aug 2023) shows GenAI approaching the Peak of Inflated Expectations and 2-5 years from productivity.

I don’t have a Gartner subscription but the diagram is taken from an article by The Next Web (and also available directly from the Gartner website). Quoting the TNW article directly,

“Gartner’s warning echoed across our conversations with European tech insiders. In 2024, they expect a cautious and pragmatic approach to AI adoption.”

The Next Web: After a year of breathless hype, AI will face reality in 2024

Another source (which is freely available) is the Gartner Emerging Technologies and Trends Impact Radar for 2024. This contains several AI techs, but shows Generative AI starting to break through:

So what does that mean? To answer that question, we look at another Gartner resource – their Top 10 Strategic Technology Trends for 2024. There are several AI-related trends mentioned, but the TL;DR is that now is the time for strategic planning.

It’s time to get AI ready

Move fast and break things is an often-used phrase suggesting agility. But sometimes, breaking things is less than ideal. And moving fast is great – as long as you’re moving in the right direction.

It’s a good time to increase your awareness of trending technologies (including the democratisation of generative AI) and think about how they can provide benefit to your organisation. But don’t worry if you’re not implementing AI right now. You’re not the only one, despite what you might think from reading around.

To take one example, yes, Microsoft Copilot is huge. The productivity benefits could be significant. But consider your AI readiness before turning on features that could expose data and information that you didn’t even know was there. Think about:

  • AI Principles: How will your organisation use AI. What are your boundaries? Can you clearly articulate and have you articulated what you will (and will not) do with AI?
  • AI Ready: Data: This is a good opportunity to examine the data you have, what you use it for, and who can access it. Making sure your data is AI ready means that it is ethically governed, secure, free of bias and accurate.
  • AI Ready: Security: Understand and prepare for new attack vectors that AI makes possible. Create an acceptable use policy for public-facing generative AI products.

Then, when you’re AI Ready, you’ll be in a position to move fast, hopefully without breaking anything.

Featured image: generated with AI, in WordPress!

The 5 or 6 Rs of cloud transformation

Posted on By Mark Wilson
This content is 4 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few years ago, a couple of colleagues showed me something they had been working on – a “5 Rs” approach to classifying applications for cloud transformation. It was adopted for use in client engagements but I decided it needed to be extended – there was no “do nothing” option, so I added “Remain” as a 6th R.

I later discovered that my colleagues were not the first to come up with this model. When challenged, they maintained that it was an original idea (and I was convinced someone had stolen our IP when I saw it used by another IT services organisation!). Research suggests Gartner defined 5Rs in 2010 and both Microsoft and Amazon Web Services have since created their own variations (5Rs in the Microsoft Cloud Adoption Framework and 6Rs in Amazon Web Services’ Application Migration Strategies). I’m sure there are other variations too, but these are the main ones I come across.

For reference, this is the description of the 6Rs that we use where I work, at risual:

  • Replace (or repurchase) – with an equivalent software as a service (SaaS) application.
  • Rehost – move to IaaS (lift and shift). This is relatively fast, with minimal modification but won’t take advantage of cloud characteristics like auto-scaling.
  • Refactor (or replatform/revise) – decouple and move to PaaS. This may provide lower hosting and operational costs together with auto-scaling and high availability by default.
  • Redesign (or rebuild/rearchitect) – redevelop into a cloud-aware solution. For example, if a legacy application is providing good value but cannot be easily migrated, the application may be modernised by rebuilding it in the cloud. This is the most complicated approach and will involve creating a new architecture to add business value to the core application through the incorporation of additional cloud services.
  • Remain (or retain/revisit) – for those cases where the “do nothing” approach is appropriate although, even then, there may be optimisations that can be made to the way that the application service is provided.
  • Retire – for applications that have reached the end of their lifecycle and are no longer required.

Right now, I’m doing some work with a client who is looking at how to transform their IT estate and the 5/6Rs have come into play. To help my client, who is also working with both Microsoft and AWS, I needed to compare our version with Gartner’s, Microsoft’s and AWS’… and this is what I came up with:

risualGartnerMicrosoftAWSNotes
ReplaceReplaceReplaceRepurchaseWhilst AWS uses a different term, the approach is broadly similar – look to replace/repurchase existing solutions with a SaaS alternative: e.g. Office 365, Dynamics 365, Salesforce, WorkDay, etc.
RehostRehostRehostRehostAll are closely aligned in thinking – rehost is the “lift and shift” option – based on infrastructure as a service (IaaS) – which is generally straightforward from a technical perspective but may not deliver the same long term benefits as other cloud transformation methods.
RefactorRefactorRefactorReplatformRefactoring generally involves the adoption of PaaS – for example making use of particular cloud frameworks, application hosting or database services; however this may be at the expense of portability between clouds. The exception is AWS, which uses refactor in a slightly different context and replatform for what is referred to as “lift, tinker and shift”.
 Revise  Gartner’s revise relates to modifying existing code before refactoring or rehosting. risual, Microsoft and AWS would all consider this as part of the refactoring/replatforming.
RedesignRebuildRebuildRefactor/re-architect.Gartner defines rebuilding as moving to PaaS, rebuilding the solution and rearchitecting the application.

AWS groups its definition of refactoring and rearchitecting, although the definition of refactor is closer to Microsoft/Gartner’s rebuild – adding features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment (for example.
  Rearchitect Microsoft makes the distinction between rebuilding (creating a new cloud-native codebase) and rearchitecting (looking for cost and operational efficiencies in applications that are cloud-capable but not cloud-native) – for example migrating from a monolithic architecture to a serverless architecture.
Remain  Retain/revisitPerhaps because their application transformation strategies assume that there is always some transformation to be done, Gartner and Microsoft do not have a remain/retain option. This can be seen as the “do nothing” approach but, as AWS highlights, it’s really a revisit as the do nothing is a holding state.
Maybe the application will be deprecated soon – or was recently purchased/upgraded and so is not a priority for further investment. It is likely to be addressed by one of the other approaches at some point in future.
Retire  RetireSometimes, an application has outlived its usefulness – or just costs more to run than it delivers in value, and should be retired. Neither Gartner nor Microsoft recognise this within their 5Rs.

Whichever 5 or 6Rs approach you take, it can be a useful approach for categorising potential transformation opportunities and I’m often surprised exercise how it exposes services that are consuming resources, long after their usefulness has ended.