Thoroughly Modern: Why You Need An IT Strategy And Roadmap
July 14, 2020 Timothy Prickett Morgan
(Sponsored Content) What makes a modernization project successful? Is it the right software and tools? Having the right people on the job? Completing the project on time and on budget? Some might argue that all of the above contribute to the overall success of these initiatives. But the experts at Fresche will tell you that building a comprehensive strategy and roadmap is the most important part. It’s the secret sauce that ensures that the project provides business value and that requirements are mapped out before you start. After all, failing to plan is planning to fail.
Businesses today are facing increasing pressure to improve IT agility, grow revenues, increase competitiveness, and enable new levels of customer satisfaction. A well-crafted and executed IBM i management and modernization strategy allows organizations to leverage their mission-critical RPG and COBOL applications while taking advantage of modern technologies. This approach enables businesses to better meet user demand, reduce costs, mitigate risk, and eliminate redundancy.
This week, I spoke to three of Fresche’s IT strategy experts – Chris Koppe, Nick Hampson, and Maxime Leclair – to get a better idea of why it’s so important to have a plan, and what the discovery process might look like for an organization.
Timothy Prickett Morgan: When your team engages with a customer, it is usually related to specific challenges that they are facing or specific objectives that they are trying to achieve. Can you tell us about why clients might come to you for IT strategy or discovery services?
Chris Koppe: Modernization means something different to everybody. It could be light modernization of the interface, code or database. It could also be transformational, getting to new languages like PHP and taking advantage of open source technologies. It could include new applications and technologies.
In some cases, these endeavors require a substantial investment of time, people, money and tools. Organizations typically want IT to produce a strong business case for their initiatives so they know upfront why they should invest and which activities might have to be deferred. Our conversations typically start around modernization and often transition to, “Is this supported? Do you need a business case for this? Do you want to build this out a bit more?”
There are a lot of questions about the how, and especially how much. The answer, as we all know in IT, is, it depends. It depends on what you want to do and what your end state is. It depends on how fast you want to do it. Each client’s journey of modernization is going to be unique but building out a plan helps the organization understand how much it’s going to cost, why they should fund it, and what value the business can expect.
These are the questions that lead to a need for some form of discovery analysis and planning, where we can build out a roadmap, budget and the business case. That’s what leads to these discovery engagements for us.
TPM: Do companies usually have a good idea in terms of what they want to do? Maybe they don’t know the how. By the time they have engaged with you, do they have a good sense and feel for what the modernization initiatives are that they want to choose, what applications they want to modernize?
Chris Koppe: Somewhere around 70 percent to 80 percent of the time, they have a pretty strong idea of what they want to do. Other times, when they don’t, they’re typically coming to us with the symptoms and the pain. They might have problems with agility. They might have problems getting resources. They don’t know if there are alternative solutions to finding resources and skills in the market.
When we have a conversation about what’s going on, we often expose that they’ve identified one of many symptoms but they just haven’t realized they’re there yet. It can start off with them knowing what they think they want to do, but we need to explore that and make sure that the right solution comes out in the approach.
TPM: There is a lot of talk around digital transformation, competitive capabilities, and so on. Is there anything else that people are looking at and what they discuss with you?
Chris Koppe: Sometimes. It’s not the predominant way that the conversation starts, because things like digital transformation initiatives are often thought of as things that can be built on the side. Systems of engagement and mobile applications and new websites can be built as new front ends to an IBM i system. However, most people don’t understand the repercussions of not treating the existing code base and trying to build digital transformation systems of engagement in front of a system that’s not prepared to work with it very well. It becomes brittle. You might have stability issues. You could have scalability issues.
Digital transformation becomes part of the expansion of thought process. The client says they want to modernize, and we dig into that. We might ask them, “What’s going on with digital in your company? How has COVID affected your business and how do you need to change and evolve? How does that affect you from a resource standpoint?” Even digital transformation requires a whole new set of skills. It requires mobile development skills, modern agile development skills, new technologies and platforms, potentially new web interfaces. All of these things make the ecosystem more complicated and further substantiates a need for a proper roadmap.
Nick Hampson: You could take it back to the definition of the word discovery: The act of finding something that has not been known before. I think that, to me, is absolutely key in what people think they want, when the reality of what they need to do in order to offers value to their business is typically dramatically different.
TPM: Chris, could you explain how the discovery typically starts, what the process is, and how you carry that out with the customer?
Chris Koppe: Most clients who engage in this process acknowledge that they need to build a strong business case and a roadmap. They need a detailed plan to sell it to the organization and defend the “why now” versus “five years from now.” Clients may start by looking at vendors tools, which is typical for an IBM i shop. They’re developers and they start by looking at technology. Instead, it’s important to look at what you need to do. What will the business support? What are the business’s ambitions? How does what we’re doing support those ambitions, enable them, drive them? Once you figure that out, then it’s time to look at how technology can help you. The roadmap and the business case should come first.
Once you do get this point, it’s helpful to have a strategist to guide you in this process. Part of this is strategy development for IT, but it’s also a strategy of IT for the business. It’s critical to engage at a business strategy and IT strategy level, at least to build the business case that’s predicated on a real business pain that the company is going to say, “Yes, I want to fund the fix of that problem.”
Strategy is important. It helps you answer some important questions: What problems are we fixing? How does this deliver a value to the company? How does it deliver value now and not after two years of heavy lifting? It’s the what and the how and the why, but then it’s also the roadmap. What is the approach? What is the sequence of activities and why is that sequence the right sequence for the business? When we do these discovery engagements, there’s a big part of it that’s around strategy development and roadmap development. What is the IT roadmap for modernization and for evolution, and how does that align directly to creating better business outcomes for the organization? A roadmap is a key part of strategy development and business case creation is central to this.
In the end, people want to know, how much? How much is very much predicated on what is the solution that’s ultimately coming together as we develop the strategy and we develop the roadmap. What is the technological solution? To find out how much, it’s two elements: What are we doing and how much of it do we have to do? There’s a quantity element. That brings in the second part of the discovery process, which is the forensic analysis of the code. We use sophisticated tools that expose the design patterns, quantify the complexity of systems and the data model. It’s gives us a detailed view of the entire system. We can even quickly scrape away the unused stuff.
Maxime Leclair: It also allows you to determine what will bring the most value. For example, if you aren’t using it, or you are only using it five percent of the time, maybe you don’t need to invest or transform those parts. The key thing is that we are aligning this strategic roadmap with the company’s business goals. Going through this exercise also gives us the ability to uncover business opportunities or operational risk. It could be one or many of them that you are trying to align with the strategic roadmap and trying to resolve. We focus on finding what will bring value for them.
TPM: Can you share what the sessions look like from a customer perspective?
Chris Koppe: The real meat in the discovery process are the collaborative workshops. There are a lot of different elements to explore, including the business, and there’s the system itself, how many apps and modules there are, how they’ve been written, how they’ve evolved over time, the health of the code base, the skills of the people, the state of the database, the future state we want to get to.
There are two elements in these workshops. One of them is education. We’re there to educate and facilitate strategy development. We’re not there to say, “Here’s your strategy. You do it.” We’re here to say, “Here’s all the things that are available, and these are the pros and cons of various approaches, technologies, and end states.” We’re bringing our experience to the table to share what clients typically do and what might be higher risk.
This flows into collaborative strategy development. Once the client understands what’s possible, then it’s about collaborating on what is the right thing for them to do. The workshops provide the means to explore, understand, educate, and collaborate on the roadmap. It provides the requirements from the client perspective and from the business perspective, and it provides the parameters around what this would need to look like in the end. Then we have work to do beyond that, where we evolve those requirements into a proper solution with a budget and a schedule. It helps the client feel comfortable that this is their plan, and they’re going to go to their executives and seek funding for it.
TPM: You said that every customer is different in how they invested in their IBM i applications over the years, everyone’s starting from a different spot with different goals coming from different industries. Can you talk about how you approach this?
Chris Koppe: We always look at the profiles of the people that we’re assigning in the engagement. Who has worked in that industry before? Who can add value to the client in the process? Then align the right team from our organization that has similar experiences or might be experts in those technologies.
Maxime Leclair: We always try to align the best resources that we have internally with the client’s business and industry. The goal is to be able to have a team up to speed and understand the customer, their system and their pains very quickly. If they already have a sense about market trends, or even the kind of issues that customer has in the past, we can provide a lot of value up front.
From time to time, we have insight that the customer is not already aware of. Regulations that are coming that might affect them. A good example is that we’ve done a lot of work with Financial institutions and Fintechs. This has given us great insight and first-hand knowledge about that space, requirements, trends, technologies being used and more. Doing this day in day out, our team gets exposed to so many different things. And, to be effective and bring the best value we can, we want to ensure that we are always on top of technologies, and have a good understanding of disruptions and trends happening in industries around the world so we can fill the gap and guide our clients.
TPM: We talked a little bit about the experience for the customer. Does the process always start with a discovery? Obviously having a strategy is key, but can you share anything, a customer perspective as to why they absolutely would want to start with this? I can see where companies might say, “Well, if we know where we want to go, why would we need to do a discovery?”
Chris Koppe: I wouldn’t say there is always a need for discovery. For large modernization initiatives, you should strongly consider proper analysis and scoping. But there are exceptions to that. There are companies that say, “Listen, we want to embark on this modernization, but we want to do it in an agile way.” They might need some help but they’re willing to develop it as they go and adjust accordingly.” It may start off with just launching into the project and doing the analysis while we’re doing work.
There are also smaller initiatives, where all you want to do is a UI reface. Our web development experts might do a discovery to scope that project but it’s less comprehensive.
Discoveries are defining the problem we are trying to solve for the client. People that want to invest in modernization understand it can be a substantial initiative, so they need to know how much so they can get organizational approval and funding for it. This is also where you need the measurements, and the strategy work, and roadmap work. Because just to say, “I want to transform to PHP, for example, from RPG.” That’s great but how much of it? And have you looked at PHP reference architectures? And how many apps do you have? And is there a sequence to this? Are you fixing the database problems along the way? And what are you doing with CL? Are you keeping all of that? Or is it better to do something else with it?”
There are a lot of things to explore about that future state and about how to best get to it. The minute people understand that it’s a journey that they have to map out, and that the price is predicated on the quantification, then they understand that it’s worth spending time on it.
Now, we customize these engagements for clients. We have a standard structure, but if a client says, “I don’t need all of that work. I don’t need all those deliverables. I don’t need such a sophisticated business case.” Or, “My needs are smaller or simpler,” then we tailor the engagement to the problems of the client and their needs. You don’t need to overdo it.
Maxime Leclair: As Chris mentioned, this is a journey. A CIO will often have one big digital transformation project in their career, and it’s important to do it right. Often, when we work with a customer that already knows what they want to do, it’s helpful to have an expert working alongside you to confirm your assumptions or point out a blind spot. Time after time, we see disconnects between IT and the business, where the discovery process re-aligns these groups.
TPM: What advice would you give to someone who isn’t sure about taking on a full IT strategy or discovery as part of their modernization initiatives?
Chris Koppe: We’ve had clients come to us and say they’re going to take the discovery on themselves, only to come back a year later after trying to figure it out on their own. They could be missing some key elements from their team or that broader experience. They might not have an IT department full of people that have done this before or experienced so many different contexts.
Other clients say “We know what we want to do. Let’s just go do it. We don’t need this discovery thing.” A year later, they are nowhere near where they thought they’d be because they didn’t properly access the effort involved. They might have struggled with it in-house. Maybe they didn’t know which tools were available that could have helped them accelerate. And maybe they simply didn’t make a realistic plan.
And then the business shut the project down because the time-to-market was too long or the costs had risen to an unsustainable level. If you don’t have the right plan and the plan is not based on actual experience and actual effort models, then the chances of being able to stick to the plan is low. That could kill your chance for modernization or staying on the platform. We’ve seen examples like that and it’s tough to see.
TPM: Any final words of advice? And Nick, you have been uncharacteristically quiet, so I am picking on you first here.
Nick Hampson: There’s a quote from Andy Grove of Intel: “Culture eats strategy for breakfast.” And I think where projects fail it is because the strategy is great, but the company won’t modernize their culture as they’re going to modernize their system.
So part of this modernization, and it’s a known thing in the digital transformation side, is that there will need to be some culture change. I think it’s something that people need to understand sometimes is, while we might give them the objectively best thing to do, they might need to kind of move a mile to get to where that is.
The value that comes from doing a strategy and planning session is clear. It’s easy to see how world events are forcing companies to look at where they are spending money and ensuring they are taking on strategic activities that are will bring value.
Fresche is hosting a limited number of free whiteboard sessions for organizations who are looking at upcoming modernization projects and want to have a preliminary strategy session to discuss their options. Organizations should jump on this offer while they can. Details and registration are available here.