The term “Digital Transformation” has become more than just a buzzword as companies continuously work toward the goal of realigning and investing in the digitization of all business aspects to meet and predict customer demands. In the midst of these big changes, there has been much confusion about what it means to actually achieve digital transformation and how to monitor your progression through each stage of the transition.
As it turns out, plenty.
Recently, the U.S. government has implemented healthcare reimbursements based on the outcome of medical treatments, rather than a traditional fee-for-service approach. These performance-based programs are designed to improve healthcare quality while lowering treatment cost. It’s this outcomes-based approach that Fortune 500 companies are considering as a way of reducing ADM costs while improving software quality.
For Jay Ferro, CIO of the American Cancer Society, his employer’s mission hits far closer to home than those of most others in his position. The father of three boys, Ferro lost his 36-year-old wife, Priscilla, to cervical cancer in January 2007. In her memory, he founded Priscilla’s Promise, a non-profit organization that brings greater awareness to cervical cancer.
Inspired by his personal experience with the disease, Ferro joined ACS as CIO in 2012 with the mission of applying his abilities as a savvy technology leader who understands how to apply IT solutions to achieve business goals. He was driven to ensure that in addition to supporting the organization’s infrastructure, IT also furthered its causes.
In a merger, integrating company names is hard enough — imagine having to integrate massive application portfolios?
As the Justice Department and the FCC evaluate the proposed merger between corporate behemoths Time Warner Cable and Comcast, I wonder if the C-suite at both companies are investing as much time evaluating the health and security of one another’s application portfolio. Historically, technical due diligence has lagged greatly behind the financial due diligence.
The CAST Application Risk Analytics Launch Party which took place at the Art Directors Club last Wednesday, April 23, in the heart of Manhattan was a success. CAST has captured these memorable moments and posted the pictures from the Event Here!
It seems like every three months there is a new mobile device that changes everything. New operating systems, from Windows 8, Blackberry 10, and Android’s Jellybean, come out once a year with updated interfaces and features. Even new programming languages are starting to pop-up. But now we’re finding that some of the stuff we built 5 years ago is still pretty good, and maybe just need a UI facelift, mobile app, or delivery method. But remember, it shouldn’t be about the fanciest, shiniest toy (even if they are nice to have). It should be about delivering relevant tools to the business, which can be accessed everywhere and can talk to everything.
Gone are the days when the VP of IT at a midmarket bank would tell his application owner to hire a consulting firm to build a new website for the Mortgage division that includes a simple mortgage calculator, a contact page, and little else. Today that same business unit is asking for a website, smartphone app, blog, data warehouse, and SEO solutions. Oh, and don’t forget about social networking tools! And to top it all off, all of these things must interface with current legacy systems.
All the app owner hears is design, API, WebService, infrastructure, QA, resources, maintenance, and above all else, COST, COST, and maybe a little more COST. Yet the Finance department is telling the VP to reduce, reuse, and outsource or offshore.
So now what? This is where Application Portfolio Management (APM) comes in. With relevant, objective facts, IT managers can develop the transparency needed to meet the requirements of the business while making smart resource investments in comparison to the cost of the application’s maintenance and operations.
We are hosting a webinar this Thursday, April 11th with Phil Murphy, a highly regarded research executive at Forrester Research, to explain a tactical approach to APM that can bring the necessary transparency to your application portfolio so you can develop trust with business leaders and apply resources more strategically.
Perhaps you have tried APM initiatives before, and didn’t find enough value for the effort put in. But IT managers who are good practitioners of APM look at the business goals behind the needs of the organization and use the concept of portfolio management to their advantage. They gather information about each application — which is not limited to lines of code or types of technologies — and use that transparency to understand the cost of building and maintaining the application.
This transparency comes from the ability to identify and eliminate redundant applications or applications not structurally sound enough to support the needs of the business, by providing objective metrics on the stability, quality, and maintainability of the applications. As a result, you can compare those factors against business value to allocate resources accordingly, define strategic planning efforts, and diffuse the inherit conflict between business leaders and IT departments.
Does your organization have an initiative to inventory its entire application portfolio? Do you think it should? Then make sure to join our discussion with Forrester Research executive Phil Murphy this Thursday.
Unless you’ve been living under a rock or in a similar media black hole the last few years, you know that the U.S. debt ceiling debate has created a global financial panic. In all likelihood, your debt ceiling isn’t getting the same press as the national debt, but maybe it should.
We all know that the cost to maintain legacy applications prevents you from investing in new projects and as systems age their cost only increases. What you may not be paying attention to is the growth of your portfolio’s technical debt and how it may be adding to this funding gap.
What is YOUR technical debt ceiling? In other words, how much technical debt can you stomach?
The best way to start this discussion is to acknowledge that you have technical debt.
Step 1: “Hello, my name is Peter and I have technical debt.”
All legacy and new systems have it. Every time we fix a bug or add new functionality we are adding technical debt. According to Capers Jones, “Roughly 7 percent of all defect repairs will contain a new defect that was not there before. For very complex and poorly structured applications, these bad fix injections have topped 20%.” So accept it and move forward.
Step 2: Determine how much technical debt you currently have
You need to understand your portfolio in context to the business, cost, value and risk in each application. You may already be ahead of the pack and have a repeatable, objective application portfolio management process in place. Or if you are like most organizations, you have never been able to find the time or funding for it. APM solutions can be extremely effective when funded and implemented properly. However, expensive enterprise APM solutions are not necessary to get started. Your company is already collecting key information about the applications within the portfolio and there are sources to help determine technical debt. There are also light-weight APM tools that are designed to be fast and affordable, while providing the APM data you need.
You may also realize that APM solutions don’t calculate technical debt. Most provide some application analytics such as size measures and quality assessments. These are typically rolled up into a pseudo-quantitative index that attempts to express technical risk. Wouldn’t it be much more impactful to monetize that risk? Expressing in financial terms how much risk is present in an application and/or a portfolio may be the only way to get some people’s attention.
So, to determine how much technical debt you have, you need an objective, repeatable, affordable, light-weight solution that quantifies technical risk.
Step 3: Determine your technical debt ceiling
It’s not realistic to think that you can eliminate all technical debt. But now that you have an idea of what debt you have and where it exists at least you can hold the discussion about how much debt you can handle.
Armed with a better understanding of your portfolio’s existing state in financial terms, you are now able to determine if you are near an uncomfortable level of risk. The appropriate level of risk varies by business; I can’t help you with that. What you do have is a quantification of the risk in the systems you currently manage coupled with the capability and value those systems provide.
You are now able to look for redundancy, high cost/low value, legacy technology and situations that cost you precious time and money – in other words, applications with high technical debt.
Now that you have an idea of how much technical debt you have and better yet where it is, you can actually have a rational portfolio rationalization discussion. Application Portfolio Rationalization quantitatively measures each project along four dimensions, business value, cost, risk and technology. Effective rationalization enables you to select the initiatives with high business and technology value, and low cost and risk. By selecting the best transformation projects, you can consolidate applications and modernize infrastructure, ultimately freeing up resources to be re-invested in the organization, rather than keeping-the-lights-on work.
Step 4: Rinse and repeat
As with most processes worth doing, this is never a one-shot deal. As I mentioned at the start of this post, we are constantly adding technical debt to our systems and hopefully, we are also removing some. So it’s a moving target that requires ongoing assessment and monitoring to insure you are moving in the right direction. What you need to support this process is to find ways to educate your organization about technical debt, find automated ways to identify and track it, and then modify your existing funding processes to incorporate this data into its decision-making process.