Sticking with an established legacy system or breaking away to new – an example conflating separate issues as if they were one
I recently received an information/insight request that I decided to respond to. The request I received read in part (here excerpting out two quotes that the writer appears to have see as connected):
“My programmer is trying to persuade me to move to .net from PHP. I have always disliked the idea because of the costs. But he’s trying none the less.” (Note: for in-house IT.)
“I have heard fantastic things about (a-blog-site). Is there a way I can import all my (another-blog-site) posts into it? Any kind of help would be really appreciated.” (Note: the second blog hosting site uses .net technology.)
And I saw several issues of more general interest and importance in that so I decided to respond here, as a blog posting, and starting that by making two points.
• The writer’s IT support staff might be putting choice of technology in use ahead of what it is being used for in advocating this change. That may or may not be a valid reason for making a change in which technology is deployed in-house.
• The writer, with this IT effort of persuasion in mind, is considering moving to a .net technology based blog site and if the only reason to make this switch is in what type of back-end technology is used by their blog platform site, this is probably not a good idea and even if this type of change would make sense in their own business’ IT systems.
I see this request note as mixing two (or more) fundamentally distinct sets of issues, and I have seen that type of blending a great many times over the years. So this posting is in fact largely about that and with this request for help as a particularly clear-cut example of a wider phenomenon.
Starting with the first half of that note, the writer’s business technology uses PHP now.
• What are they using it for and does it meet current and anticipated/high priority needs?
• What would this writer and their business seek to do that would not be easily/cost-effectively doable using PHP and what is the strategic priority for doing that? Note: this can mean doing new things, scaling up current activities or processes where quantitative change can in effect become qualitative for performance and maintenance, or both.
• Would a .net system cover all legacy and readily anticipated new needs?
• How time consuming and expensive would it be to port over to this new system and with what learning curves – for planning and carrying out that port, and for managing, maintaining and using the new systems?
• Would this simply trade one set of scalability and related issues and concerns for another?
• And if a PHP solution currently in place is in fact a growing problem in need of significant overhaul or replacement, is a move to .net or related even the right choice?
Would it make sense to prototype test a new approach on one application area to see how it works out, with the old system maintained in place until the new is validated? Would it make more sense to move from one standard, established technology solution to another, or would it make sense to try a newer and perhaps technologically disruptive innovation – a game changer? This becomes a particularly valid question when prototyping on a single functional area or application is tried, to get hands-on and in-house experience with the newer option and to see how it works for you with a real implementation.
Basically, I am outlining what by now for this blog should read as one of my more standard analytical approaches, designed to cover the issues so as to limit unpleasant surprises from gaps in planning and execution. Now I turn to the real ringer in the message that I was sent. How does that connect into a call for changing blog service providers, or for changing from one third party provider of any sort to a new one, where the technology they use is behind the scenes and largely invisible to the businesses that use their services as customers?
• If you are using a third party provider – here a blog platform, and they use an underlying technology in support of their site that cannot effectively support functionalities that you need, then their technology is an issue.
• Otherwise it is not.
• Note that information security and other support services are very important considerations here. So, as a made-up for this posting example, if you had reason to believe that PHP systems were more vulnerable to security breaches than .net systems, that could be a valid reason to make a move. That would certainly apply if you were concerned about securely retaining control over administrative rights and content of your blog with evidence that other customers of that blog site had lost control to hackers. (Note: this was a made-up example and I have no evidence that .net is intrinsically more secure than a well built and maintained PHP-based system.)
But for the most part, there is no real need for your technology and your third party provider’s technology systems to match in type, except to the degree that they need to communicate together for you to effectively use their services. That is probably not the case for a business’ IT systems and the systems deployed by the blog platform site that they host their business blog on. And in this, I am simply writing about same or different platforms and tools per se. It might or might not make sense for your systems to move to that new, cutting edge disruptive technology that is gathering tech-press hype. It might or might not make sense for your third party providers to do that, and as they review and follow through on the types of bullet point issues I listed towards the top of this posting. But those decision making processes will probably, or at least should probably be completely separate.
Do you like the blog template you have now? Can people open and use your blog and navigate around it with ease and do they do so? Do you find your admin tools and dashboard helpful and effective for meeting your needs? Do you get customer support if you encounter a problem with your blog? Ask questions like those and not about what underlying back-end technology your blog provider is using. And draw an effective, working distinction between what you do in-house and what the businesses you work with use.
As a final thought here, I acknowledge that the person who wrote me this note is not a technology expert or even necessarily all that comfortable working hands-on with information technology tools. I strongly suspect that they are at least a bit unsure of the distinction between .net as in the top internet domain and .net as in the Microsoft technology platform. But while this note offered a very simple set of separate issues to distinguish between, conflation of issues rarely fits so easy a pattern – even as this problem is common and in both technical and non-technical settings.
I gave a simple technology-based example here because this is one that a reader of this blog would in most cases immediately see through, for what it is. The real problem is where this type of conflation involves issues, problems and challenges that are less easily defined and analytically dissected, as is often the case where they involve complex strategic and/or operational planning and decision making. And you cannot always prototype test your alternatives on select test-case parts of your business.
Look for overarching assumptions that cannot be sustained when fully considered. Look for communications gaps and misunderstandings when working with others on this. And start out assuming that you might need to refine and even redefine the basic issues that you seek to address as you start planning to work on them.