Any software architects here?
Discussion
Hello, do we have any software architects here?
If you have created your own software as service, how do you track the costs of each customer implementation?
Do you enforce timesheets on your developers where they need to record time on the platform versus any specific implementation? Is that even sensible in an Agile world?
Any thoughts or real world experiences?
Thanks
If you have created your own software as service, how do you track the costs of each customer implementation?
Do you enforce timesheets on your developers where they need to record time on the platform versus any specific implementation? Is that even sensible in an Agile world?
Any thoughts or real world experiences?
Thanks
Well, I was lead architect on a massive SaaS product for many years.
You may have to clarify your question a bit... by "customer implementation" do you mean adding a Feature to your SaaS system driven by the whims of a single customer?
And by "costs", do you mean the build costs alone? Or more holistic? (i.e. costs of documentation, support, infrastructure, etc...)
You may have to clarify your question a bit... by "customer implementation" do you mean adding a Feature to your SaaS system driven by the whims of a single customer?
And by "costs", do you mean the build costs alone? Or more holistic? (i.e. costs of documentation, support, infrastructure, etc...)
Single tenancy (ie each customer has their own database) or multi-tenancy (database striped by customer)?
What are your charging metrics (or what metrics do you think you can charge by)? MB data storage? Transactions per month? Data transfer volume?
It would be unusual to charge customers for dev effort for SAAS, unless as mentioned, you are asking them to pay for a one-off enhancement they have requested. And then, in an SAAS environment, I would only do it if the enhancement were to be made available to all customers
What are your charging metrics (or what metrics do you think you can charge by)? MB data storage? Transactions per month? Data transfer volume?
It would be unusual to charge customers for dev effort for SAAS, unless as mentioned, you are asking them to pay for a one-off enhancement they have requested. And then, in an SAAS environment, I would only do it if the enhancement were to be made available to all customers
Edited by mikef on Tuesday 17th February 20:05
Thanks for the replies so far.
We have a SAAS architecture that separates the shared infrastructure layer and each customer instance deployed on top of it.
The business is finding it hard to record development time spent on shared infrastructure versus each customer implementation (some of these might be things like changing the colour of the UI or other customers what something more bespoke).
Software are saying, yes we have a ticket system but its hard to map those tickets to the timesheet system the whole company uses.
I want to measure cost of devops (maintaining the infrastructure) and cost of each deployment.
We have a SAAS architecture that separates the shared infrastructure layer and each customer instance deployed on top of it.
The business is finding it hard to record development time spent on shared infrastructure versus each customer implementation (some of these might be things like changing the colour of the UI or other customers what something more bespoke).
Software are saying, yes we have a ticket system but its hard to map those tickets to the timesheet system the whole company uses.
I want to measure cost of devops (maintaining the infrastructure) and cost of each deployment.
I've tried to do similar in the past, and attempted to assign effort/ownership to each and every ticket. It was doomed to failure as tickets often had multiple workers, had periods of inactivity, could often be attributed to multiple requirements and be part of larger deployments. I tried to do this for about 3 months, but the list of caveats for each piece of work became totally unwieldy and it was clear that what looked like accurate metrics were mostly b
ks.
i.e. a single ticket "change the button colour to pink" would involve multiple different people to design/implement/QA/deploy with gaps in handover between workers. Therefore you coudn't just say 2days of dev time @£500/day = £1k.
The reality was 2 hours of UI design, 3 hours of impact assessment by Solution Architect, 20 minutes of dev to change colour, 2 hours of dev time to update automated testing pipeline, 5 minutes as part of deploymenent checks for a larger releases, plus compute time, licensing costs etc etc.
And that is assuming that tickets are updated properly....
In the end, I used to calculate the total costs (people, computing costs, licensing etc) for a typical 2 week sprint, and then talk to the Product Owner/Team leads to estimate each epic/ticket as part of the sprint release. i.e. "change button colour to pink" was 5% of our work this sprint, therefore it cost ~£1k to implement.
tl;dr Don't over metric the work, just ask the experts to estimate the effort they spent after the fact.
ks.i.e. a single ticket "change the button colour to pink" would involve multiple different people to design/implement/QA/deploy with gaps in handover between workers. Therefore you coudn't just say 2days of dev time @£500/day = £1k.
The reality was 2 hours of UI design, 3 hours of impact assessment by Solution Architect, 20 minutes of dev to change colour, 2 hours of dev time to update automated testing pipeline, 5 minutes as part of deploymenent checks for a larger releases, plus compute time, licensing costs etc etc.
And that is assuming that tickets are updated properly....
In the end, I used to calculate the total costs (people, computing costs, licensing etc) for a typical 2 week sprint, and then talk to the Product Owner/Team leads to estimate each epic/ticket as part of the sprint release. i.e. "change button colour to pink" was 5% of our work this sprint, therefore it cost ~£1k to implement.
tl;dr Don't over metric the work, just ask the experts to estimate the effort they spent after the fact.
We've done the "put the booking code on every ticket" thing before, mainly because we got bombarded with a whole bunch of booking codes and no-one was quite sure what to book to.
It works and we didn't have the problem of multiple people on a ticket as above because the tickets were ore granular - there would be an epic and then tasks under that for design / implement / release etc.
It was, however time consuming to ensure all tickets and a booking code.
My other thought is to do it at the point at which the work is accepted, if your PO accepts the request, a ticket gets created I presume someone estimates it - can you just "book" that estimate to the customer and therefore you have some idea of what time you're spending on customer work vs core (shared) ? Or even do it after a sprint ends based on actual time spent (assuming its recorded on the ticket).
It works and we didn't have the problem of multiple people on a ticket as above because the tickets were ore granular - there would be an epic and then tasks under that for design / implement / release etc.
It was, however time consuming to ensure all tickets and a booking code.
My other thought is to do it at the point at which the work is accepted, if your PO accepts the request, a ticket gets created I presume someone estimates it - can you just "book" that estimate to the customer and therefore you have some idea of what time you're spending on customer work vs core (shared) ? Or even do it after a sprint ends based on actual time spent (assuming its recorded on the ticket).
Edited by Crafty_ on Wednesday 18th February 10:18
tangerine_sedge said:
tl;dr Don't over metric the work, just ask the experts to estimate the effort they spent after the fact.
This is my approach as well. The tech lead / manager should be able to provide an estimate to 1/2 a day accuracy that should be good enough for all purposes. The one thing I'd add is that trying to over-measure the actual time spent is a sure fire way to pi**ing off the dev team. In my experience, no-one likes timesheets and they don't actually give you the correct data anyway.
If the business is so tight as to be needing per hour spent time on a bug/issue, then this solution is almost certainly fixing the wrong problem...
I'm questioning why you want/need to cost the effort of DevOps and coding per customer in an SAAS environment
What you charge each customer is more of a commercial consideration than a technical one
If you really wanted to keep each customer distinct, you might have architected the stack differently in the first place - but probably I wouldn't. I would recommend focussing on the pricing metrics, more than cost
What you charge each customer is more of a commercial consideration than a technical one
If you really wanted to keep each customer distinct, you might have architected the stack differently in the first place - but probably I wouldn't. I would recommend focussing on the pricing metrics, more than cost
Edited by mikef on Wednesday 18th February 14:37
mikef said:
I'm questioning why you want/need to cost the effort of DevOps and coding per customer in an SAAS environment
What you charge each customer is more of a commercial consideration than a technical one
If you really wanted to keep each customer distinct, you might have architected the stack differently in the first place - but probably I wouldn't. I would recommend focussing on the pricing metrics, more than cost
Its coming from the CFO, we know what the revenues are from each customer, but how much did it cost to deliver each service to them?What you charge each customer is more of a commercial consideration than a technical one
If you really wanted to keep each customer distinct, you might have architected the stack differently in the first place - but probably I wouldn't. I would recommend focussing on the pricing metrics, more than cost
Edited by mikef on Wednesday 18th February 14:37
Are we underwater with some contract implementations, hidden by the margins of other customers?
the-photographer said:
some of these might be things like changing the colour of the UI or other customers what something more bespoke)
Software are saying, yes we have a ticket system but its hard to map those tickets to the timesheet system the whole company uses.
I want to measure cost of devops (maintaining the infrastructure) and cost of each deployment.
Where’s your Product Manager in all this?Software are saying, yes we have a ticket system but its hard to map those tickets to the timesheet system the whole company uses.
I want to measure cost of devops (maintaining the infrastructure) and cost of each deployment.
If you’re getting requests for basic stuff like UI colour changes then this should, perhaps, end up as a config option.
Similarly, “bespoke” requests in SaaS shouldn’t always be implemented on a single customer basis. If it’s useful functionality the PM should be considering where it goes on the roadmap.
Too much bespoke work, and the maintenance overhead it introduces, can sink a team in the end…
The colour one we did on an SAAS product - colours, logos, bespoke images
That was about 10 years ago and we used LessCSS, there will be better approaches now. It took a day to change the look and feel for a new customer and we could charge them each a fortune
All these things need to be architected in from day one (just like internationalisation, accessibility, multi-tenancy, etc, etc). Any attempt to layer them on afterwards ("lipstick on a pig") is painful
That was about 10 years ago and we used LessCSS, there will be better approaches now. It took a day to change the look and feel for a new customer and we could charge them each a fortune
All these things need to be architected in from day one (just like internationalisation, accessibility, multi-tenancy, etc, etc). Any attempt to layer them on afterwards ("lipstick on a pig") is painful
mikef said:
Well, you could tell your DevOps crew that they have to fill in detailed timesheets because their CFO doesn't understand SAAS
See how long they stick around. My lot wouldn't have
Correct, this is why I asked how other people do here, enforcing timesheets would fix one thing but the bubble would just expand in a different area.See how long they stick around
. My lot wouldn't haveLooneyTunes said:
the-photographer said:
some of these might be things like changing the colour of the UI or other customers what something more bespoke)
Software are saying, yes we have a ticket system but its hard to map those tickets to the timesheet system the whole company uses.
I want to measure cost of devops (maintaining the infrastructure) and cost of each deployment.
Where s your Product Manager in all this?Software are saying, yes we have a ticket system but its hard to map those tickets to the timesheet system the whole company uses.
I want to measure cost of devops (maintaining the infrastructure) and cost of each deployment.
If you re getting requests for basic stuff like UI colour changes then this should, perhaps, end up as a config option.
Similarly, bespoke requests in SaaS shouldn t always be implemented on a single customer basis. If it s useful functionality the PM should be considering where it goes on the roadmap.
Too much bespoke work, and the maintenance overhead it introduces, can sink a team in the end
I agree basic config features should be costed to the shared platform, but the service can be customised beyond the typical web SAAS platform into the realms of the customer have their own database.
Sounds like time for a PM who understands the job!
If there is genuine opportunity for feature development on a bespoke / per customer basis then great, but you’d hope that a PM was thinking more holistically than that and considering broader applicability/integration into the core product.
From a commercial perspective, some customers love bespoke. Some businesses love giving it to them. Neither group necessarily sees the dark places that it can take them to… it can become a nightmare maintaining bespoke stuff, especially if the customer it has been developed for works in an atypical way and won’t adapt their own processes in order to allow broader deployment.
If there is genuine opportunity for feature development on a bespoke / per customer basis then great, but you’d hope that a PM was thinking more holistically than that and considering broader applicability/integration into the core product.
From a commercial perspective, some customers love bespoke. Some businesses love giving it to them. Neither group necessarily sees the dark places that it can take them to… it can become a nightmare maintaining bespoke stuff, especially if the customer it has been developed for works in an atypical way and won’t adapt their own processes in order to allow broader deployment.
This
The biggest cost to many legacy application providers (and I worked for many years for one of the world's biggest in California) is having to support customers on old platform versions and the biggest reason that they are stuck on old platforms is that some commission-driven idiot agreed to provide customisation at a cost, but those customisations never get updated to recent versions of the platform
The biggest cost to many legacy application providers (and I worked for many years for one of the world's biggest in California) is having to support customers on old platform versions and the biggest reason that they are stuck on old platforms is that some commission-driven idiot agreed to provide customisation at a cost, but those customisations never get updated to recent versions of the platform
Product Manager and product roadmap is the route I would go. Allow customers to raise enhancement requests, ideally on a website, allow other customers to vote (limit votes per month by some metric) and then queue the development, QA and release accordingly. All customers get the new functionality and you manage one stack of development and core software release. It makes managing the code base straightforward and provides your customers with a visible roadmap. It also means as you grow the user base you're not having to grow the team, as you still have a single product to manage.
The alternative is to implement a time based billing / finance system and have the developers record their time to a matter for all dev, QA, release, issues management et al. You're then managing multiple code bases and have to either QA any core product changes against all the customisations or get your clients to do it before they upgrade to the latest software...this becomes either a cost to you or the client. In my experience this creates dissatisfaction across the board and means as you grow the user base, you also grow the PS team to manage this element of the SDLC.
I'm on a break at the moment and start a new role in June, so feel free to DM me if you'd like to discuss further. Thanks.
The alternative is to implement a time based billing / finance system and have the developers record their time to a matter for all dev, QA, release, issues management et al. You're then managing multiple code bases and have to either QA any core product changes against all the customisations or get your clients to do it before they upgrade to the latest software...this becomes either a cost to you or the client. In my experience this creates dissatisfaction across the board and means as you grow the user base, you also grow the PS team to manage this element of the SDLC.
I'm on a break at the moment and start a new role in June, so feel free to DM me if you'd like to discuss further. Thanks.
LooneyTunes said:
Sounds like time for a PM who understands the job!
If there is genuine opportunity for feature development on a bespoke / per customer basis then great, but you d hope that a PM was thinking more holistically than that and considering broader applicability/integration into the core product.
From a commercial perspective, some customers love bespoke. Some businesses love giving it to them. Neither group necessarily sees the dark places that it can take them to it can become a nightmare maintaining bespoke stuff, especially if the customer it has been developed for works in an atypical way and won t adapt their own processes in order to allow broader deployment.
Agreed, the PM is acting like a business development director, product director, head of strategy and more.If there is genuine opportunity for feature development on a bespoke / per customer basis then great, but you d hope that a PM was thinking more holistically than that and considering broader applicability/integration into the core product.
From a commercial perspective, some customers love bespoke. Some businesses love giving it to them. Neither group necessarily sees the dark places that it can take them to it can become a nightmare maintaining bespoke stuff, especially if the customer it has been developed for works in an atypical way and won t adapt their own processes in order to allow broader deployment.
I am suspecting the service, originally built for one customer has morphed into a monster, CFO has said give me the info to sort it out.
AndyTR said:
Product Manager and product roadmap is the route I would go. Allow customers to raise enhancement requests, ideally on a website, allow other customers to vote (limit votes per month by some metric) and then queue the development, QA and release accordingly. All customers get the new functionality and you manage one stack of development and core software release. It makes managing the code base straightforward and provides your customers with a visible roadmap. It also means as you grow the user base you're not having to grow the team, as you still have a single product to manage.
The alternative is to implement a time based billing / finance system and have the developers record their time to a matter for all dev, QA, release, issues management et al. You're then managing multiple code bases and have to either QA any core product changes against all the customisations or get your clients to do it before they upgrade to the latest software...this becomes either a cost to you or the client. In my experience this creates dissatisfaction across the board and means as you grow the user base, you also grow the PS team to manage this element of the SDLC.
I'm on a break at the moment and start a new role in June, so feel free to DM me if you'd like to discuss further. Thanks.
Thank you, will message in the morning. The time based billing / finance system is the nuclear option, something I don't want to recommend (yet)The alternative is to implement a time based billing / finance system and have the developers record their time to a matter for all dev, QA, release, issues management et al. You're then managing multiple code bases and have to either QA any core product changes against all the customisations or get your clients to do it before they upgrade to the latest software...this becomes either a cost to you or the client. In my experience this creates dissatisfaction across the board and means as you grow the user base, you also grow the PS team to manage this element of the SDLC.
I'm on a break at the moment and start a new role in June, so feel free to DM me if you'd like to discuss further. Thanks.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff