Defining an Application

How is behavior altered? In his book “The Social Animal”, David Brooks notes that some experts have said people just need to be taught the long-term risks of bad behavior. Unfortunately, in the world of applications, this hasn’t been enough to transform behavior.

The understanding of the current state portfolio is much more important than any transformational strategy. Why? How can you begin to determine where you need to be (future state) if you don’t understand where you are (current state)? In addition, a sound knowledge of the complexity and gaps in support of the business will go a long way in determining what the strategy should be and where it should take you.

This is an extremely difficult task: “Telling people, who truly believe (and in many cases helped build it) in the portfolio and what it provides, that it will literally destroy their company if they don’t (immediately) begin transforming it?” Difficult indeed…

I’m NOT talking about the infrastructure (e.g. the ‘machines’, or whether they reside in the cloud or not. Nor the data, nor the connectivity, etc.). I’m talking about the applications themselves – those systems and pieces of software that your employees use to access knowledge and information that keeps your company alive and competitive.

Why is defining what an “application is” so difficult?

Today’s heterogeneous application environments defy simple definition. Applications tend to lack any truly useful or standard unit of measure. Today’s applications are a mix of massive, client / server, packaged, service-oriented architecture (SOA) services / web applications, etc. – no one definition seems to apply. For example, how do stored procedures and / or reusable components change a definition? Will SOA services erode the definition entirely by replacing silos with loosely coupled shared services? How should open-source be counted — as custom code, a partial-packaged application, or a service?

Firms that have spent excessive time debating the term “application” have likely lost track of their context or never properly defined it to begin with. Context – arguably an ugly word. Context depends on what you are doing — your objectives, goals, and perspectives.

Some contexts require a high degree of technical precision. Operations and change management that run / migrate applications to / from production require precise inventories of components making up each application. On the other hand, a developer may define an application by its source code, shared components, data, and /or integration.

Other contexts define applications by the technology base. Enterprise architects (EAs) may assemble a view of applications based on the technology used — database management systems, OS, and programming languages, for example. These usage-based views enable EAs to monitor the cumulative technology in use, ensure adherence to technical policies and standards, and making recommendations to retire obsolescence.

Still other contexts blur or ignore application boundaries. IT and business leaders may group applications together to approximate the resources that the business consume. Business process SMEs may ignore application boundaries entirely to focus on how future-state processes should flow regardless of the current-state applications. EAs may take a similarly intellectual view as they develop capability maps and future-state diagrams.

Where do I start?

Good question. Before we get into the nitty-gritty of defining an application, the basics apply to this endeavor:

  • Calculate the investment
  • Set priorities
  • Prepare
  • Determine a course of action and move ahead boldly

Just what is an application?

To start, you don’t need tedious planning sessions, you need one plan that will bring quick action. You simply get the definition right to create transparency and enable transformation. Start with a ‘working’ definition…

AppWorkingDefinition

This working definition is used to narrow the focus – this first-scrub should significantly reduce the list of application ‘candidates’.

The first step then, is to apply a general application definition to these ‘candidates’. Ask, does it:

  • Accomplish a specific task(s)?
  • Aid the firm in performing business?
  • Create, edit and/or store data?
  • Require support and maintenance?
  • Can upgrades be deployed separately?

If the answer is “yes” to all of the above questions, the definition moves to the second level of analysis. Step two refines the definition:

  • Does it communicate with other systems?
  • Does it have licensing, maintenance and / or support costs?
  • Is it a system of record?
  • Does it create, edit and / or store ‘enterprise’ data?
  • Does it require manual process(es) to engage / interact with?

If the answer is “yes” to any of the above questions, the definition moves to level 3 of the analysis. The third, and final, step involves identifying application ‘buckets’:

  • Does it ONLY support out-of-scope functional (OOS) areas? Yes, you determine what OOS is / isn’t
  • Is it a non-business application? (IT & system apps for backup, security, help desk, testing, development apps & tools, data subscriptions, services, and unknown apps)
  • Has it already been retired or replaced?
  • Etc.

Based on your unique context, only the in-scope applications are inventoried and analyzed further. Transformation is not produced by neglect, denial, withdrawal, or bitterness. It only comes from extremely hard work tackling difficult problems.

But wait, how do I identify which of my applications are business applications? It’s called ‘tiering’. Until next time…

See you in the future…

Frank Wood

Frankwood944@yahoo.com

Managing an Every-Changing Master Inventory Requires Meticulous Hands-on Governance

Don’t have an APM team? Get one!

Combining two lists into one master list can be done relatively easily. Combining several dozen lists into one master is a significant challenge for anyone:

  • Removing duplicates becomes extremely challenging. A (must) by-product of this is standardization of naming conventions (TLAs [three letter acronyms], common names, nick-names, official names, names of vendors in lieu of software names, etc.)
  • Redundancy in TLAs becomes an issue – oh, yes it does…
  • Tracking all the individual tidbits of information from each source-list that needs to be rolled into the master inventory becomes mandatory and increasingly difficult
  • Identifying only the new applications becomes more challenging as the master list absorbs more and more source lists
    • Performing this manually can become a major risk for any project’s time line and / or deliverables
    • A tool is required to insure that no information is lost or over looked from the source lists and insuring only new applications are added to the master list

Example De-duping Tool

DedupingTool1

How to use a dupe-identification tool like the one shown above:

  1. Clear the contents of columns 1 and 2 (below ‘black’ header row) as applicable
  2. Update the contents of columns 1 – 2 with lists of applications that have been identified to date (Note: Change column header where necessary)
  3. Enter new Application list in “new list” column as shown (below ‘black’ header row)
  4. Click on the “Identify New Applications” button (note: requires VB code not shown here)
    • “Analysis” Column will display the analysis
    • “Potential New Items” Column will display potential new applications – final analysis of these potentials will need to be done manually by APM team

When done, move the entire list from “new list” column into the “Processed Lists” tab. This will help you limit duplicate analysis of new items as you move through additional list yet to be de-duped.

DedupingTool2

Processed list is then moved to ‘processed list’ tab.

DedupingTool3

Then the tool is ready to analyze the next source list, repeating the process.

DedupingTool4

The lists considered MUST include shadow IT (Underground apps, departmental IT, etc.) applications. The ranks of business people (e.g. business end-user developers) who are capable of developing applications are swelling due to:

  • Technology-savvy workers entering the workforce
  • The proliferation of easy-to-use development tools
  • Burgeoning demand for applications

These business people don’t want developers’ jobs; they just want to get things done. Their enthusiasm and lack of professional application developer backgrounds can lead to poorly designed, insecure, and un-scalable applications that application development professionals ultimately inherit.

Business users gone wild…

End-user developers can easily get in over their heads. Armed with BPM, business rules, Excel, SharePoint, Drupal (an open source content management platform), enterprise mashups (e.g. integrated heterogeneous digital data / applications from multiple sources for business purpose(s)), and other tools, end-user developers have virtually no limits. The result can be applications that proliferate out of control.

Most application rationalization efforts ignore end-user-developed applications and that is a BIG mistake. Just because they aren’t developed under IT’s radar doesn’t mean they shouldn’t be included in a firm’s MASTER inventory. Understanding the ‘why’ behind these underground applications, can go a long way in identifying potential gaps in the IT offering.

These applications can replicate faster than enterprise architectures can develop standards for controlling them, especially when developers can email or deploy them on a web-based platform. End-user development is often not subject to the same stringent testing regime that is employed during standard IT software development processes. Hidden bugs can cost millions.

Do You Shut Down Development All Together?

No. Although simple applications can become beasts, any end-user developer armed with an idea, ambition, or need can build significant applications – that, over time, can become strategic. The challenge becomes when businesspeople embed numerous home-grown applications in critical business processes that result in a convoluted process that makes a business less agile. WHY? Business developers often work alone. A business process that becomes dependent on a businessperson-developed-application might become dependent on the person who developed it. When they leave the firm, what happens to the application?

With or Without IT, Business Developers Are Here to Stay

The ranks of businesspeople who are willing and able to develop applications are increasing due to the proliferation of easy-to-use development tools, demand for functionality that outpaces IT’s ability to keep up, and the growth of cloud computing. They don’t want to become developers; they just want to get things done within their OWN timeline. With their enthusiasm comes poorly designed, insecure, and stand-alone (e.g. no interfacing) applications that development professionals in IT ultimately inherit.

Instead of ignoring or trying to shut down business developers, the organization should provide EA guidelines and standards – to insure success and safety for the business. Business ALWAYS preserve the right for business-needs, desires, and wants. Business CANNOT tell IT what is the best solution – that is the business of IT! However, you must identify a way to provide a strategy that illustrates to business executives you are trying to get out of their way while preserving some sanity in their future-state solutioning.

Next up — Why is defining an application so bloody difficult?

See you in the future…

Frank Wood

A Business Based Approach to Application Portfolio Decision Making

It is important to take a self-inventory in order to identify strengths and weaknesses. Whenever in doubt, ask, “Can I do that without the business? Can I influence others for good, rather than being influenced by them?” In areas of strength, you should guard against being corrupted by the enterprise; rather you should be persuasive in your transformation ‘story’. In areas of weakness such as an immature transformational vision that has not yet been developed, you need to be cautious.

Business Context

  1. What is my current state application usage, technical constraints, and operational speed bumps?
  2. What is the current state of our business? How does the portfolio currently support the business? What is the future state of our business? How does the portfolio need to change to continue to support the business in this future?
  3. What applications do we have, who owns them and what business capabilities do they support?

Many times, transformational architects base their planning on opinion, personal dislikes, or cultural bias rather than a sound strategy. Hoping is not an alternative to preparation and your personal belief is not a substitute for hard work. You must leverage all the talent and resources available within the enterprise.

MUST HAVE: Application Risk / Financials

  1. How complex is your application portfolio today?
  2. How complete is your application data (e.g. basic knowledge of each application)?
  3. How do application costs and risks align to business capabilities?
  4. What are the existing skill sets and FTEs for each application?
  5. How successful have your past transformational efforts been?
  6. How does the cost of an application and the value it provides compare? Does the business agree with this comparison?
  7. How do you estimate an operational TCO for each application when that data isn’t available?

Many people think that prosperity and success come from having power, influential personal contacts, and a relentless desire to get ahead. But the strategy for gaining affluence goes against such criteria. You must be:

  1. Strong and courageous because the task ahead will not be easy
  2. Obey corporate governance – transformation does NOT play outside of this realm
  3. Constantly read and study transformational thought, vision, and best practices

MUST HAVE VISION: Consolidation Opportunities

  1. Is there opportunities to consolidate applications across regions and business units?
  2. What are the best candidates for rationalization? Better yet, what is the criteria you use to answer this question?
  3. What applications are you planning to retire? Why haven’t they been retired yet? Somebody in the decision tree ultimately will ask THE question, “What is this application retirement going to save me?” Or, “Where is the data going to end up?” If you can’t answer both of these, don’t even attempt retirements / replacements…

You may ask, why all the complicated preparations for transformation?

  • Success will depend on a transformational vision NOT culture and expertise
  • Transformational leadership will accentuated the enterprise ‘stuck in the mud’ mentality
  • Faith in your willingness to follow through completely is paramount

Challenges (These WILL Happen)

  • Inventory
    • Not complete and up to date across the enterprise
    • Not kept in a central location and easily accessible by business and IT decision makers
    • Most will think ‘inventorying’ is a waste of time, saying, “Let’s get on with the real transformation!”
  • Consistently updating the inventory is the only way to continue making good investment decisions
    • How do you decide where new technologies such as cloud and mobile change the importance of various applications and delivery platforms if you don’t keep this information current?
    • Inventorying is not a one-time effort, rather a continuous tracking, documentation, and analysis of one of your firm’s largest assets
  • Prevent ‘”Shelfware
    • Gather organizational support needed to implement the transformational change(s)
    • Delivering real business benefit (reducing costs – remember operational TCO, reducing risk, increasing agility)
  • Step-by-step
    • First, commit to measuring the performance and business value of each application
    • Identify both business owners and IT owners for each and every application
    • Focus on answering the most critical challenges facing the business

When you experience a setback (and you will…):

  • Man-up and ID what went wrong and why?
  • Refocus, deal with the issue, and move on – this cycle will strengthen the transformation effort, not weaken it
  • Lessons learned from failures should make you better able to handle the same situation the second time around

The persuasive power is in the transformation ‘story’ not the transformational leader (e.g. storyteller). The organization (e.g. business) won’t be against those who carefully prepare, but against those who try to impress others only with their own knowledge. Following these important principles will insure success:

  • Find common ground with the business
  • Avoid a (technical) know-it-all attitude
  • Make the business feel accepted
  • Be sensitive to the business’ needs and concerns
  • Look for opportunities to make the business more successful

See you in the future…

Frank Wood

 

 

Application Portfolios – The Paradox

I almost like it, even though it sort of irritates me. Maybe I like it because it irritates me. But that’s my problem“.

OK, so you have a massive application portfolio with technology that is significantly outdated. In addition, the application landscape has grown without currency maintenance. In other words, many of your servers are outdated to the extent you can’t upgrade your core applications, and many of your servers cannot be upgraded because the upgrades won’t support the most current versions of software. And let’s not forget the last acquired business unit – they are still running on all their own systems.

In a September 2012 survey, Gartner found that “78% of application portfolios will change over the next 2 years.” That was 31 months ago. Did yours? If yes. Is it going to change again by 2017? If no, how is your legacy portfolio going to support your business differentiation in 2016-17 and beyond?

Everything has a Price

“Everything has a price” seems to be true in our world of expanding markets, revenue, growth, M&A, and divestitures. No amount of money however, can buy optimization.

Most firms have already adjusted to their competitors’ differentiators, global market forces, and every-growing customer demands. The only way to leverage the power within an application portfolio is to discover, document, analyze, and then, develop future strategies from your findings. Those strategies must transform your current state through portfolio standardization; process refinement through governance; managing the portfolio via established metrics / measurements; and proactively optimized assets. In short, transform the portfolio so as to optimize the knowledge and enhance the business support derived from it.

First Things First

  1. Begin by following your instinct for the obvious need to transform – starting with where the concerns are
  2. Define where you are today (the good, bad, and ugly) – then you can demonstration how transformation applies to those concerns
  3. Explain the forethought of your future state – but don’t forget / neglect the current state, it defines the scope of your transformation

Suddenly Transported to a Future State?

No. A bold vision will no doubt stir up controversy. Knowing this, you can prepare for it.

  1. Don’t lose your fierce intensity, rather channel it
  2. Ensure your intentions and efforts are sincere
  3. You must be an apostle of your transformational beliefs
  4. Realize little has been accomplished to date, you are going to be different – you are on a missionary journey

You will never know all you can accomplish until you allow transformation to identify all that you have need of. Hearing is absorbing and accepting information. Learning is understanding its meaning and implications. Following is putting into action all you have learned and understood. All three parts are essential in a successful transformation.

An “IT transformation” is not just a tech initiative within IT, it is a business strategy adopted throughout a company.

  1. Recognize what is currently taking place
  2. Renounce this state as unworthy of expansion / extension
  3. Ask for support, funding, and insist on executive backing
  4. Restructure your priorities, therefore the motivation for each
  5. Examine progress daily to be sure the business units are spending the time and making the commitment to quantify transformation benefits

Transformation Cannot be Ignored

How would you feel if someone took a picture of you, framed it, stared at it a lot, showed it to others, but completely ignored the real you? Transformation cannot be treated that way either. First it is a movement, a large activity, a migration. At some point it becomes much more. It becomes the ‘new you’ – the transformed organization that is quicker to respond, more agile, more cost effective, AND won’t have to stop and perform another application assessment because you are pro-actively management the portfolio.

Hardest Challenges

  1. We’ve always done it this way. Sure it’s tough sometimes but we’ve managed so far…
  2. Resentment for change in leadership – transformation may require new leadership with new vision and priorities
  3. Lack of vision can spread like an virus
  4. The rigors and challenges of transformation
  5. Some may want to transform ‘only a little’, rather than the entire journey – most CIOs will want to knockoff projects incrementally, even if they have a vision for how they’ll work together. That approach will deliver benefits but for an IT group to change the company’s edge over competitors – “be the benchmark”  – means taking on all weak spots at once

Belief in Monotheism

For a company that has wandered 40 years in a parched desert of hair-ball architecture, a future state flowing with knowledge and agility probably sounds like paradise. Don’t wait around for a miracle. Sow your seeds of transformation on the best ground you can find the best way you can, and leave the convincing to your success of reducing cost, complexity, and increasing agility and a vision to your future.

See you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com

Transformation Deliverables That Deliver Business Value

Does this sound familiar?

How many of your colleagues call ‘their buddy’ in IT whenever they need something? Who’s the business owner of the application(s) you use every day? Do you own an app that will perform (fill in the blank)? If no, then it’s a manual activity, correct?

Decreased OpEx: Why do I have to key in this data manually when it’s available from (fill in the blank)? Why are there so many timesheets? Why are my IT chargebacks so high?

Improved business case development: Who struggles with estimating benefits in a business case? Does any application really operate for free?

Lower support costs: How many people work on reporting each month? What % of my staff’s time is spent on the ERP system? Can it be reduced? Why is my app not available?

Reduced complexity, redundancy, cost: How many apps do you use that are not supported by IT? What app houses the ‘single point of truth’? Is part of your job the ‘manual interface’ between applications?

Improved business support: Why can’t we get rid of this old dying system? Why can’t we upgrade this one? Why can’t we expand the functionality of these two?

Improved investment decisions: Why are my requests never funded? In the last year, we’ve successfully completed every request by the business but strategically, we haven’t moved the needle. Why?

Improved business support strategy: What’s the plan? Where are we headed?

Greater efficiencies: Why’d we invest in that? Why do most projects run over budget? We spend the budget but never realize the benefits. Why?

Increased decision making ability: Who should be involved in this decision? We’ve got all this data, now what do we do with it? How do we reduce costs / risk exposure?

Is there anyone that delivers answers to ALL these questions during a typical assessment?

Yes. Maybe, just maybe, I’ll see you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com

“Houston, We Have a Problem.” We Aren’t Responding Quickly Enough to Business Needs!

Class reunions, photo albums, familiar songs, and old applications – like longtime friends that awaken our memories and stir our emotions. The past is a kaleidoscope of promises, failures, victories, and embarrassments. Sometimes we want to forget memories that are too painful. As the years pass, however, remembrances of unpleasant events usually fade into our subconscious. But there is a time to remember: Mistakes should not be repeated; commitments made must be fulfilled and the memory of special events can encourage us and move us to action.

The Israelites spent 40 years on a journey that should have lasted 11 days. How long has your company been building the hair-ball you call the ‘current state’ application architecture?

The case for a strategy

Lacking a strategy, past generation(s) have been coding / building / buying software for up to 40 years and have perished into the wasteland of:

  • “Put-out-a-fire” architecture,
  • Point fixes that don’t fix problems,
  • Bypassing middleware because it’s “cheaper”,
  • Departmental IT

Are you your firms’ Moses?

After the organization choses to follow any transformation, they need to know ‘how’ to follow the transformation. “How”? The lessons are clear. Because of what was done, have hope and follow a different path. Because of what is now expected, listen and transform. Because of who they were (e.g. “IT”), you should honor their humble beginnings but not build newer technology on top of their legacy. Learning these lessons will prepare you for the future – your future.

All in the backdrop of an ever-growing bewildering range of integration choices. They left a manual-intensive paper-based model behind, but never reached the promise land of automation, technology, and a new style of IT that was to save them.

  • Strengthening governance
  • Standing up Enterprise Architecture
  • Implementing an Application Portfolio Management capability
  • Aligning current business climate, consumers, and emerging business climate
  • Transforming your technology post-merger / acquisition
  • Responding to radically different business models by new market entrants, using IT in new and threatening ways
  • Developing more knowledge rather than more information

It’s a tremendous challenge to lead transformation. As portfolios grow and become increasingly complex, conflicting needs and plans arise. Look for ways of sharing the load so that others may leverage their abilities in support of the transformation. Focus on the positive – problems don’t have to rob you of the victory.

Challenges you may face

  • Which systems should be launched? Updated? Replaced?
  • So hard to figure out the current “as-is”. Business is always screaming for more!
  • What’s the best environment for cloud? Should we even move to the cloud?
  • Need operation software, but it’s so bloody expensive
  • Which technologies meet our requirement? Meet our EA standards? Do we even have standards that need met?
  • Complete automation!? No way!
  • Spaghetti-like functionality structure

Defining ‘Business’ Value

“Houston, we have a problem.” We aren’t responding quickly enough to business needs. We cannot counter the disruptive influences of mobility, cloud, social media, and empowered consumers. Pressure from business leaders is increasing as you have failed to link transformation with innovation that supports their business needs.

  • Are you implementing business-led innovation?
  • Would you consider yourself an IT-enabled business?
  • Are your business units’ ideas driving top line growth that your current systems can’t support?
  • How well are you doing at reducing spending on traditional IT and moving spend to business projects?
  • Is IT a strategic partner or just another vendor for the business?

Be honest. You aren’t in this alone! If you haven’t seen your main competitors in a white paper or at a recent technical conference, trust me, they are fighting the same thing. Your (and theirs) enterprise has become part of a much broader ecosystem – one that requires ecosystem-centric transformation.

You are slowly moving from legacy systems to modernized (what DOES that mean?) and mobile and cloud and unstructured data that requires increased security, information optimization, and mobility integration.

Bloody hell, no wonder you need a consultancy!

Where to start?

“Once it is obvious that the application / system complexity is a problem, focus your efforts on doing something about it, rather than further documenting the problem.” (Gartner “What is the penalty for complexity in application portfolios?” June 2010)

How can something so simple and straight forward, still be spot-on almost 5 years later?

Because, E-V-E-R-Y-O-N-E skips the basics. It ALL starts with documenting your current state!

How can you begin to invisition a future state when you don’t have a clue where you are today?

Think about it a bit, and I’ll see you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com

Application Assessments Are Done WITH you, not TO You!

If I hire a consultancy to perform an application assessment / analysis, why do my application people need to be involved? Great question!

Short answer: They simply MUST be involved “.” (e.g. period!)

Longer answer: We, even us consultants, wish it were that easy – sign the SOW and go do an assessment to the client. LOL! Do I actually get paid for this kind of activity?

It’s a tremendous burden to lead transformation by yourself. It cannot be done single-handedly. As portfolios grow and become increasingly complex, conflicting needs and plans arise. No longer can one leader make all the decisions. Rather than trying to handle larger responsibilities alone, look for ways of sharing the load so that others may leverage their abilities and vision.

Enter the consultancy…

Boldness is not reckless impulsiveness. Boldness requires courage to press on and do what you know is right. To gain boldness, you must:

  • Insure you have executive buy-in, from the business, IT and CXO level
  • Look for opportunities to reduce complexity, reduce operational costs, and increase strategic investment
  • Realize that denial, shared discomfort, and awkwardness are not necessarily persecution of your transformation vision

Without portfolio-unity, transformation becomes yet another IT project doomed to failure.

Where do I start? How do I found the journey? How do I define the path?

OK – you are at least asking the correct questions! It is not a membership requirement in order to be a part of any transformation. Organizational structure is not an executive command. Do you see both internal and external problems facing your portfolio of applications? Internally: shadow IT and underground applications; complexity headaches? Outside: firm being pressured by oppressive competition and excessive client demands?

You, as a transformation leader, MUST keep your focus on what is most important – transforming the portfolio to provide the business with improved ___ (e.g. any answer is correct as long as it starts with ‘to provide the business with improved…”).

Ask yourself, can an outsider answer the following questions with any level of accuracy without input from your team?

  • What does the future business look like (not just industry-wide, but specifically, to your company) so that the future portfolio is aligned?
  • What is the business impact of key applications – numbers of users, usage statistics, process SMEs?
  • What are the current costs of each application for support, software license costs, infrastructure costs, and so forth?
  • What are the current standards, policies, and procedures pertaining to applications / infrastructure development and maintenance?
  • What are the current / planned projects that may impact any transformation?
  • What are the current development and maintenance productivity and performance metrics, current governance structure, policies, standards and procedures?

CAUTION: Any consultancy that tells you they can accurately identify any of the above without input from your staff – don’t hire them!

See you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com