Cloud – Are You Ready?

Today’s Challenges are Not the Same

Today’s plethora of technology advances with their bewildering cornucopia of choices, why would they be the same? Your company wasn’t born digital. How in the Sam Hill do you compete with those who were? Their speed and agility are simply staggering – the way they innovate the customer proposition keeps you awake at night. You must be thinking, “Oh, how I wish our firm had that ability.”

Is Cloud the Answer?

Let’s take a look…

You are facing hundreds, or maybe even thousands, of applications built at different times, in different languages, by different teams in different geographies to meet different goals. Yet, they all need to be evaluated before migration to the cloud can begin – but how do you do that? In addition to a profound understanding of your application portfolio, this often requires an equally deep knowledge of the existing infrastructure and the cloud resources that would replace existing FTEs, to name but two.

Here is a basic check list of the information required before making cloud-centric decisions. Note, that this information is required for each and every application that is on your cloud-candidate list (more on that later).

Portfolio-wide:

Do you have a complete up-to-date inventory of all applications? If you don’t, this in itself is daunting. A few years ago, I led a team of consultants for North America’s largest utility — it took us 6+ months, interviewing 400+ employees, uncovering 43 out-of-date incomplete lists to compile a master inventory — which had never existed prior. At one point, we had 50,000+ app-candidates with which we started the ardent task of deduping, removing junk (server names, project names, interfaces, websites – you name it…), before we validated approximately 1500 applications. 6 months x 10 consultants x 40 hours / week = a (very) large investment in one of their firm’s largest and most important assets – the inventory of applications. And you know something? The client admitted THE most important deliverable of the entire project was a simple, yet complete, inventory of their current state. He had realized they couldn’t move forward without it. Lesson learned: DON’T SKIP THIS STEP! Admittedly, it’s not very sexy, but it is mandatory.

What is the benefit of ‘on-demand access’ to an ‘elastic pool’ of shared computing assets — applications, servers, storage, networks? What, literally, does scaling up or down as needed on a pay-per-use basis get your firm? If you can’t quantify the benefit to the business, you shouldn’t proceed. Why would you?

Can you “quantify” these benefits that come from cloud?

  • Greater flexibility
  • Both hard & soft savings
  • Someone else manage your HW/SW, lowering risk
  • (Dramatic) reductions in support staff à more FTEs available to focus on value-add innovation
  • Efficiency – only pay for what you use, freeing up funding for additional investment
  • Reduced support costs via a platform for automated, self-service IT

Are you prepared to manage applications in the cloud? How so? What needs to change? How will you develop and test applications in the cloud? Should you outsource that as well? Can you envision how to connect your end-users to their applications once in the cloud?

The SO WHAT test:

  • Organizationally, are you prepared to share resources across the enterprise? Cloud will require you to do that. From a HR perspective, are your IT performance metrics extendable to include public providers? If no, what’s the effort to make them so? Should they be the same? What will be the impact on existing roles in your IT organizations? Will your employees deem this cloud-thing as a demotion? More effort on their part? Will they want more money? More training? Who will leave the organization? Why will they leave? Bottom line, you must prevent any migration to the cloud from becoming a demotivating influence to your current employees.
  • Your business may be adopting cloud ‘x-times faster’ than IT. Do you know why? Is it OK? Can you get both organization back on the same page? Should they even be on the same page? If yes, what’s the value to the enterprise?
  • IT core competency needs to shift from being (just) providers to being brokers. OK, we’ve all heard this, but does a relationship exist between your IT organization and operations to allow this to become reality? If it doesn’t, cloud certainly is not the solution to change the relationship.

Individual Applications:

Which applications are the ones that anyone within IT or the business feels needs to be retired in the next 2-3 years? Obviously, these applications shouldn’t be considered cloud candidates. Cloud isn’t the solution for all applications. Do you have a method to breakdown your inventory into two lists? One, keep supporting in-house with existing staff, and the second – the cloud-candidate list.

  • What’s the criteria to develop each list? What are the deciding attributes? What is the weighting factor for each attribute? Is each weighted appropriately?
  • Who developed the criteria for attributes and weightings? How long ago? Is it still valid today?
  • Who decides when to add new criteria? To remove old criteria?
  • Who can override any scoring mechanism and make a rogue ‘executive management’ decision?
  • What applications need a quicker response time? Why?
  • Which applications provide enough business value that the front-end investment to move them to the cloud is a sound financial decision?
  • Which applications, once cloud-enabled, will still fit the way you do business? Which will do it better?
  • Which applications require the best stability? Reliability? Why? What is the impact on the business if they don’t have it?
  • Which applications, and their data, must be secure? What’s the business reason for the security? What’s the impact to the enterprise if there is a breach?
  • What is the impact on existing integration points with other applications? Does the integration need upgraded? Is the business case strong enough to cover these additional upfront costs?

So…What’s in it Really for the Business?

Remember, that pesky bunch that you support? Let me put it out there… Do NOT, I repeat, do NOT move 1 application to the cloud without asking the business what’s in it for them? Ask them, “what will the cloud provide you that you currently aren’t experiencing today?” Then listen intently…

Simply put, if you cannot articulate the ‘value’ business will receive in answering ‘the why’ moving an application to the cloud makes sense – don’t move it! Period, end of story, nada, move on to plan B…

Make sense? Applications are the key to greater efficiency, growth-oriented innovation, and IT cost reductions. These should continue when leveraging the cloud at any degree.

Questions that Many Clients Face

  • Can the cloud provide value to my application portfolio during a merger, acquisition or divestiture?
  • How do I determine if my legacy application environment is simply too old for transformation?
  • Will the cloud help translate maintenance spend to supporting the drive towards new innovation (read – business value)?
  • Will there be an uptick in complexity? How do I manage that while achieving more agility? How do I insure alignment with my business teams on meeting their future business needs?
  • Will the business need to change? (Tell me, oh please tell me, that the business was involved in the solutioning and decision making process – please) If yes, what impact does that have on my IT organization?
  • Do I start with the “problem children” in my portfolio or save them for last? Maybe just retire or replace them
  • What about my in-flight projects? They have already been approved. I can’t afford to finish all of them and spend on new projects to the cloud. How do I decide which?

So, Frank, Am I Ready for the Cloud?

Clients ready for any application transformation typically exhibit some of these driving forces

  • Struggle to align with the business from a strategic, capability, or an enabler point-of-view
  • Managing a (very) large number of applications and trying to figure out the right choices to rationalize to a smaller number
  • Struggling with an ERP implementation or other significant modernization project(s) that are not progressing as desired
  • Dealing with a lot of change within the business (e.g. M&A, markets, products, services, desire to globalize and / or centralize operations)
  • Changes in leadership, new CIO trying to put arms around what they have and how best to manage the business’ expectations while staying within an ever increasingly stringent budget
  • Consolidation in data centers and considering if it is the right time to modernize / rationalize / move applications at the same time

On the other hand, clients thinking about application transformation but are not really ready exhibit restraining forces like:

  • Little or no understanding of a strategic direction from either a business or IT perspective
  • Specific direction with regards to their infrastructure, data center, or network with no desire for functional or application change
  • Maturity of organization, governance, enterprise architecture, and / or business participation is low or non-existent
  • Too few FTEs being asked to support far too many applications
  • People funding enterprise applications not rational about which applications truly provide the most value, resisting any effort to modernize. Remind you of a car owner and their favorite old car?

Which of the above lists describes your current situation?

Here’s Your Plan of Action

First and foremost, understand your business’ goals! You’ve heard it before, right? But it’s true, your organization’s strategies and goals should define their future state. In addition, define your target architecture, along with a cloud strategy that supports the business goals. ANY effort, MUST satisfy that business direction.

(DON’T SKIP THIS STEP!) Build a full inventory of your applications portfolio. If you don’t, STOP right here and don’t read any further… You need to clearly understand the application technologies you’re starting with. Including such attributes as (1) the application architecture; (2) integration with, and dependencies on, other applications and data; (3) application technologies and resources; (4) the infrastructure on which it runs today, and; (5) all unique aspects of application operations and business service delivery that may exist.

Oh, and don’t forget the parts you can’t see:

  • Include inventorying the ‘shadow IT / underground applications’. May take twice the time but it might just uncover areas of need that a cloud environment could address.
  • Avoid migrating dead or duplicated code
  • In-flight projects may be an accelerator or a brake to any transformation – determine which is which for each major project. Don’t be afraid to cancel or postpone some.

In addition:

  • Identify all the business issues that impact (or may be impacted by…) what you can do with each application. Items such as regulatory / compliance, security, geography differences, vendors and partners who provide any type service or support
  • Once you have cleansed an appropriate application cloud-candidate list, develop a transformation strategy to the cloud for each. This should include identification of the target landing zone for each.
  • Review current business strategies and goals down to level-3 business process levels supported by each application, focusing on current, as well as future state
  • (Obviously) assess each application’s suitability to run in a cloud environment. Make the assessment process repeatable and use it consistently across the portfolio
  • Develop a project plan that incorporates a seamless transition to running the application after it’s been migrated to a cloud environment. Some may require running in parallel before the final cutover.

So…is cloud the answer for your current situation?

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

What Is an APM Team and Why Do I Need One?

An Application Portfolio Management (APM) team should consist of operational team members who will utilize the APM Playbook (see my previous blog post 4 March 2017) to prioritize transformation efforts.

Ok, you say that makes sense. So far so good. Then you say, “my very competent governance organization should be able to operationalize the APM Playbook.”

I say, “Fine, let’s look under the hood at that suggestion for a moment.”

Governance – that holistic approach needed to manage relationships, decisions, and actions across all pillars, segments, and business units. Strategically, that would include items such as:

  • A model encouraging performance improvement while ensuring conformance to principals and processes aligned with strategic direction and decisions
  • Policies and standards linked with how IT will deliver capabilities and support business processes
  • Roles, with accountability and responsibility, for decisions required to deliver and manage IT products and services

Tactically, you would expect this same organization to provide:

  • Detailed IT process definitions and interactions
  • Defined IT organization design and aligned demand requirements
  • Measured objectives for managing / delivering IT products and service
  • Defined capabilities and value for IT services and processes
  • Common decision model
  • Managed Risk

Who’s on First, What’s on Second, I Don’t Know on Third

You say, “I agree with everything you’ve presented.” I respond with a knowing smile…

“So, those individual governance teams that exist within all the pillars, segments, and business units are performing the exact same activities and delivering the exact same projects, all at the same time, in locked-step for the good of the firm – all the time?”

Your eyes drop to your computer screen checking for a discussion-saving email or IM.

“Never any duplicity or redundancy? Expectations and impacts are always in perfect alignment? Each individual decision within a pillar never results in inconsistent, fragmented decisions and capabilities in other pillars or segments? Is your firm that siloed that can actually happen? Documentation and communication plans are always exemplary so as to be shared with other business units?”

With a crease over your eyebrow, you look at me with your own knowing smile.

I’ve got your attention now…

Remember What an APM Playbook Is

An APM Playbook provides guidance to optimize a firm’s application portfolio and achieve measurable business results by shaping the Playbook content with:

ShapingAPM

Why an APM Team?

Portfolio-wide responsibilities and oversight to insure:

  • The optimal number of applications to support the business?
  • Which applications will be the “go-forward” applications?
  • Metrics to support strategic decision making
  • Enhanced decision making capability based on detailed attributes
  • A strategy to properly align an application portfolio with the business strategy

This level of specific responsibility over an enterprise portfolio of applications is not within the scope of the broader governance model.

Membership on an APM team is NOT a Part-time Gig

Members don’t keep their ‘day jobs’. Any APM strategy, Playbook, Framework, or Team is not a quick fix. It is a new way to view a portfolio of applications — as one of your firm’s largest and most important assets. Hence, it requires this type of stewardship and oversight.

Design, align, staff, and implement the APM Team with methodology / metrics for planning and execution of the APM framework.

  1. Engage an external transformation consultancy in an oversight capacity to insure team is staffed properly, develops proper mission and goals, and identify communication standards
  2. As an example, validate the following roles: Team Sponsor(s); architect(s); business owners / users; financials; Management of Change (MOC); others…
  3. (Probably the most important) Develop HR standards and embed these new job role(s) into existing career paths. Ensure that after an employee rolls off the APM team, that they are rewarded with a higher position that which they left to join the team.
  4. Transfer employees into new roles and staff team
  5. Launch Team, communicate to organization
  6. Establish measurable business-driven goals & decision criteria

Initially, team’s focus should be on:

  1. Oversight of investment, and cost (total cost of ownership of portfolio) management
  2. APM risk and compliance, alignment with existing governance structure / policies, etc.
  3. APM processes and standards
  4. Communication with executive committee, governance organization, etc.
  5. Managing metrics and measurement reporting
  6. Maintaining the prioritization of high priority initiatives, and ensure each is planned and resourced with required skills
  7. Provide oversight to the APM strategy and identification of additional transformational projects and their recommendation
  8. Develop succession planning for APM members – cyclic roll-off / roll-on after 1-½ to 2-½ year assignment for all members. Members should be responsible for identifying suitable replacement for themselves

The APM team is shaped by a set of guiding principles (e.g. Team Charter)

  • Deliver as much real value as possible as quickly as possible
  • Time the delivery of capabilities so that it will be of immediate benefit to the user community
  • Minimize possible disruptions to the organization
  • Balance the needs of many groups within the firm
  • Ensure the Framework (e.g. Playbook) is implemented aggressively and the results highly attainable

Preferred skills for APM team members

  • Strong vision – ability to communicate goals and direction in a compelling manner
  • Strategic thinking – understanding of business processes
  • Strong leadership skills
  • Ability to make decisions in a timely manner
  • General understanding of information technology support relative to the business
  • Help the team diagnose its leadership needs; identify individuals who could counter-balance the team’s weaknesses – energized by working together
  • Coordinate activities to accomplish a common goal
  • Focuses On high levels of output
  • Work at confronting and working through differences – stride towards synergy

Organizational considerations for APM team members

DOs

  • Mid-level to senior employees that are known within the organization
  • Basic Understanding: Leadership is learned / shared matter
  • Basic Understanding: Leadership can come from anyone in team
  • Team decisions are essential (“None of us are as smart as the rest of us”)
  • Equal representation between IT and Business across multiple layers within the firm
    • Number of members
    • Equivalent org chart positions

DON’Ts

  • New employees / junior employees (APM is not an entry-level team)
  • Destructive debater
  • Emphasis on analysis and counter-analysis
  • No attempt to coordinate ideas
  • Over-focused on task roles

Symptoms of a cohesive (healthy) team

  • Democratic process
  • Full participation
  • Consensus decisions
  • Conflicts worked through
  • Very productive / satisfying
  • 1/3 To 1/2 time spent planning

Symptoms of an unhealthy team

Divergent Group (Unhealthy)

  • Leadership Void
  • Too Cautious
  • Voting
  • Conflict Avoided
  • Very Unproductive / Dis-satisfying
  • Do Not Complete the Task

Fragmented Group (Unhealthy)

  • Autocratic leadership
  • Quick decision
  • Little participation
  • Conflict ignored
  • Somewhat productive / dis-satisfying
  • Usually <1 min planning

As Peter Senge stated in his book, The Fifth Discipline, “Organizations break down, despite individual brilliance and innovative products, because they are unable to pull their diverse functions and talents into a productive whole.”

When implemented correctly, APM Teams can be one of a firm’s most strategic driving forces.

APM Typical Results

APM_TypicalResults

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

What Is an APM Playbook and Why Do I Need One?

An APM Playbook (e.g. Framework) defines a method to score each application and their health as a portfolio by assessing strategic attributes such as an application’s age, supporting technology and skills, available vendor support, and the value an application provides to the business. Using these criteria, business decisions can be made to determine whether specific applications should be kept, updated, retired or replaced.

An APM Playbook Should:

  • Define a standardized approach to measuring the risk of technology obsolescence
  • Create measurement criteria for evaluating operational risk of applications
  • Create a process for justifying investment in technology modernization effort
  • Consider the complexity of functional and / or integration changes

This framework should consider business architecture, technical architecture and operational concerns when evaluating and prioritizing application modernization initiatives. This ensures future investments have a strategic alignment with corporate initiatives.

But First, Let’s Back up a Bit – Just What Exactly is APM?

APM is a management-level discipline – a fundamental, ongoing discipline, not just a one-off exercise to support transformation.

BUT Why, Why APM?

  • Determine what is the optimal number of applications to support the business
  • Identify which applications will be the “go-forward” applications
  • Decide if the focus should be on business innovation or on the efficient management of application assets. Or both

So, what do I REALLY get from APM?

  • Strategic metrics to support decision making
    • How consistent and standardized does the firm wish its business processes to be?
    • What is the optimal number of applications to support the business?
    • What are the operational costs of each application?
  • Enhanced decision making capability
    • Which applications to keep, which to get rid of
    • Which apps should be invested in, which apps are too far gone to invest in further?
    • Projecting the total spend for the next 3-5 years, then perpetuating these projections very much like a firm’s vision statement. What? In other words, you never want to achieve your vision, you always, constantly want it to stretch you into becoming even better.
  • A strategy that addresses numerous issues that a firm needs to properly align an IT strategy with that of the business

The Value of APM and the APM Playbook

valueofapm

An APM playbook should, at a minimum, include the following sections:

  • Executive Overview / Introduction
  • APM Plan
  • APM Lifecycle
  • APM Governance Model
  • Analytics Framework
  • APM Decision Framework & Decision Events
  • APM Capability Management
  • How to Mature the Playbook

With this level of detail, you can increase effective communication; increase the speed of the implementation of a transformation roadmap; and increase responsiveness and effectiveness. In addition, and more importantly, integrate the process between the transformation initiatives and existing governance / EA standards and policies, such as:

  • Single governance review for all transformation projects on the roadmap
  • Approval for all additional projects not on initial (e.g. master) roadmap. No project gets approved without integration into the master roadmap as it’s the “single source of truth” so to speak…

An APM Playbook should support

  • Identification of business areas affected by application consolidation
  • Assessment of the degree of variations across application versioning
  • Mapping of current applications, with their basic cost and quality data, to business processes
  • Obtaining management approval of portfolio standardization goals
  • Deciding the optimal number of applications to support the future state
  • Assessment of the existing apps (e.g. a 1-time application rationalization analysis)
  • Performing an operational cost analysis of individual applications
  • Development of a business case for the transformation roadmap
    • Business benefits, OpEx savings, CapEx of modernization, cost of de-commissioning and subsequent OpEx savings, etc.

At the core of any Playbook is an analytics framework as well as a decision framework and decision events. The analytics framework must include a risk framework, analysis linking risks to application dispositioning, and strategic attributes.

Leveraging the analytics framework, the decision framework must include the decision criteria, disposition prioritization and types, maturity, and linkage to the APM Lifecycle. Finally, the decision events include event scenarios and scenario examples.

It’s so easy to think, our people have navigated successfully through one transformation, so perhaps it won’t be as hard to sign them up for another one.

Oh, oh, I almost forgot — if you have an APM Playbook, do you need an APM Team to implement?

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

INSURING Successful Application Transformation

Oh, the “BIG if”. IF (and trust me, this is big – really really BIG) you are going to embrace application transformation, it goes without saying you want to do everything you can to insure success, correct?

What Outputs Are Key To Insure That Success?

  • Produce a rationalized portfolio that will support a broader strategy of the enterprise?
  • A life cycle for the applications mapped to the future, enabling the modernization of the portfolio?
  • Financial model to insure applications are contributing to the success of the organization?
  • Application transparency providing the ability to advise the business rather than just??? (fill in the blank here)
  • Business capability based on value t-o   t-h-e   b-u-s-i-n-e-s-s, current condition (health), and level of resource consumption which forms the informational base that enables rationalization?

Yes, yes, yes, yes, and a resounding yes. A good transformation plan addresses multiple issues that the enterprise needs to properly align IT with the business. Note, I DIDN’T say, “align the business to IT”. It should include sourcing, platform migration, delivery models, governance, life cycle management and process integration, and…

Enterprise Coaching That Includes:

  • Improved focus on transformation
  • Organizationally, insuring people are ready for transformation
  • Developing a vision for how technology will transform the business
  • Identification of all stakeholder issues

Risk Management

It is very appropriate to identify a single set of risk criteria across the scoped applications to be transformed.

  • How consistent and standardized does your firm wish its business processes to be?
  • What is the optimal number of applications to support the business processes? One (1) may have been realistic back in the 80s but not today. Thousands are too many.
  • Which applications will be the “go-forward” applications? No need to replace all of them.
  • Should we focus on business innovation or on the efficient management of IT assets?

In addition, consider these always-present risks:

  • Critical assumptions may not prove to be valid
  • Shifting enterprise priorities may redirect the project scope and / or critical resources
  • Business resources may not available, and to the extent required – yet another reason to get the business involved from the start. Transformation is something you do WITH the business NOT to them.
  • Scope of the project, along with other business and IT commitments, may be unmanageable
  • Desire of business leadership to alter the current state

The Risky Nature of Avoiding Risk

What has changed? To be successful, you have to out-innovate and out-execute your competition and that means moving faster, entering new markets, being more accessible to clients, and launching new products. In may mean increased risk = increased success.

Information is an asset that, like other business assets, is essential to an organization’s business and consequently needs to be suitably protected. This is especially important in the increasingly interconnected business environment. As a result of this increasing interconnectivity, information is now exposed to a growing number and wider variety of threats and vulnerabilities. As you share more information with your employees and customers alike, risk increases. As you leverage social media, risks go up. New markets? New risk.

There are two types of people. Those good at growing things that are already working. They suffer from xenophobia – the fear of the unknown.

Then, there is the transformation-people. Those that take greater risks and transform things that need it. Imagination – transformation needs that. For these folks, the world doesn’t change in front of their eyes, it changes behind their back – because of what they transformed.

Effective Communication During Transformation

  • Increases speed of implementation
  • Increases responsiveness and effectiveness
  • Enables a single transformation oversight team, using standard processes, thus eliminating inconsistencies in projects
  • Integrates processes between transformation initiatives and existing governance and EA standards and policies.
    • Single solution governance review for all transformation projects
    • Approval for all additional projects not on initial roadmap
    • No project gets approved without integration into the transformation roadmap – the master / single source of truth
  • Get opinions? Yes, but then decide, then move…

Move FAST!

Gartner says that this year (2017), 50% of total IT spending will be spent outside the formal IT organizations. IDC adds that 80% of Enterprise IT organizations will commit to hybrid cloud architectures.

Need to Identify:

  1. Objective(s) that benefit the business
  2. ID Dimensions of risk (business suitability, compliance, security, etc.)
  3. Define inputs / outputs
  4. Identify key roles and responsibilities

What Results can you expect?

  • Improved performance
  • Reduced costs
  • Rationalized portfolio
  • A future-proofed IT
  • Reduced risks

Easy? No. Mandatory? Yes!

It’s so easy to think, “Our people have navigated successfully through one transformation, so perhaps it won’t be as hard to sign them up for another one.

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

Value Migration and the Impact of a Journey into Application Transformation

Many organizations attempt transformation and use transformation-centric language, but they really don’t believe in it or strive for it. Because? They don’t see the value in it. Profession doesn’t always mean possession. How do your strategies match with your conformity to take the journey?

One of the most difficult lessons to learn is that transformation is inevitable. It is above all those other things – M&A, organizational changes, new leadership, new products / services, new markets – OR, maybe it’s because of all these things? Lack of transformation kills a firm’s value delivery, thus limiting the power and authority of the entire enterprise. Those who live in the upper branches of the organizational tree, with relatively comfortable financial situations and high degrees of autonomy, find this difficult to understand. While we may feel as though we are free to do what we please, transformation is sovereign over every departmental plan and action.

Your company has entrusted to you, value creation. Have you, in turn, trusted transformation to take you to the future of value creation? It should be THE top priority.

As priorities evolve, you will say, “I don’t care about our historical abilities to ____?_____. Our business has changed, our needs have changed. What I really care about is _____?____. What I will pay a premium for is _____?____.

You’d better be in a position to fill in these blanks. The pattern is clear – when needs (think – value migration) are emerging, the business looks to transformation. When needs mature, business looks for low cost and stability.

Emotionally, it’s easier to change when you’re hemorrhaging

What’s on your radar screen? If your executives are worried about competitors’ moves, customer’s demands, or market shifts, they very well better be worried about how to transform the plethora of applications to support these changes – starting today.

As Andy Grove, former CEO of Intel, said, “There is at least one point in the history of any company when you have to change dramatically to rise to the next performance level. Miss that moment and you start to decline.

Transformational denial can blind your organization.

Take a look at this quote from a recent key executive, “We found it very very hard to face up to the decision. Financially, it should have been easy. In retrospect, it should have been easy strategically too. Yet, we, the management, were at each other’s throats over this.

Sound familiar?

Success can trap you. The more successful you are as a company, the more difficult it is to transform into something else. To take advantage of the opportunities in front of you, you must transform. And your portfolio of applications had better be nimble enough, agile enough, scalable enough, integrated enough, and cost effective enough not to get in the way.

The time to transform is to do it while your core business is still strong enough to see it through. Need proof? Take a look at the big legacy technology companies today. Ask yourself, “at what point is our decline irreversible?

One of the best ways to influence the ‘we’ve-always-done-it-this-way” group is to work diligently and responsibly on the transformation journey. Always representing the strategy in a positive light – increasing the awareness for the need for the journey. Your critics will have a difficult time finding legitimate arguments against it.

Can you wait?

46 years ago, in 1970, the market capitalization of (all) the world’s companies was $929B. 23 years later, in 1993, this grew to $12.6T. Today, the capitalization of the world’s 100 largest companies stands at $16.2T.

Are you on the verge of forgetting? The longer you wait to transform, the greater legacy can choke an enterprise. At some point, firms develop institutional-Alzheimer’s. Wait long enough, the damage will be so complete that nothing you do will generate value of any consequence. You could find yourself on the short-end of any digital business strategy – a death sentence in today’s environment.

Begin transformation by asking, “What journey should I be developing today?

Justification

We’ve all heard them and experienced them. The eight common excuses for not transforming

  • “They” (another BU, department, region, etc.) don’t deserve help. They got themselves into this current state, let them get themselves out
  • The call for transformation applies to others
  • We don’t know of any other companies doing this
  • Competing needs, goals, and strategies
  • Any money invested in transformation with be wasted or re-appropriated
  • We may become involved so deep we’ll become victims ourselves
  • Don’t know where to start, and don’t have time
  • Any effort won’t make any difference

CostOfAdditionalApplications

Be smart, have a plan…

There is no right or wrong answer to the transformation journey or the value it can generate. There is more than one road to the future. Remember baseball legion Yogi Berra’s line, “If you come to a fork in the road, take it.”

The Transformation Suitcase

What to put in your enterprise-wide suitcase for the eventual journey in transformation? At first thought, you don’t know what to take. Here’s an idea: Put in everything that is in the back-half of its life cycle. Put in all the legacy AND lack of technology-currency you can find. Also, all the BU-centric solutions that were implemented during those budget-lean years. Plus all the stand alone applications with manual interfaces. In other words, you are focused on all the technologies that have zero value left to offer the organization.

Hopefully, you will identify many things to put into your suitcase.

As important as your transformation journey is, you want, and need, the enterprise’s backing. On your own, you have neither the ability to fulfill nor the power to disrupt the momentum of legacy. Take a look at the following current-state application architecture of one of North America’s largest utilities. Ask yourself, “Is this model sustainable?”

CurrentStateAppArch_PGE-Example

Can you envision doubling or tripling this complexity? Support staff? Operational cost? Consider, this graphic represents only 20% (top 300 of 1,500) of the application portfolio with:

  • “Put-out-a-fire” architecture
  • Point fixes that don’t fix problems
  • Bypassing the middleware because it’s “cheaper”
  • Departmental IT (e.g. shadow IT)
  • Bewildering range of integration choices
  • Functional redundancy
  • Prevalent manual processes

Implementing the Plan

Implementation of your transformation journey is critical. A roadmap must be approved, executed, and governed. You are either “mixing mortar”, “filling the cracks in the wall”, or “building a cathedral”.

You decide.

Roads? Where we’re going, we don’t need roads…

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

Choosing a Functional Area for Transformation (???)

First comment – don’t. The functional areas you ignore will negate any transformation in the area(s) you chose. ALWAYS perform transformation at the enterprise level if at all possible.

Second commentmake it possible (to perform a transformation at the enterprise level). ALL your arguments will be valid. Although all excuses sound sensible at first, they are dangerous rationalizations. Don’t listen…

That said, it is (somewhat) common to implement a sequential functional ‘sleeve’ approach. Once you complete all functional ‘sleeves’, you’ll have completed the entire enterprise portfolio. This is doable. However, the extended time required increases the risk of completely the entire enterprise sleeve-by-sleeve. Remember the old adage, “time kills deals” — rings true for transformation projects as well.

Pros of a Sequential Functional ‘Sleeve’ Approach

  • Built-in go / no go decisions points at end of each sleeve’s assessment
  • Functional-specific recommendations delivered quicker
  • Allows focus on known ‘problem areas’
    • Look first at high value, low risk, quick return items
  • Savings from initial sleeve(s) recommendations, when implemented, could be used to fund assessment of later sleeves
  • Can factor in risk / complexity to ensure success and high return early to best position higher risk, more complex efforts

Cons of a Sequential Functional ‘Sleeve’ Approach

  • Takes longer, total cost is greater to asses entire portfolio using a sleeve-by-sleeve approach
  • Multiple modernization roadmaps and business benefit models will need to be ‘rationalized’ into one, at the completion of the final sleeve (e.g. completed enterprise)
  • All redundant functionality may not be discovered within a narrow scope of individual sleeves
  • Possible re-work on earlier recommendations as additional sleeve assessments are competed
  • Implementation of recommendations while completing additional sleeve assessments could add complexity to the level of effort required
  • A narrow sleeve assessment would result in increased assumptions / less actual recommendations
  • Retirement / replacement recommendations will need to be vetted with additional (out of scope) users of each application

Pros of Enterprise-wide Approach

  • Maximized value by delivering enterprise-wide recommendations
    • Recommendations will minimize conflicts for limited FTEs and funding
  • Minimized time and investment in actual assessment
  • Timing considerations, critical dependencies, and design complexities can be determined across the enterprise for all recommendations
  • Composite view of data warehouse, business intelligence, data sources, etc. provides increased clarity
  • Enterprise-wide business case makes funding decisions more strategic
  • Increased business scalability and agility

Cons of Enterprise-wide Approach

  • Very few recommendations are implemented until after the completion of the assessment. There are exceptions to this…
  • The complete solution will be delivered in a multi-step fashion
  • The enterprise-wide roadmap solution would require increased time to reach a decision / funding approval; and volatility of work and demand for client resources
  • Organizational risks could be increased as multiple recommendations are implemented across broad functional areas
    • Business resource availability
    • End user change impact
    • Other project commitments

What Both Approaches Have in Common

  • Determine what applications are in use supporting the business
  • Which applications score best and worst for function and technical quality
  • What applications are based on ‘at risk’ technology
  • What applications cost the most to maintain?
  • Determine what applications should be retired, consolidated or extended
  • (Assuming implementation of the findings) Reduce portfolio total cost of ownership (TCO) and / or enable spend redirection from sustaining work to high value-add initiatives
  • Alignment between applications and business objectives
  • Increase the performance, efficiency, and usability of a portfolio
  • Similar assets will be delivered

In addition, an enterprise-wide approach can result in additional value such as analysis of:

  • IT organization model
  • Current projects
  • Portfolio management
  • Governance practices

A functional-sleeve approach will not allow an across-the-organization view of these areas. It is extremely difficult (e.g. near impossible) to stitch together a message sleeve-by-sleeve across these important areas.

Quiet convictions (e.g. enterprise view) often earn long-term respect.

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

Defining Application Tiers

“The secret power of lawlessness is already at work!” — means the any future work based on tradition (e.g. the past) is already going on. Secret means something no one has discovered, but something that will be revealed in any transformation effort. Lawlessness is the hidden, subtle, underlying force from which “we’ve always done it this way…” springs.

Rationalizing the need makes it easier to commit, but rationalization does not convince executives or cancel legacy practices that brought you to the point at which you find yourself today.

Why define tiers?

So…you’ve discovered and documented your portfolio of applications. Congratulations! Do you know how many companies don’t have their portfolio documented? Most of them…

Are you surprised how big your documented inventory is? I’ll bet you didn’t think you had that many applications? The list invariably includes business applications, IT tools, interfacing applications, middleware, utilities, and desk-top productively apps. You name it, you’ve got it in your inventory. Again, CONGRATULATIONS!

So… now that you have your inventory, you are ready to manage one of your firms largest assets more effectively, therefore reducing costs, right? Then why can’t you? Ask yourself, what do business applications and IT tools have in common? The answer is ‘nothing’.

Don’t get me wrong, a complete inventory is THE essential first step. The second step is just as important — YOU MUST DEVELOP A TIERING MODEL in order to effective focus your attention on what needs your attention.

Why?

You could retire 100% of your IT tools and not save enough money to pay for the inventorying effort. On the other hand, understanding what the business truly needs in the way of functionality, reporting, and forecasting is worth its weight in gold.

The Secret of Developing a Tiering Model

There is no secret. Rather, you just do it…

Maybe one secret: Compromise can be defined as a blending of the qualities of two different things or a concession of principles. Cooperate with people (e.g. business people if you’re in IT, IT people if you are in operations) as much as you can, but avoid any alliance, partnership, or participate that could lead to continuation of the current state, and more importantly, a water-downed less-than effective future state strategy.

Your tiering model does NOT delete anything from the composite inventory. It DOES tier less important things out of your way. You want your transformation focus to be on business applications – those enterprise and regional apps that are generating revenue, profit, and keeping your customers onboard.

An example might be:

Tier 1: Enterprise, business unit or regional level applications critical to the firm’s business processes

Tier 2: Plant specific, non-industry specific business applications

Tier 3: [Utility Example] Specialized generation, transmission, or distribution applications or tool sets

These 3 tiers would be your focus for any rationalization, modernization, or transformation effort. Experience shows that the majority of cost savings can be realized by transformation of business applications. In most organizations, these three tiers account for about 40% of the total portfolio.

Tier 4: Everything else

Not so fast… Additional cost savings may be identified in other tiers, so a little effort in this area may be of additional value. Something like:

Tier 4: Desktop office productivity applications

Tier 5: IT and system applications for backup, security, help desk, testing

Tier 6: Development applications & tools

Tier 7: Data subscriptions, services and unknown applications

You may also want to consider additional criteria such as:

  • Previously identified rationalization candidates
  • High support-cost applications
  • Focus application-areas for business standardization or improvement
  • Linkage to in-flight projects
  • Identify “top business processes”, and look at the world of actual applications and desired standards for these processes

Remember, ask yourself, what is the value in this particular tier’s definition? For every tier defined. Point is, each tier must be defined BEFORE linking each application to its appropriate tier. The tier number simply becomes another attribute that helps you define and management your portfolio.

If you are a reader of my blogs, you’ll remember that ‘tiering’ is directly linked to ‘Defining an Application’ – check it out @ https://appstrans.wordpress.com/2015/07/08/defining-an-application/

Again, with larger portfolios a tiering model is developed to provide focus on the upper tiers that will provide the largest payback in any transformation effort. A completed example may look something like this:

TeiringModelExample

What’s Next After Tiering?

Simply put, begin the analysis of your current state inventory. But Frank wait, Frank, Frank, do I perform an analysis across the enterprise or functional area-by-functional area?

You are finally asking the right questions. Until next time…

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com