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
How to use a dupe-identification tool like the one shown above:
- Clear the contents of columns 1 and 2 (below ‘black’ header row) as applicable
- Update the contents of columns 1 – 2 with lists of applications that have been identified to date (Note: Change column header where necessary)
- Enter new Application list in “new list” column as shown (below ‘black’ header row)
- 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.
Processed list is then moved to ‘processed list’ tab.
Then the tool is ready to analyze the next source list, repeating the process.
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…