Weeding Out a Manic Software Ecosystem


My very first job out of uni­ver­sity was in a big com­pany with lo­ca­tions all over the world. Whilst there are ben­e­fits to work­ing with a team that op­er­ated within an in­ter­na­tional frame­work, one of the down­sides was the manic soft­ware ecosys­tem they had grown in. I re­mem­ber I had filled out the back page in my note­book with a “software (or pro­gram)” glos­sary. Each time I would hear of a new pro­gram’s name, I would note it down and write its core func­tion­al­ity. This list grew sub­stan­tially in the first few weeks.

The size of the list was­n’t my biggest an­noy­ance; it was the trends ap­pear­ing in the func­tion­al­ity I was not­ing down. For in­stance, I noted there was a sep­a­rate pro­gram for each of these: pay­roll, ex­penses and in­voices. Yes, these sys­tems work in­de­pen­dently from each other, but at the core of their func­tion­al­ity, they dealt with the fi­nance and ac­count­ing as­pects of the busi­ness.

With this be­ing said, it was a few years ago when I was work­ing there, and SaaS (Software as a Service) in­te­gra­tions were still mak­ing peo­ple scep­ti­cal, so I can safely say that com­pany has now changed many of their op­er­a­tional work­flows to take full ad­van­tage of un­der­stand­ing their ecosys­tem.

So, what is this ecosys­tem?

When we think of an ecosys­tem, typ­i­cally we think about how it ap­plies to na­ture and how each el­e­ment of that nat­ural space works to­gether to­wards im­prov­ing its health and longevity. Essentially, every­thing in ex­is­tence serves a pur­pose. Disruption to that pur­pose­ful en­vi­ron­ment, such as com­pet­ing plants, or even if some­thing is re­moved en­tirely, can have flow-on ef­fects far greater than the orig­i­nal dis­rup­tion.

When think­ing about nat­ural en­vi­ron­ments and po­ten­tial dis­rup­tions, let’s look at the be­hav­iour of weeds. Just hear­ing their name makes any green thumb gri­mace. So, what elic­its this re­ac­tion?

Is it the fact that pulling them out is al­most a lost cause be­cause they al­ways come back? Or is it be­cause they are slowly crawl­ing over the beau­ti­ful plants in your gar­den and suf­fo­cat­ing them from bloom­ing growth? Or maybe it’s the fact that they can only some­times be re­moved with harsher, chem­i­cal meth­ods, that could harm the other plants? In all hon­estly, it’s most likely a com­bi­na­tion of all three.

Paralleling the in­ces­sant na­ture of weeds with soft­ware and how it can dis­rupt a healthy ecosys­tem, let’s look back to my first job re­flec­tion at the be­gin­ning of this ar­ti­cle.

Yes, weeds an­noy me as did the num­ber of sys­tems we used. Although the root of my frus­tra­tion (no pun in­tended!) was de­rived from the num­ber of sys­tems we used that were all so sim­i­lar. Yet, this did­n’t seem to sur­prise any­one, or they did­n’t think too much of it, be­cause it was just the nor­mal op­er­at­ing pro­ce­dure of the busi­ness. In gar­den­ing, when one weed ap­pears, it opens up the en­vi­ron­ment for more to creep through and con­tinue hand­i­cap­ping the growth of the gar­den.

In my role, I get to hear var­i­ous com­pa­ny’s goals for the fu­ture of their busi­ness. A com­mon theme in these goals is growth. A par­al­lel we can draw be­tween pro­fes­sional set­tings and our gar­den is the idea that weedy dis­rup­tions to en­vi­ron­ments have an in­verse ef­fect on growth.

If we look at growth in a busi­ness as ef­fi­ciently max­imis­ing the profit mar­gin (amongst other things), we need to con­sider costs that de­crease that mar­gin. Whether it’s be­spoke or off-the-shelf - soft­ware costs money. Operational pro­grams, such as Asana, HubSpot and Xero, are widely used by many busi­nesses for day-to-day pro­ceed­ings. They are nec­es­sary pro­grams. Where the is­sues arise is when a busi­ness uses Xero for pay­roll, but MYOB for in­voic­ing. Or HubSpot for their CRM but MailChimp for their EDMs. What is hap­pen­ing here is the dou­ble up in func­tion­al­ity across these pro­grams which is costly to sus­tain, timely to main­tain and can be a night­mare when it comes to train­ing and knowl­edge trans­fer; these pain points are our weeds! If you’re in­ter­ested in es­ti­mat­ing the cost of cus­tom soft­ware you can find in­for­ma­tion on that here.

An illustration of a mobile tablet with black lines acting as branches. At the end of each line is an illustration of a software product

A Few Weeding Techniques

1. Program Overall Cost

  • Catalogue the pro­grams your busi­ness pays for. A great place to start is your bank state­ments. Keeping in mind pay­ments for pro­grams can be car­ried out through dif­fer­ent av­enues and may be in var­i­ous sizes (e.g. monthly vs yearly sub­scrip­tions/​con­tracts).
  • List them out on a spread­sheet with the soft­ware pric­ing in the next col­umn.

2. Subscription Level

  • Most SaaS prod­ucts have dif­fer­ent of­fer­ings for dif­fer­ent sub­scrip­tion lev­els.
  • Next to the cost col­umn, note the sub­scrip­tion level on the same spread­sheet.

3. User Count and Cost

  • Typically, each sub­scrip­tion model has a cer­tain user count pay­ment fee, note what the cost is per user/​group per month/​year (top tip: also note if the pro­gram can have cer­tain users at one level and oth­ers at an­other — this could be very help­ful later).

4. Organisational Users

  • For each pro­gram, note down who has ac­counts, what level of per­mis­sions they hold and their last ac­tiv­ity date (usually found in set­tings).
  • Also, note (use in­dica­tive high­light­ing here too) whether or not that ac­count holder is still a mem­ber of the com­pany.

5. Program Audit

  • Next, add in a fea­tures list as per the sub­scrip­tion you are pay­ing for (i.e. if you are pay­ing for the en­try tier, there’s no need to list out the en­ter­prise-level of­fer­ings).
  • This one will take some time, but the best ad­vice here — use the pro­gram’s mar­ket­ing web­site’s pric­ing page and add any­thing else in if you need to. (top tip! If you start to pick up dou­ble-ups of fea­tures in this col­umn, high­light the du­pli­cate fea­tures so that you have one colour per re­peated fea­ture — this will make the next cou­ple of steps much eas­ier).
  • Also, note down if the pro­gram (at the sub­scrip­tion level you pay for) in­te­grates with other plat­forms you pay for.

6. Operational Use

  • Make an in­fer­ence to how much this pro­gram is used by the busi­ness on a per­cent­age scale: 0%: no use to 100%: can’t live with­out it. If you like con­di­tional for­mat­ting, use a colour scale on this col­umn to note where the biggest con­tri­bu­tions to your busi­ness lie.

A green horizontal quote that reads "weedy disruptions to environments have an inverse effect on growth". Dark green squiggles decorate the quote.

The Next Step: Assess!

1. Program Overall Cost

  • Note which pro­grams are cost­ing you the most and con­sider how this ties in with the per­cent­age of op­er­a­tional use? Are you pay­ing the most amount of money for a pro­gram you only use 5% of the time?

2. Subscription Level and Program Audit

  • Assess the fea­tures of­fered for the sub­scrip­tion you are pay­ing for and ask your­self, “do we need all of this?”
  • Also, eval­u­ate where the colours lie in the pro­gram list, can whole pro­gram func­tion­al­i­ties be cov­ered in an­other pro­gram that rates higher on your Operational Use scale?

3. User Count and Cost and Operational Users

  • How many peo­ple are ac­tively still us­ing the sys­tem? If the date of use is out­side a month (take the av­er­age of the cur­rent users), it would be safe to say that this pro­gram is­n’t used as widely as pre­vi­ously thought (and check your op­er­a­tional us­age per­cent­age again).

Final Considerations

Integrations - they’ve made a world of dif­fer­ence in de­lin­eat­ing the com­plex­ity of ecosys­tems in re­cent years. The ad­vice here is to note what kind of in­te­gra­tion it is. For ex­am­ple, a vi­sual in­te­gra­tion means that there might be a panel on each pro­gram that shows the sta­tus of the linked item be­tween the two. Whereas a data in­te­gra­tion could work so that when a piece of data is up­dated in one pro­gram, it is con­fig­ured to also up­date in an­other pro­gram. I would rec­om­mend un­der­stand­ing which in­te­gra­tions work best for the pro­grams you have, and the op­er­a­tions you are us­ing them for.

Once this as­sess­ment has been com­pleted you will have a pretty good idea of the level of com­plex­ity in your soft­ware ecosys­tem and can start to make de­ci­sions about the ne­ces­sity of each pro­gram. This task may take a while to com­plete, so I would rec­om­mend giv­ing your­self a cou­ple of weeks, if not a full month.

After the as­sess­ment and ac­tions have taken place, save your spread­sheet! It will be a great live doc­u­ment to add to if more pro­grams are added to your busi­ness’s soft­ware ecosys­tem in the fu­ture.

If mul­ti­tudes of in­di­vid­ual soft­ware so­lu­tions are get­ting you down you can al­ways con­sider in­vest­ing in a cus­tom soft­ware so­lu­tion. To get an idea of what the cost of cus­tom soft­ware for your busi­ness may be, you can read our handy guide here.

Discover Software


Alice Spies

KPI mo­ti­va­tor and res­i­dent head chef

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Cost Breakdown: Offshore Vs Onshore Software Development — What You Need to Know

Your vi­sion,

our ex­per­tise