If a journalist makes a new R bucket in the wooded realm of internet media, should it make a sound?
It’s worth noting that the Gartner R Bucket definitions are a moving target. Three years ago, Gartner had five R Buckets, today they recognize more than 12.
Virtual Clarity/DSE hold our definitions constant for purposes of consistency. Gartner change their definitions constantly because they are a media publisher and need to appear to be constantly generating 'fresh' content.
We use four standard R Buckets because they represent immutable points of assessment which are not impacted by nuance. So what exactly is an 'R Bucket'?
Sometime referred to as a 'migration treatment', a 'disposition', a 'migration strategy', R Buckets represent the colloquial short hand to categorize the kind of work being performed on an Asset as part of a migration or transformation program.
In the old days (basically anytime prior to about five years ago), everyone created their own labels to describe the various degrees of effort across a wide spectrum. Customer and Service Providers might talk about: Replatforms, Rearchitect, Retain, Retire, Rebuild, Revise, Rehost, and lots of other permutations of labels used to describe work. Many of these labels didn’t even start with R - but why does that matter?
Establishing a common lexicon to describe migration-oriented effort being performed on an Asset against a Placement option is key - but wait! What is an Asset and what is a Placement option? Rewind!
Migrations and transformations can generally be described using three important variables:
* Asset – a noun, represents the object in consideration for migration
* Placement – a noun, the target location for the Asset post-migration, often referred to as landing zones. Placements can be places, like AWS or Azure, but Placements can also represent virtual constructions defined to establish an operational state e.g. Containerization
* Treatment – a verb, a Treatment describes the work being done on an Asset to migrate or transform the Asset as required to achieve a state of compatibility with the target Placement. R Buckets are the shorthand labels for Treatments
When assessing large portfolios of Assets for fitment into future state landing zones, it is essential to codify Placement and Treatments in basic, intrinsic forms that are free from nuance, inferred knowledge and subjectivity. But what does that mean ?
When performing large scale assessments against the portfolio of Assets, variables need to be defined in such a way as to enable programmatic evaluation. In other words, let algorithms do the heavy lifting to achieve scale. Computers generally do not express opinions and are not good at subjective evaluations based on inferred knowledge. Computers do what they are told - so how do we tell a computer to evaluate a portfolio of Assets against Placement options in a form that enables the production of Treatment categorization? We start with building a stack of Treatments that are logical. Wishes, dreams, hopes and favorites are not logical things. Can and Can’t are logical. Want and Should are not logical
Rehost – the Asset is 100% compatible with the EA Standards used to define the target landing zone (Placement)
Refactor – the Asset has a current state dependency on an operating system version that does not meet the EA Standards of the target landing zone, and must be upgraded during migration
Revise – the Asset has hard-coded IP Addresses in the source code, and these hard-coded addresses must be removed during the migration
This is where things can get complicated, unless we are careful about how we codify various forms of subjectivity:
Rebuilds live in a world of hopes and dreams, but sometimes have humbler beginnings. Because our goal is to assess large portfolios efficiently, accurately and in a standardized way, we must disentangle the objectivity from the subjectivity.
Objectivity = can/can’t
Subjectivity = want/should/hope/dream/wish
Therefore, Force Rebuild = can’t/can’t
The Asset currently runs on Solaris and is required to migrate to a windows containerized landing zone
The Asset should employ a microservices aligned containerization architecture
The computer understand that Solaris is not compatible with a windows container = forced rebuild
The computer does not understand why a microservices architecture is required to achieve containerization…decomposing an Asset into microservices is not an inherent requirement to containerization
So how many R Buckets do I really need? And should they change? Why does Gartner list 12 or more? How do we all speak a common language? How do I keep my sanity over time? How do I stay current? Am I still cool if my R bucket definitions have not changed in two years? Do hipsters dream of new R buckets from over-priced lofts in Brooklyn? Why do I have so many questions?
Back to basics. Not changing is cool. Find strength in conviction. Use a Sharpie.
- R bucket definitions need to start with immutable truths
- Yes/No and binary evaluations will keep you free from subjectivity, inference and arguments
- Build a foundation on codified objectivity
- Decompose wishes/desires/hopes/dreams into statements of fact
- R Bucket definitions should be allowed to recursively mature and harden, but not proliferate
- The application is entirely compatible with the target landing zone and can be migrated with only configuration changes.
Example: The application is 100% compatible with the target landing zone.
Example: Running RedHat 6.5 and requires upgrading to RedHat 7.4.
Example: Removal of hard code IP/configurations
Example: Solaris, AIX
Example: Decompose application into SOA compliant components to take advantage of containers.
The answer is four. You need four R Buckets to assess any portfolio of Assets against any number of Placements. Trust me. Your Migration Factory friends will thank you.